The README tells users to run the script with sh wikisuite-script-install.sh, and on Debian 12 sh is dash. The S3 backup section is written in bash (read -p ... -n 1, [[ =~ ]], ${!var} indirect expansion), so under dash it prints read: Illegal option -n and [[: not found, the question is never asked, and configuring automated S3 backups is simply unreachable for anyone following the documentation.
This rewrites just that block in POSIX sh, so it behaves the same under dash and bash:
printf + read -r REPLY and a ${REPLY#[Yy]} test replace read -p -n 1 and [[ $REPLY =~ ^[Yy]$ ]]
the indirect ${!var_name} becomes an eval emptiness test, and the export is quoted
read -r input_value || return 1 stops prompting on end of input; before, a mandatory prompt hitting EOF re-ran forever
Two small behaviour notes: the y/N answer now needs Enter (POSIX read has no single key mode), and any answer starting with y or Y is accepted.
Tested on a Debian 12 container, running the real script with the downstream installer stubbed, same answers piped to dash and to bash: all five S3 variables reach the sourced installer identically in both shells; n skips everything; an empty answer to a mandatory prompt asks again; an empty answer to an optional prompt leaves the variable unset; EOF terminates cleanly. shellcheck -s dash on the script now reports a single error, the $EUID root check line addressed by !6.
When no hostname argument is given, the script falls back to hostname -f. On a server without a FQDN this returns the short name, hostnamectl set-hostname happily applies it, and the failure only surfaces much later inside the Virtualmin installer with a confusing message, as in the report in #2.
This adds a guard right where the hostname is decided: if it does not contain a dot, print what a FQDN looks like and how to pass one to the script, then exit 1 before anything hostname related happens.
Tested on a Debian 12 container:
root, no argument, short hostname: Error: '' is not a fully qualified domain name (like server.example.org). plus the command to re-run, exit 1.
root, install.sh myserver: refused the same way, exit 1.
root, install.sh test1.example.org: validation passes, * Set hostname test1.example.org, the script continues to the installer.
Closes #2
The README tells users to run the script with sh wikisuite-script-install.sh. On Debian 12, sh is dash, and $EUID is a bash variable that dash never sets. The root check therefore evaluates [ "" -ne 0 ], dash prints [: Illegal number: and the check passes silently, so the script keeps going as a regular user and dies on apt lock errors much later, exactly as reported in #1.
This replaces $EUID with id -u, which is POSIX and behaves the same under sh and bash, and makes the error message tell the user what to run instead.
Tested on a Debian 12 container:
sh install.sh as a regular user: Error: This script must be run as root. Re-run it with: sudo sh install.sh, exit 1 (before the fix: [: Illegal number: then apt permission errors).
bash install.sh as a regular user: same message, exit 1.
as root under sh: the check is silent and the script proceeds.
Closes #1
This dependents on tikiwiki/tiki-manager!549 (merged) . It has been merged and for the same behavior to be reflected in virtualmin we need some progress here. Hope this will get attention asap
I’ve just run a new series of tests and fixed several issues.
The new WikiSuite Installer version 2.1.0 now works on all supported minimal clean distros.
If you find any related bugs, open a new ticket first and discuss it internally. If Marc confirms the issue, assign it to me with a clear and concise bug description, and I will take care of it.
The WikiSuite integration with the Virtualmin installer turned out to be very nice but also quite complicated.
Example:
On the whitespace point: what appears as extra space is actually a tab delimiter used by Virtualmin template syntax, so I kept it unchanged for consistency with the existing templates.
On the second point: php_admin_value[disable_functions] and php_admin_value[allow_url_fopen] are intentionally kept in the same php_fpm= value and separated by tabs, because in these template files tabs represent line breaks/directive separation when Virtualmin generates the final PHP-FPM pool config.
So no functional change is needed here, and this keeps the same structure as the other templates.