uberchuckie
-
Posts
87 -
Joined
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by uberchuckie
-
-
On 4/2/2024 at 6:16 AM, binhex said:
I'm currently on holiday, I shall take a look when I get back on Saturday
Sent from my 22021211RG using Tapatalk
I took a quick look at it. The process fails with:09:12:04 [INFO ][deluge.core.rpcserver :1622] Starting DelugeRPC server :58846 09:12:04 [ERROR ][deluge.core.daemon_entry :1622] Unable to start deluged: [('SSL routines', '', 'ee key too small')] 09:12:04 [INFO ][deluge.core.daemon_entry :1622] Exiting...My guess the problem is with the deluge daemon cert key pair: https://github.com/binhex/arch-delugevpn/blob/master/config/nobody/webui/web.conf
The cert from my setup is from 2017 and it expired in 2021. It's also RSA 1024 bit.
-rwxrwxr-x 1 nobody users 623 Oct 15 2017 daemon.cert -rwxrwxr-x 1 nobody users 916 Oct 15 2017 daemon.pkey openssl x509 -text -noout -in daemon.cert Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: CN = Deluge Daemon Validity Not Before: Jan 3 19:47:27 2016 GMT Not After : Jan 1 19:47:27 2021 GMT Subject: CN = Deluge Daemon Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:c5:96:5b:59:37:49:f0:ad:a0:0b:8c:9d:28:52: ca:d5:19:1c:57:dd:7f:40:53:d0:99:9b:94:b3:c3: 4f:4e:bc:c4:cd:29:26:5f:da:70:21:ab:e3:e2:a6: 0d:d9:63:ad:1a:6d:14:fd:5b:0b:ec:5f:a5:03:c0: ca:e0:79:a2:7c:c4:64:cf:78:61:00:c5:17:ca:1a: 8a:0c:89:ca:7a:b6:67:c6:73:2c:f6:cf:71:6a:f3: 98:7d:3f:55:95:35:62:48:00:92:64:76:e5:0f:fb: 52:f9:a3:69:93:87:e2:ac:13:4f:73:fd:09:b5:57: e9:a3:cb:5d:ab:d6:bc:da:bd Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption Signature Value: 90:e7:c4:00:4d:98:04:75:6f:46:1a:13:bb:f6:19:52:97:6a: 52:87:86:23:2c:5c:d0:de:a7:94:5a:10:94:a0:86:d4:d7:58: 73:dc:d2:4d:92:b1:26:2c:bc:67:1f:db:61:f9:0d:69:8d:db: 78:4a:8c:67:4e:d5:78:a2:fc:28:25:06:0b:dd:68:33:18:f2: 1c:f8:31:f0:c7:35:44:f8:7e:d0:4b:9d:be:b1:76:9a:40:ee: 02:d2:17:5d:ce:c2:23:b1:28:0b:74:57:72:57:87:8e:ee:34: 3a:d3:ab:e6:1d:82:d6:b9:3f:f2:15:d4:26:47:c9:86:99:6c: 69:aeSince it's on the /config volume mount. I think regenerating the certificate should fix it?
I tried creating a new cert with the existing private key:
openssl x509 -in daemon.cert -signkey daemon.pkey -x509toreq -out daemon.csr openssl x509 -signkey daemon.pkey -in daemon.csr -req -days 3652 -out new.certOverwriting the old cert with the new one didn't fix it. It's the same error.
Maybe I need to use RSA 2048 or larger key size? The "ee key too small" error suggests that's the case?
Generating a new key and CSR, then creating a new certificate:
openssl req -newkey rsa:2048 -nodes -keyout new.pkey -out new.csr openssl x509 -signkey new.pkey -in new.csr -req -days 3652 -out new.certI used CN=Deluge Daemon like the existing certificate but I don't know if certificate verification is on since the old one expired years ago and things were still working.
Again, overwriting the existing daemon.cert and daemon.pkey...
That fixed it! It looks like something in the latest build is preventing private keys with RSA 1024 bit key size to be used. This is probably a good thing since it's not considered to be secure anymore.
-
I'm currently on holiday, I shall take a look when I get back on Saturday
Sent from my 22021211RG using Tapatalk
Thanks. No rush. Rolling back works around the problem.
Sent from my iPhone using Tapatalk -
11 hours ago, chesh said:
Probably to patch the XV library backdoor. But, I'd hold off on updating as the latest version isn't starting completely.
I see the same thing. The container image upgraded about eight hours ago.
The last two lines in the log file is[info] Deluge process started [info] Waiting for Deluge process to start listening on port 58846...
Adding DEBUG=true enabled debug logging but didn't add any more logs after the above.
Rolling back to the 2.1.1-4-05 tag "fixes" it.
xz in the image with that tag is version 5.4.5 (which does not contain the backdoor).
-
1
-
-
@uberchuckie
For me the case is done, I have made a step by step migration on my nine server 7.0.0 is the current version and it runs perfectly.
What was the cause of this error I can only guess, old Unraid version.
Thank you very much for your help and support
Greetings from Switzerland
Toby-CH
So it’s working now after you upgraded unRAID and not just rebooting your server?
Sent from my iPhone using Tapatalk -
On 4/10/2023 at 10:33 AM, Toby-ch said:
Yes Is attached to.
I created a nine container on my other Unraid server. CPU last over 22% Start Log:
In the appendix: New-OBV-Docker.txt
The same as with the migrated container:
eb75344e1cd2.err Is in the appendix
Currently I use 5.0.0 (MariaDB 10.7.4) 7.0.1 requires MariaDB 10.11.2 I think the internal migration does not work.
I hope I was able to help you with this information.The log files show everything worked as expected. The logs you provided are truncated to the last page but no indications that the schema creation or the migration failed.
Which version of or unRAID are you running? Which version of docker? I don't know what else to follow up on. I can't debug something that I cannot reproduce.You may have to try connect to the database through the command line to see if that is the problem.
Is it possible to outsource the MariaDB to a separate Maria DB container? All in one is great but it doesn't seem to work.There are other containers built to use an external database. You'll be better off using those. This container is setup to configure everything automatically.
-
7 hours ago, Snoopy said:
I've only just noticed an issues with the latest docker image. I have SSL email settings defined. PHP is now crapping out with the following:
PHP Fatal error: Uncaught Error: Undefined constant "ssl" in /config/config.php:46
Stack trace:
#0 /opt/observium/includes/sql-config.inc.php(25): require()
#1 /opt/observium/poller.php(19): include('...')
#2 {main}
thrown in /config/config.php on line 46
#Quick fix is to disable SSL authentication for email alerts. Anyone got a better more permanent fix?
The offending config line is
$config['email']['smtp_secure'] = ssl; // Enable encryption. Use 'tls' or 'ssl
Many thanks
Dave
The configuration value needs to be in quotes since it's a string.
It should be like this:
$config['email']['smtp_secure'] = 'ssl'; -
@Toby-ch Can you also attach the contents of `/config/databases/edbf6a8d423d.err`?
If you can try to setup a separate instance in a different appdata directory to see if it's an issue with the database migration or it's a problem with a fresh install as well.
-
6 hours ago, Toby-ch said:
Hello, everyone
I'm still using the version 5.0 because the container died during the last update, a downgrade to 5.0 helped, but does this have to be solved?
It seems like a few people are having problems with builds past 5.0. If you post the container log file and the database log file `/config/databases/<container_id>.err`, we can see if there is something pointing at what's wrong. Without more information, I can't debug the problem as I can't reproduce it. -
On 3/17/2023 at 3:25 AM, ivom said:
Hi, I know this is a long shot, but did you ever find a permanent solution for this?
I just pushed a new build that should work around the problem. It worked for me but let me know how it's working for you.
-
It takes a bit of time to upgrade the schema. If you let it run and still doesn’t work you can try deleting the files in appdata and start from scratch.
-
17 hours ago, uberchuckie said:
Let's hope a 6.5.54 image is released soon. It fixes the Log4j remote code execution vulnerability.
6.5.54 has been built and tagged.
-
Let's hope a 6.5.54 image is released soon. It fixes the Log4j remote code execution vulnerability.
-
1
-
-
15 hours ago, stFfn said:
i´ve tryed to install this docker but it seems like i cant access the webgui.
do i have to do something befor it works?
The UI does come up but for the first run, it takes a minute or two to initialize the database. If you tried to logon right away, it won't work. If you stopped the container while it was still creating the database schema, it won't be initialized properly.
Stop the container, delete the appdata directory for observium and start it again. Wait for the database schema creation to complete. You can monitor it from the log file.
-
On 2/23/2021 at 7:05 AM, Hamsterman said:
Is there any way to change the port.
I noticed that when I run the container behind a proxy (Traefik) it is still requesting parts of the website on port 8668.
@Hamsterman Someone else asked about this and I took a quick look. You can edit the config.php file and change the $config['base_url'] config line to the URL you need.
-
11 hours ago, Hamsterman said:
Is there any way to change the port.
I noticed that when I run the container behind a proxy (Traefik) it is still requesting parts of the website on port 8668.
You can change the host port but not the container port. It's configured and exposed when the container image is created. I assume there are parts of observium that references the port when it builds the URL.
To change the container port, you'll have to fork the repository and run your own image.
-
10 hours ago, salvdordalisdad said:
Hi,
I have a script which updates my DDNS, and uses dig which now throws library errors. Nothing has been updated in a while, so I'm not sure why it's suddenly broken.
Tested on my primary & backup systems & both the same result.
So I'm trying to understand why & fix it, so I ended up here.
I tried your "fix" updating those two libraries, but both those links say "404 file not found".
So I looked closer & used the ones which are there on the slackware repository, but I think that was a bad idea as it hasn't fixed dig or nslookup & gives more errors.
dig now produces several 'GLIBC_2.33' not found messages.
I have no idea what else has broken, and now the nerdtools page shows that those two are "update ready" but they don't update.
I haven't done this fix on my primary system, just the backup system.
I assume this will get fixed in the fullness of time, so I'll await that & find an alternative in the meantime.
Thanks guys.
Use "removepkg" to remove any packages you have manually installed. The Nerd Pack cannot install or upgrade any packages that you have upgraded manually.
-
I created a test image yesterday based on phusion's alpha Ubuntu 20.04 based baseimage. It seems to work from my short testing. The biggest change is upgrading Python to 3.8 from 2.7, the latter of which has reached End-Of-Life awhile back. I've tagged the image as focal-alpha if people want to try it out.
Observium and MariaDB doesn't change in this image so there shouldn't be any differences other than upgraded libraries.
Again, this is just for testing or if you were curious, I wouldn't upgrade right now if you depend on it working correctly.
-
I just checked again, all the timezones are set correctly in my container. I'm still seeing graphs in UTC.
-
On 1/26/2021 at 8:23 AM, Silvan-0172 said:
Hi uberchuckie, thank you for your time and effort in maintaining this container.
I was wondering if the issue with the timezone did get fixed ? Yesterday i installed the container again and set the TZ in the properties but its still showing in UTC. I searched the thread but didnt find a anwser.Kind regards.
Yeah, I don't think anyone has figured it out yet.
-
I fixed the problems with dig and nslookup.
Note that this upgrades json-c.wget http://slackware.cs.utah.edu/pub/slackware/slackware64-current/slackware64/n/krb5-1.18.3-x86_64-1.txzupgradepkg --install-new krb5-1.18.3-x86_64-1.txz
upgradepkg --install-new json-c-0.15_20200726-x86_64-1.txz
/usr/lib64/libjson-c.so.4 is replaced with /usr/lib64/libjson-c.so.5.Package json-c-0.15_20200726-x86_64-1.txz installed. Package json-c-0.13.1-x86_64-1 upgraded with new package ./json-c-0.15_20200726-x86_64-1.txz.I don't know what else relies on the older version of json-c.
ldd $(which dig)linux-vdso.so.1 (0x00007ffebdd8f000)
libdns.so.1608 => /usr/lib64/libdns.so.1608 (0x00001501e86b2000)
libirs.so.1601 => /usr/lib64/libirs.so.1601 (0x00001501e86a5000)
libbind9.so.1600 => /usr/lib64/libbind9.so.1600 (0x00001501e8691000)
libns.so.1605 => /usr/lib64/libns.so.1605 (0x00001501e8648000)
libisccfg.so.1601 => /usr/lib64/libisccfg.so.1601 (0x00001501e8614000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00001501e85c3000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00001501e84eb000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00001501e84bd000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00001501e84b7000)
liblmdb.so.0.0.0 => /usr/lib64/liblmdb.so.0.0.0 (0x00001501e84a0000)
libisc.so.1607 => /usr/lib64/libisc.so.1607 (0x00001501e8425000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00001501e814b000)
libjson-c.so.5 => /usr/lib64/libjson-c.so.5 (0x00001501e8136000)
libuv.so.1 => /usr/lib64/libuv.so.1 (0x00001501e8105000)
libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00001501e7f9f000)
libz.so.1 => /lib64/libz.so.1 (0x00001501e7d88000)
libidn2.so.0 => /usr/lib64/libidn2.so.0 (0x00001501e7d69000)
libdl.so.2 => /lib64/libdl.so.2 (0x00001501e7d64000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00001501e7d40000)
libc.so.6 => /lib64/libc.so.6 (0x00001501e7b5b000)
/lib64/ld-linux-x86-64.so.2 (0x00001501e88e4000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00001501e7b4c000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00001501e7b45000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00001501e7b2a000)
librt.so.1 => /lib64/librt.so.1 (0x00001501e7b1e000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00001501e7b03000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00001501e78dd000)
libm.so.6 => /lib64/libm.so.6 (0x00001501e7790000)
libunistring.so.2 => /usr/lib64/libunistring.so.2 (0x00001501e740e000)
-
1
-
-
On 11/17/2020 at 8:13 AM, dmacias said:On 11/17/2020 at 8:03 AM, cinereus said:host: error while loading shared libraries: liblmdb.so.0.0.0
I also have this host issue.Updated bind. Let me know.
I think the latest bind version broke dig. dig was working on my system before I inadvertently updated it.
(I removed the libraries that are found on the list)
Quoteldd /usr/bin/dig
libgssapi_krb5.so.2 => not found
libkrb5.so.3 => not found
libk5crypto.so.3 => not found
libjson-c.so.5 => not found/usr/lib64/libjson-c.so.4 exists but not version 5. Maybe the latest version of bind added kerberos support from krb5.
/usr/lib64/krb5 only contains winbind_krb5_locator.so
nslookup has the same library dependency issue.
-
9 hours ago, TrueImpulse said:
Guinea pig reporting in.
Switching to WireGuard was simple and worked flawlessly. I'm on the east coast and now getting 800Mbps into Montreal.
Thanks for adding WireGuard to your containers.
Had to buy you that beer for all the hard work you do on all your Unraid containers.
WireGuard working fine for me with PIA as well. Getting much better throughput with WireGuard than OpenVPN. I think it was CPU bound due to OpenVPN being single threaded.
-
1
-
-
16 hours ago, seanwalter said:
@uberchuckie good news...updating my 2.0.2 container to 3.0_beta worked -- my data history is intact, I can connect via the web GUI using my user name and password, etc...
It looks like others are having success as well, though to close the loop, I am using /mnt/cache/appdata for my observium config and other files.
Thank you for sticking with us on this, and working through the issues!
@seanwalter Thanks for helping to debug. You can switch back to the latest tag as all the fixes have been applied to it.
-
The new version 3.0 image is working for me both upgrading from the previous image and from scratch. I've updated the latest tag. Please switch back to the latest tag if you've tested the other tags. Thanks.
[Support] binhex - DelugeVPN
in Docker Containers
Posted
OK. That worked too.
openssl x509 -text -noout -in daemon.cert Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: sha256WithRSAEncryption Issuer: CN = Deluge Daemon Validity Not Before: Apr 6 21:15:29 2024 GMT Not After : Apr 6 21:15:29 2027 GMT Subject: CN = Deluge Daemon Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit)