Hi, everyone, I upgraded from ISPC 220.127.116.11 (I think) to 18.104.22.168. Everything seemed to go smoothly and I was able to access the ISPC interface. But some 10 to 15 minutes later, all hell seemed to break loose on this server. In particular, I began to notice several permissions-related problems, such as "immutable" flags being set on files within some of the websites stored in the /var/www directory. I ran "chattr -R -i /", which seemed to fix the immutable problems, but then I noticed others. The first symptom I observed was this, in /var/log/apache2/error.log: Code: Warning: SuexecUserGroup directive requires SUEXEC wrapper. I found the thread at http://www.howtoforge.com/forums/showthread.php?t=29912 and ran "apt-get install apache2-suexec", which fixed this problem. Everything seemed to be well, until 10 to 15 minutes later when the same problem occurred again. So, again, I installed apache2-suexec, and it fixed the problem. How is this software being uninstalled? This server is a mediaTemple VPS, and I assume that some of the core system image components are shared among several instances, and they were doing maintenance on some servers (although, supposedly not this one) during this time. (I wonder if they broke something during the maintenance on other servers.) But now, whenever I try to access the ISPC interface, I receive a server 500 response and see the following in /var/log/apache2/error.log: Code: [Sat May 11 14:43:52 2013] [notice] mod_fcgid: call /var/www/ispconfig/index.php with wrapper /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter /usr/bin/php-cgi: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory [Sat May 11 14:43:52 2013] [warn] [client 22.214.171.124] (104)Connection reset by peer: mod_fcgid: error reading data from FastCGI server [Sat May 11 14:43:52 2013] [error] [client 126.96.36.199] Premature end of script headers: index.php [Sat May 11 14:43:58 2013] [notice] mod_fcgid: process /var/www/ispconfig/index.php(20179) exit(communication error), terminated by calling exit(), return code: 127 It seems that libz.so.1 is part of the zlib package, which is definitely installed. And, when I perform a "find" on that file, the same two files exist that exist on my other servers that don't have this problem: Code: find / -name "libz.so.1" /var/www/clients/client1/web9/lib/libz.so.1 /var/www/clients/client1/web4/lib/libz.so.1 /usr/lib32/libz.so.1 /lib/libz.so.1 I also see the following, which I assume to occur whenever ISPC tries to do its scheduled monitor check: Code: [Sat May 11 14:45:01 2013] [error] [client 127.0.0.1] client denied by server configuration: /htdocs I'm wondering if anybody might know what could have happened, and more importantly, how to fix it. Thanks for any help here! EDIT: I was able to get back into the ISPC interface by commenting-out the SuexecUserGroup directive in /etc/apache2/sites-enabled/000-ispconfig.vhost: Code: <IfModule mod_fcgid.c> DocumentRoot /var/www/ispconfig/ #SuexecUserGroup ispconfig ispconfig <Directory /var/www/ispconfig/> Options Indexes FollowSymLinks MultiViews +ExecCGI AllowOverride AuthConfig Indexes Limit Options FileInfo AddHandler fcgid-script .php FCGIWrapper /var/www/php-fcgi-scripts/ispconfig/.php-fcgi-starter .php Order allow,deny Allow from all </Directory> IPCCommTimeout 7200 MaxRequestLen 15728640 </IfModule> Now I can log into ISPC. But I hesitate to change anything until I can figure out what happened to "break" ISPC in the first place. Might anyone know how to fix this situation, which seems to be suexec-related? EDIT 2: I should mention that I have several other sites whose PHP mode is set to Fast-CGI with the SuExec box checked, and these sites always functioned, even when the ISPC virtual host went tits-up. And they continue to function now, yet their vhost files also contain the "SuexecUserGroup" directive: Code: <IfModule mod_suexec.c> SuexecUserGroup web14 client1 </IfModule> Ultimately, I am wondering why using this directive causes the libz.so.1 failure when used in the ISPC vhost configuration, but seems not to cause problems anywhere else.