This won’t be my usual “Problem, Solution, Long Story” style troubleshooting post. There are a few complexities involved that don’t allow it to fit into that template so easily.
I have a client-facing server running CentOS 5.7 and Plesk 10.3. When clients need web space, I put them on my Plesk server so they have shiny buttons to click when managing their own web space. Recently I had a series of unfortunate events cause an outage on one client.
It starts with my craving to have things standardized. All client account domain directories are in lower case. All, that is, except for one: AmazingClient. Their main domain’s vhost directory is /var/www/vhosts/AmazingClient which, in Plesk-land means that any reference to that client’s domain is always in that case. It bugs me. More than it should. When I created the client account several months ago, for some inexplicable reason, I used CamelCase in their name. One recent evening I decided to change the capitalization for their account’s main domain. Simple, right?
I did say that I’m using Plesk, did I not?
Before I go any further, I know what you might be thinking. “Domains aren’t case sensitive! What nonsense are you on about?!” They’re not case sensitive when approaching domains from a DNS perspective. However, I’m looking at this from a filesystem and Plesk user account perspective.
To change something as simple as the case of a domain’s vhost directory, one cannot merely rename it. There are many configuration files to consider as well as Plesk-specific tasks that rely on the domain’s directory not being glibly swapped out from underneath it. To change a domain’s name in Plesk, one has to go into the client’s control panel, and click on the Websites & Domains tab.
From there you will find the domain that you want to change the case of (remember, this isn’t about “domain” in the DNS sense, but rather the representation of that domain within Plesk and on the filesystem) and click on its link. From there you will come to the Host Settings page for that domain. Once on the Host Settings page, you’ll have the option to change the domain name. Here comes the trouble: you can’t change the name merely based on case. Even though Plesk sees the client domain differently in the backend based on case, in this Host Settings interface case is not taken into account. Plesk will complain that the domain already exists. You need to change the domain name to something different, then change it back to the original domain name, minus the capitalization. (Plesk FAIL #1)
In my case, I wanted to swing it from AwesomeClient.com, to awesomeclienttemp.com, and then back to awesomeclient.com (sans the capital “A” and “C”).
Tipping Over the Edge of Doom
When trying to move from AwesomeClient.com to awesomeclienttemp.com I received this error:
Internal error: [domain path] is out of webspace
Message is out of webspace
File Webspace.php
Line 334
Type PleskFatalException
After that error, the Websites & Domains tab is no longer accessible to that client account. Trying to use it receives the same “Internal Error: [domain path] is out of webspace” error.
You see, it appears that Plesk, upon requesting a domain rename, copies the domain’s existing files and then deletes the old ones. It does not perform a mere rename action (Plesk FAIL #2). This client uses quite a bit of space and it apparently maxed out their quota. I say “apparently” because, by a strict accounting for free space and quotas on the server, it should have been allowed – but just barely. Perhaps there’s more space that Plesk needs than a simple doubling of existing files. (Plesk FAIL #3?) Plesk certainly didn’t perform any kind of filesystem or account limitation checking prior to attempting the move. (Plesk FAIL #4)
The client site was still responsive; there didn’t appear to be any negative effects. I needed to investigate further, but as the night wore on I decided to postpone a thorough examination until another day.
Ask Not For Whom Your Cell Phone Tolls
Bright and early the next morning, I got a call. It was from the client.
“Our website seems to be down, so… uhh… if you could look into that…”
Super.
Nothing was being served up in response to any page requests for this domain. Apache’s error logs were showing requests for this client’s files as hitting in the default vhost root, not their own. Then, it hit me.
Plesk does not use the standard Apache configuration files. I mean, it does, but not really. It auto-generates Apache configuration files based on the information that is stored in its own customer database within MySQL. That’s why the domain was just fine the evening before, but didn’t fail until the wee hours of the morning. The configuration files had been latently generated based on the failed attempt at changing the domain account name.
Silly me… I expected there to be rollback statements in any of the SQL DML statements made to the database. I expected that a fatal error would be caught and changes rolled back. They weren’t. (Plesk FAIL #5) Silly, silly me.
Of course, I wasn’t going to be able to change the domain information because the Websites & Domains tab bombed out permanently with an internal error. I couldn’t access the officially sanctioned means of modifying the domain account. This called for some database mangling.
Let Pry Through the Portage of the Database
I logged into mysql and dumped the psa database. From there, I used grep to scour the .sql file for any mention of awesomeclienttemp. Sure enough, the bad change was recorded in the database. There were dozens of records in several tables that pointed to the bad domain. That was causing Apache configuration files to be written with bad data, among other applications. There was also mention of the original, unsullied domain. I guess not all of the SQL statements that are part and parcel of a domain change were able to be executed before the error condition was achieved. (Side note: ROLLBACK!! ROLLBACK!! ROLLBACK!!)
Solving the problem was a simple as searching for and replacing the string awesomeclienttemp with AwesomeClient. I used mysql to perform that, but it could have been done on the dump file and then imported. For those interested, I used the replace() function and performed a select statement first just to make sure that I was changing the data that I expected to. Once satisfied with the results I performed an update statement also using the replace() function. Here’s an example of changing some values in the dns_recs table of Plesk’s psa database:
mysql>> SELECT REPLACE(displayVal,'clienttemp', 'Client') FROM dns_recs WHERE displayVal LIKE '%clienttemp%';
+--------------------------------------------+
| REPLACE(displayVal,'clienttemp', 'Client') |
+--------------------------------------------+
| mail.AwesomeClient.com. |
| AwesomeClient.com. |
| AwesomeClient.com. |
| AwesomeClient.com. |
+--------------------------------------------+
mysql> UPDATE dns_recs SET displayVal=REPLACE(displayVal,'clienttemp', 'Client') WHERE displayVal LIKE '%clienttemp%';
With the database in a better state, there is still one more thing left to do. Plesk doesn’t dynamically look to the database for configuration information. It looks to regular files that have been dynamically generated from the database’s information. That generation happens on a schedule, but can be expedited using the httpdmng command. Specifically, I used:
/usr/local/psa/admin/bin/httpdmng --reconfigure-domain AwesomeClient.com
You could also use the –reconfigure-all option to perform a regeneration of all domain configuration files. After running httpdmng the domain was up and running.
Apache Test Page or Blank Page Problems
I glossed over some of the troubleshooting techniques I used while tracing the problem to its root. If you’re having trouble with seeing the Apache test page, then search through your httpd.conf file and make sure that your DirectoryIndex directive is set to look for all of the variants of an index.html page that you use. For example, index.html, index.htm. index.php, etc.
Furthermore, just to reiterate, check all of your vhost conf files, such as yourdomain/conf/vhost.conf (or any conf files that reside in that directory) for the DocumentRoot directive and make sure that it’s pointed to what you want it to be pointed at. Do not edit the files that are named similar to 13279881860.14852200_httpd.include. Those are auto-generated by Plesk and at worst you could cause destruction of files in your domain; at best you will have to re-edit those files every time a new one is generated.
Of course, do a dummy check to make sure that the domain you are trying to access is really resolving to the IP address of your web server. Just… do it. It takes 5 seconds and you have the outside chance of being pleasantly surprised.
The Takeaway
Plesk is rickety. If anyone has used a better control panel for client-facing servers, let me know. I’ve worked with cPanel and Plesk, but never with any of the others that I’ve listed in this giant list of web based server control panels. Most people will shout “Just don’t use a control panel!” but that’s not a terribly client friendly option. I’m not categorically against control panels when used in the correct situations. I am, however, against misbehaving control panels.
Let me know your experiences in the comments below.
