Introduction / Abstract
Almost every server operator is (at least if he has customers) want to use a Web server or need.
In the simplest version with mod-php PHP interpreter with the same rights as the webspace is running. Is convenient, it can read and write everything you need nothing (?) Set.
Disadvantage: it can actually read and write everything. For example, the directories of another customer. If you like testing with webadmin whether one comes out from its directory.
Then there are mod-suphp, which starts an extra page for each PHP interpreter with appropriate user rights.
That’s better! But unfortunately very very slow because really once for each page view is loaded and the PHP interpreter is terminated after
A better (in my eyes) solution is to start php as fastcgi. This PHP per user but once started and then reused.This allows each user their own php.inis but also own php versions (PHP4 anyone?) To use and is much faster – only the first call will take a little longer.
In my eyes the best solution even if one should go for really large number of customers tend to suphp. since for each user (account) a php is held, which can use in the long run some RAM.
I use this configuration in a suExec + fcgid, that is, each domain runs under a user.
This harmonizes beautifully with the individual FTP users in my PureFTPd HowTo
For discussion / corrections please use forum thread use
Vorneweg some limitations:
This is because there is no copy and paste howto. It may have been forgotten individual sub-steps, and spelling errors have occurred. Who does not know a broken system will possibly create – test (VMWare) and you should be able to debug.
If you want to use this configuration a system is obtained, which is much safer than a standard mod_php installation.
There are also disadvantages:
- It is slower than mod_php (after first starting the process but not excessively)
- You can not install web applications as Debian packages. More precisely, one can not install Debian packages without after its configuration (vhost / php.ini) to tackle it.
The Debian packages use Apache as www-data display properly, suexec and open_base_dir play there without further with. On stresfreiesten to install phpmyadmin and Co by heruntergeläd and installed it myself.To update one must then take care of itself but.
- The memory requirements can be very large for many users. Who should 1,000 different planning domains and that 1000 users and PHP instances to his crate to have possibly look for other options.
We install apache2, php5 as cgi / fcgi and mod-fcgid (should work with all the mod-fastcgi etc) to prevent suexec works, we also need the (alternative: apache2-suexec-custom)
aptitude install libapache2-mod-fcgid php5-cgi apache2 apache2-mpm-worker apache2-suexec
Not surprised the php version is also compatible fcgi despite the name.
Then activate the fcgid module. Suexec must also be started.
a2enmod fcgid a2enmod suexec
Now we need a web account per user, under whose rights then PHP is running.
So that Apache can also read later that the user associated with html pages he must belong to the appropriate group:
adduser www-data example
In the directory structure, the rights are very important for suexec must be in the Debian variant everything under / var / www and the users IDs are to be greater than 1000.
I suggest the following structure, so that all the important data are together:
/ Var / www / example.com / conf / php.ini # here is for this domain / Var / www / example.com / docs / # here the normal Webroot / Var / www / example.com / logs / logfiles # / Var / www / example.com / tmp / session data # / temporary data / Var / www / example.com / php-fcgi / # startup script for fcgid
(In my case I have both users and the directories under / var / www a domain name or something like that .. that facilitates the mapping.
So create and set the (correct) rights:
mkdir-p / var / www / example.com / conf mkdir / var / www / example.com / docs mkdir / var / www / example.com / logs mkdir / var / www / example.com / tmp mkdir / var / www / example.com / php-fcgi chown root: example / var / www / example.com chmod 750 / var / www / example.com chown example: example / var / www / example.com / * chmod 750 / var / www / example.com / * chmod 550 / var / www / example.com / conf
We copy the php.ini from / etc/php5/cgi / our directory:
cp / etc/php5/cgi/php.ini / var / www / example.com / conf /
We adapt to our needs and php provide a little security:
open_basedir = / var / www / example.com / docs / :/ var / www / example.com / tmp / upload_tmp_dir = / var / www / example.com / tmp session.save_path = / var / www / example.com / tmp
The most important setting is the OpenBasedir, which imprisons the php process in the two relevant directory.the other two will make sure that this instance of their session data, uploads, etc. invests in its own tmp directory.
For more suggestions, I’m open (docroot? More memory?)
So that the php.ini is used must adjust the rights
chown example: example php.ini chmod 440 php.ini
Concerns should be the module that reads it automatically installed in every vhost active (mysql, pdo, xcache, etc.) because Debian default / etc/php5/cgi/conf.d. This can prevent by symlink removes the conf.d to. But after that you have to install separately per vhost, which at least in often needed modules / extensions (GD or mysql) is annoying any necessary modules. Alternatively, you can remove individual extensions from the conf.d and accessible only to certain vhost php.ini make about their (Xcache etc.)
Creating fcgi starter
In / var / www / example.com / php-fcgi we create a file called php-fcgi-starter:
cat> / var / www / example.com / php-fcgi / php-fcgi-starter << EOF # / Bin / sh PHPRC = "/ var / www / example.com / conf /" export PHPRC export TMPDIR = / var / www / example.com / tmp exec / usr/bin/php5-cgi EOF
Give all the users, otherwise suexec complaining and it does not work:
chown example: example / var / www / example.com / php-fcgi / php-fcgi-starter
Put even have the proper privileges otherwise makelt suexec – 750 comes to us just right:
chmod 750 / var / www / example.com / php-fcgi / php-fcgi-starter
So that the user can not change it but we set the immutable bit:
chattr + i-v / var / www / example.com / php-fcgi / php-fcgi-starter
Creating Apache vhost
Apache has this for a certain directory (our domain) can be said for a specific startup script is responsible for fcgi.
I’ve had good experiences with the following version,
cat> / etc/apache2/sites-available/example.com << EOF <VirtualHost *:80> Server Admin firstname.lastname@example.org ServerName example.com ServerAlias www.example.com SuexecUserGroup example example AddHandler fcgid-script. Php DocumentRoot "/ var / www / example.com / docs" DirectoryIndex index.php index.html index.htm <Directory /> Options FollowSymLinks AllowOverride None </ Directory> <Directory "/var/www/example.com/docs"> Options Indexes FollowSymLinks MultiViews + ExecCGI FCGIWrapper / var / www / example.com / php-fcgi / php-fcgi-starter. Php Order allow, deny allow from all </ Directory> ErrorLog / var / www / example.com / logs / error.log LogLevel warn CustomLog / var / www / example.com / logs / access.log combined ServerSignature On </ VirtualHost> EOF
Then activate the site:
The SuexecUserGroup specifies the user runs under the whole course, and must match the owner of the respective directories.
- If the permissions?
- What do the log files / var / www / example.com / logs / error.log or / var/log/apache2/suexec.log
- Apache kannphp holders no html files -> is www-data belonging to the group?