Live testing on a real DirectAdmin/CustomBuild server showed the Apache
alias fix alone wasn't enough: the default vhost serving /var/www/html
uses `SuexecUserGroup webapps webapps`, so PHP for the private phpMyAdmin
copy actually executes as user/group "webapps" - not as Apache's own
httpd.conf "Group" (typically "apache"), which is what
detect_apache_group() was reading. SSO ticket files ended up owned
root:apache with mode 0640, unreadable by the webapps-executing
da_login.php, producing "The phpMyAdmin login ticket is not available
or has already been used." even though the ticket really was written.
detect_apache_group() now checks the default vhost's SuexecUserGroup
directive first (the actual PHP-execution identity under SuExec), and
only falls back to the plain Apache Group directive when no
SuexecUserGroup is configured.
Bump version to 1.2.13 and rebuild the release archive.
phpMyAdmin login was broken because phpmyadmin_install.sh never wired
the private phpMyAdmin copy into the web server: no Apache Alias was
registered via DirectAdmin CustomBuild, so the SSO redirect target was
unreachable. Add configure_apache_alias()/apply_apache_alias() (Alias +
Directory blocks, ./build rewrite_confs, httpd reload), detect the real
Apache group instead of hardcoding diradmin:diradmin, stop silently
swallowing chown/chmod failures, and verify an optional SHA256 for the
downloaded phpMyAdmin tarball. Extend phpmyadmin_health_check.sh to
detect a missing/incorrect Apache alias and to probe HTTP reachability.
Security hardening: scope temporary phpMyAdmin SSO MySQL roles to
127.0.0.1 instead of '%', tighten SSO ticket file permissions to 0640
(they contain a plaintext MySQL password), and log MySQL connection
failures for diagnosis instead of swallowing them silently.
Bump version to 1.2.12 and rebuild the release archive.
Marek Miklewicz