2025-10-29 14:27:06 +01:00
2025-10-29 14:27:06 +01:00

Changelog

27-10-2025

Woke up in the middle of the night thinking, “Hang on — I never actually tested the -h flag on my MariaDB scripts where MariaDB was a crucial part of the scripts operation.”
Thats when it hit me: the logic behind my usage output could fail if MariaDB wasnt running, because the detection happens after the usage function.
Simple oversight — but it changes everything when you go from a private toolbox (where you know your own setup) to a public one.

In my old scripts, I assumed too much.
On my own systems, I know MariaDB is running, I know socket auth works — but once the code is public, assumptions become landmines.

So heres the new baseline logic Im rolling into all web-app installers:

  1. Check if MariaDB is running. If not, bail out early with a clear message.
  2. Detect authentication method.
    • If socket auth works for root, use it.
    • If socket auth isnt available, require credentials using -a <admin> and -m <password>.
    • If neither works, bail out. No silent fallbacks, no guessing.

The important part is that this check happens before the usage function.
That avoids empty variables or misleading output when someone just runs -h for help.
Theres no reason to re-run the same detection every time a user mistypes a flag.

Then came the next realization — my PHP-FPM version detection relied on php -r, which assumes php-cli is installed.
Thats fine on my systems, but not guaranteed elsewhere.

The fix was cleaner and fully independent of php-cli:

phpfpm=$(systemctl list-units --type=service --all   | awk '/php[0-9]+\.[0-9]+-fpm/ {print $1; exit}'   | sed 's/\.service//')

if [[ -z "$phpfpm" ]]; then
    printf "\nUnable to detect php-fpm version. Is PHP-FPM installed?\n\n"
    exit 1
fi

This uses systemd directly to find the versioned PHP-FPM service, which is reliable across Ubuntu releases.
And the nice side-effect? I could drop the $phpver variable entirely — fewer moving parts and simpler Nginx snippets.


Going from private scripts to public tools means changing ones mindset.
When you look around, you notice how many scripts assume too much about the system theyre running on.
And sure — those assumptions often work, but they also make things brittle.

The idea here isnt to over-engineer or second-guess everything.
Theres a limit to what you can (and should) check.
At some point, you have to draw the line and say:

“Ive verified what I can — lets not turn this into a Windows installer.”

Thats the balance Im aiming for now.
Check whats reasonable, bail cleanly on failure, and keep the rest simple.
Because if a script starts doing too much “hand-holding,” it usually ends up tripping over its own shoelaces.

Keep it simple. Keep it human. And never assume.

— Allan


26-10-2025

Added a Postfix Ubuntu installer script today — a no-fuzz setup that doesnt yell at you with a wall of prompts.
Its been part of my private toolbox for years, but now that its public, its grown up a bit.

I had to add some basic safety checks, which I normally skip in private use — I know what runs on my own servers and whats safe to execute.

Making a script public means thinking a bit differently: it needs to behave predictably, even in environments I dont control.

Anyway, the scripts out there. It does the job, its solid, and its free.

— Allan


More Information

More guides and documentation can be found on wiki.x-files.dk

Description
No description provided
Readme 43 KiB