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 script’s operation.”
That’s when it hit me: the logic behind my usage output could fail if MariaDB wasn’t 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 here’s the new baseline logic I’m rolling into all web-app installers:
- Check if MariaDB is running. If not, bail out early with a clear message.
- Detect authentication method.
- If socket auth works for
root, use it. - If socket auth isn’t available, require credentials using
-a <admin>and-m <password>. - If neither works, bail out. No silent fallbacks, no guessing.
- If socket auth works for
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.
There’s 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.
That’s 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 one’s mindset.
When you look around, you notice how many scripts assume too much about the system they’re running on.
And sure — those assumptions often work, but they also make things brittle.
The idea here isn’t to over-engineer or second-guess everything.
There’s a limit to what you can (and should) check.
At some point, you have to draw the line and say:
“I’ve verified what I can — let’s not turn this into a Windows installer.”
That’s the balance I’m aiming for now.
Check what’s 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 doesn’t yell at you with a wall of prompts.
It’s been part of my private toolbox for years, but now that it’s public, it’s 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 what’s safe to execute.
Making a script public means thinking a bit differently: it needs to behave predictably, even in environments I don’t control.
Anyway, the script’s out there. It does the job, it’s solid, and it’s free.
— Allan
More Information
More guides and documentation can be found on wiki.x-files.dk