« Apache : Suexec pour un vhost spécifique » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| (6 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
{{ArticleHead|Adadov}}{{Obsolète}} | {{ArticleHead|Adadov}} | ||
{{Obsolète | |||
| cause = La gestion des utilisateurs se fait via PHP-FPM | |||
| nouveau = LAMP: Utiliser un utilisateur spécifique pour un vhost | |||
}} | |||
Il existe de multiples cas où on a besoin que le serveur Apache puisse écrire sur des fichiers, dans ce cas on donne généralement le droit à l'utilisateur Apache sur ce fichier et c'est tout.<br /> | Il existe de multiples cas où on a besoin que le serveur Apache puisse écrire sur des fichiers, dans ce cas on donne généralement le droit à l'utilisateur Apache sur ce fichier et c'est tout.<br /> | ||
| Ligne 31 : | Ligne 35 : | ||
Ensuite il faut configurer les vhosts, pour ça j'ai fait un template afin de simplifier la création de nouveau vhosts. | Ensuite il faut configurer les vhosts, pour ça j'ai fait un template afin de simplifier la création de nouveau vhosts. | ||
< | <syntaxhighlight lang="apache"> | ||
<VirtualHost *:80> | <VirtualHost *:80> | ||
| Ligne 60 : | Ligne 64 : | ||
</IfModule> | </IfModule> | ||
</VirtualHost> | </VirtualHost> | ||
</ | </syntaxhighlight> | ||
{DOM} = Le nom de domaine associé au vhosts. | {DOM} = Le nom de domaine associé au vhosts. | ||
| Ligne 74 : | Ligne 78 : | ||
Il doit absolument se situer dans un dossier dont les uid et gid sont identiques à ceux entrés dans la configuration d'Apache et aux siens.<br /> | Il doit absolument se situer dans un dossier dont les uid et gid sont identiques à ceux entrés dans la configuration d'Apache et aux siens.<br /> | ||
Il contiendra la définition de plusieurs variables pour PHP et la ligne de commande pour l'exécution. | Il contiendra la définition de plusieurs variables pour PHP et la ligne de commande pour l'exécution. | ||
< | <syntaxhighlight lang="bash"> | ||
#!/bin/sh | #!/bin/sh | ||
export PHPRC=/web/config/{UID} | export PHPRC=/web/config/{UID} | ||
| Ligne 80 : | Ligne 84 : | ||
export PHP_FCGI_CHILDREN=1 | export PHP_FCGI_CHILDREN=1 | ||
exec /usr/bin/php-cgi | exec /usr/bin/php-cgi | ||
</ | </syntaxhighlight> | ||
On oubliera pas de spécifier un chemin vers un fichier php.ini particulier afin de pouvoir redéfinir certaines options comme on le souhaite et éviter ainsi des problèmes. | On oubliera pas de spécifier un chemin vers un fichier php.ini particulier afin de pouvoir redéfinir certaines options comme on le souhaite et éviter ainsi des problèmes. | ||
Dernière version du 23 janvier 2023 à 15:15
|
Article obsolète. Cet article a été marqué comme obsolète, vous devriez chercher des informations plus à jour. Cause : La gestion des utilisateurs se fait via PHP-FPM Reportez vous à l'article : LAMP: Utiliser un utilisateur spécifique pour un vhost |
Il existe de multiples cas où on a besoin que le serveur Apache puisse écrire sur des fichiers, dans ce cas on donne généralement le droit à l'utilisateur Apache sur ce fichier et c'est tout.
Mais dans le cas où plusieurs webmaster ont des hébergements sur un serveur, il devient difficile de laisser à chacun la possibilité de donner les droits sur ses fichiers pour qu'Apache puisse les écrire tout en conservant la possibilité de les écrires eux mêmes.
C'est justement dans ce dernier cas qu'il devient utile que ces scripts soient lancés avec les droits de l'utilisateur qui sert au webmaster au lieu de l'utilisateur Apache.
Présentation[modifier | modifier le wikicode]
Pour mettre en place ce fonctionnement il faudra faire des modifications assez importantes dans la configuration d'Apache.
Tout d'abord, on ne peut pas utiliser mod_php. Il faut que les scripts PHP soient appelés comme des CGI, ce qui va obliger à changer tous les vhosts d'un coup. Il reste cependant possible d'utiliser PHP comme CGI tout en laissant l'utilisateur apache exécuter les scripts.
Il faudra donc aussi installer un module pour l'exécution de ces CGI, pour ma part j'ai choisi fcgid.
Et pour finir il faudra créer un wrapper pour chaque utilisateur, il s'agit là d'une histoire de droits d'exécution qu'on verra plus tard.
Apache[modifier | modifier le wikicode]
Installation des modules[modifier | modifier le wikicode]
Sous CentOS l'installation se fait très simplement, mod_fcgid est disponible directement sur les repository de la distribution et mod_suphp est disponible sur rpmforge.
| [root@linux] # | yum install mod_fcgid | dblclick to copy |
| [root@linux] # | yum install mod_suphp | |
Configuration d'Apache[modifier | modifier le wikicode]
Pour commencer j'ai changé le nom du fichier de configuration de mod_fcgid, je l'ai nommé 00-fcgid.conf afin qu'il soit chargé en premier avant même que le premier vhost ne soit lu.
Ca évitera que certains vhosts puisse ne pas fonctionner correctement.
Ensuite il faut configurer les vhosts, pour ça j'ai fait un template afin de simplifier la création de nouveau vhosts.
<VirtualHost *:80>
ServerName {DOM}
ServerAlias *.{DOM}
DocumentRoot /web/{FOLD}
CustomLog logs/{DOM}.log combined
Options FollowSymlinks
<IfModule mod_fcgid.c>
Alias /fcgi-bin/ /var/www/cgi-bin/
<Location /fcgi-bin/>
SetHandler fcgid-script
Options +ExecCGI
</Location>
SuexecUserGroup {UID} {GID}
<Directory /web/{FOLD}>
Options +ExecCGI -Indexes IncludesNOEXEC FollowSymlinks
AddHandler php-fcgi .php
Action php-fcgi /fcgi-bin/{UID}/php-{UID}
FCGIWrapper /var/www/cgi-bin/{UID}/php-{UID} .php
Allow from all
AllowOverride All
</Directory>
</IfModule>
</VirtualHost>
{DOM} = Le nom de domaine associé au vhosts.
{FOLD} = Le nom du dossier où se trouve le site.
{UID} = Le nom de l'utilisateur qui servira pour exécuter les scripts.
{GID} = Le groupe qui servira pour l'exécution des scripts.
 | Dans le cas où le vhost ne serait disponible que pour un nom d'hôte particulier, il faudrait enlever la ligne ServerAlias et adapter le ServerName |
Les Wrapper[modifier | modifier le wikicode]
Vient ensuite le wrapper, c'est lui qui va servir à exécuter PHP.
Il doit absolument se situer dans un dossier dont les uid et gid sont identiques à ceux entrés dans la configuration d'Apache et aux siens.
Il contiendra la définition de plusieurs variables pour PHP et la ligne de commande pour l'exécution.
#!/bin/sh
export PHPRC=/web/config/{UID}
export PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_CHILDREN=1
exec /usr/bin/php-cgi
On oubliera pas de spécifier un chemin vers un fichier php.ini particulier afin de pouvoir redéfinir certaines options comme on le souhaite et éviter ainsi des problèmes.
Une fois ce fichier en place et les droits correctements définis, le vhost doit fonctionner.
On peut surveiller le fichier /var/log/httpd/suexec.log qui enregistre tous les appels fait via le module Suexec afin de garantir le bon fonctionnement.
Retouches pour php.ini[modifier | modifier le wikicode]
La seule retouche que j'ai dû faire absolument est de modifier le chemin pour le stockage des fichiers de session.
En effet vu que ce n'est plus Apache qui vient écrire les fichiers il devient compliqué de laisser tous les fichiers de session dans le même dossier, puis c'est pas très sécurisé non plus.
Donc on va modifier la directive session.save_path pour la faire pointer vers un dossier où seul l'utilisateur concerné aura le droit d'écriture (et de préférence hors du dossier contenant le site).