Category: Computing

Switching from DSL to Cable

I’ve been on DSL forever. I started out on Bell, have been on NCF, and most recently TekSavvy. I’ve had my trials and tribulations with DSL, and have a collection of DSL modems (some are backup, some are bad, some were sensitive to line conditions).

Cable has always been a faster alternative, but it meant I needed to pay a cable install fee and switch technology in general. Also, a static IP wasn’t possible on cable – and having self hosted lowtek.ca for a long time, I’ve always felt a bit trapped to DSL to give me a static IP.

DSL can be fast, but not in my area which seems to have been left behind for faster connectivity. The highest speed I could get was 15 down, 1 up. Now, 15 down is great – I can stream HD Netflix without any real problems. The internet feels fast enough.

I have to say, I really appreciate that Google has built a good enough speed test that is easy to use.

One motivating factor was my desire to stop paying Bell for my land line. It’s nearly $50 a month and we barely use it. Sure I could switch to a VOIP provider but then I still have to pay for the dryloop cost and it sounded like I’d probably experience a service outage (of up to 5 days) when the line switched.

Moving to cable means losing the static IP. It also means that outgoing port 25 is going to be blocked and this means my self hosted email server will have problems.

I’ve sketched out a solution for static IP hosting. I’ll try to write that up in the future once I’ve done it. For now, because on cable your IP rarely changes – I’m just pretending that the IP I have is a static IP.

For sending email, I needed to route all my mail via Teksavvy, treating them as a smarthost. My email setup is postfix, thus there is literally a one line setup change to /etc/postfix/main.cf

This works because TekSavvy allows anonymous SMTP to this from inside of the network they control. What it does is force all outgoing email to be sent to their server, which in turn will send it out.

Now modern email servers do additional trust checks, one of these is Sender Policy Framework (SPF). Configuring your SPF is done via a TXT record in your DNS. While the relayhost was working, I was seeing a warning when checking email sent to gmail (but other email providers check SPF too).

It took a while for me to figure out how to get my SPF record setup correctly. I got a bit lucky, as I was reading https://support.google.com/a/answer/33786?hl=en which pointed at _spf.google.com as the Google SPF record holder. It turns out TekSavvy adopted the same naming: _spf.teksavvy.com. Your SPF record needs to point at other SPF records, so finding this meant it was an easy change to my DNS TXT record for SPF.

I will point at MXToolBox as a great web based tool for sorting out all sorts of email issues.

Now email was not only working via the smarthost, but my SPF record was setup correctly. I’m still experiencing delays when sending to gmail, but not apparently to other sites. From looking at the headers, it seems TekSavvy can at times (often) delay delivery to gmail. This is frustrating, but there are other paths to solution if it’s a big problem.

Now that email was sorted out, switching to cable was really easy. The cable box arrived and was “installed” by finding the live cable in my basement by the power panel and plugging the box in. It turns out that since the cable comes from a box at the end of my lawn and the buried cable to my house (which is 20yrs or more old) is in good shape, I get fantastic signal strength. The tech had to install an attenuator to reduce the signal to the happy range where the modem was going to work well.

Switching from DSL with static IP to Cable with rarely changing IP was a simple matter of swapping the WAN cable into my router from one box to the other. I had to reconfigure my router to use “Automatic” from “PPPoE”, and boom I was on the internet again. Visiting https://www.whatismyip.com/ and I had the new IP address, followed by a simple DNS change to use that as the address for lowtek.ca and I’m back.

At this point all I’ve lost is the reverse DNS check is failing, because the IP that lowtek.ca resolves to – does not answer lowtek.ca when you look up that IP. This is more important for sending email than receiving, and since I’m sending via Teksavvy it doesn’t matter as much. I still want a more ‘proper’ static IP to be assigned to lowtek.ca – more on that in a future post.

Boom – cable is just faster than DSL. With the added bonus that changing speeds is zero admin costs. If I want to move to 2x faster, it’s another $7 a month. On DSL I was at the fastest speed available to me at my location. Cable is costing me about $14 more a month, but the phone line savings will make up for that – once I get past the hump of buying a new cable modem and VOIP ATA box.

 

Server Upgrade Part 5: rsyslog

Now that mail is running in a container, logwatch is a lot less interesting because log data is not visible on the host (the container has the logs). One option is to map the log files from the container into the host logs, but this might get messy. It seems like a better idea to build out an rsyslog setup to flow logs from the container into the host.

To start with I needed to understand rsyslog a bit better. Then I came across a post that does pretty much what I’m trying to accomplish, docker containers sending logs to the host with rsyslog.

Before we configure the container, we need to get our host machine accepting rsyslog input. We’ll need to turn on one of TCP or UDP remote access on the host. I’ll stick with just TCP for my initial setup.

Edit /etc/rsyslog.conf, you’ll find a comment near the top about TCP reception, uncomment the pair of lines below it

and then restart the service to pick up the new config

I’m using a firewall on the host so I’ll also have to open up the firewall so that things can see this new port. When we do firewall stuff, we should always pause and think about the security implications here.

In my case, the machine that has the port open will be behind my router, which also runs a firewall. So while we’re punching a hole in the firewall, we actually have another firewall protecting us from the big bad internet.

At this point our host machine has rsyslog running and waiting for traffic. Now let’s take a look at the mail server container and change it to flow logs to the host rsyslog.

It turns out the client is really easy, but you do have to be aware of UDP or TCP.  Inside the container – we modify our Dockerfile to create an /etc/rsyslog.d/10-rsyslog.conf file that looks like:

If you are using TCP, use both @@ – for UDP just a single @. You also need to use the actual hostname of the host machine (the one we configured with rsyslog just above). We need rebuild and restart the container to activate the rsyslog configuration.

Back on the host, we see data showing up with the container hostname in the logs. If we look on the host machine in /var/log/syslog we see rsyslogd startup from the mail container:

 

There are plenty of other log messages related to the mail container start up as well.

We could manually emit some log messages from the client inside the container, by shelling into the container and running logger.

and in /var/log/syslog on the host we see..

Logwatch should be a lot more interesting

Server Upgrade Part 4: systemd and docker containers

I’ve set the BIOS on the new server to resume running after a power failure. The OS happily comes back no problem, and docker even starts up – but none of the containers.

Apparently in docker 1.2 there is now support to restart your containers after boot, this sounds useful, but the version of docker in Ubuntu 16.04 is 1.12.1, close but not quite recent enough.

No worries, we can use systemd to sort this out. The docker documentation has some examples, but I found an article which takes a slightly different approach – one they claim is more aligned to CoreOS.

Adding our own services to systemd is simply a matter of adding a file to /etc/systemd/system/. The very first one I want to add is one to host my own registry. Now you probably don’t want to host your own registry since you could simply use the public dockerhub, or any number of other solutions. However, I’m also the type of person who hosts their own email, so of course I’m going to host my own registry.

The %n in the file is replaced with the ‘full unit name’. If we save this file as /etc/systemd/system/docker-registry.service the unit name should be docker-registry.

In a simple configuration, the local docker registry will persist data as a docker volume. I decided it was safer to map to a local file tree.

Once you’ve created the file /etc/systemd/system/docker-registry.service we need to reload the systemd daemon and start the service.

If all has gone well, docker ps should show us the new running registry (it does). Now let’s make it start every boot.

And yup, a reboot and we see the registry has started. So now we have a local registry to store our containers in, and a pattern to apply to make them services that start even after a reboot (expected or unexpected).

Pushing images to a local registry is covered in the documentation. I might later want to add a certificate to the registry, but it is not required.