Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have set up a LAMP-server using ISPConfig 3 for the administration. PHP is running over Fast-CGI.

I have several domains, like, and, but they all point to the same application/website. Each domain has its own web-root-folder and is running under its own user. The application itself is in a common directory which is owned by another user, like so:

# path to my_application (owned by web1)

# sym-link to my_application from (owned by web5) 
/var/www/ -> /var/www/clients/client1/web1/web/ 

# sym-link to my_application from (owned by web4) 
/var/www/ -> /var/www/clients/client1/web1/web/ 

With a setup like this I have encountered a few problems concerning the permissions when performing filesystem-operations with PHP. For instance, if the application is called via, the user web5 is trying to write something to the application-folder. But the application-folder is owned by the user web1, so web5 is not allowed to write there.

As far as I unterstand, this is how Fast-CGI works.

After some research and asking a few people, the solution seems to be to break it all down to one domain (e.g. and define the other domains (, as alias for this one domain. That way, there would be only one user who has all necessary permissions.

However, this would mean that we'd have to buy a multidomain SSL-certificate - but we already have an SSL-certificate for each domain. We were able to use them with our previous provider (managed hosting), and there we also had only one web-directory and multiple domains.

So if this was possible, I wonder: Is putting all the domains together into one v-host with one main- and several alias-domains the right approach in this case? Or may I have misunderstood something?

share|improve this question
what about using .htaccess to redirect all other domains to the domain/directory where you host the application? – Hex Sep 29 '12 at 15:02
@Hex I guess this is not an option since it is important that the top-level-domain stays like how the user entered it. It's also needed within the application. And as far I understand, the user would still not be allowed to perform filesystem operations. – Quasdunk Sep 29 '12 at 15:07
Ok then try creating a group, add the users to that group and then give the necessary permissions to the directory for that group. – Hex Sep 29 '12 at 15:11
@Hex They already are in the same group (client1) and I've already sort of "patched" the problem for the necessary directories with chown -R g+rwx dir/, but I'm not sure if this is really the solution since those permissions did not work in every case and they also are different from what we had before with our old hosting provider (and it worked fine with those permissions). I'm not too familiar with this and I'm afraid I migh tear a security hole in my application without noticing it... Or is it ok to have permissive group settings? – Quasdunk Sep 29 '12 at 15:26
You should really go close or delete your old questions before one of them gets closed for you. – Brent Pabst Sep 29 '12 at 15:30

Turning my comment into an answer.

I would aim for one Apache process running as one system user but serving several IP addresses corresponding to several domain names, each with its own SSL certificate. Unless explicitely configured otherwise (e.g. using suEXEC or the -user option to FastCgiServer), Apache will launch all child processes as the same user it's using for its own access to the data, independently from the virtual host a request belongs to. How many processes there will be depends on the server configuration, ist MPM in particular, but as long as all processes belong to the same user, you shouldn't have to care for this issue here. Use IP-based virtual hosts in the apache config, as name-based SSL certificate selection requires SNI which still isn't supported by all clients.

I don't know whether your management tools can handle this. Feel free to edit this answer and provide details on that once you know.

share|improve this answer
Sorry for the late reaction, and thanks again for your answer. Unfortunatelly this did not quite work out, so I've decided to go for a multi-domain SSL-cetificate. +1 for your effort though! – Quasdunk Oct 26 '12 at 19:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.