OpenVPN only for Transmission data, and associated modifications

[Nezil]

I have wanted to move functions away from my ageing Mac mini OS X server onto unRAID for some time, and finally found time to get around to doing it all.

 

One of the major features that I wanted, was to have all BitTorrent traffic routed over a  OpenVPN link, disconnecting if the VPN tunnel went down, and have the rest of the unRAID server functions continue as though the VPN link were never up. If the VPN link should go down, BitTorrent traffic would simply stop, until the VPN link was restored, which it should do automatically.

 

Initially I didn't think that this would be a complicated problem to solve, but it ended up requiring a custom Transmission build, as well as a custom Kernel build to support the routing necessary for only BitTorrent traffic to use the VPN.

 

In this thread, I'll provide links to each of the plugins (and kernel) that I've used, and talk about any changes that I made. I'm going to be talking about:

• Transmission Plugin, including patched version with 'bind-interface-device' support
  
• OpenVPN Plugin, including routing table settings for Private Internet Access
  
• Custom Kernel, with support for policy routing enabled
  

I personally like to fully understand the plugins that I'm installing, and also like to make them as transparent as possible with comments indicating what's going on. I therefore re-wrote most of the plugins I'm using here, simplifying them greatly. I'd like to point out that I didn't find anything wrong with the original plugins, but just wanted something more simple. I also need to credit the original authors of the plugins on which mine are based, and have done so in the comments at the top of each of my versions.

 

It's no secret also, that there is a package version issue that exists with different plugins calling for different versions of the same package. I ran into issues with OpenSSL in particular, and therefore updated all of the plugins that I'm using to the latest (Heartbleed fixed) version. Updated versions of these plugins can be found in my signature below.

 

For clarity, I've named my plugins in the standard way with a version number and my initials at the end of the filename e.g. '*-3nr.plg' for a third version.

[Nezil]

Transmission Plugin

 

Transmission, by default, offers a setting to bind to a specific IP address (both IPv4 and IPv6 appear to be supported), and this can be used to bind to the IP address of the VPN tunnel (assuming the appropriate routing tables are set up). While I was researching this feature however, I discovered a patch for a very recent version of Transmission that includes a setting to bind to an interface rather than an IP address. Details of this patch can be found here: https://trac.transmissionbt.com/ticket/2313.

 

Since the local IP address of your VPN tunnel usually changes each time your VPN tunnel is established, it would be necessary for the settings.json file to be updated every connection, as well as Transmission itself restarted for the changes to take effect. Binding to the tunnel avoids the need for any scripting like this, and is therefore a potentially simpler option.

 

Unfortunately, there are no pre-built packages for the patched version of Transmission, and it was therefore necessary to compile an updated version from source, and create the package myself. The slackware package I made can be downloaded here: https://dl.dropboxusercontent.com/s/2g1thgkqguy218i/transmission-2.82r14243-i486-1nr.txz

 

The package is obviously downloaded automatically by the associated plugin, which is a vastly simplified version based on the work of 'Influencer', who's plugin is still linked to in the wiki.

 

The only setting available in the unRAID UI (other than enable / disable) is the location of the configuration directory. If this configuration directory is on the RAM disk (which it is by default, at /usr/local/transmission), the plugin will copy the settings.json file from /boot/config/plugins/transmission at boot time. Any changes made in Transmission will be lost on reboot unless they are also changed in the settings.json file on the flash drive. It is therefore suggested that the configuration directory be set to a location that persists between reboots (though not the flash disk). I personally have an additional drive running outside the array for applications, but a cache drive would also work well.

 

As described above, I was intending to make use of the bind-interface-device support of this patched build, and therefore made the following changes to my settings.json file after installation:

 

"bind-interface-device": "tun0", 
"bind-interface-enabled": true, 

 

Please note that these settings are not set by default in the plugin, because without all of the other settings that I'll be discussing in this thread also being set, Transmission would fail to download anything.

 

My patched Transmission plugin can be found here: http://tinyurl.com/m9xcwad

[Nezil]

OpenVPN Plugin, Private Internet Access OVPN, and routing table modifications

 

First off, apologies for taking so long to continue this thread. I have a 6 week old son, and supporting my wife with him is taking more of my free time than I anticipated.

 

As discussed previously, I like to simplify the plugins that I'm using so that they have as few options in the unRAID UI as needed, and any advanced customisation work is done in the Terminal. With that in mind, I created my own simplified OpenVPN plugin, which also allowed me to use the latest openssl packages.

 

As with my simplified Transmission Plugin, the only setting in the unRAID UI (other than enable / disable) is the location of the OVPN configuration file. It was my intention, having configured all of my plugins, that OpenVPN maintain a connected VPN tunnel at all times, so there is no unRAID UI button to connect the VPN at all; if the OpenVPN plugin is enabled, OpenVPN should just keep re-connecting the tunnel until the plugin is disabled.

 

The key to having Transmission data only pass over the VPN tunnel, is to modify the routing tables of the unRAID system so that there are two routes for internet data. Having Transmission bind to the tunnel interface ensures that Transmission will only use the VPN route for it's data, while all of the other unRAID services will continue to use the normal default route.

 

My OVPN file looks like this:

 

#default privateinternetaccess ovpn lines
client
dev tun
proto udp
remote us-california.privateinternetaccess.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
# ca ca.crt
tls-client
remote-cert-tls server
# auth-user-pass
comp-lzo
verb 1
reneg-sec 0

# Provide full paths to certificate and passwords files
ca /apps/openvpn/ca.crt
auth-user-pass /apps/openvpn/password.txt

# Change routing behaviour
script-security 3
route-delay 5
route-up "/apps/openvpn/route-up.sh"

# Set location of Status Log
status /tmp/openvpn/openvpn-status.log

# Add code to re-connect if link drops
keepalive 10 60

 

The key parts of this OVPN configuration file are the call to the route-up script, and the keepalive statement that handles re-connections. If you're using privateinternetaccess as your VPN provider, then the only change you'd perhaps make is which VPN server you choose to connect to. If you're using a different VPN provider, you'd probably only need to add the route-up and keepalive sections to their suggested OVPN file for the routing to work as desired.

 

My route-up scripts looks like this, with comments added here to explain what's happening:

 

#!/bin/sh

# Checks to see if there is an IP routing table named 'vpn', create if missing
if [ $(cat /etc/iproute2/rt_tables | grep vpn | wc -l) -eq 0 ]; then
        echo "100     vpn" >> /etc/iproute2/rt_tables
fi

echo "------------------------------------------------------------------"
/sbin/ip route show
echo "------------------------------------------------------------------"

# Remove any previous routes in the 'vpn' routing table
/sbin/ip rule | sed -n 's/.*\(from[ \t]*[0-9\.]*\).*vpn/\1/p' | while read RULE
do
echo "remove old rule:  /sbin/ip rule del ${RULE}"
/sbin/ip rule del ${RULE}
done

# Delete the default route setup when the OpenVPN tunnel was established
/sbin/ip route del 128.0.0.0/1 via ${route_vpn_gateway}
/sbin/ip route del 0.0.0.0/1 via ${route_vpn_gateway}

# Add routes to the vpn routing table
echo ip rule add from $ifconfig_local lookup vpn
/sbin/ip rule add from ${ifconfig_local} lookup vpn

# Add the route to direct all traffic using the the vpn routing table to the tunX interface
echo ip route add default dev ${dev} table vpn
/sbin/ip route add default dev ${dev} table vpn

# Restart Transmission to load new tunnel local IP
/etc/rc.d/rc.transmission restart

exit 0

 

The comments in this script should be self explanatory, but what is not obvious, is that the default unRAID kernel does not support routing tables, and a custom kernel is therefore needed to address this; see my next post for details on this.

 

My updated, simplified OpenVPN plugin can be downloaded here: http://tinyurl.com/ltendo6

My privateinternetaccess OVPN configuration file can be downloaded here: http://tinyurl.com/oloqz2f

My route-up script can be downloaded here: http://tinyurl.com/ml94gh9

[Nezil]

Custom Kernel with support for policy routing

 

As mentioned in my previous post, a custom unRAID kernel is necessary, with added support for policy routing, if you want to be able to define a different route for the VPN interface.

 

These policy routing options appear to be enabled by default in most up to date Linux builds, and I'm unsure why Lime Technology chose to leave these options disabled for us. The intention may be to simplify the kernel and reduce file size, but I cannot say for sure. I'm hopeful that Lime Technology may enable these options in future builds, so that a custom kernel is not necessary for this function.

 

With that being said, a custom kernel is currently necessary, and I followed the process on the wiki (linked here) for how to do this. I did find that it was necessary to change a couple of things in the wiki process, and this was really only necessary because my system (and many other user systems) has a Realtek ethernet interface, which requires additional kernel modules to be installed.

 

Firstly, I accept no responsibility for issues caused by using my updated kernel and image files, though I have been using them in my system for more than a month with no problems at all. My suggestion is that you modify the syslinux.cfg file (located in /boot/syslinux) to provide an additional option to select this new kernel at boot, and after you're satisfied with stability, perhaps consider changing this option to the default.

 

As an example, my syslinux.cfg file looks like this:

 

default /syslinux/menu.c32
menu title Lime Technology
prompt 0
timeout 50
label unRAID OS Custom Kernel
  menu default
  kernel /bzimaged
  append initrd=/bzrootd
label unRAID OS Custom Kernel (no plugins)
  kernel /bzimaged
  append initrd=/bzrootd unraidsafemode
label unRAID OS Standard
  kernel /bzimage
  append initrd=/bzroot
label unRAID OS Standard (no plugins)
  kernel /bzimage
  append initrd=/bzroot unraidsafemode
label Memtest86+
  kernel /memtest

 

Downloads for my custom kernel and image files can be found below. These need to be placed in the root of the flash drive and called in the syslinux.cfg file discussed above.

 

bzimaged: http://tinyurl.com/o8x2xhf

bzrootd: http://tinyurl.com/k72k3a4

[Nezil]

Building the custom kernel

 

In this, the last post of the series, I'm going to talk about the issues that I ran into creating the custom kernel that I needed. As I mentioned earlier, the process that I followed was the one used on the Lime Technology wiki (linked here), but I had to introduce a couple of changes in order to have a working pair of bzroot / bzimage files.

 

To be fair to the authors of the wiki, the page does mention that it's under construction. I'm hoping here to simply state the solutions that I found, in case others find it useful.

 

I first installed a clean Slackware OS in a Parallels virtual machine running on my MacBook Air. I used this OS to compile the custom kernel before moving it over to my unraid system.

 

The only change that I needed to make was to switch on a couple of additional options in the menuconfig UI.

 

After I'd made my changes, I ran through the following commands as shown on the wiki:

 

make

make modules

make modules_install

make install

 

I then went ahead and built the required Realtek drivers from source and installed them as well. Initially, the modules_install command would place files in the wrong locations, and I ended up using the following two commands:

 

sudo make -C /lib/modules/3.9.11p-unRAID/build SUBDIRS=/[path to Realtek driver source code]/r8168-8.037.00/src modules

sudo make -C /lib/modules/3.9.11p-unRAID/build SUBDIRS=/[path to Realtek driver source code]/r8168-8.037.00/src/ INSTALL_MOD_DIR=kernel/drivers/net/ethernet/realtek modules_install

 

The wiki page provides a great set of script files to automate the building of the bzroot and bzimage files, but I ran into a show-stopper issue that required a change... The script for bzroot-update is shown below:

 

#!/bin/bash

if [ ${DEBUG:=0} -gt 0 ]
   then set -x -v
fi

set -o nounset

P=${0##*/}              # basename of program
R=${0%%$P}              # dirname of program
P=${P%.*}               # strip off after last . character
O=${P%_*}               # Operand
D=${P#${O}_}            # Data (last param before _ character)

source ${R}/bzroot-config.sh

# KERNEL=3.9.11p-unRAID
# RDROOT=/boot/initrd-unraid

cd /usr/src/linux
make modules_install install

if [ ! -d ${RDROOT} ] ; then mkdir ${RDROOT}; fi
cd ${RDROOT} || exit

rsync -a /usr/src/linux/System.map ${RDROOT}/usr/src/linux
rsync -av --delete /lib/modules/${KERNEL} ${RDROOT}/lib/modules/

find ${RDROOT}/usr/include         -type f -exec rm {} \;
find ${RDROOT}/usr/lib -name '*.a' -type f -exec rm {} \;
find ${RDROOT}/usr/man             -type f -exec rm {} \;
find ${RDROOT}/usr/src/slackbuilds -type f -exec rm {} \;

 

As you can see, there is a line in this script which re-runs the make modules_install command. Doing this removes the changes made by the Realtek installation, and I therefore ended up without the driver that I needed. The solution of course is to simply comment out this line in the script!

[JonathanM]

Building the custom kernel

 

In this, the last post of the series, I'm going to talk about the issues that I ran into creating the custom kernel that I needed. As I mentioned earlier, the process that I followed was the one used on the Lime Technology wiki (linked here), but I had to introduce a couple of changes in order to have a working pair of bzroot / bzimage files.

 

To be fair to the authors of the wiki, the page does mention that it's under construction. I'm hoping here to simply state the solutions that I found, in case others find it useful.

Please, since you have already done the legwork, would you consider adding your information to the wiki? I'm pretty sure if you are currently logged into the forum, you can edit the wiki and add the appropriate notations right there so as to give the next victim the benefit of your experience.

 

If you don't want to redo the wiki page, at least insert a link there to your forum post.

[Nezil]

Please, since you have already done the legwork, would you consider adding your information to the wiki? I'm pretty sure if you are currently logged into the forum, you can edit the wiki and add the appropriate notations right there so as to give the next victim the benefit of your experience.

 

If you don't want to redo the wiki page, at least insert a link there to your forum post.

 

OK, I've updated the wiki page as you suggested. I was nervous to do this because I have feelings of inadequacy and was worried that I may have made some mistakes myself! Having said that, I agree that the state of the wiki would result in a build that probably more than 50% of users could not use.

 

I hope my changes are appreciated by more than just you Jonathan!

[Raidersan]

Hi Nezil,

 

This is brilliant, I have been looking for something like this for a long time, I never thought it would be that complicated!

The only variation I would like is the ability to switch the VPN on & off from time to time, as my VPN supplier doesn't provide full speed, so for some downloads I turn it off. I understand this could be tricky with your solution, wouldn't it?

 

Anyway, great work and thank you!

[Nezil]

Actually Raidersan, the only thing that you'd have to change is the "bind-interface-device": "tun0" line in the transmission settings.json file. If you changed this to eth0 instead of tun0 then Transmission wouldn't use the vpn link any more, and you could still keep the VPN link up, it just wouldn't be doing anything.

 

As soon as you want to have Transmission use the VPN again, stop it, change the settings.json file back to tun0 and restart.

 

You might have to edit the settings.json file when Transmission isn't running, because it writes to the file as it shuts down and may overwrite your change!

[Raidersan]

Clever! Any chance to have that option on the GUI?

[Nezil]

Clever! Any chance to have that option on the GUI?

 

Well as I said in my earlier posts, I try to make my plugins as simple as possible since there is so many 'advanced' features that users might want, the plugin can start to get unwieldy and confusing. Advanced users are therefore open to making changes themselves as they see fit, either in the plugin itself, or in the configuration files.

 

Having said that... I understand the need, and the fact that there would need to be manual intervention every time you made the change, rather than simply setting up a configuration file as needed. With that in mind, give me some time to think about how best to handle this, and I'll come back to you on it.

[Raidersan]

That would be grand, thanks!

[Nezil]

Try this one and see how you get on:

 

https://dl.dropboxusercontent.com/s/fkpqyw9jqffojbd/Transmission-2.82r14243-i486-2nr.plg

 

I also added an option to change the port that the Transmission Web Interface runs on. I was changing this in the settings.json file manually, but I thought that might be useful so I added it to the unRAID UI.

 

Please let me know if you have any issues.

[Nezil]

By the way, you'll either need to reboot after putting that plugin in the correct place, or delete the two files that were changed in this version before running installplg.

 

In other words, if you don't want to reboot, run the following commands after replacing the v1 plugin with the v2 in the link above:

 

/etc/rc.d/rc.transmission stop
rm /etc/rc.d/rc.transmission
rm /usr/local/emhttp/plugins/transmission/transmission.php
installplg /boot/config/plugins/Transmission-2.82r14243-i486-2nr.plg

 

Refresh the unRAID UI and the change should be there and ready to go...

[Nezil]

In order to test that your Transmission client is really using the VPN tunnel, or to confirm that it is not, I recommend using the website http://www.ipleak.net/ which has a magnet link that will tell you the external internet IP address that your Torrent client is using.

 

You'll probably visit the ipleak.net web page on a desktop OS rather than unRAID, so the section titled 'Your IP Address' at the top of the page is your regular ISP allocated internet IP address. As long as that IP address doesn't match the one detected by the magnet link, your data is encrypted over the VPN tunnel.

 

Your ISP allocated IP address is also shown at the bottom right of your posts in this forum ;-)

[Nezil]

Here is a further updated Transmission plugin that adds a lookup of the ISP allocated Internet IP address as well as the VPN tunnel Internet IP address (when connected), to the unRAID UI.

 

https://dl.dropboxusercontent.com/s/7i6c08g0z37k3i1/Transmission-2.82r14243-i486-3nr.plg

[Raidersan]

Wooowwwww... I am soooo lost! This is where lack of knowledge becomes dangerous.

 

I have gone through all your posts, I am running on your kernel BUT... :-)

 

1) Openvpn won't start, I am getting the following when trying to start it manually after reboot:

 

root@Tower:/boot/plugins# /etc/rc.d/rc.openvpn start
btguard.ca.crt
btguard.ovpn
Your ovpn file already have the option --> password.txt
Your ovpn file already have the option --> persist-remote-ip
Starting Openvpn Tunnel: wait .........
nohup: redirecting stderr to stdout
The OpenVPN Client is running with Process 10805
An error accured, probably there is some issue with your acount!!!, Try to login in again !!
Stoping Openvpn Tunnel.....
/etc/rc.d/rc.openvpn: line 67: kill: (10805) - No such process
... OK
The OpenVPN Client is running with Process 10805
Writing to the plugin config file....

 

I am trying to follow my config files but I have discovered so may openvpn references that are probably historically there that I do not know what is what. I have references in:

 

/boot/config/plugins/openvpn

root@Tower:/boot/plugins# ls -l /boot/config/plugins/openvpn

total 36

-rwxrwxrwx 1 root root  506 2012-06-25 20:27 Connected.jpg*

-rwxrwxrwx 1 root root  460 2012-10-20 08:51 Device_status.png*

-rwxrwxrwx 1 root root  473 2012-06-25 20:28 Disconnected.jpg*

-rwxrwxrwx 1 root root  778 2012-10-20 08:53 Information.png*

-rwxrwxrwx 1 root root  607 2012-10-20 08:52 New_config.png*

-rwxrwxrwx 1 root root 5918 2012-06-24 09:34 Openvpn.png*

-rwxrwxrwx 1 root root  71 2014-05-17 16:42 openvpn.cfg*

-rwxrwxrwx 1 root root  15 2014-05-09 11:54 password.txt*

 

/boot/config/openvpn

root@Tower:/boot/plugins# ls -l /boot/config/openvpn/

total 8

-rwxrwxrwx 1 root root 136 2014-05-09 08:35 openvpn.cfg*

-rwxrwxrwx 1 root root  15 2014-05-09 08:35 password.txt*

 

/boot/openvpn

root@Tower:/boot/plugins# ls -l /boot/openvpn/

total 1068

-rwxrwxrwx 1 root root    1257 2010-08-07 01:51 btguard.ca.crt*

-rwxrwxrwx 1 root root    610 2014-05-17 16:09 btguard.ovpn*

-rwxrwxrwx 1 root root 1085440 2014-05-17 16:42 core*

 

/boot/plugins/openvpn

root@Tower:/boot/plugins# ls -l /boot/plugins/openvpn/

total 360

-rwxrwxrwx 1 root root    506 2012-06-25 20:27 Connected.jpg*

-rwxrwxrwx 1 root root    460 2012-10-20 08:51 Device_status.png*

-rwxrwxrwx 1 root root    473 2012-06-25 20:28 Disconnected.jpg*

-rwxrwxrwx 1 root root    778 2012-10-20 08:53 Information.png*

-rwxrwxrwx 1 root root    607 2012-10-20 08:52 New_config.png*

-rwxrwxrwx 1 root root  5918 2012-06-24 09:34 Openvpn.png*

-rwxrwxrwx 1 root root 335200 2013-08-07 12:48 openvpn-2.3.2-i486-2-autologin.txz*

-rwxrwxrwx 1 root root    71 2013-02-21 09:26 openvpn.cfg*

 

/mnt/cache/.apps/openvpn

root@Tower:/boot/plugins# ls -l /mnt/cache/.apps/openvpn/

total 4

-rwxrwxrwx 1 root root 912 2014-05-16 17:38 route-up.sh*

 

 

Trying to start Transmission, it seems to fail to locate my config file. I am not sure why it does not find the one that I used to use with my previous version of the plugin? Can you enlighten me as to how it initially locates it?

 

Tx!

 

[Nezil]

Wooowwwww... I am soooo lost! This is where lack of knowledge becomes dangerous.

 

I'm happy to help, but please be patient as I have a 3 month old second child that is restricting my ability to respond as quickly as I'd like!

 

I have gone through all your posts, I am running on your kernel BUT... :-)

 

1) Openvpn won't start, I am getting the following when trying to start it manually after reboot:

 

...

 

Trying to start Transmission, it seems to fail to locate my config file. I am not sure why it does not find the one that I used to use with my previous version of the plugin? Can you enlighten me as to how it initially locates it?

 

Your issues could be caused by several things. I'll try to explain my thoughts first, and then give you some options for fixing the issues.

 

Possible Causes

 

First off, did you install the plugin without rebooting? Doing this will only work if there isn't an older version of the plugin already installed. The reason is that any new version will skip installation of any files that already exist. If the /etc/rc.d/rc.openvpn file already exists, for example, it won't be updated.

 

The second possible issue is that older versions of the plugins have left files on your flash drive that are interfering with the new plugin. This is less likely I think, but of course possible.

 

The third option, which is sadly quite probable, is that other plugins are installing some of the helper packages needed by OpenVPN and/or Transmission that are older than the ones needed for the versions in my plugins. This is a known issue with the plugin system, and apparently Lime-Tech is working on a fix for this.

 

Fixes

 

The easiest thing to do, would be to reboot, making sure that no other versions of the Openvpn or Transmission plugin are in your /boot/config/plugins folder.

 

To be safe, before rebooting, I'd also make backups and move the /boot/config/plugins/openvpn and /boot/config/plugins/transmission folders; call them something like openvpn.bak and transmission.bak so that you're not loosing them altogether.

 

I am not using the following folders, so you can probably safely delete them (or make backups if you prefer):

 

/boot/config/openvpn

/boot/openvpn

/boot/plugins/openvpn

 

I'm assuming that you're using your cache drive as the location for your config files, so you'll want to move your .ovpn file, password file and route-up.sh file over there.

 

Actually, the only file that needs to be located by the plugin is the .ovpn file; all of the other files are called directly from this configuration file, and you can decide where you'd like to put them. Take a look at my example .ovpn file for how to set that file up with the service you're using.

 

For the Transmission plugin, the default location for the settings.json file is in /boot/config/plugins/transmission. If you change the default, and I'm guessing that you'll be putting it on your cache drive, then the settings.json file is copied over if it doesn't already exist.

 

I'm not sure what would happen if you try to use a settings.json file from a different Transmission build. If I had to guess, I'd say that it would add the additional lines for routing in when the daemon starts, but I couldn't say for sure.

 

If I were you, I'd take a backup of your existing settings.json file, and then delete the original one. Allow my plugin to start Transmission from scratch, and make your changes as you see fit. I'd be surprised if you had settings that were so complicated that it would take you more than a few minutes to set them up.

 

Follow Up

 

As I said earlier, I expect that you also probably have compatibility issues with different builds of the support packages. This is especially likely for the OpenSSL package, which may be quite old in some other plugins.

 

If you're still running into problems after doing the things I've said above, please take a capture of the first 1000 or so lines of your /var/log/syslog and attach them to a post here. It will be quite obvious if there is a support package issue because the plugins are installed at boot, and I'll see some lines that say that a package is already installed and is being 'upgraded'.

 

The package manager is not intelligent enough to know if a package is newer or not, and so backs up and overwrites the existing package, even if it is newer! If the versions are the same however, it simply says that the package is already installed and just moves on.

 

---

 

Let me know how you get on!

[Raidersan]

Many thanks for your help! I see that most files (cfg,..) that I had don't get overwritten with yours, which I can understand, so i started deleting mines and letting yours install, but I am confused as to why the .page file does't get replaced, I thought anything on the ramdisk filesystem (including /usr I thought) gets created at boot every time, so how can I have an old version of that file and not the one from your plugin? The only explanation I can think of is that there is an old openvpn plugin somewhere but I cannot find any.

 

Here is the content of that file, in case it rings a bell:

 

root@Tower:~# cat /usr/local/emhttp/plugins/openvpn/openvpn.page
Menu="NetworkServices"
Icon="Openvpn.png"
Version="2.1.8"
Author="Peter_sm"
Type="php"
Title="OpenVPN Client"

 

 

[Nezil]

I'd have to agree with you. The only way that you have a different .page file is if another plugin is installing it. The easy way to find out if this is the case, is to type this command:

 

cat /var/log/syslog | grep "installing plugin"

 

Which will show you which plugins were installed since you booted your unRAID system; any duplicates there will be very obvious.

 

Next issue this command:

 

find /boot -name "*vpn*"

 

Which will list all files and directories on your flash drive with vpn in the name. For reference, the result of the command on my system looks like this:

 

/boot/packages/openvpn-2.3.2-i486-2-autologin.txz
/boot/config/plugins/Openvpn-2.3.2-i486-2-2nr.plg
/boot/config/plugins/openvpn
/boot/config/plugins/openvpn/Openvpn.png
/boot/config/plugins/openvpn/openvpn.cfg

 

The first file is the package downloaded by my plugin, and cached for future boots like all other plugins in the /boot/packages folder.

Next is the plugin itself, and then the plugin support directory with just two files.

 

If you run the command and have any other files or directories showing, you should be able to move or delete them.

 

Finally, to see if any packages are being overwritten and breaking things, run the following command:

 

cat /var/log/syslog | grep "Installing package"

 

And look for duplicate packages with different versions. Duplicates with the same version pose no problem at all, but different versions very well could cause problems.

 

As I said before however, the simplest thing that you could do to help me diagnose this, is to send over a full copy of your syslog (located at /var/log/syslog).

[Raidersan]

Ok, I am bit further now after missing an obvious .plg  . But I am now getting a segfault when I try to start your openvpn, so I guess this is what you predicted earlier, the wrong library version is picked up:

 

May 18 22:56:25 Tower kernel: openvpn[8651]: segfault at 14 ip 4019ad06 sp bffd24ec error 4 in libcrypto.so.0.9.8[400c1000+12d000]
May 18 22:57:01 Tower sudo:     root : TTY=unknown ; PWD=/mnt/cache/.apps/openvpn ; USER=root ; COMMAND=/usr/sbin/openvpn --writepid /var/run/openvpn/openvpn.pid --mute-replay-warnings --config /mnt/cache/.apps/openvpn/btguard.ovpn

 

Here is my syslog: http://pastebin.com/0bvxpz3f

[Nezil]

The syslog helps a lot.

 

To start with, I can see that you have two versions of plexupdater when you should probably only have one (though that shouldn't affect openvpn or transmission).

 

I can also see that you have a Sickbeard plugin that isn't mine, which shouldn't cause any problems other than the fact that it might be installing packages that we'd rather it didn't. I've made sure that all of my plugins play well with one another, but it's impossible to do that for everyones plugins of course.

 

Looking at the packages being installed, I can see that you have duplicates of the following:

 

May 18 22:50:05 Tower logger: Installing package openssl-1.0.1g-i486-1.txz:
May 18 22:50:33 Tower logger: Installing package openssl-0.9.8y-i486-1_slack13.37.txz:
May 18 22:51:02 Tower logger: Installing package openssl-0.9.8r-i486-3.txz:

May 18 22:50:08 Tower logger: Installing package openssl-solibs-1.0.1g-i486-1.txz:
May 18 22:50:26 Tower logger: Installing package openssl-solibs-0.9.8y-i486-1_slack13.37.txz:

May 18 22:50:08 Tower logger: Installing package libidn-1.25-i486-2.txz:
May 18 22:51:06 Tower logger: Installing package libidn-1.19-i486-1.txz:

 

Dynamix Email Notify

 

It's obvious to me initially that the packages ending in slack13.37.txz are those downloaded (and renamed) by dynamix plugins. I happen to know that the email notify plugin from dynamix calls both OpenSSL and OpenSSL-SOLibs packages. You have this plugin enabled, and there is a single instance of these slack13.37.txz packages being installed on your system at boot. You therefore only need to make a change to the email notify plugin to solve at least a third of your issues.

 

Luckily the author of the dynamix plugins knows about the issue of incompatible packages, and has provided an option to disable downloading of the packages that you don't want.

 

In all of the dynamix plugins there is a section which looks like this (taken from the dynamix.email.notify-2.1.0-noarch-bergware.plg plugin in my system):

 

<FILE Name="/tmp/plugin-packages">
<INLINE>
# Mandatory packages     13.1                13.37             14.0              14.1
a openssl-solibs  txz    0.9.8y-i486-1       0.9.8y-i486-1     1.0.1e-i486-1     1.0.1e-i486-1     no-install    # openssl library
n openssl         txz    0.9.8y-i486-1       0.9.8y-i486-1     1.0.1e-i486-1     1.0.1e-i486-1     no-install    # openssl library
</INLINE>
</FILE>

 

As you can see, in my file, I've already changed the last section (which was set to do-install) to no-install. This prevents the plugin downgrading to a lower version of OpenSSL and OpenSSL-SOLibs during installation.

 

Sickbeard

 

The duplicate libidn package is the last to be installed. Taking a look at the order of plugins being installed, we can see that this is most likely being called by the Sickbeard plugin that you're running.

 

The third duplicate OpenSSL package is also pretty late in the boot process, a little after python-cheetah, which is definitely needed for a Sickbeard installation. It is therefore possible that the Sickbeard plugin is also downgrading OpenSSL.

 

You now have two options:

• Switch out to my Sickbeard plugin (making sure to backup your settings etc.)
  
• Find the sections in your existing plugin and update it to reference the latest libidn and OpenSSL packages
  

If you choose the second approach, which is arguably easier, you'll need to locate the section near the top of the in the Sickbeard plugin that you're using that references the libidn and OpenSSL packages and replace it with this (The order doesn't matter, but you must replace the whole section, not just the download URL):

 

<FILE Name="/boot/packages/libidn-1.25-i486-2.txz" Run="upgradepkg --install-new">
<URL>http://mirrors.slackware.com/slackware/slackware-14.0/slackware/l/libidn-1.25-i486-2.txz</URL>
<MD5>bd13034446d71ce8b140efd4b12f7df7</MD5>
</FILE>

<FILE Name="/boot/packages/openssl-1.0.1g-i486-1.txz" Run="upgradepkg --install-new">
<URL>http://mirrors.slackware.com/slackware/slackware-current/slackware/n/openssl-1.0.1g-i486-1.txz</URL>
<MD5>bf07a4b17f1c78a4081e2cfb711b8748</MD5>
</FILE>

 

It's quite possible that these packages are not being called by the Sickbeard plugin, and if that is the case, then you'll have to work back through your plugins in reverse alphabetical order (sabnzbd_unplugged is next, then one of your two plexupdater plugins), until you find the offending package calls.

 

Good Luck!

[Raidersan]

Thanks again, that gives me plenty of guidance and ideas. I shall knuckle down after work and report back when I taste success!

[Raidersan]

Partial success! I have tun0 open, although some messages in syslog worry me a bit, can you confirm they are normal?

 

May 19 13:40:57 Tower avahi-daemon[4572]: Withdrawing workstation service for tun0.
May 19 13:41:23 Tower kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
May 19 13:42:35 Tower ntpd[1111]: Listen normally on 16 tun0 10.10.10.110 UDP 123
May 19 13:42:35 Tower ntpd[1111]: Deleting interface #15 tun0, 10.10.10.94#123, interface stats: received=0, sent=2, dropped=1, active_time=300 secs
May 19 13:42:35 Tower ntpd[1111]: 88.150.156.178 interface 10.10.10.94 -> (null)
May 19 13:42:35 Tower ntpd[1111]: new interface(s) found: waking up resolver
May 19 13:43:01 Tower avahi-daemon[4572]: Withdrawing workstation service for tun0.

 

 

Now my next issue, Transmission! I believe I have resolved the first problem which was that you need an extra parameter in the transmission.cfg file, called ROUTE_VPN=yes, I could not see this in your instructions. At least that is what I thought from following the script and it has resolved the error, but Transmission still fails to load, on a different error:

 

root@Tower:~# /etc/rc.d/rc.transmission start
mkdir: missing operand
Try `mkdir --help' for more information.
chown: missing operand after `transmission:users'
Try `chown --help' for more information.
chmod: missing operand after `755'
Try `chmod --help' for more information.
Starting transmission:  sudo -u transmission /usr/bin/transmission-daemon --port 9091 --config-dir  --pid-file /var/run/transmission/transmission.pid --logfile /var/log/transmission.log
1...2...3...4...5...6...7...8...9...10...11...
Transmission.pid not created for some reason

 

The first few lines seem to indicate it cannot find my config file, or I am wrong?

There is is something fishy, as trying to load the transmission config page on the GUI takes minutes, and eventually leads to what I think is a kernel out of memory, loosing the file system completely (no ls, cat, grep,...)

 

Any Idea?

[Nezil]

Partial success! I have tun0 open, although some messages in syslog worry me a bit, can you confirm they are normal?

 

May 19 13:40:57 Tower avahi-daemon[4572]: Withdrawing workstation service for tun0.
May 19 13:41:23 Tower kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
May 19 13:42:35 Tower ntpd[1111]: Listen normally on 16 tun0 10.10.10.110 UDP 123
May 19 13:42:35 Tower ntpd[1111]: Deleting interface #15 tun0, 10.10.10.94#123, interface stats: received=0, sent=2, dropped=1, active_time=300 secs
May 19 13:42:35 Tower ntpd[1111]: 88.150.156.178 interface 10.10.10.94 -> (null)
May 19 13:42:35 Tower ntpd[1111]: new interface(s) found: waking up resolver
May 19 13:43:01 Tower avahi-daemon[4572]: Withdrawing workstation service for tun0.

 

I don't see the ntpd lines in my syslog, but I don't think they're causing any issue. ntpd is the network time deamon, and it appears to try and work over the tunnel, and fail. That's not really a problem of course.

 

You could try adding the following lines to your route-up.sh script. I don't have these in mine, but you may have some other plugin running that is using ntpd in a different way:

 

# ntpd will use the tun0 interface, so block it
echo iptables -A OUTPUT -o ${dev} -p udp --dport 123 -j DROP
/usr/sbin/iptables -A OUTPUT -o ${dev} -p udp --dport 123 -j DROP

 

Now my next issue, Transmission! I believe I have resolved the first problem which was that you need an extra parameter in the transmission.cfg file, called ROUTE_VPN=yes, I could not see this in your instructions. At least that is what I thought from following the script and it has resolved the error, but Transmission still fails to load, on a different error:

 

root@Tower:~# /etc/rc.d/rc.transmission start
mkdir: missing operand
Try `mkdir --help' for more information.
chown: missing operand after `transmission:users'
Try `chown --help' for more information.
chmod: missing operand after `755'
Try `chmod --help' for more information.
Starting transmission:  sudo -u transmission /usr/bin/transmission-daemon --port 9091 --config-dir  --pid-file /var/run/transmission/transmission.pid --logfile /var/log/transmission.log
1...2...3...4...5...6...7...8...9...10...11...
Transmission.pid not created for some reason

 

The first few lines seem to indicate it cannot find my config file, or I am wrong?

There is is something fishy, as trying to load the transmission config page on the GUI takes minutes, and eventually leads to what I think is a kernel out of memory, loosing the file system completely (no ls, cat, grep,...)

 

Any Idea?

 

This one looks reasonably easy to diagnose... You appear to have no path for the transmission configuration directory. By default, this is defined as /usr/local/transmission/. This path is obviously lost at each reboot, so the settings.json file from /boot/config/plugins/transmission is copied over at each boot.

 

I'd obviously recommend that you change away from the default, and in your case, point this variable at a directory on your cache drive. The settings.json file will then not need to be copied over, because it will already exist from the previous time you ran transmission.

 

One thing that you cannot do, is to have the $CONFIGDIR variable empty. The rc.transmission script specifically defines the location of the configuration files with the --config-dir switch, and yours appears to be empty.

 

The only way that this would be empty, is if your /boot/config/plugins/transmission/transmission.cfg file was hanging over from the previous plugin (just like we had going on with your openvpn issues), or if you had deleted the default path in the unRAID webUI and then left it blank.

 

It would probably be wise to delete (or backup and move) your existing /boot/config/plugins/transmission folder so that my plugin can re-create the files with the default settings. You should then be able to go to the relevant setting in the unRAID webUI and change the path for your configuration files, as well as the RPC port and if you'd like transmission to always use the VPN.