19 Jun 2013, 10:14

Installing Squid, Sick-Beard, Deluge, and an always-on VPN (IPVanish) on Archlinux for an automated seed box

I recently signed up for VPN service through IP Vanish (well, several providers, but that’s the one that stuck). While I like their client software, I was mildly annoyed with having to start and stop the thing when I wanted to run traffic through it, and with having it run ALL my traffic when that’s not necessarily what I wanted.

My solution was to spin up an Archlinux Hyper-V virtual machine on Windows Server 2012 server, and configure it to be a Squid caching proxy and VPN. Then I just pointed the applications that I wanted at it and let it proxy my traffic through the VPN. I went one step further by abandoning uTorrent and installing Deluge and BrickyBox’s Sick-Beard clone for torrent management and saving data to my Drobo-FS.

Note: I have removed all of the comments from these configuration files since most of them were in the default files to begin so you can still really read them if you want, and aren’t relevant to the configurations themselves. I encourage you to understand what these files are actually doing, not just pasting them in to your configs.

Configuring PPP for the IPVanish VPN


pacman -S pptpd



# Secrets for authentication using CHAP

Obviously, replace YOUR_USER_NAME, SERVER_ALIAS, and PASSWORD with your specific information. For BIND_IPS, I used an asterisk to bind to all ip addresses. You can be more specific here if you’d like.


maxfail 0
pty "pptp sea-a01.ipvanish.com --nolaunchpppd"
remotename SERVER_ALIAS
file /etc/ppp/options.pptp

Again, change YOUR_USER_NAME to reflect your IP Vanish username, make sure that SERVER_ALIAS matches what you put in chap-secrets, and use the server that you want to connect to for the pty parameter.



Enable traffic routing

Now that we have a functioning VPN, we want to route all of our traffic through it. Be sure to chmod +x both of these.


if [ "${CONNECTION}" = "" ]; then CONNECTION=${PPP_IPPARAM}; fi
if [ "${TUNNEL}" = "" ]; then TUNNEL=${PPP_IFACE}; fi
if [ "${CONNECTION}" = "ipvanish" ] ; then
 ip route del ${SERVER} dev ${TUNNEL}
 if [ "${GATEWAY}" = "" ] ; then
   ip route add -host ${SERVER} dev ${PRIMARY}
   ip route add -host ${SERVER} gw ${GATEWAY} dev ${PRIMARY}
 ip route del default ${PRIMARY}
 ip route add default dev ${TUNNEL}


if [ "${CONNECTION}" = "" ]; then CONNECTION=${PPP_IPPARAM}; fi
if [ "${TUNNEL}" = "" ]; then TUNNEL=${PPP_IFACE}; fi
if [ "${CONNECTION}" = "ivanish" ] ; then
 # direct packets back to the original interface
 ip route del default ${TUNNEL}
 ip route del ${SERVER} dev eth0
 if [ "${GATEWAY}" = "" ] ; then
   ip route add default dev ${PRIMARY}
   ip route add default gw ${GATEWAY} dev ${PRIMARY}

Creating a custom systemctl unit

To help facilitate automation, I create a custom systemctl unit for the VPN so I wouldn’t have to manually start and stop it all the time.


Description=IPVanish Proxy

ExecStart=/usr/bin/pon ipvanish
ExecStop=/usr/bin/poff ipvanish


After you create the unit, you can start and stop the proxy with systemctl start ipvanish and systemctl stop ipvanish respectively. You can also make it start at boot with systemctl enable ipvanish.

Installing Squid


pacman -S squid


The Squid package will automatically create a proxy user for you, as well as the necessary systemd units. The only changes that are necessary are in the /etc/squid/squid.conf file. A lot of those changes are going to be predicated on your caching needs. I’m not going to go in to too much detail here, and just show the two lines that you need in your squid config to make this work. The rest of the stuff for actually storing objects and ACLs and the like, I’ll leave as an exercise to the reader.


tcp_outgoing_address # This is the IP of your VPN
http_port # This is the IP of your machine

Mounting network shares


pacman -S smbclient autofs

I am mounting my network shares with AutoFS so they’ll come up as soon as someone (deluged) tries to use them. This will mount the one share specified in my auto.media file as /mnt/MOUNT_NAME. Be sure to change NAS_IP, NAS_PATH, and MOUNT_NAME to reflect your setup. In the credentials file, set your USERNAME and PASSWORD for the user that you’ll be connecting to the NAS as. The dir_mode and file_mode directives are the UMASK for the mount points. Mine are set to 777 so that everybody has write access to them, specifically the deluged user.


/mnt /etc/autofs/auto.media


MOUNT_NAME -fstype=cifs,file_mode=0777,dir_mode=0777,credentials=/etc/samba/credentials,workgroup=WORKGROUP ://NAS_IP/NAS_PATH



Installing Deluge


pacman -S deluge python-mako

This was incredibly trivial. Just install the packages from the Arch repository. I did some light configuration through the web-ui to point deluged at my mounted NAS shares, and I was off to the races.

26 Jan 2013, 22:17

Adding custom units/services to systemd on Arch Linux


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:


Description=sdbarker.com Chiliproject
Requires=mysqld.service nginx.service
Wants=mysqld.service nginx.service

ExecStart=/usr/bin/bundle exec /usr/bin/unicorn_rails -E production -c config/unicorn.rb



Description=Git daemon

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


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.

09 Jul 2012, 14:39

Git credential caching on Windows


Update: This is no longer necessary, check out the update here.

In my last post (PRO-TIP: Recursively updating all git repositories in a directory) I made mention of using Git’s new credential caching to improve your Git experience.

A couple things of note:

  • The API for credential management in Git is fairly newish (as of 1.7.9) so you’ll a fairly newish Git to make use of it.

  • This doesn’t work for Windows systems as git-credential-cache communicates through a Unix socket. Windows users can find joy here at https://github.com/anurse/git-credential-winstore (specifically for the download the joy is located at https://github.com/anurse/git-credential-winstore/downloads). Just make sure that the binary is in your path (which is likely C:\Program Files (x86)\Git\libexec\git-core if you’ve installed msysgit and didn’t mess with the defaults). The integration is with Windows Credential Manager which you can pull up via the Windows Control Panel.

Once you’ve got it installed, from a command prompt:

git config --global credential.helper winstore

Or you can edit your .gitconfig manually:

     helper = winstore