How do I setup suphp for ISPConfig3 on debian etch? I tried to install the package, made sure the module is active, and I get: Invalid command 'suPHP_UserGroup', perhaps misspelled or defined by a module not included in the server configuration failed! when I restart apache. another question: do I normally (if all is well) need to restart/reload apache after adding a site through ISPConfig? one last question: I noticed that the web directory for a site looks something like this: /var/clients/client0/web1/web is it possible to have the user files stored under his home directory? (/home/user)
1) Uninstall mod_suphp from debian and try this guide: http://www.howtoforge.com/install-s...tions-for-use-with-ispconfig-2.2.20-and-above 2) no 3) No, as there is no such directory as /home/user in ISPConfig3.
Thanks, I`ll try the suphp link. about /home/user : I noticed that when I create a site through ispconfig (3), there is an option to specify the linux user and group, and the directory for the site. however, it does not seem to make any actual difference. is that a bug? I tried to create a shell user. the user was create in ispconfig but was not created on the server (nothing in /etc/passwords). another bug or am I missing something? what is the proper way of granting users shell access, and make sure they have access to their web sites?
No, thats not a bug. You will have to create the user and directory manually before, there is no assistence from ispconfig in ths. Also it is not recommended to change this setting at and it may cause the complete vhost to fail. There is no known bug with that. I just tested it and it works for me. maybe a bug in your setup. Aditionally, if you changed the settings that you mentioned above, the creation of shell users may fail. Create a shell user in ispconfig interface.
I see. from the usability standpoint, ispconfig should fail the action if the directory/user does not exist instead of succeeding with the default value. I deleted my test host, created it again, and now I managed to create an shell user and login with it. one thing is bothering me: when I create a shell user, I am associating it with a site and not with a client. this means that for a client with multiple sites, I will have to create a user for each site. this is cumbersome. is it possible to create a shell user for a client, which will have access to all the client sites? About suphp: I got it to work, but I also had to apply the patch from here: http://www.howtoforge.com/apache2_suphp_php4_php5_p2 any idea what suphp is not patched with this by default? looks like suphp is almost but not quite working, and it's a pity that users have to go through all those fire hoops to get it to work. unless there is a good reason, the suphp debian package should be configured in a way that allows the use case for ispconfig by default. thanks for all your help.
Maybe I remove the option to change the user and path until the final version. This is a matter of security. If all sites of a client share the same user, they will all be affected of a hack if one of the sites get hacked as the scripts of the site run under this user. neverthesless, all sites of a user share the same group, so als long as your files are grup writable, it can be accessed by the same user. This question you will have to ask the maintainer of the suphp packages. I have removed the suphp_UserGroup directive now. But this is not as secure as the configuration with Usergroup. Without suphp_UserGroup setting, the php scripts are run under the user that owns the files. This is genrally fine as long as you uploaded the files with the correct user. But in case you (as root admin) coped some files from another website and forgot to chown the files, they will get wrong access priveliges, with suphp_UserGroup setting you would have got a 500 error in this case.
I understand your point, but personally I am willing to live with user level isolation. is there any chance for this to be implemented, at least as an option? I see. in fact this question should go to the suphp developer first, because the latest code he released does not allow proper usage of the suphp_UserGroup settings. I had to slightly change the code.
This is not planned yet. As far as I know, its not a problem with the suphp developer. It is a question of compile options. If suphp is compiled with --with-setid-mode=paranoid, then suphp_UserGroup can be used, otherwise not. The only thing I dont know is why this setting is not just optional, so if suphp_UserGroup is there use it, otherwise rely on the ownership of the files.
as I said, you need to apply this patch for the directive to work in the contect ispconfig is trying to use it: http://www.howtoforge.com/apache2_suphp_php4_php5_p2
because you removed the usage of suPHP_UserGroup. you said yourself it's more secure.. about updating: once I update my source dir from svn, how do I upgrade the system?
No. The patch you applied has nothing to do with this. The patch is applaide as suphp does not read configuration settings that are written in a vhost instead of a directory directive. run: ispconfig_update_from_svn.sh on the shell as root user.
True, and since ispconfig puts the suphp section inside the vhost (and not inside a directory), the patch is needed. without it apache bitches that it can't accept one of the directives (suPHP_UserGroup?) in the suphp clause. about ispconfig_update_from_svn.sh : looks like a more efficient way would be to do : svn up cd install php -f update.php from the directory where I checked up ispconfig from.
seems to be broken in svn. I get this: [Thu Sep 18 22:32:53 2008] [error] [client 79.178.130.180] No user or group set - set suPHP_UserGroup
Its not broken. The setup has just been switched to support the suphp packages that come with the linux distributions. As your suphp is compiled with "paranoid" mode, you will have to enable the suPHP_UserGroup line in the vhost master configuration file in /usr/local/ispconfig/server/conf/ again.
