Facebook
Twitter
burnleyvic
Regular Pleskian
The issue, which we consider major due to the mail & www services outage caused, was SELinux related. Let me explain:
This Plesk server runs as domU under Xen. Probably because it's not running under Virtuozzo the installer assumes SELinux support, *but* the way it's restoring the SELinux context is just plain wrong! Plesk installer ran restorecon & setsebool *twice*, once for mail upgrade and once for www upgrade. The total outage caused was almost an hour! During the outage the mail authentication wasn't working for any of the services using it and all the websites were displaying the default CentOS page. Pretty embarrassing I'd say, what do you reckon?
In our case we run this box in Permissive mode -> we don't need the SElinux file contexts to be restored for the services to run. Simply put, we didn't need to run restorecon, setsebool & friends at all, the misconfiguration will only cause excess noise in the logs, which we can live with.
I'd suggest you some installer adjustments to deal with this case:
- if getenforce=Permissive or Disabled, defer SELinux-related commands for a later stage and carry on with the upgrade of the remaining packages to minimize the outage windows. Once everything is back up and running, including the Panel, run restorecon & the likes. Your developers should look into the rpm triggers for this, or the similar deb feature for Debian-based installers.
- in all cases, stop Postfix to avoid the bounces generated by your very own postfix-local not being able to find files or directories because the mail-related Plesk packages were in the process of being upgraded.
We just can't afford to have critical service outages for this long. Please think of the service availability when working on the upgrade process logic from now on.
This Plesk server runs as domU under Xen. Probably because it's not running under Virtuozzo the installer assumes SELinux support, *but* the way it's restoring the SELinux context is just plain wrong! Plesk installer ran restorecon & setsebool *twice*, once for mail upgrade and once for www upgrade. The total outage caused was almost an hour! During the outage the mail authentication wasn't working for any of the services using it and all the websites were displaying the default CentOS page. Pretty embarrassing I'd say, what do you reckon?
In our case we run this box in Permissive mode -> we don't need the SElinux file contexts to be restored for the services to run. Simply put, we didn't need to run restorecon, setsebool & friends at all, the misconfiguration will only cause excess noise in the logs, which we can live with.
I'd suggest you some installer adjustments to deal with this case:
- if getenforce=Permissive or Disabled, defer SELinux-related commands for a later stage and carry on with the upgrade of the remaining packages to minimize the outage windows. Once everything is back up and running, including the Panel, run restorecon & the likes. Your developers should look into the rpm triggers for this, or the similar deb feature for Debian-based installers.
- in all cases, stop Postfix to avoid the bounces generated by your very own postfix-local not being able to find files or directories because the mail-related Plesk packages were in the process of being upgraded.
We just can't afford to have critical service outages for this long. Please think of the service availability when working on the upgrade process logic from now on.
