activ

Community Developer
  • Posts

    126
  • Joined

  • Last visited

Everything posted by activ

  1. I was hoping that might fix it Hopefully the improvements in the new scripts will make it worth the effort. Sorry it didn't work before and thanks a lot to both of you for helping me troubleshoot.
  2. So a manual start works? I've just pushed a new version again with some extra log information that will at least tell us which of the two start lines is used.
  3. The new version is up, could one of you see if it fixes the problem?
  4. I think I found something. Can't test because I don't have PIA, but a new version will be online in a few minutes.
  5. @nexusmaniac: Could you try starting it manually? Maybe we'll get an error message or something. b.t.w.: 10 minutes is the sleep time of the script, that's why it's 10 minutes.
  6. Yup, and pointed to the Toronto node: ca-toronto.privateinternetaccess.com Could you do the same checks Nexusmaniac has done? I'm thinking this has something to do with the PIA specific part of the code. (Maybe your is also working after waiting 10 minutes)
  7. The part of the script that starts it is this echo "[info] Attempting to start transmission..." echo "[info] Removing any transmission session lock files left over from the previous run..." rm -f /config/transmission/session/*.lock if [[ "${VPN_PROV}" == "pia" || -n "${VPN_INCOMING_PORT}" ]]; then # run tmux attached to transmission, specifying listening interface and port /usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n transmission /usr/bin/transmission-daemon "--foreground" "--config-dir" "/config" "--allowed" "${WHITELIST}" "--bind-address-ipv4" "${transmission_ip}" "--peerport" "$transmission_port"" else # run tmux attached to transmission, specifying listening interface /usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n transmission /usr/bin/transmission-daemon "--foreground" "--config-dir" "/config" "--allowed" "${WHITELIST}" "--bind-address-ipv4" "${transmission_ip}"" fi echo "[info] transmission started" You will of course have to replace the variables.
  8. That's what I thought, the initial start is failing and after 10 minutes the script notices transmission is not running and starts it. Now for the real question, why is it not starting the first time. As far as I know the command for the restart is the same as the start.
  9. Sorry, the command should be: docker exec -it Transmission ps -A The weird thing in the log is that at 12:13 transmission is started, but then at 12:23 it's determined to be not running and restarted. Maybe the initial start is failing for some reason. could you try the ps command in the first 10 minutes? 2017-01-29 12:13:55,735 DEBG 'transmission-script' stdout output: [info] transmission started 2017-01-29 12:23:55,876 DEBG 'transmission-script' stdout output: [info] transmission not running
  10. okay, so the network tunnel is working. Maybe do a docker exec -it Transmission ifconfig ps -A to see if transmission is running too
  11. Hmm, nothing weird in there. I'm pretty sure the issue is with the vpn and Transmission doesn't even get started. Maybe put the dns as NAME_SERVERS=8.8.8.8,8.8.4.4 while we figure this out, thats what I have. I don't know how good you are with cli, but can you ssh into the unraid server and run the below command? (it assumes the container is called arc-transmissionvpn) The output should include a network interface called tun0 if the vpn is working. docker exec -it arch-transmissionvpn ifconfig p.s. did the trouble for you also start with updating Unraid?
  12. Could you post your settings? (user and password excluded of course)
  13. That makes it a bit tricky, I don't have an Unraid machine to test on anymore. Since it's broken anyway you could try removing it and doing a clean install from scratch.
  14. I think the real reason you cannot access the web interface is that transmission is not started. I'm not even sure the vpn in actually connecting. Which version are you on? Is it the one form yesterday or from before? Did you just update unraid and it stopped working or did you also update the container? At the moment there are two versions available: Version 1.0 - The version that has been up for the last few months Latest - The version I updated today with new scripting from Binhex for disconnect handling and such.
  15. Okay guys and girls, I hope I got the kinks out enough to now share the new version. The new version is based on the latest scripting by Binhex and it has auto reconnect etc. It does however also need more info passed into the container, so make sure you add the right variables. More info here: https://github.com/activ/arch-transmissionvpn Example: docker run -d \ --cap-add=NET_ADMIN \ -p 9091:9091 \ -p 8118:8118 \ --name=<container name> \ -v <path for data files>:/data \ -v <path for config files>:/config \ -v /etc/localtime:/etc/localtime:ro \ -e VPN_ENABLED=<yes|no> \ -e VPN_USER=<vpn username> \ -e VPN_PASS=<vpn password> \ -e VPN_REMOTE=<vpn remote gateway> \ -e VPN_PORT=<vpn remote port> \ -e VPN_PROTOCOL=<vpn remote protocol> \ -e VPN_DEVICE_TYPE=<tun|tap> \ -e VPN_PROV=<pia|airvpn|custom> \ -e STRONG_CERTS=<yes|no> \ -e ENABLE_PRIVOXY=<yes|no> \ -e LAN_NETWORK=<lan ipv4 network>/<cidr notation> \ -e NAME_SERVERS=<name server ip(s)> \ -e WHITELIST= <example 192.168.*.*> \ -e DEBUG=<true|false> \ -e PHP_TZ=<php timezone> \ -e PUID=<uid for user> \ -e PGID=<gid for user> \ activ/arch-transmissionvpn
  16. The missing mangle support is not your issue, it should still work without. Do you have a more complete log?
  17. There was a bad version up for a while yesterday, just grab the current version and it should work again. Sorry
  18. @Binhex: I've been digging into your updates docker to make a new version of my own. Am I right is thinking that you check processes, ports and IP addresses, but not the actual connection or tunnel interface?
  19. Thanks for the tip, I'll have a look at implementing your changes when I have some time.
  20. I have the same issue, it doesn't seem to reconnect. The docker uses OpenVPN cli to connect, and I guess that doesn't automatically reconnect. I've been meaning to research options to trigger a reconnect automatically, but haven't found the time. If you have a proposed change in the docker to fix if let me know and I'll paste it in.
  21. For the questions about the caliber stuff it's probably best to go to their git. For updates of the version in the container I trigger a new build every once in a while, if a new version contains something you need just post here and I will trigger a new build.
  22. Looks like you have Some leftovers from a previous install. Try fully removing it using donker cli.