I found that default php for Ubuntu may be changed when updating php in multiple php environment or thus this update may caused problem for ISPConfig and other programs relying on default php. So I tried this script with monit: Code: OUTPUT=`php -v | head -n 1 | cut -d ' ' -f 2 | cut -f1-2 -d'.'` if [ $OUTPUT = 7.2 ]; then exit 0; fi exit 1 Code: check program default-php with path /usr/share/dphp/dphp.sh if status != 0 then exec "/usr/bin/update-alternatives --set php /usr/bin/php7.2" It seems working for now but if you see any things that can be improved in the aboves, do reply with your suggestion. EDITED: The above implementation actually creates zombie's process, which I don't like, so I modified the code and use a much simpler approach yet cover wider OS version as follows: 1. Create an executable bash script for checking and restoring OS default php. E.g. /usr/share/default-php/default-php.sh Code: #!/bin/sh ### BEGIN INIT INFO # Provides: Check default OS php & restore if it was changed # Required-Start: $local_fs $network # Required-Stop: $local_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Check default OS php & restore if it was changed # Description: Check default OS php & restore if it was changed ### END INIT INFO osName=`grep -oP '(?<=^ID=).+' /etc/os-release` osVersion=`grep -oP '(?<=^VERSION_ID=).+' /etc/os-release | tr -d '"'` phpVersion=`php -v | head -n 1 | cut -d ' ' -f 2 | cut -f1-2 -d'.'` #IF UBUNTU if [ $osName == ubuntu ] && [ $osVersion == 16.04 ] && [ $phpVersion != 7.0 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.0 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.0-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.0; fi if [ $osName == ubuntu ] && [ $osVersion == 18.04 ] && [ $phpVersion != 7.2 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.2 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.2-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.2; fi if [ $osName == ubuntu ] && [ $osVersion == 20.04 ] && [ $phpVersion != 7.4 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.4 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.4-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.4; fi if [ $osName == ubuntu ] && [ $osVersion == 22.04 ] && [ $phpVersion != 8.1 ]; then /usr/bin/update-alternatives --set php /usr/bin/php8.1 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php8.1-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi8.1; fi #IF DEBIAN if [ $osName == debian ] && [ $osVersion == 8 ] && [ $phpVersion != 5.6 ]; then /usr/bin/update-alternatives --set php /usr/bin/php5.6 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php5.6-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi5.6; fi if [ $osName == debian ] && [ $osVersion == 9 ] && [ $phpVersion != 7.0 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.0 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.0-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.0; fi if [ $osName == debian ] && [ $osVersion == 10 ] && [ $phpVersion != 7.3 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.3 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.3-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.3; fi if [ $osName == debian ] && [ $osVersion == 11 ] && [ $phpVersion != 7.4 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.4 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.4-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.4; fi if [ $osName == debian ] && [ $osVersion == 12 ] && [ $phpVersion != 8.2 ]; then /usr/bin/update-alternatives --set php /usr/bin/php7.4 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php7.4-fpm.sock && /usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi7.4; fi 2. Create a con job for it to run every 10 minutes (or your preferred time) E.g. /etc/cron.d/default-php Code: */10 * * * * root /usr/share/default-php/default-php.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/default-php; done This will run the script every 10 minutes and if it founds, for example, that Ubuntu 18.04 default php version has been changed, php7.2 will then be restored. Feel free to use, modify and/or expand the script for your personal usages.
I revisited this to ensure if there is anything I can do to rewrite the code with monit, if one really wants to use it to monitor php version change and thank god, I see one. I think it can be done as follows (e.g. for Ubuntu 22.04): Code: check directory DefaultPHP path /etc/php/8.1/fpm if changed timestamp then exec "/usr/bin/update-alternatives --set php /usr/bin/php8.1 && /usr/bin/update-alternatives --set php-fpm.sock /run/php/php8.1-fpm.sock" check directory DefaultPHPCGI path /etc/php/8.1/cgi if changed timestamp then exec "/usr/bin/update-alternatives --set php-cgi /usr/bin/php-cgi8.1" I haven't tested this fully but it should work for those who want to use monit to monitor their server default php version and fix it automatically if it was changed. I think we may also check "/var/run/php" or its pid file for change of timestamp. The other way will be to use incron to monitor and similarly run something like the above if any of the php directory is changed.
Sorry to drag up an old post, but I have a question well two actually. First, could this not just be done by modifying the upgrade script, basically then it only runs when the upgrade runs, no need for a cron job for it. Second.. Should ISPConfig not just select the correct php version it works with instead of using the default? I know that an updated default php could break more than ISPConfig but for the sake of keeping the panel and other related things running smoothly maybe it should be so.
Answer for the first is yes but it is up to you to code it that way and share it if you like but now I do not use cron anymore but monit. To note the softwares update in my server is unattended so I would not really know when it will happen, therefore I basically used monit to monitor if default php is changed (the sample is before your post) and restore if such change happened. Answer for the second is no as ISP is set only to use OS default php but it does not monitor nor restore to default php in the event it has been changed. I wrote this because it happened in my Ubuntu server several times since I used Ondrej Sury php repo that have gone through several years of Ubuntu upgrade but if you set your default php and it never changed like what was reported by other Debian users, that you may not need to use this at all.
The php version upgrade breaks with an apt update, not an upgrade of ispconfig, so the upgrade script isn't running then. What you might do is instead of running via cron, set the script to run after apt updates; eg. rkhunter installs this file which you could base it on: Code: # cat /etc/apt/apt.conf.d/90rkhunter // Makes sure that rkhunter file properties database is updated after each remove or install only APT_AUTOGEN is enabled DPkg::Post-Invoke { "if [ -x /usr/bin/rkhunter ] && grep -qiE '^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then /usr/share/rkhunter/scripts/rkhupd.sh; fi"; }; APT::Update::Post-Invoke { "if [ -x /usr/bin/rkhunter ] && grep -qiE '^APT_AUTOGEN=.?(true|yes)' /etc/default/rkhunter; then /usr/share/rkhunter/scripts/rkhupd.sh; fi"; }; You might not even have the "correct" version installed. Surely the autoinstaller should install and configure the correct version; and I think ISPConfig's install/update script may check the installed version and print a warning if it's "wrong" (or maybe that was mentioned as an enhancement, but not implemented?).
Yes, i wasn't too clear there, I did actually mean after the system upgrade and not that of ISPConfig. I assumed it was possible to hook in somewhere after the upgrade had finidhed. Your code block clarifies it. To be honest I was looking for something else, ive not had this issue as yet, but then my php install was set to manual when I was rerunning all the php + modules when I had issues with the cron jobs. Probably the same report as others have made, manually set doesnt upgrade default. Then I will have to watch for that if ISPConfig moves onto a higher php version.
also you need to remember to change the cron / script / monit config after completing a dist upgrade. don't want the actual default system php version really changing to eg 7.4 and then have your monitoring set it back to the now non-system default 7.2
