binhex

OK i see your issue, you have given the container a set ip address, this then causes a clash as the docker network and the lan are then the same, from your log:- 2023-11-08 06:32:02,593 DEBG 'start-script' stdout output: [debug] Docker IP defined as 192.168.4.5 2023-11-08 06:32:02,599 DEBG 'start-script' stdout output: [debug] Docker netmask defined as 255.255.252.0 2023-11-08 06:32:02,935 DEBG 'start-script' stdout output: [info] Docker network defined as 192.168.4.0/22 the fix is either to setup another docker network separate to your lan and use that, or simply switch it back to 'bridge'.

that's a successful start but i see you have overlapping networks defined, from your log:- LAN_NETWORK defined as '192.168.4.0/22, 192.168.4.0/24' change this to be:- LAN_NETWORK defined as '192.168.4.0/22'

I have corrected this, please pull down the latest image, i have confirmed it is now running 10.8.12

a new image has been produced which should sort out the cert issue for you, please pull down latest and let me know.

can you give me details as to the error message, i can then post an issue with the developer of nzbget-ng and get a real fix in place, copying pem files around sounds just plain nasty.

have you confirmed this is still an issue with this image, the fix may not be relevant any more. i have confirmed there are no pem files in the image, so nothing to remove.

hmm that's a bit sad 😞 what issue? the unpack issue?, this won't be fixed by updating a cert.

still going ok?, any unpack issues?

It's for both Sent from my 22021211RG using Tapatalk

try Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/delugevpn.md

Well that IS good news!, I was hopeful it might fix this as we are now compiling from source as opposed to using the pre-compiled 'app', awesome!.

🙂 looks that way doesn't it.

Well in nzbget-ng current state, probably nothing as the download would then need compiling, you would also be performing a rather large downgrade not an upgrade, note the dates:- As you probably are aware i prefer stable releases over new shiny, but in this case we have to go bleeding edge (develop branch - the only branch!) as there are no latest releases, so you are literally running THE latest code available, if releases start to happen on a regular basis then i will switch over to release. I am going to merge this change into main and push out a new image so feel free to target 'latest' again in around 40 mins from this post.

nope, sadly im not using a linux desktop, remote to linux vm's sucks donkeys balls ( i tried several distros and several remote servers, they all are clunky), so im stuck on a windows vm for my dev work for now - beyondcompare is the king for diffing on windows, at least in my opinion it is 🙂 OK new image for you to test (cheers for the config file), please pull down same tagged name again, this one should now correctly fix up your config file, let me know the outcome.

lol, awesome!, any chance you can send it to me minus of course sensitive info so i can test my fix?

hopefully not!, i think i have a fix for the transition issue you had, im hoping you have a copy of the old config before you fixed it up so you can give the fix a go.

sorry i lied!, when i was testing it was creating a brand new config file, so yeah looks like the issue you are having is around transitioning from an existing config file with the old locations of nzbget to the new locations of nzbget-ng, taking a look now....

yep still the same port, i used an existing config file and it simply worked, got anything in the log?

i have been officially poked :-), OK new image created please give it a whirl and let me know, if it looks ok i will merge to main, the tag name is 'nzbget-ng'

I see, so you do need a working incoming port, that is going to be tricky, as i mentioned the port is dynamic for pia (other vpn providers permit static incoming port), so even if you find out what the port is you would then need a programmatic way of configuring soulseek to use it, otherwise you would need to manually reconfigure soulseek each time the port changes. so is it possible?, yes but its going to require some work on your part to configure soulseek.

looks related:- https://www.planetminecraft.com/forums/help/bedrockedition/bedrock-server-smithing-table-error-after-1-20-update-673307/ btw i too see this but i had forgotten about it 🙂

The PIA incoming port is dynamic so every time you restart the container or the vpn drops and re-establishes you may have a new port number, what is it you are trying to achieve?, access a web ui of a container externally?

A quote from the reply:- Already done, it is bound to the vpn interface, and we also specify the vpn adapters ip for incoming, so yeah not much else i can do here unless im missing a setting in the ui. from my previous post:- i see you included this in your post, ok he does go on about setting the incoming adapter but there is no way to do that, you can only set the incoming address, and if you try and force this by editing the core.conf it simply errors, so i dont know how to achieve this, it must be some hackery of libtorrent probably via itconfig i assume.

If this is repeatable (which by the sound of the above it is), then restart the container, wait for the issue to occur and then docker exec inside the container and issue the following command which will reveal your external ip, it should be your vpn provider assigned ip:- curl http://ifconfig.co if it is your vpn provider ip then raise a bug with deluge, detail that you have the vpn provider adapter bound in deluge for 'outgoing interface' and the ip address of the vpn adapter defined for 'incoming address' yet the external ip address shown is your isp ip address and see what they say.

This must be a bug with how deluge detects your external ip address, it is clearly bound to the vpn adapter (as shown in your last screenshot - wg0) and it is advertising your vpn ip, as shown by whatismyip.net, on top of this there are strict ip table rules in place to prevent ip laakage, so there is no way for deluge to connect to peers via your isp connection. FYI i cannot replicate the bug on my system, are you running the latest image?.