fsy 41 Posted ... Hello! I came across a few problems during AirVPN Suite 2.1.0 installation on a custom Linux box caused by the installer script. I had to fix the installation manually. Here my findings and thoughts. 1. read -p is not POSIX-compliant despite #!/bin/sh The install.sh script declares: #!/bin/sh and the documentation instructs users to run it with sh ./install.sh. However, the script uses read -p for interactive prompts, for example: read -p "Do you want to install AirVPN Suite? [y/n] " yn read -p is not part of POSIX sh and is not supported by shells such as Debian/Ubuntu's dash. As a result, running the installer with /bin/sh can produce an error such as: read: Illegal option -p The script does not check the return status of read, so it may continue execution with an empty/unset response. This can cause prompts to be effectively skipped and the installer to proceed with unintended defaults. Possible fix: keep the script POSIX-compatible by replacing read -p with: printf '%s' "Do you want to install AirVPN Suite? [y/n] " read yn The same issue appears in multiple interactive prompts throughout install.sh. 2. Incorrect group membership check The installer checks whether the airvpn user belongs to the airvpn group using: grep ^$AIRVPN_GROUP /etc/group | cut -d: -f4 | grep -q $AIRVPN_USER This is not a reliable way to check group membership. Because grep -q $AIRVPN_USER performs a substring match, it can produce false positives. For example, if the group members contain: someairvpnuser the check can incorrectly consider airvpn to be a member. It also directly parses /etc/group, which bypasses the system's NSS configuration, so it may fail on systems where group information is provided through LDAP, SSSD, NIS, etc. Possible fix if getent is available: getent group "$AIRVPN_GROUP" with proper parsing of the member list. If getent is not available the system's group membership mechanism may be a solution, for example: id -nG "$AIRVPN_USER" | tr ' ' '\n' | grep -qx "$AIRVPN_GROUP" 3. Not bugs but poor design install.sh performs several critical file operations using cp without checking whether they succeed. For example: cp bin/bluetit /sbin/bluetit cp bin/goldcrest $BIN_DIR cp bin/hummingbird $BIN_DIR If one of these commands fail, for any reason, the installer continues executing instead of aborting. There is no global set -e and no explicit error handling around these operations. As a result, the script can potentially reach its final success message even though one or more required components were never installed. This can leave the system in a partially installed and inconsistent state, while giving the user the impression that the installation completed successfully. The same issue should be reviewed for other critical commands such as mkdir, chmod, chown, systemctl, and service-management operations. At minimum, critical operations should check their exit status and warn the user. Seeyabyez Quote Share this post Link to post