SUMMARY DigiKam on openSUSE Tumbleweed fails to connect to MySQL database after the latest update, although the connection works fine from a Windows client. (If I do roll back to previous version, the connection is OK). STEPS TO REPRODUCE 1. Configure DigiKam to use a MySQL/MariaDB database. 2. Attempt to connect to the database from Digikam on openSUSE Tumbleweed. 3. Observe that DigiKam fails to connect, while the same credentials work with the mysql command-line client on the same machine and from a Windows client. OBSERVED RESULT DigiKam fails to connect to the MySQL database with an "Database connection test was not successful. Error was: TLS/SSL error: Certificate verification failure: The certificate is NOT trusted. QMYSQL: Unable to connect" error despite successful connections from both the mysql command-line client (CLI) and a Windows client DigiKam. EXPECTED RESULT Digikam should be able to connect to the MySQL database without any issues. SOFTWARE/OS VERSIONS Client: plasmashell 6.3.4 digikam 8.6.0 (Release 3.1) kernel 6.14.4-1-default Server: mysql Ver 15.1 Distrib 10.11.9-MariaDB, for Linux (x86_64) using EditLine wrapper openSuse Leap 15.4 kernel 6.4.0-150600.23.47-default ADDITIONAL INFORMATION MySQL/MariaDB service is running and accessible. The user has the correct privileges for access from any host (%). Firewall has been disabled and does not affect the connection. The issue started after a recent system update on openSUSE Tumbleweed
This isn't something digiKam can fix. If it occurred after a system update, this is where the problem should be located. Do you use MySQL over the Internet? If locally, why is it encrypted? Maik
Perhaps one more hint: to create an encrypted connection with digiKam, you must specify the appropriate connections options (certificates, keys, etc.). Maik
A typical connection option to use an SSL server (from the Qt Doc): "SSL_KEY=client-key.pem;SSL_CERT=client-cert.pem;SSL_CA=ca-cert.pem;CLIENT_IGNORE_SPACE=1" Maik
(In reply to Maik Qualmann from comment #1) > This isn't something digiKam can fix. If it occurred after a system update, > this is where the problem should be located. > Do you use MySQL over the Internet? If locally, why is it encrypted? > > Maik No, the MySQL is hosted on server in local network.
(In reply to Maik Qualmann from comment #3) > A typical connection option to use an SSL server (from the Qt Doc): > > "SSL_KEY=client-key.pem;SSL_CERT=client-cert.pem;SSL_CA=ca-cert.pem; > CLIENT_IGNORE_SPACE=1" > > Maik Thank you. I don't need to use ssl to connect to the server. It looks like ssl is required after the upgrade.
I'm using openSUSE Tumbleweed, and so far, SSL hasn't been automatically enabled for the MariaDB server. It must be a bug in the server configuration. Simply disable SSL again or submit a bug report to openSUSE if one doesn't already exist. Maik
Good thing I haven't updated yet: https://bugzilla.opensuse.org/show_bug.cgi?id=1227311 Maik
Oh, that was a bug from 2024... Maik
I've fully disabled ssl on mariadb server, but I still can´t connect. It seems to me, that Digikam some how enforces the ssl (on client side)... is it possible? MariaDB [digikam]> SHOW VARIABLES LIKE 'have_ssl'; +---------------+----------+ | Variable_name | Value | +---------------+----------+ | have_ssl | DISABLED | +---------------+----------+ 1 row in set (0,002 sec) MariaDB [digikam]> SHOW VARIABLES LIKE 'require_secure_transport'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | require_secure_transport | OFF | +--------------------------+-------+ 1 row in set (0,001 sec)
No, digiKam doesn't initiate an SSL connection. I'll update my Thumbleweed and then we'll see. Maik
I've opened a bug report in opensuse bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1242910 but still did not succeed.
I'm also up to date with Tumbleweed and haven't noticed any changes. However, my MariaDB is on the same machine as digiKam. Because I'm testing AppImages, I'm using the local 127.0.0.1 address instead of localhost. Is Tumbleweed a client for you, and the MariaDB server on a different machine? Maik
MariaDB is on different machine (openSuse Leap).
According to the Qt docs, "MYSQL_OPT_SSL_MODE=SSL_MODE_DISABLED" is specified. The problem is that this connection option is only supported by MySQL, not MariaDB. When I look at the Qt source code, I don't see a valid option for MariaDB. Maik
Yes, the MYSQL_OPT_SSL_MODE=SSL_MODE_DISABLED didn´t work. I've set up the ssl, so I can now connect to db. It might be useful to update the Digikam documentation and make it clear, that for remote mariadb is required to use ssl.
I guess this is a new mariadb feature and not a bug. Thank you for your time and help.
Tomas, I hope it's ok if I jump into this ticket - I ran into the same problem after last Tumbleweed update. Would mind directing me to some information what needs to be done to set up ssl / TLS correctly? I understand that mariadb does this for a long time already by default (using self-generated certificates), so I guess I'd need to change my digikam database configuration? Thanks - Karsten
I second the request for info on how to properly configure this setup. I have DigiKam 8.6 running on Windows 11 connecting to a MariaDB instance running 10.3.39 on a remote AlmaLinux 8.10 system. That system does have some LetsEncrypt certificates on it, but would prefer to configure the database connection to not rely on the certs. I'd greatly appreciate the additional info needed to use this. The initial database creation worked well, as did the initial photo directory location, however after that subsequent starts of DigiKam result in the same mysql.dll error as was earlier reported.
I've been able to resolve my problem in the meantime - 1st of all, I was wrong in assuming that the mariadb version installed on my server already provides TLS connections with self-generated certificates - this is only with a very recent version of mariadb I cannot use for other reasons (not supported with nextcloud) - So I configured mariadb TLS with the certificates I'm using for a web server on the same machine. This did the trick, and digikam connects to its databases again. No changes needed in digikam's database configuration.
Could someone that's managed to get this working provide additional details about how they performed the mariadb configuration? I've been beating my head against a wall trying and so far I've been entirely unsuccessful. I'd really like to get this resolved so I can get this working across multiple systems accessing the same images.
hi Chad, have a look at https://mariadb.com/docs/server/security/securing-mariadb/securing-mariadb-encryption/data-in-transit-encryption/secure-connections-overview Assuming you already have TLS certificates (e.g. from letsencrypt) set up on the server that hosts the mariadb server, these are the steps that worked for me: - on the server, locate the / a mariadb configuration file (there may be more than one, which may all be evaluated) => in my case (under debian), I used '/etc/mysql/mariadb.cnf' - look for the section '[mariadb]' (if there is none, create it by putting [mariadb] at the beginning of an empty line) - In this section (so it existed) you should find a few commented-out lines, such as #ssl_cert = /etc/my.cnf.d/certificates/server-cert.pem #ssl_key = /etc/my.cnf.d/certificates/server-key.pem #ssl_ca = /etc/my.cnf.d/certificates/ca.pem - Add the links to your existing TLS certificates - in my case these were ssl_cert = /etc/letsencrypt/live/<name of the server>/cert.pem ssl_key = /etc/letsencrypt/live/<name of the server>/privkey.pem => note that I have not added the link to the ca.pem - this should not be needed for letsencrypt certificates - now restart mariadb to evaluate the modified configuration using your OS'es mechanism - in my case: sudo systemctl restart mariadb - if you wish, you may check if TLS was actually enabled: - login to mariadb with your admin account: sudo mariadb -u <admin name, e.g. root> -p => you will be prompted for your admin password - on the mariadb prompt, enter SHOW GLOBAL VARIABLES LIKE 'have_ssl'; (the semicolon needs to be there) - you should see something like +----------------------+-----------+ | Variable_name | Value | +----------------------+-----------+ | have_ssl | YES | +----------------------+-----------+ - exit mariadb: exit; That's it - digikam should now start, assuming that its databases had been created correctly.
So this is still NOT working. Same database server on 8.4 works just skippy. 8.5, 8.6, or 8.7 all fail. I've configured SSL: MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'have_ssl'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | have_ssl | YES | +---------------+-------+ MariaDB [(none)]> status -------------- mysql Ver 15.1 Distrib 10.3.39-MariaDB, for Linux (x86_64) using readline 5.1 SSL: Cipher in use is TLS_AES_256_GCM_SHA384 I set up a single database `digikam`. I dropped the old one entirely, and did all the grants per the setup. MariaDB [digikam]> show tables; +--------------------+ | Tables_in_digikam | +--------------------+ | AlbumRoots | ...... +--------------------+ 32 rows in set (0.000 sec) So clearly the initial tables are able to be created. Alas, Event Viewer still shows: Faulting application name: digikam.exe, version: 8.6.0.0, time stamp: 0x67d47119 Faulting module name: libmysql.dll, version: 8.0.40.0, time stamp: 0x679767b8 Exception code: 0x80000003 Fault offset: 0x000000000006e722 Faulting process id: 0x1f7c Faulting application start time: 0x01dbeae03b70658f Faulting application path: C:\Program Files\digiKam\digikam.exe Faulting module path: C:\Program Files\digiKam\libmysql.dll No idea why it keeps doing this, but it would seem that since it's starting with a blank database, and adding tables, the communication to the DB is at least somewhat functional. Literally as I start digikam it'll show up in the task list for about 2-3 second before it silently quits. I'm installing the "debug" version of 8.7 so if there's anything that can be done to help with troubleshooting this "not a bug" that'd be great. It's been crazy hard to set up an external database, as there's not much troubleshooting info for an external database. I need an external DB because I'm going to be using different systems to manage the same photos, so having the common external database is the only realistic option for me, but the days of head scratching have left me exhausted and frustrated.