During a phase of system testing on server c1, in the new datacentre, an interesting problem was discovered.
Using WordPress as the template (so the results could be applied to Drupal installations – and any other of those .php-related content management systems), we discovered that permissions on high-level directories were not being replicated down to low-level directories.
This meant a loss of function (where that function relied on scripts that are installed in those low-level directories by the vanilla application).
In WordPress and Drupal, for example, uploading media of any type wouldn’t work.
This is a significant barrier for a content management system.
The first workaround seemed to solve the problem, except that the uploaded files were owned by Apache (the webserver in the LAMP stack).
Unfortunately this took us to another permissions-based problem which stopped the owner (system user) modifying those files – even through ftp.
If you think about it for a minute, it’s an interesting problem – where a vanilla software installation granted the higher-level directories one set of permissions, while the lower-level directories were granted different (and functionality-limiting) permissions.
Anyway.
The first attempt to fix the problem was to deploy suEXEC on the server (VM). Unfortunately suEXEC didn’t get us all the way out of the problem, so we needed to look for another solution.
The second attempt to make the problem go away was to use fastCGI.
Yesterday afternoon Manuel, our brilliant technical resource, deployed fastCGI on the VM we have been using as a test.
I used the standard WordPress admin control panel to upload an image in to a test post and successfully published that.
Then created another test post, uploaded the image in to that and successfully published it.
Then I went back to both published posts and using the standard WordPress screen, I modified the second image and republished the post.
All of these tests worked.
Manuel’s next job is to add the deployment of fastCGI in to the VM creation template.
This will enable the datacentre to deploy a fully-functional LAMP-stack VM for a customer within a matter of seconds.
Well done Manuel!
Does that make you Basil? Sorry!
I don’t pretend to understand how web server permissions should be set up, but I am intrigued why a tool is required to be installed. Is it a matter of out-foxing a wayward CMS install process?
It’s a problem that exists at the OS level, Allister. A combination of SELinux restrictions and the native behaviour of the CentOS platform. The way most hosting organisations get around it is to cheat – to loosen permissions down from the root of the VM.
What I wanted to achieve was a completely secure environment with SELinux and the OS restrictions in place, but allowing full user functionality.
Mind you, a technical enabler to the fix that had to be deployed first was to change the OS from CentOS to Debian. So I built a replica host, installed Debian, then Manuel laid in KVM over the top of the OS and did a virtual-to-virtual migration of the VMs on to the new platform.
But that’s a different story.
🙂
Ahhh, it all makes sense to me now.
Not.