Release 4.3.0: Newer OpenVPN and Transmission

[haugene]

The main update in this release is that we're changing the base image from Ubuntu 20.04 to 22.04 🎉
This means that we're moving from Transmission 2.94 to 3.00, and OpenVPN 2.4.7 to 2.5.5.

There's also a fix for an issue that has been affecting NordVPN users in the last few releases #2404

On the non-functional side we're moving the image builds from CircleCI to GitHub actions both because there was a time limit that caused problems for the beta builds and that it will bring the CI/CD stuff closer to the code. We're already using GitHub for repo hosting, discussion board and issue tracking so we gather more in that ecosystem.

The latter also meant that I had to rewrite the build pipelines and we're changing the image tag strategy ever so slightly. We're relying on the docker/metadata-action to generate tags for us instead of doing it in a custom way, conventions over configuration! latest will now point to the latest release rather than the latest commit on master branch. Apart from that it will be pretty similar. edge will be the latest commit on master branch (soon main branch I suspect), and we will also tag each build with the branch name as well so dev will still be dev.

Let's see how it goes. Need to make this release to see that all the tags appear as they should 🤞

---

This discussion was created from the release Release 4.3.0: Newer OpenVPN and Transmission.

[haugene]

There was an error with the triggering of GitHub Actions. Fixed in 4.3.1 👍
So 4.3.0 won't exist, but 4.3 will and also 4.3.1 😄

[tmknight]

No issues encountered with my Nord container. Reminder that Privoxy is "upgraded" to 3.0.33...fixes and new features (https inspection being the most significant).

[dankrr]

No issues encountered with my Nord container. Reminder that Privoxy is "upgraded" to 3.0.33...fixes and new features (https inspection being the most significant).

My privoxy has stopped working recently and not sure why. Was working on previous builds. Tried looking around for a solution with no luck

[tmknight]

Hard to tell based on what you've shared (and I have my own custom configs for Privoxy, so not sure what is default for the image), though, maybe you need to re-configure the bind address to 0.0.0.0 in the config file.

[petebanham]

Unfortunately 4.3.x broke it for me. Running on a Pi using pureVPN. Container starts and logs shows the VPN initialisation completes fine then nothing, Transmission doesn't start . Docker shows the container as unhealthy and server does not respond on port 9091. Rolled back to 4.2 and it works again

[petebanham]

Sorry for the delay in reply , I have been working away from home for a few weeks. Here is my config, pinned to v4.2

transmission:
    container_name: transmission
    image: haugene/transmission-openvpn:4.2
    ports:
      - '9091:9091'
    environment:
      TZ: 'Europe/London'
      OPENVPN_PROVIDER: PUREVPN
      OPENVPN_CONFIG: de2-ovpn-tcp
      OPENVPN_USERNAME: *******
      OPENVPN_PASSWORD: *******
      DISABLE_PORT_UPDATER: 'true'
      WEBPROXY_ENABLED: 'false'
      TRANSMISSION_DOWNLOAD_DIR: /nas/complete/
      LOCAL_NETWORK: 192.168.5.0/24
      DROP_DEFAULT_ROUTE: 'true'
      TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED: 'false'
      OPENVPN_OPTS: --inactive 3600 --ping 10 --ping-exit 60
    volumes:
      - '/home/pi/nas/:/nas/'
      - '/home/pi/nas/trans/:/config'
      - '/home/pi/nas/trans/:/data' 
    cap_add:
      - NET_ADMIN
    logging:
      driver: json-file
      options:
        max-size: 10m
    restart: unless-stopped

[petebanham]

Really sorry to rake this up again but I have not been able to upgrade past 4.2 as I still get this same issue. At the end of the startup script when Transmission should start, I get
RTNETLINK answers: No such process
Anyone have any ideas please as I am well out of date on v4.2 now.
Thanks

[petebanham]

My current config is below, I have tried separating out the config and data directories, moving home to /config and also using the default openvpn config and it still doesn't work if I remove the 4.2 tag
transmission: container_name: transmission image: haugene/transmission-openvpn:4.2 ports: - '9091:9091' environment: TZ: 'Europe/London' OPENVPN_PROVIDER: PUREVPN OPENVPN_USERNAME: ******* OPENVPN_PASSWORD: ******* DISABLE_PORT_UPDATER: 'true' WEBPROXY_ENABLED: 'false' TRANSMISSION_DOWNLOAD_DIR: /nas/complete/ LOCAL_NETWORK: 192.168.5.0/24 DROP_DEFAULT_ROUTE: 'true' TRANSMISSION_SCRAPE_PAUSED_TORRENTS_ENABLED: 'false' OPENVPN_OPTS: --inactive 3600 --ping 10 --ping-exit 60 volumes: - '/home/pi/nas/:/nas/' - '/home/pi/nas/trans/config:/config' - '/home/pi/nas/trans/data:/data' cap_add: - NET_ADMIN logging: driver: json-file options: max-size: 10m restart: unless-stopped

[petebanham]

Okay so I have finally found my problem, from this version (v4.3) the DROP_DEFAULT_ROUTE=true stops Transmission from starting. At least it does with my PUREVPN config. Without it, from within the container the ip -r command shows the default route as:
4.2
default via 172.22.0.1 dev eth0
and from 4.3 it is
default via 10.1.191.1 dev tun0
So pre 4.3, PureVPN is setting the default route outside of the tunnel so needs the DROP_DEFAULT_ROUTE to get rid of that, but from 4.3 it seems to set it to the tunnel and the flag causes the startup to fail.
@haugene I'm assuming this isn't a bug but don't know if it also affects other providers so not sure if it warrants a separate thread rather the being buried in this release notification? Thanks for all your work on this. Pete

[pkishino]

Considering 4.x is old now, please open a new issue, possibly on vpn provider repo when you test this with 5.x

[Schabernack]

Just noting: The Transmission upgrade from 2.94 to 3.00 introduced serious memory leak issues for me. Containers would relatively quickly grow in memory use and eventually crash, sometimes taking the whole system with them.

Pinned an earlier version and no more crashes. I might just wait for the upgrade to Transmission 4.0 which hopefully improves resource use

[forkless]

Idem ditto. I am running Docker (2.10.3-1308 on a Synology NAS). The 3.0 Transmission client was crashing multiple times a day, reverting back to the 4.2 tag brought back the stability.

[ameinild]

I'm also experiencing a large memory leak - has opened an issue.

It seems there is a fix in a later build of Transmission 3, and also in the upcoming Transmission 4.

[pkishino]

I can warmly recommend the 4.0 beta on the beta branch! Works great, been running it for weeks

[ameinild]

Thanks pkishino - will try that out. 👍

[lukemcguire]

Hey, I realize that I'm a little late on this but it's been a while since I've updated things. I remember when the Transmission client got downgraded from v3.00 to v 2.94 back in 2021 there were some issues with hashes not verifying and some files being forced to re-download. This can be especially problematic for some of the private trackers out there. Will the same thing happen going up from 2.94 to 3.00 this time?

[haugene]

Have had no reports on that. And transmission has most probably made it backwards compatible so that upgrading versions is ok. It's another thing to suddenly revert back to an older version that knows nothing about the new hashing. So I don't know for sure, but it would surprise me if that caused any issues. Taking a backup of the transmission-home folder is always nice when doing upgrades. That way you know you can get back if anything goes wrong. Has never happened to me, but one day I guess I'll be happy to have it :) søn. 12. mar. 2023, 19:28 skrev Luke McGuire ***@***.***>:

…

Hey, I realize that I'm a little late on this but it's been a while since I've updated things. I remember when the Transmission client got downgraded from v3.00 to v 2.94 back in 2021 there were some issues with hashes not verifying and some files being forced to re-download. This can be especially problematic for some of the private trackers out there. Will the same thing happen going up from 2.94 to 3.00 this time? — Reply to this email directly, view it on GitHub <#2411 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH5ODVLBP72MFEUZZKTBMLW3YPV3ANCNFSM6AAAAAASCHEWSY> . You are receiving this because you authored the thread.Message ID: <haugene/docker-transmission-openvpn/repo-discussions/2411/comments/5282919 @github.com>