I’ve started my own business, and have been working with a friend’s business to migrate his web hosting clients over to my servers. For the most part this transition has been smooth, except for one client. Due to how their directories were configured (and WP misconfigurations), instead of creating normal subdomains through ISPConfig, I had to create them as new domains. This was fine until they changed their name servers to reflect mine…then in came the 500 and 503 errors. Luckily, I documented what I did for similar issues with those who use Apache2 + PHP + ModFCGI.
I spent a good hour cycling through the vhost config file trying to figure out why the include paths were not working and showing. This is the first time I’ve used FCGI (a successor of sorts to FastCGI), so I wasn’t considering it being a possible cause.
After I exhuasted the vhost config file possibility, I decided to figure out where the include_path was specified, because no matter where and how I included “php_value include_path “…”” in the vhost file, it wouldn’t read. I did the old-school trick of running grep on the directory:
grep -r -H “include_path” .
This was initially done on the Apache2 directory (/etc/apache2), but it returned nothing helpful. So, in a hail-marry attempt I ran that same command in the web-root (/var/www/) directory. Low and behold, there was a “.php-fcgi-starter” script in a lot of the directories for web-users, except for the one I needed. After making some changes to the user’s account (the starter script wasn’t created due to going over the disk-space limit), I copied over a starter script from a previous install. I made it half-way to the finish line. PHP was running for it (which took care of the 500 errors), but now the website still wasn’t loading, and was giving out 503 errors.
How did I fix this? Well, there are two commented-out lines:
These two were the culprit of the 503 errors. After I uncommented these lines and reloaded Apache2:
service apache2 reload (my servers run Ubuntu)
The website loaded properly. Now, I just had to do this for their subdomains as well, and one was not as nice to me.
All in all, it took about 5 hours to help the client, with some lengthy periods of no communication. So, about a total of 3 hours of actual work (1 hour due to a DNS resolve issue, 2 hours trying to get the domains and subdomains to play nicely). A productive, but unnecessary long night because documentation via ISPConfig doesn’t go into this detail.