Backups via settings fail because mariadbdump attempts to use ssl by default (Not desired).

[ipaqmaster]

Debug mode

• [X] I have enabled debug mode
• [X] I have read checked the Common Issues page

Describe the bug

Taking a backup fails because mariadb-dump attempts to use SSL by default in latent releases which is not the case on this machine's local socket connections.

Reproduction steps

1. Try to take a backup in the Settings area
2. A large error consuming the entire page is spit out, I have attached an excerpt below.

...

Expected behavior

A backup to be created

Screenshots

NA

Snipe-IT Version

Updated to commit c54bff0f83baba2e89e7e20c6af92d9e71c50d63

Operating System

Archlinux (Kernel 6.6.16-1-lts)

Web Server

Nginx 1.26.0-3

PHP Version

8.3.7-2

Operating System

Archlinux

Browser

Firefox

Version

129.0.1

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

Backup failed because: The dump process failed with a none successful exitcode. Exitcode ======== 2: Misuse of shell builtins Output ====== <no output> Error Output ============ /usr/bin/mysqldump: Deprecated program name. It will be removed in a future release, use '/usr/bin/mariadb-dump' instead mysqldump: Got error: 2026: "TLS/SSL error: SSL is required, but the server does not support it" when trying to connect .

Additional context

I think snipe-it should be able to retry the backup with the appropriate flags to disable SSL when it fails.

I think my workaround for this will have to be some kind of client config file for mariadb-dump to NOT try ssl.

[welcome[bot]]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[ipaqmaster]

Worked around this issue by modifying snipe-it/vendor/spatie/db-dumper/src/Databases/MySql.php

In the getDumpCommand function I appended "--skip-ssl", to the $command section, where the mysqldump command and its arguments are prepared for execution. Backups work for me now.

[snipe]

You should never edit vendor files, as your changes will be blown out during the next update.

What do you have in the DB section of your config? (With password redacted, of course). Also, per the error, you should probably update the dump path.

[swift2512]

Worked around this issue by modifying snipe-it/vendor/spatie/db-dumper/src/Databases/MySql.php

In the getDumpCommand function I appended "--skip-ssl", to the $command section, where the mysqldump command and its arguments are prepared for execution. Backups work for me now.

Looks like you have misconfigured you .env file. From .env file:

# --------------------------------------------
# OPTIONAL: SSL DATABASE SETTINGS
# --------------------------------------------
DB_SSL=false
DB_SSL_IS_PAAS=false
DB_SSL_KEY_PATH=null
DB_SSL_CERT_PATH=null
DB_SSL_CA_PATH=null
DB_SSL_CIPHER=null
DB_SSL_VERIFY_SERVER=null

[ipaqmaster]

Worked around this issue by modifying snipe-it/vendor/spatie/db-dumper/src/Databases/MySql.php

In the getDumpCommand function I appended "--skip-ssl", to the $command section, where the mysqldump command and its arguments are prepared for execution. Backups work for me now.

I know but needed this feature to work for the client on short notice.

Here's the database section of .env

# --------------------------------------------
# REQUIRED: DATABASE SETTINGS
# --------------------------------------------
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=SomeDatabase
DB_USERNAME=SomeUser
DB_PASSWORD=SomethingSpecial
DB_PREFIX=null
DB_DUMP_PATH='/usr/bin'
DB_CHARSET=utf8mb4
DB_COLLATION=utf8mb4_unicode_ci

# --------------------------------------------
# OPTIONAL: SSL DATABASE SETTINGS
# --------------------------------------------
DB_SSL=false
DB_SSL_IS_PAAS=false
DB_SSL_KEY_PATH=null
DB_SSL_CERT_PATH=null
DB_SSL_CA_PATH=null
DB_SSL_CIPHER=null

I still believe this is caused by unknowingly calling mysqldump (mariadb-dump) with some kind of recent 'TLS by default' behavior rather than snipe-it trying to exclusively force ssl in the command itself. I think it is now implicitly enabled.

[snipe]

You can add that to your config file. https://stackoverflow.com/questions/78677369/mariadb-11-also-mysql-cli-error-2026-hy000-tls-ssl-error-ssl-is-required

Stack Overflow

MariaDB 11 (also MySQL) "CLI ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it" when connecting to MariaDB 10.4

When I try to connect to a server using MariaDB 11's mariadb/mysql cli commands, I get the error "ERROR 2026 (HY000): TLS/SSL error: SSL is required, but the server does not support it" w...

[ipaqmaster]

Yeah that's what I tried first for both the nginx and php user which run this platform. But it had no impact. Hardcoding --skip_ssl into db-dumper's command arguments was the next option.

[ZebboKlaufix]

Sorry to ask, but this issue is marked as closed. But I'm not able to figure out how to fix it, if not by editing the vendor code. My .env looks as proposed:

# --------------------------------------------
# OPTIONAL: SSL DATABASE SETTINGS
# --------------------------------------------
DB_SSL=false
DB_SSL_IS_PAAS=false
DB_SSL_KEY_PATH=null
DB_SSL_CERT_PATH=null
DB_SSL_CA_PATH=null
DB_SSL_CIPHER=null
DB_SSL_VERIFY_SERVER=null

And I don't have a ~/.my.cnf, as mentioned in the solution. And the error persists, even if I create one with the following content:

[mysql]
skip-ssl = true

Can you help me to get the backup jobs working again?

[swift2512]

For me it looks like a server problem, not Snipe-IT. I have a copy of Snipe-IT running on Ubuntu Server v24.04, php 8.3.10, mariadb v10.6.18 and backups generate flawlessly.

[ZebboKlaufix]

The error occured after an OS update of the snipe-it host. The the database host is untouched. I think the error occurs, because snipe-it / db-dumper are relying on the maria-db-client installed on the snipe-it host OS. And db-dumper ignores deprication warning by still using mysqldump. And I see no option in snipe-it to pass --skip-ssl to db-dumper. This seems to lead to the error, because mariadb-dump now uses ssl by default. At least, that's what I think of what's happening.

Edit: I'm running on snipe-it v7.0.11 - build 15044

[ipaqmaster]

Can't be much more clear about this. After updating mariadb it now expects tls by default. This seems to be a recent new default behavior of mariadb's client tools. This distribution is rolling by design and sees updates that others may not have yet so it's not a surprise that Ubuntu 24.04 on v10.6.18 does not have this behavior seen in 11.4.2.

[swift2512]

Can't be much more clear about this. After updating mariadb it now expects tls by default. This seems to be a recent new default behavior of mariadb's client tools. This distribution is rolling by design and sees updates that others may not have yet so it's not a surprise that Ubuntu 24.04 on v10.6.18 does not have this behavior seen in 11.4.2.

I've upgraded my mariadb version to latest - no problems with creating backups.

[ZebboKlaufix]

As I wrote before: It has nothing to do with the MariaDB-Server. It's the client binary.

[swift2512]

I am not a programmer so have absolutely no clue what you're talking about. Anyway, it works for me and you're the only one here who complains that backups doesn't work. :D

I'll just leave it here, in case someone finds it useful.

[ZebboKlaufix]

I'm obviously not the only one with this problem. And it's not about the mariadb-client. As the initially provided log states clearly it's about the binary '/usr/bin/mysqldump'. The incompatible version is mariadb-dump from 11.4.2-MariaDB, client 10.19 for Linux (x86_64). All in all I don't understand the reason why this is marked as 'solved', because the problem is - besides editing vendor files - not solved on @snipe 's side. We still need a solution like "pass the .env.DB_SSL=false down to db-dumper". I'm kinda forced to edit the vendor files, too. If there's anything I can do to check or test, let me know.

[swift2512]

Why not do an upgrade for incompatible versions? I still believe that this is misconfiguration on the server side. I have 5 different SnipeIT builds, running on different versions of mariadb and ubuntu server - all problems I had, were because of misconfiguration. If issue you have was common and widespread, github would be plagued with reports. Maybe SSL is enabled on your mariadb server, but you haven't configured it? If your mariadb server requires SSL for some reason, create certificates and configure .env file accordingly.

Here's a nice tutorial - https://www.cyberciti.biz/faq/how-to-setup-mariadb-ssl-and-secure-connections-from-clients/

Just a moment...

[Tyree]

@ZebboKlaufix I have this issue as well. Backups worked a few months ago, now they don't work. I have MariaDB container pinned at 10.11.10

I've been using the linuxserver snipe-it container which is recently deprecated/abandoned and now need to move to the official container. But I can't get a backup first. Ugh.

Did you ever figure out how to get past the TLS/SSL error?

[snipe]

All in all I don't understand the reason why this is marked as 'solved', because the problem is - besides editing vendor files - not solved on @snipe 's side

As we've said in other threads, set DB_DUMP_SKIP_SSL=false or remove it from your .env

https://github.com/grokability/snipe-it/blob/bca843e06c71fa670fe407fa76885a5120a18d55/config/database.php#L21-L24

[ZebboKlaufix]

@Tyree currently I'm on the following solution: snipe-it/vendor/spatie/db-dumper/src/Databases/MySql.php inside of getDumpCommand() I added one line: $command[] = '--skip-ssl';

so every time I skip ssl on mysql / mariaDB dumps.

But as mentioned before in this thread: Editing vendor files isn't the best idea. Following @snipe comment, Snipe-It now seems to be able to make use of the .env parameter skip_ssl. If so, it's by far the better solution. I haven't tried it yet, but I will - in a week or so.

[Tyree]

@Tyree currently I'm on the following solution: snipe-it/vendor/spatie/db-dumper/src/Databases/MySql.php inside of getDumpCommand() I added one line: $command[] = '--skip-ssl';

so every time I skip ssl on mysql / mariaDB dumps.

But as mentioned before in this thread: Editing vendor files isn't the best idea. Following @snipe comment, Snipe-It now seems to be able to make use of the .env parameter skip_ssl. If so, it's by far the better solution. I haven't tried it yet, but I will - in a week or so.

Okay. Thanks. I ended up doing the same thing yesterday and was able to get a backup. This was only a temporary measure for me so I could restore a backup to the official image. I switched over to the official docker image, restore the backup, and I can run backups fine with the new setup, without the spatie hack or the skip_ssl env. Don't know what broke on the old install.