fix: centralize version tag logic across workflows - #4550

🏁 Script executed:

#!/bin/bash
# Description: Verify the short URL redirects to the expected GitHub script

# Check if the short URL is accessible and returns the script content
HTTP_CODE=$(curl -sSL -o /dev/null -w "%{http_code}" https://opensourcepos.org/install)
echo "HTTP Status: $HTTP_CODE"

# Verify it redirects to GitHub
REDIRECT_URL=$(curl -sSL -w "%{url_effective}" -o /dev/null https://opensourcepos.org/install)
echo "Redirect URL: $REDIRECT_URL"

# Check if content looks like a bash script
FIRST_LINE=$(curl -sSL https://opensourcepos.org/install | head -n1)
echo "First line: $FIRST_LINE"

if [[ "$FIRST_LINE" == "#!/bin/bash"* ]]; then
  echo "✓ Short URL serves a bash script"
else
  echo "✗ Short URL does not serve a bash script"
fi

Repository: opensourcepos/opensourcepos

Length of output: 190

🏁 Script executed:

# First, let's read the actual file to confirm the current implementation
cat -n scripts/install-ubuntu.sh | sed -n '84,90p'

Repository: opensourcepos/opensourcepos

Length of output: 509

🌐 Web query:

apt-cache policy output format for unavailable packages

💡 Result:

For a package that is unavailable to APT, apt-cache policy typically shows Installed: (none) and Candidate: (none), and in the Version table you’ll usually see no available versions. apt-cache “policy” is designed to show pinning priorities and the candidate selection for the named package [1].

Citations:

• 1: https://manpages.debian.org/bullseye/apt/apt-cache.8.en.html

🌐 Web query:

apt-cache show command behavior for missing packages

💡 Result:

When you run apt-cache against the APT package cache, the “missing packages” behavior is determined by which apt-cache subcommand you use and what metadata is available in that cache. 1) apt-cache show (missing package name) - apt-cache show only queries and prints records “for the named packages” [1][2]. It does not state an alternative/placeholder output when the named package is absent; in practice it results in no package record being printed (i.e., essentially empty/“nothing found”) because there is no matching package entry to display. This matches the manpage’s description that it “displays the package records for the named packages” [1][2]. 2) apt-cache unmet and “Missing packages” counts (unmet dependencies) - apt-cache unmet reports “a summary of all unmet dependencies in the package cache” [1][2]. - Separately, for the dependency-related output, apt-cache statistics-style output defines “Missing” as “the number of package names that were referenced in a dependency but were not provided by any package” [3][1][2]. This is about dependency relations referencing names that no package provides in the current cache, not about whether the user requested a particular package name with apt-cache show. - That means you can see “missing packages”/unmet entries even if the packages themselves are not installed and even if some referenced dependency names no longer exist in the distribution metadata that’s currently loaded into your APT cache (or your sources are incomplete/out-of-date). The apt-cache docs explicitly note this interpretation: “Missing packages may be evidence if a full distribution is not accessed, or if a package (real or virtual) has been dropped from the distribution” [3][1][2]. 3) Why this happens after restoring old configs / fresh install - apt-cache uses the metadata from the local APT package lists/cache; it “does not manipulate the state of the system” and “the metadata is acquired and updated” (via apt-get update, etc.), but apt-cache can work “independently of the availability of the configured sources” and can be “outdated if the last update is too long ago” [4]. - Therefore, after changing/restoring sources or configs, your local package lists may still contain (or lack) dependency relationships, leading to unmet/missing dependency names in the apt-cache view [4][1]. 4) How to reduce confusion / narrow scope - Use apt-cache commands that match your intent: a) To inspect a particular package’s metadata, use apt-cache show (it only prints records that exist in the cache for that exact name) [1][2]. b) To inspect missing/unmet dependency relationships across the cache, use apt-cache unmet (it summarizes unmet dependencies across the cache, not just installed packages) [1][2]. - If you see huge amounts of unmet output, there is a manpage option -i/--important to narrow what unmet prints: “Print only important dependencies … for use with unmet and depends” [5]. Practical takeaway - apt-cache show: if the named package does not exist in the currently loaded cache, there is no package record to print (so you effectively get no output/record for that name) [1][2]. - apt-cache unmet / dependency “Missing” counts: these refer to dependency targets referenced by other packages but not provided by any package in the cache (often due to stale/out-of-date package lists, incomplete sources, or packages dropped from the distribution) [3][1][2].

Citations:

• 1: https://manpages.ubuntu.com/manpages/trusty/en/man8/apt-cache.8.html
• 2: https://manpages.ubuntu.com/manpages/xenial/man8/apt-cache.8.html
• 3: https://manpages.debian.org/bullseye/apt/apt-cache.8.en.html
• 4: https://man.cx/apt-cache(8)
• 5: https://askubuntu.com/questions/716876/apt-cache-unmet-shows-non-existent-packages

🏁 Script executed:

# Verify the actual behavior difference between apt-cache policy and apt-cache show
# by checking Ubuntu/Debian documentation and common usage patterns

# Let's also check if there are any other PHP version checks in the codebase
rg -n "php" scripts/install-ubuntu.sh | head -20

Repository: opensourcepos/opensourcepos

Length of output: 719

🌐 Web query:

apt-cache show exit code behavior missing package ubuntu

💡 Result:

apt-cache show does not reliably use a non-zero exit code to indicate “missing package” (no package record found). For a non-existent package name, the command may print errors but still return exit status 0 in at least some cases/configurations. Evidence: In an Ubuntu bug report, running apt-cache show gedit > /dev/null; echo $? returns 0 even though LC_ALL=C apt-cache show gedita > /dev/null; echo $? returns an error message and a different exit status in that scenario [1]. Another authoritative reference states only that apt-cache returns zero on normal operation and decimal 100 on error (but “missing package” appears to be treated as not an error in some implementations/uses) [2]. What to do instead (recommended): 1) Use dpkg-query for installed packages. It provides configurable, machine-parseable status/formatting and has well-defined semantics. For example, to get an installed version you can use: dpkg-query --showformat='${Version}' --show (This works for installed packages) [3]. 2) If you must use apt-cache, don’t rely on its exit code for “not found”; parse its output (e.g., look for “Unable to locate package …”) or check availability first (e.g., apt-cache show <pkg> then confirm that a Version: line exists). The apt-cache man page notes show “displays the package records” for named packages and that apt-cache “does provide operations to search and generate interesting output from the package metadata” based on cached lists [4]. So the practical answer to your query is: for “missing package ubuntu” (i.e., query a package name that does not exist in the cache), don’t depend on apt-cache show exit codes; use output parsing or switch to dpkg-query when you specifically need installed versions [3].

Citations:

• 1: https://bugs.launchpad.net/bugs/1037521
• 2: https://man.cx/apt-cache(8)
• 3: https://askubuntu.com/questions/1476913/apt-cache-show-package-field-show-single-field-of-a-package
• 4: https://manpages.ubuntu.com/manpages/focal/man8/apt-cache.8.html

🏁 Script executed:

# Verify the exact apt-cache policy output format to design the best fix
# Let's check what a proper detection pattern should be

# Search for any documentation or comments about package detection in related scripts
rg -A5 -B5 "apt-cache" scripts/

Repository: opensourcepos/opensourcepos

Length of output: 926

🌐 Web query:

apt-cache policy output format candidate version none ubuntu

💡 Result:

When you run the command apt-cache policy <package_name> on Ubuntu or Debian, the output provides information about the package's installation status, the candidate version for installation, and the available versions in your configured repositories [1][2][3]. The Candidate field specifies the version of the package that APT would select for installation if you were to run an install command [4]. If this field displays (none), it indicates that APT cannot find any available version of that package in your currently configured software sources [1][3]. This typically happens for one of the following reasons: 1. The package name is misspelled or does not exist in the repositories currently defined in your /etc/apt/sources.list or /etc/apt/sources.list.d/ directory. 2. You have not run apt update recently, meaning your local package cache is outdated and does not reflect the current contents of the repositories. 3. The repository containing the package is not enabled on your system. To resolve this, ensure the package name is correct, run sudo apt update to refresh your local cache, and verify that the necessary repositories are enabled [4][2].

Citations:

• 1: https://unix.stackexchange.com/questions/121413/understanding-the-output-of-apt-cache-policy
• 2: https://debian-handbook.info/browse/stable/sect.apt-cache.html
• 3: https://stackoverflow.com/questions/18885820/how-can-i-check-the-version-before-installing-a-package-using-apt-get
• 4: https://askubuntu.com/questions/1367352/multiple-outputs-for-apt-cache-policy-package-name

🏁 Script executed:

# First, let's examine the full script to understand the context
wc -l scripts/install-ubuntu.sh

Repository: opensourcepos/opensourcepos

Length of output: 101

🏁 Script executed:

# Read the relevant section of the install script with surrounding context
sed -n '100,130p' scripts/install-ubuntu.sh

Repository: opensourcepos/opensourcepos

Length of output: 1094

🏁 Script executed:

# Search for any references to MYSQL_ROOT_PASS setup in the script
rg "MYSQL_ROOT_PASS" scripts/install-ubuntu.sh -B 3 -A 3

Repository: opensourcepos/opensourcepos

Length of output: 1334

🏁 Script executed:

# Check if there are other places where MariaDB/MySQL authentication is configured
rg -i "mysql|mariadb" scripts/install-ubuntu.sh | head -20

Repository: opensourcepos/opensourcepos

Length of output: 859

🌐 Web query:

MariaDB default root authentication method Ubuntu unix_socket

💡 Result:

On Ubuntu (MariaDB packaged via Debian/Ubuntu repos), the MariaDB root account is configured to authenticate using the unix_socket authentication plugin for the 'root'@'localhost' user account by default.[1][2] MariaDB’s unix_socket plugin is installed by default and “is used by the 'root'@'localhost' user account by default.”[1][2] The authentication mechanism allows login without a MariaDB password via the local Unix socket (OS credentials), defined by MariaDB’s socket system variable.[1] Also note that MariaDB 10.4+ installation creates root@localhost with an OR between unix_socket and mysql_native_password, where mysql_native_password starts with an invalid password hash; password auth requires setting a real password with SET PASSWORD, while unix_socket allows local OS-root logins over the Unix socket.[3]

Citations:

• 1: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-unix-socket.md
• 2: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-unix-socket
• 3: https://mariadb.com/docs/server/security/user-account-management/authentication-from-mariadb-10-4

🌐 Web query:

MariaDB unix_socket authentication vs password authentication security Ubuntu

💡 Result:

In MariaDB on Ubuntu, the unix_socket and password-based (e.g., mysql_native_password) authentication methods offer different security models. The unix_socket plugin is the default for the root user in standard Ubuntu installations [1][2]. Unix_socket Authentication This method is passwordless and relies on the security of the operating system [1][2]. When a user connects via a local Unix socket, MariaDB uses the SO_PEERCRED socket option to retrieve the UID of the connecting process and maps it to the corresponding MariaDB user [3]. - Security Strengths: It eliminates the risk of password brute-force attacks and prevents password exposure through configuration files, backups, or accidental leakage [1][2]. Because it requires local access, it is inherently resistant to remote eavesdropping [4]. - Security Dependencies: Its security is entirely dependent on the security of the underlying Unix user accounts [1][2]. If an unauthorized user gains access to a specific OS account, they can connect to the database as that user without needing a separate database password [1][2]. - Limitations: It only works for local connections [5]. It cannot be used for remote network connections [5]. Password Authentication Traditional password authentication (e.g., mysql_native_password) requires the user to provide a password, which is then verified by the database [6]. - Security Strengths: It provides a layer of authentication independent of the OS user, which is necessary for remote connections [5]. - Security Risks: Passwords can be weak, reused, or exposed in configuration files, scripts, or backups [1][2]. If a password is compromised, an attacker may gain access regardless of their OS-level privileges [4]. Comparison and Best Practices - Default Configuration: Ubuntu's default MariaDB installation uses unix_socket for the root user to enhance security by ensuring that only the system root user (or users with sudo privileges) can access the database root account [1][2]. - Hybrid Approach: Since MariaDB 10.4, you can configure accounts to support multiple authentication methods using the OR keyword [7][4]. For example, you can allow unix_socket for local administrative tasks while requiring a strong password for remote or application-based connections [7]. - Recommendation: Use unix_socket for local administrative access to minimize password management risks [1][2]. For application users or remote access, use strong, unique passwords combined with appropriate network restrictions (e.g., binding to 127.0.0.1 or using firewalls) [8][9]. Avoid using the same account for both local socket and remote password access if possible, or ensure the password is highly secure [4].

Citations:

• 1: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-unix-socket.md
• 2: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-unix-socket
• 3: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/pluggable-authentication-overview.md
• 4: https://stackoverflow.com/questions/66429827/mariadb-unix-socket-without-password-or-mysql-native-password-what-is-safer
• 5: https://www.tenable.com/audits/items/CIS_MariaDB_10.11_v1.0.0_L2_MariaDB_RDBMS_MySQLDB.audit:7ffaf455cf4e0ce35e0a388a941027ad
• 6: https://www.linuxbabe.com/mariadb/plugin-unix_socket-is-not-loaded-2
• 7: https://stackoverflow.com/questions/41846000/enable-password-and-unix-socket-authentication-for-mariadb-root-user
• 8: https://www.blogarama.com/technology-blogs/1455526-green-webpage-blog/76185222-install-secure-mysqlmariadb-almalinux-step-guide
• 9: https://dev.to/vultr/installing-the-lemp-stack-on-ubuntu-2604-3m2k

🌐 Web query:

Ubuntu MariaDB root@localhost default auth socket

💡 Result:

On Ubuntu, MariaDB installations use the unix_socket authentication plugin by default for the root@localhost user [1][2][3]. This security feature allows you to log in to the MariaDB root account without a password, provided you are logged into the operating system as the root user (typically by using sudo) [4][5][6]. How it works: The unix_socket plugin verifies your identity by checking the operating system user credentials of the process attempting to connect via the local Unix socket file [1][3]. Because the system root user already has full access to the server's data files and memory, requiring a separate database password for the root user is considered redundant and less secure than relying on OS-level authentication [6]. Accessing the database: To connect to MariaDB as root, you should use the following command: sudo mysql -u root If you attempt to connect using mysql -u root -p without sudo, or if you try to provide a password when one has not been set, you will likely receive an "Access denied" error [5][7]. Configuring password authentication: In modern MariaDB versions (10.4 and later), the root account is often configured to support both unix_socket and password-based authentication simultaneously [4][6]. The password method is disabled by default (set to an invalid hash) [3][6]. If you wish to enable password-based access (for example, to allow applications or remote tools to connect), you can set a password while retaining the ability to use sudo for passwordless local access [6]: ALTER USER 'root'@'localhost' IDENTIFIED VIA mysql_native_password USING PASSWORD('your_secure_password'); After running this, you can still use sudo mysql -u root to log in without a password, but you will also be able to log in using the password you just set [6]. Note that if you are connecting via TCP (e.g., 127.0.0.1) rather than the Unix socket, you must use the password [8].

Citations:

• 1: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-unix-socket.md
• 2: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/authentication-plugin-unix-socket
• 3: https://mariadb.com/docs/server/reference/plugins/authentication-plugins/pluggable-authentication-overview.md
• 4: https://www.simplified.guide/mysql-mariadb/root-access-without-sudo
• 5: https://stackoverflow.com/questions/28068155/access-denied-for-user-rootlocalhost-using-password-yes-after-new-instal
• 6: https://mariadb.org/authentication-in-mariadb-10-4
• 7: https://stackoverflow.com/questions/43379892/mariadb-cannot-login-as-root
• 8: https://stackoverflow.com/questions/41846000/enable-password-and-unix-socket-authentication-for-mariadb-root-user

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.