Nezil
-
Posts
130 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Nezil
-
-
It's late now, and I'm getting tired, but I'll try and do some additional debugging over the weekend.
Regarding Ubiquiti... I had wanted to upgrade my WiFi for a while, because although I like the two Apple Airport Extremes that I had, I was having some odd behaviour switching between access points as I moved through the house, and neither of them supported 11ac. This need is what switched me on to Ubiquiti, because I'd heard their WiFi stuff was good.
To be honest, I also REALLY like learning new things, and had wanted to dabble with VLAN for a while, so an EdgeRouter Lite and at lease one UAP-AC-PRO were ordered, along with an Engenius POE switch (to power the AP), and a couple of Netgear low cost managed switch for other parts of my house.
It took quite a bit of time to set it all up, though simply replacing the AirPort Extreme Router functionality was very quick indeed, the firewall, VLAN and IPv6 stuff took a bit longer. Having said that though, maybe I'm crazy but I found it so much fun, and now that it's all done, I'm itching to do something similar and am looking doing an IP camera setup around our housing community!
In summary, the Ubiquiti stuff has been great. A single UAP-AC-PRO has replaced two Airport Extremes and I get better coverage throughout my (3-floor town) house, and the EdgeRouter feels faster than the AirPort Extreme whilst providing me with greater functionality. I'd say go for it, but maybe get the EdgeRouter POE rather than the EdgeRouter Lite.
-
I recently upgraded to unRAID 6, and in doing so obviously lost all of my old plugins, including the Transmission one I created a couple of years ago that included OpenVPN support.
Rather than try and re-write my old plugin into a Docker, I thought I'd check to see if there already was a Transmission Docker that fit my needs, and sure enough, thanks to @active, there is!
The docker installed fine, and appears to connect to PIA using OpenVPN just like my old plugin did. I made a couple of changes like moving the
Unfortunately, once the Docker starts up, it appears to have no connection to the outside world. I'm not sure if this is a problem with the way that my network and firewall router are set up, or if it's a configuration issue in the Docker. Would someone be able to help me debug this?
The details of my network are:
unRAID server running on VLAN 20 in my network, with an IPv4 subnet of 172.16.20.0/24
NAT Router (Ubiquiti EdgeRouter Lite) has a zone based firewall set to allow all outgoing to WAN, and allow established and related in from WAN. I tried opening up the firewall on the input, but this didn't help at all.
I don't have any ports forwarded to the unRAID box currently, because I use a VPN to connect to the home network if I'm away and need access. I didn't need any ports forwarded with my Plugin before, but this is my thought on the most likely issue. Having said that, if all of the Transmission data is going over the OpenVPN link, there shouldn't be any need for local port forwarding I'd have thought?!?
Thanks in advance for any help!
-
Riot,
Thank you very much for correcting the mistake in my version. As I mentioned previously, my wife and I recently had our second child, and that was tying up a lot of my free time. To add to this, my landlord gave us 60 days notice to get out of our house, and I've been working to buy a house (and all the paperwork that involves) ever since!
It's quite a relief to see someone else step up and take over.
My signature has been updated with the latest version.
-
@randall526, Try using version 1nr of the plugin; it's easier to customise for your requirements because there is fewer options in the web UI.
-
OK, so the commands that your VPN provider pushes to you are these (IP addresses shown with variable names):
/usr/sbin/ip link set dev tun0 up mtu 1500 /usr/sbin/ip addr add dev tun0 local 10.10.10.214 ($ifconfig_local) peer 10.10.10.213 ($route_vpn_gateway) /usr/sbin/ip route add 109.201.137.166/32 via 192.168.1.1 /usr/sbin/ip route del 0.0.0.0/0 /usr/sbin/ip route add 0.0.0.0/0 via 10.10.10.213 ($route_vpn_gateway) /usr/sbin/ip route add 10.10.10.1/32 via 10.10.10.213 ($route_vpn_gateway)
Which are quite different from those pushed by private internet access:
Thu May 22 12:59:17 2014 /usr/sbin/ip link set dev tun0 up mtu 1500 Thu May 22 12:59:17 2014 /usr/sbin/ip addr add dev tun0 local 10.172.1.6 ($ifconfig_local) peer 10.172.1.5 ($route_vpn_gateway) Thu May 22 12:59:23 2014 /usr/sbin/ip route add 198.23.71.73/32 via 172.16.17.1 Thu May 22 12:59:23 2014 /usr/sbin/ip route add 0.0.0.0/1 via 10.172.1.5 ($route_vpn_gateway) Thu May 22 12:59:23 2014 /usr/sbin/ip route add 128.0.0.0/1 via 10.172.1.5 ($route_vpn_gateway) Thu May 22 12:59:23 2014 /usr/sbin/ip route add 10.172.1.1/32 via 10.172.1.5 ($route_vpn_gateway)
The route-up.sh must be set up to modify the routes pushed by each VPN provider, and the example that I gave, and you're using is based on the routes pushed by private internet access.
The major difference is that my VPN provider pushes an additional route (128.0.0.0/1 via $route_vpn_gateway), and this route is also deleted by the route-up.sh script.
The full list of routing commands in the route-up.sh is (IP addresses from your example added, as well as comments):
/sbin/ip rule del ${RULE} - This command removes any previous routing rules that would have been set up in previous sessions
/sbin/ip route del 128.0.0.0/1 via 10.10.10.213 ($route_vpn_gateway) - This command should fail on your system, because the route wasn't pushed by your VPN provider
/sbin/ip route del 0.0.0.0/1 via 10.10.10.213 ($route_vpn_gateway) - This command should work fine, removing the default route down the VPN tunnel
/sbin/ip rule add from 10.10.10.214 ($ifconfig_local) lookup vpn - This command should also work fine, creating a routing rule pointing packets from 10.10.10.214 to the 'vpn' routing table
/sbin/ip route add default dev tun0 ($dev) table vpn - This command should also work, creating a default route for packets applied to the 'vpn' table, routing them down the tun0 interface
I'm surprised that the current route-up.sh script doesn't work to be honest; the deleting of the 128.0.0.0 route will obviously fail, but that shouldn't cause any problems.
Could you comment out the script in the .ovpn file, and then manually run through each of the commands that I've shown above. It's important that when you do this, you also run the first command to remove the old rule; to find the rule that you're going to remove, first run this command:[pre]/sbin/ip rule | sed -n 's/.*\(from[ \t]*[0-9\.]*\).*vpn/\1/p'[/pre]and then use the output of that command to replace ${RULE} in the first command that you manually enter. You can do this before or your VPN has been restarted because it applies to the previous session.
Update:
I initially failed to notice that your VPN provider also issues an ip command to remove the existing default route, which mine does not, it only adds an additional one which appears to take precedence; that's this line:[pre]/usr/sbin/ip route del 0.0.0.0/0[/pre]This route will need to be added back in, or you'll have no default route for normal traffic after everything else is set up.
I'm going to take a stab at an updated route-up.sh script that might solve everything as follows:
#!/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 0.0.0.0/1 via ${route_vpn_gateway} # Add back deleted default route echo ip add ip route add 0.0.0.0/1 via 192.168.1.1 /sbin/ip route add 0.0.0.0/1 via 192.168.1.1 # Add rule pointing 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 # 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 # Restart Transmission to load new tunnel local IP /etc/rc.d/rc.transmission restart exit 0 -
@Nezil, a question about transmission binding to the tunnel.
I have notice that "bind-address-ipv4" & "bind-address-ipv6" get automatically populated by the deamon, but I now see that "bind-interface-device" also gets filled in automatically, to "tun0". I noticed that as I tried to experiment binding to eth0 instead to see if there was an issue with the tunnel itself, but then notice that the value in the JSON file gets overwritten with tun0 as soon as it is started.
Is that normal? What if you wanted to bind it to something else? How does it get the interface name?
I think the reason that the bind is failing, has to do with the routing that's set up.
The basic process is to allow the VPN provider to update your routing as normal, remove the default routes, add a new ip rule that directs packets originating from the VPN IP address to the 'vpn' routing table, and add a default route to this 'vpn' routing table.
I'm guessing that something is wrong with the routing tables, and that will prevent transmission from binding to it.
To answer your question re. the binding setting being overwritten, this is happening because the rc.transmission startup section looks to see the status of the ROUTE_VPN variable, and if set to 'yes', sets the settings.json parameters to route over tun0; if set to 'no', the settings.json parameters will be set not to bind to any interface and simply use the default routes. Any changes that you make to the settings.json file related to binding will always be overwritten as transmission starts up.
As an aside... this is exactly why I try to keep my plugins with as few options in the webUI as possible. Adding things to the webUI is nice, but can make things complicated and confusing for debugging and power users. I prefer to have as few settings as possible, and let a power use configure things in the application settings files as needed. As you can see previously in this post, I was asked to add this option, and I reluctantly did so. If you use the plugin version in my signature, the ROUTE_VPN option is not in that version, and neither is the option in the webUI. The rc.transmission script will also not update the settings.json file on each startup - this is the version that I use in fact.
Back to your issue...
Would you mind setting the 'verb' line in your .ovpn file to 'verb 3', starting the VPN and providing a capture of your openvpn.out file. This should show the routing commands that your provider is pushing to your machine on connection, and we can then go about modifying the route-up.sh file to match what's needed for your vpn provider.
It would be helpful if you could also let me know what the $route_vpn_gateway and $ifconfig_local variables are for this connection, but I'm sure I could work it out if you aren't able to do that.
For this test, it doesn't matter if you have a route-up.sh file called or not; I'm interested in what happens before any additional scripts are called.
-
I'm pretty sure that version 3 has a problem where it does not save the ROUTE-VPN option in the configuration file. Version 3 should definitely not be used.
If version 4 is not working, let's look at debugging that one. To start with, remove all trace of any plugin, including the /boot/config/plugins/transmission folder, and restart with version 4 in place. If that doesn't work, we'll need to dig deeper, but @Raidersan is using that one with no issues as far as we know.
-
Sorry to hijack a productive conversation, great thread and much appreciated work to all.
1. I am running Transmission-2.82r14243-i486-3nr.plg and can't get my settings in settings.json to stick. Editing while transmission is running does nothing, and restarting transmission over writes the file with defaults every-time just after I edited it. I have the config directory pointed at /mnt/cache/.transmission/conf. It's picking up on my pre downloaded blocklist there just fine, however getting it to bind to an interface never takes and is over written when the service is bounced.
2. Port forwarding, transmission requires a port forward to work properly which always breaks on my VPN, regardless of what my router VPN gateway port fowards are set to. If I understand the issue correctly, my true Internet edge is my VPN address assigned by my VPN provider, further out on the net somewhere. I have no control over how that gateway is configured. Has anyone gotten their port forwards to work? My understanding is my setup with a DD-WRT router set to use a VPN would have the same issue running the OpenVPN client on unraid as far as port forwards are concerned. Has anyone gotten this to work properly?
Thanks much
No problem with hijacking the conversation, you post is totally relevant.
To quickly answer question 2, no I am not aware of any way to have port forwarding working for torrents over a vpn link. I was able to get this to work using Private Internet Access' own software on the Mac, but only on a few (I believe it was Cananda and Netherlands) server addresses, and even then, the port changes every hour or so, requiring constant changes to your torrent client.
Private Internet Access did have some forum discussion about a scripted way to identify the port, and then adjust your torrent client when a change is detected, but I never managed to get this to work myself.
Having said that, I don't really think that port forwarding is necessary any more. I have downloaded a lot using the setup described in this thread (I'm talking around 1TB in the last few months) and I've never had a problem. My seed ratio is not fantastic, but it's also not 0. With popular torrents it approaches and sometimes exceeds a ratio of 1, and if I left torrents active I'm sure that the ratio would simply continue to increase.
In short, I'm not sure that it's important, and I'm certainly not worried about it.
For question 1, I'm far from a routing expert, so I can't help too much if that is what's causing your problems. Have you checked the Transmission log to see if it's throwing up any errors relating to the loading of the settings.json file?
You might also want to check that you don't have any remnants of other Transmission plugins hanging around that might be messing with your configuration like @Raidersan did.
I do know that any changes directly to the settings.json file must be done while Transmission is NOT running. If it's running, they'll be overwritten on exit with whatever was there when Transmission started, along with any changes made in the UI. You must first stop, then edit the file, then restart.
-
I'll take a look at this later today @Raidersan. Apologies for taking so long to get back to you, but I think we're very nearly there.
-
Yes indeed I can copy to folders just not to the root of the drive. Since I normally have folders is why I didn't much care.
Sent from my Nexus 7 using Tapatalk
Yeah I hear you with attempting to figure out all the VM stuff! I re-read Nezil posts and it sounds like I may be able to create folders as long as I am not in the root of my mounted drive. I'll have to mess around with this tomorrow though.
The reason that you're unable to create folders in the root of the share, is because the ownership of the folder on the unRAID system is probably root:root, with default permissions of drwxr-xr-x:
I added the following command to my plugin to solve this problem:
[pre]chgrp users /apps
chmod g+w /apps [/pre]This changes the ownership to root:users, and makes the directory writable for members of the group users. The user that connects to the SMB share is a member of the users group, and is therefore able to write to the root of the share.
By the way, the commands should be issued, I think, after the drive is mounted, rather than before. This might not be necessary, but that's how I did it.
-
Thanks, I have a meeting I need to go to now, so it would be great if you're able to diagnose it yourself.
If it helps, the output of those commands on my system with vpn disconnected is as follows:
root@unRAID:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.16.17.1 0.0.0.0 UG 1 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo 172.16.17.0 * 255.255.255.0 U 0 0 0 eth0 root@unRAID:~# ip route show default via 172.16.17.1 dev eth0 metric 1 127.0.0.0/8 dev lo scope link 172.16.17.0/24 dev eth0 proto kernel scope link src 172.16.17.3
And with route-up.sh disabled, so the default routing from my vpn provider only:
root@unRAID:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 10.152.1.5 128.0.0.0 UG 0 0 0 tun0 default 172.16.17.1 0.0.0.0 UG 1 0 0 eth0 10.152.1.1 10.152.1.5 255.255.255.255 UGH 0 0 0 tun0 10.152.1.5 * 255.255.255.255 UH 0 0 0 tun0 loopback * 255.0.0.0 U 0 0 0 lo 128.0.0.0 10.152.1.5 128.0.0.0 UG 0 0 0 tun0 172.16.17.0 * 255.255.255.0 U 0 0 0 eth0 198.23.103.88-s 172.16.17.1 255.255.255.255 UGH 0 0 0 eth0 root@unRAID:~# ip route show 0.0.0.0/1 via 10.152.1.5 dev tun0 default via 172.16.17.1 dev eth0 metric 1 10.152.1.1 via 10.152.1.5 dev tun0 10.152.1.5 dev tun0 proto kernel scope link src 10.152.1.6 127.0.0.0/8 dev lo scope link 128.0.0.0/1 via 10.152.1.5 dev tun0 172.16.17.0/24 dev eth0 proto kernel scope link src 172.16.17.3 198.23.103.88 via 172.16.17.1 dev eth0
This should give you some indication of what is created and deleted by the route-up.sh. There is some things left over in the routing actually, because the route-up.sh removes some things before it adds others. I don't have time now to get a clean, route-up.sh disabled output I'm afraid.
-
You're right, something is wrong with the routing.
Can you show me the output of the following commands, I'm showing mine for reference:
root@unRAID:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.16.17.1 0.0.0.0 UG 1 0 0 eth0 10.151.1.1 10.151.1.5 255.255.255.255 UGH 0 0 0 tun0 10.151.1.5 * 255.255.255.255 UH 0 0 0 tun0 loopback * 255.0.0.0 U 0 0 0 lo 172.16.17.0 * 255.255.255.0 U 0 0 0 eth0 198.23.71.90-st 172.16.17.1 255.255.255.255 UGH 0 0 0 eth0
root@unRAID:~# ip route show default via 172.16.17.1 dev eth0 metric 1 10.151.1.1 via 10.151.1.5 dev tun0 10.151.1.5 dev tun0 proto kernel scope link src 10.151.1.6 127.0.0.0/8 dev lo scope link 172.16.17.0/24 dev eth0 proto kernel scope link src 172.16.17.3 198.23.71.90 via 172.16.17.1 dev eth0
I think the next thing to do would be to manually walk through the stages of the route-up.sh script and see where it's stumbling. It looks like the default route for eth0 is not being set up correctly.
-
My STUPID mistake, I guess I rushed getting the plugins up for the previous poster, and didn't bother to reboot my own system to check. I'd updated my rc.transmission file for testing, and hadn't put all of the changes into the plugin.
Here is an updated file; you shouldn't have to reboot to get it to work, just delete your /etc/rc.d/rc.transmission file, as well as your /boot/config/plugins/transmission folder, then run:
[pre]installplg /boot/config/plugins/Transmission-2.82r14243-i486-4nr.plg[/pre]Download the updated plugin from here: https://dl.dropboxusercontent.com/s/c3f84xqs4c8ksr5/Transmission-2.82r14243-i486-4nr.plg
-
You're correct that the configuration file should have PORT and ROUTE_VPN parameters included, and transmission will of course fail to load without a port defined.
It's strange that these appear to be getting wiped for some reason... let me check the plugin one more time...
-
Your current .ovpn file looks like this (so you say):
#default privateinternetaccess ovpn lines client proto udp dev tun remote vpn.btguard.com 1194 resolv-retry infinite nobind persist-key persist-remote-ip persist-tun 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 btguard.ca.crt auth-user-pass /mnt/cache/.apps/openvpn/password.txt # Change routing behaviour script-security 3 route-delay 5 route-up "/mnt/cache/.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 default recommended btguard .ovpn file looks like this:
client dev tun proto udp remote vpn.btguard.com 1194 resolv-retry infinite nobind persist-key persist-tun ca /etc/openvpn/btguard.ca.crt verb 3 mute 3 auth-user-pass mute-replay-warnings float reneg-sec 0
I'd therefore modify it to look like this:
# Default btguard configuration client dev tun proto udp remote vpn.btguard.com 1194 resolv-retry infinite nobind # Change routing behaviour script-security 3 route-delay 5 route-up "/mnt/cache/.apps/openvpn/route-up.sh" # Continue default btguard configuration persist-key persist-tun # ca /etc/openvpn/btguard.ca.crt verb 3 mute 3 # auth-user-pass # mute-replay-warnings float reneg-sec 0 # Provide full paths to certificate and passwords files ca /mnt/cache/.apps/openvpn/btguard.ca.crt auth-user-pass /mnt/cache/.apps/openvpn/password.txt # Set location of Status Log status /tmp/openvpn/openvpn-status.log # Add code to re-connect if link drops keepalive 10 60
-
Are you absolutely sure that the .ovpn file you pasted is the one being called? I can see that the route-up.sh is definately being called correctly, but part of the problem is that your vpn provider is not giving your unRAID machine a correct routing table for itself.
I can also see that the .ovpn file you attached is resulting in quite a verbose openvpn.out file, but it is only set to verb 1.
I'm going to have a look at what a standard settings file from your provider should look like, because this might help.
This an excerpt from my openvpn.out log file with verb 3 set, which shows the full routing when the VPN connects initially, before any modifications are made by the route-up.sh script:
Tue May 20 11:13:11 2014 ROUTE_GATEWAY 172.16.17.1/255.255.255.0 IFACE=eth0 HWADDR=d0:27:88:59:8f:8b Tue May 20 11:13:11 2014 TUN/TAP device tun0 opened Tue May 20 11:13:11 2014 TUN/TAP TX queue length set to 100 Tue May 20 11:13:11 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Tue May 20 11:13:11 2014 /usr/sbin/ip link set dev tun0 up mtu 1500 Tue May 20 11:13:11 2014 /usr/sbin/ip addr add dev tun0 local 10.151.1.6 peer 10.151.1.5 Tue May 20 11:13:16 2014 /usr/sbin/ip route add 198.23.71.90/32 via 172.16.17.1 Tue May 20 11:13:16 2014 /usr/sbin/ip route add 0.0.0.0/1 via 10.151.1.5 Tue May 20 11:13:16 2014 /usr/sbin/ip route add 128.0.0.0/1 via 10.151.1.5 Tue May 20 11:13:16 2014 /usr/sbin/ip route add 10.151.1.1/32 via 10.151.1.5 ------------------------------------------------------------------ 0.0.0.0/1 via 10.151.1.5 dev tun0 default via 172.16.17.1 dev eth0 metric 1 10.151.1.1 via 10.151.1.5 dev tun0 10.151.1.5 dev tun0 proto kernel scope link src 10.151.1.6 127.0.0.0/8 dev lo scope link 128.0.0.0/1 via 10.151.1.5 dev tun0 172.16.17.0/24 dev eth0 proto kernel scope link src 172.16.17.3 198.23.71.90 via 172.16.17.1 dev eth0 ------------------------------------------------------------------
As you can see, four additional ip route commands are issued by openvpn immediately after connection, your openvpn.out log doesn't show any of these, and I believe that is the source of your problems.
There is an option that can be put in the .ovpn file that stops this from happening, and that might be what's causing this behaviour (route-nopull), which is why I'm questioning if you really are using the correct .ovpn file.
-
Oh it definitely is if you got that result...
Let me take another look at your files and logs.
-
Well those files both look OK to me.
One thing that is concerning is that your openvpn.out log shows a couple of lines at the point of one of the ip commands:
[pre]RTNETLINK answers: No such process[/pre]I would only expect this to happen if you weren't actually running my custom kernel.
Could you check if you are indeed running the custom kernel? To do this, issue the following two commands and tell me what you see:
[pre]ip rule list[/pre]On my system, with my vpn running, I see the following:
0: from all lookup local 32765: from 10.112.1.6 lookup vpn 32766: from all lookup main 32767: from all lookup default
If my custom kernel is not running, you would see this:
RTNETLINK answers: Operation not supported Dump terminated
In case this is the problem, you need to make sure that my custom kernel files are being linked in the syslinux.cfg file. Since my custom kernel files are called bzimaged and bzrootd, it's not as simple as just putting the files in the root folder on the flash drive. You could rename them bzimage and bzroot and then reboot, but you'd probably want to backup the original bzimage and bzroot files before you do that.
In my case, I've set my custom kernel files as the default, but retained the original files as options that I could select at boot. My syslinux.cfg file therefore 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
-
Good work getting this far @Raidersan!
You're correct that the unRAID settings page taking a long time to load would be as a result of lookup of IP address. To be honest, I wasn't sure about putting these into the webUI, but thought it was useful (when everything is working correctly!).
I think the most likely issue is that your route-up.sh script is at fault, or your .ovpn file that calls it. You cannot run the route-up.sh script directly, because when it is run, certain variables are passed to it that are required for commands to work correctly; the only way that route-up.sh will work is when it's called by openvpn.
Although you've provided quite a lot of terminal output, you've not given me copies of the two files that I need... Could you paste up the contents of your .ovpn file, and your route-up.sh file please.
-
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 DROPNow 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.
-
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!
- Switch out to my Sickbeard plugin (making sure to backup your settings etc.)
-
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).
-
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!
-
One last thing to do, might be to add the smb-extra.conf information to the plugin. I don't need it myself because I'd already created the file, but for it to be truly usable as a plugin by other users, this would be necessary.
If anyone would like that doing, please let me know, and I'll look at creating a fully fledged plugin for the purpose.
[Support] activ - TransmissionVPN
in Docker Containers
Posted
@activ,
I removed and re-created a new Docker, and everything is working great.
I didn't spend much time debugging the previous instance of the Docker, so I'm not sure what I'd done to mess it up there, but the important thing is that the new one is working so I'm happy.
Thanks for the work creating it!
Me too, though I do admit that the UniFi controller UI Dashboard pane does look disappointingly empty without any swithes or routers in it. How often do you look at that though, once it's up and running...