RSS

Victor Emanouilov (b9d45457) at 04 Sep 06:00 Merge branch 'fix/posix-s3-prompts' into 'main' ... and 1 more commit

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 (merged).

luci (c4d88114) at 01 Sep 10:19 Merge branch 'fix/root-check-posix' into 'main' ... and 1 more commit

I set up a new server (Debian 12), and followed the instructions at: https://wikisuite.org/How-to-install-WikiSuite#Quick_installation On many servers, you can't log in directly as root. Instead, you log in as another user (in this case debian), and then you use sudo. debian@test1:~$ sh wikisuite-script-install.sh * Updating the package repository information Reading package lists... Done E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied) E: Unable to lock directory /var/lib/apt/lists/ W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied) W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied) * Installing sudo E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied) E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

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 (closed). 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 (closed)

I set up a new server (Debian 12), and followed the instructions at: https://wikisuite.org/How-to-install-WikiSuite#Quick_installation I got an error because my server didn't have a FQDN. Once I set that up, I re-reran the script and all went well. The error message could have been nicer for end users.

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 (closed). 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 (closed)

luci (486017a5) at 01 Sep 10:16 Merge branch 'fix/fqdn-validation' into 'main' ... and 1 more commit

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