So a friend of mine noticed my previous post about updating all of my VPN configuration and asked the question, “Why did you decide to go with HideMyAss when they keep logs?” I had a couple of reasons, the primary was that they weren’t the provider that I was using before, and secondarily because I didn’t really care that much.

The more that I thought about it, the more that I decided that I did care that much. To that end, I’ve taken his non-direct advise and switched providers yet again. This time, I’ve gone with PrivateInternetAccess.com, who according to their privacy policy, don’t collect any logs.

Due to the changes that I outlined in my previously mentioned post, switching providers was very, very trivial. I only needed to add a new peer, which I symlink‘ed to vpn, updated my chap-secrets with the relevant information, and I had a small change my ip-up.d and ip-down.d scripts that were responsible for my iptables rules to route all of my traffic through the ppp0 interface, as well as my fastest_ip.py script to find the fastest route.

I know I can still improve on this process, but for now, done and done.

So, it’s been a little bit over half a year since I published the article about how to set up an always-on seed-box/VPN using Squid, Sick-Beard, and Deluge. A little bit has changed since then.

First, I no longer use IPVanish. I had an issue with them where they double charged me for a month, and gave me a little bit of a run-around trying to resolve it. Specifically, after contacting their support, they told me that only one of the transactions was successful, the other failed. My PayPal account and my financial institute disagreed. Then they told me I’d have to take it up with PayPal. I took this as a sign that it was time to switch providers. To their (mild) credit, after pressing them for more information, they just went ahead and reversed the charge. Unfortunately for them (not that they probably care that much), I had already switched providers. I now use HideMyAss Pro VPN (disclosure: that’s an affiliate link).

In addition to having switched to HideMyAss Pro VPN, I’ve updated the infrastructure in a couple of different ways to be a bit easier to work with and a bit more flexible.

First, there’s no longer a ipvanish config file, since that’s been replaced with a hidemyass file. But that’s been symlinked to vpn via ln -s hidemyass vpn. That file, just as with the previous one for ipvanish contains the necessary config bits to connect to HideMyAss. The options.pptp file isn’t referenced, so I just left that alone and it’s ignored. I updated chap-secrets to contain the credentials that I use for HideMyAss. Of note, HideMyAss uses a different password for PPTP and L2P connections than your normal password. Find that in your dashboard.

The ipvanish.service unit for systemctl has been renamed to vpn.service so that it’ll stand up semantically to provider changes. It’s also been updated to remove any ipvanish references in favor of the more generic term vpn. It’s also not directly calling pon anymore to turn the VPN on and off. I created a couple of scripts to manage this for me.

The togglevpn.sh script is what’s called by the systemctl unit vpn.service. It just passes on or off just as were passed directly to pon. That script first calls update_vpn_to_fastest_ip.sh which calls fastest_ip.py to retrieve the IP of the fastest VPN node that’s near me (this is just a local-ish subset of the IPs that HideMyAss provides), and updates the /opt/ppp/peers/vpn link (which points to /opt/ppp/peers/hidemyass) to use that IP. After that, pon is called to turn the VPN on. Finally, Squid is updated with update_squid_outgoing_ip_to_interface.sh and then restarted.

/opt/togglevpn.sh:

#!/bin/sh
case "$1" in
on)
        echo "Finding fastest IP..."
        /opt/update_vpn_to_fastest_ip.sh
        sleep 2s
        echo "Turning VPN on..."
        /usr/bin/pon vpn
        sleep 2s
        /opt/update_squid_outgoing_ip_to_interface.sh ppp0
        sleep 2s
;;

off)
        echo "Turning proxy off..."
        /usr/bin/poff vpn
        sleep 2s
        /opt/update_squid_outgoing_ip_to_interface.sh eth0
        sleep 2s
;;

restart)
        $0 off
        $0 on
;;
esac

systemctl restart squid

/opt/fastest_ip.py:

#!/usr/bin/python2.7
# Finds the fastest Seattle IP for HMA

import sys
import re
from subprocess import Popen, PIPE
from threading import Thread

ips = [
        "173.208.32.98",
        "216.6.236.34",
        "108.62.61.26",
        "216.6.228.42",
        "173.208.32.66",
        "173.208.32.74",
        "208.43.175.43",
        "70.32.34.90",
        "108.62.62.18",
        "173.208.33.66",
        "23.19.35.2"
]

fastest_ip = ""
lowest_ping = 100
for ip in ips:
        p = Popen(['/usr/bin/ping', '-c 1 ', ip], stdout=PIPE)
        time = str(p.stdout.read())
        m = re.search("time=([0-9.]+) ms", time)
        if m:
                ms = float(m.group(1))
                if ms < lowest_ping:
                        lowest_ping = ms
                        fastest_ip = ip
                #print("%s is alive.  round trip time: %f ms" % (ip, ms))

#print("Fastest ip is %s at %s" % (fastest_ip, lowest_ping))
print(fastest_ip)

/opt/update_vpn_to_fastest_ip.sh:

#!/bin/bash
ipaddy=`/opt/fastest_ip.py`

echo "Updating VPN to $ipaddy..."
sed -i -e "s/^pty.*/pty \"pptp $ipaddy --nolaunchpppd\"/g" /etc/ppp/peers/vpn</pre>

/opt/update_squid_outgoing_ip_to_interface:

#!/bin/bash
case "$1" in

ppp0)
        ipaddy=`ip addr | grep ppp0 | grep inet | cut -d' ' -f6`
;;

eth0)
        ipaddy=`ip addr | grep eth0 | grep inet | cut -d' ' -f6 | sed 's/\/24//g'`
;;

esac

echo "Updating squid to $ipaddy..."
sed -i -e "s/^tcp_outgoing_address.*/tcp_outgoing_address $ipaddy/g" /etc/squid/squid.conf</pre>

All in all this works rather well for me. I have occasional issues with ppp0 dropping out. I’m not sure if this is my problem or theirs, but I just log in and systemctl restart vpn and I’m back to the races. I’ve considering setting up a cron job to do this for me every hour or so, but it’s not been that much of a problem.

I recently migrated my Arch Linux VMs from sysvinit to systemd as the newer Arch install media are all using systemd and support for sysvinit is discontinued. The migration itself was an incredibly trivial and straight-forward process. I had only one hang up with the migration in general; every time I’d reboot the machine, eth0 wouldn’t come back up. That was fixed with a simple systemctl enable dhcpcd@eth0.

After I had the migration complete, sshd (and everything else) enabled, and eth0 finally coming up, I had two services (or as systemd refers to them, units) that I needed to configure; Chiliproject and git-daemon. Adding these custom units to systemd was incredibly easy.

Your custom service files live in /etc/systemd/system and end with the extension .service. Here the contents of the two that I created:

sdbarker.com-chiliproject.service:

[Unit]
Description=sdbarker.com Chiliproject
Requires=mysqld.service nginx.service
Wants=mysqld.service nginx.service

[Service]
User=www-data
WorkingDirectory=/path/to/chiliproject/install
ExecStart=/usr/bin/bundle exec /usr/bin/unicorn_rails -E production -c config/unicorn.rb
PIDFile=/path/to/chiliproject/install/tmp/pids/server.pid

[Install]
WantedBy=multi-user.target

git-daemon.service:

[Unit]
Description=Git daemon

[Service]
Type=forking
User=git
WorkingDirectory=/path/to/git/home
ExecStart=/usr/lib/git-core/git-daemon --pid-file=/path/to/git/home/temp/pids/git-daemon.pid --detach --syslog --verbose --base-path=/path/to/git/home/repositories
PIDFile=/path/to/git/home/pids/git-daemon.pid

[Install]
WantedBy=multi-user.target

Overall, it was an incredibly easy migration, and my startup time (however rare) is greatly reduced, service management is much, much easier, journalctl for viewing logs is very convenient, and removing all of the boilerplate initscript code that was always a pain in the ass and honestly always a bit flakey was very welcome.

I noticed the other day that my Archlinux logs were all zero bytes. Empty logs don’t do much good, so I spent a while trolling around the internets and had a difficult time finding anything valuable.

I did find one valuable thing in my boot log at /var/log/boot:

Starting Syslog-NG [BUSY] Error binding socket; addr='AF_UNIX(/run/systemd/journal/syslog)', error='No such file or directory (2)'

Which was enough to lead me to this post, https://bbs.archlinux.org/viewtopic.php?id=151132 (which had an unrelated title). The solutioon is to update /etc/syslog-ng/syslog-ng.conf and change the line that sets unix-dgram to read unix-dgram("/dev/log");, and then restart (or start, since it probably never started in the first place) syslog-ng with rc.d start syslog-ng. If you log out and log back in after that, you should see at the very least auth.log will have content.

Of note, I also had a permissions problem with a lot of the log files, so I had to do a quick chmod --recursive g+w /var/log/* to give the log group permissions to write to the logs.