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

[ipaqmaster]

Debug mode

• I have enabled debug mode
• 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 c54bff0

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]

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