uberchuckie

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)

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:ae Since 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.cert Overwriting 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.cert I 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.

Thanks. No rush. Rolling back works around the problem. Sent from my iPhone using Tapatalk

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).

So it’s working now after you upgraded unRAID and not just rebooting your server? Sent from my iPhone using Tapatalk

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.

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.

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.

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.

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.

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.

@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.