Installation script doesn't correctly detect current installation when SSL certificate error. Deletes database

[tareko]

Summary

My freescout database is deleted with every bootup of Freescout

Steps to reproduce

Mysql server is at host.docker.internal

docker-compose up

Every single time, I get:

freescout-app    | 2025-02-28.04:33:10 [WARN] ** [freescout] Detected empty Database - Setting up - Please wait..
freescout-app    | 2025-02-28.04:33:21 [WARN] ** [freescout] Creating Administrative User
freescout-app    | 2025-02-28.04:33:22 [WARN] ** [freescout] Installing Modules into container
freescout-app    | 2025-02-28.04:33:22 [WARN] ** [freescout] Running any Database Migrations

What is the expected correct behavior?

To not delete the database with each startup

Relevant logs and/or screenshots

Environment

• Image version / tag:
• Host OS:

Any logs | docker-compose.yml

Possible fixes

This was fixed by editing the following line: https://github.com/tiredofit/docker-freescout/blob/main/install/etc/cont-init.d/30-freescout#L246

To instead be:

/usr/bin/mariadb --skip-ssl -u $DB_USER -p$DB_PASS -h$DB_HOST -P$DB_PORT -e "use "$DB_NAME"; SELECT * FROM users;" > /dev/null 2>&1

[tiredofit]

Can you tell me what version of the image you are using? You can go inside and type image_version which should output a string of version numbers. By default SSL should be disabled as of a few months back in the upstream tiredofit/alpine image.

[tareko]

Note that this is in the image that I built based on your Dockerfile, modified with my command above.

$ image_version
"Image: /assets/.changelogs/tiredofit_docker-alpine.md 7.10.27"
"Image: /assets/.changelogs/tiredofit_docker-nginx-php-fpm.md 7.7.17"
"Image: /assets/.changelogs/tiredofit_docker-nginx.md 6.5.10"

[tiredofit]

Sorry to hear that you've had some data loss due to this. I'll investigate to see if Freescout supports SSL for the databases via its internal env routines and build that in as a feature but make SSL support explicitly disabled as per your modification.

[tareko]

Mercifully, I didn't have any data loss due to great backups, but it could easily have gone that way! I think the wider point is that there's a difference between 0 rows returned, where it's a fair assumption that there is an empty db, and "failed to access db", where maybe it should stop and reassess. I assume error codes are different for those. Another possible idea here is to pause and say "initialize DB? [y/N]" . I realize that will cause its own set of problems, but it might be a way to approach this.

[tiredofit]

Yes, this is an interesting one:
There is a database connectivty check here before the database row test occurs.

Unfortunately interactive mode is not optimal with docker images, but you are right, there are better ways to do this long term - but the real issue is accommodating for the upstream changes with mariadb clients always assuming that SSL is enabled therefore the routines that previously relied on it being default=false can get back to working again and these things can be addressed as part of the upcoming entire image catalog overhaul (sometime this year?)..

I have a long flight coming up soon, this sounds an excellent way to pass the time.

[tareko]

Can I help you in any way?

[tiredofit]

1.17.110 has a new option DB_SSL TRUE/FALSE (default) which should resolve this issue.