Impossible d'installer de nouveaux plugins à cause de l'erreur "Impossible de créer le répertoire"
Un membre du corps professoral a des difficultés avec une installation wordpress pédagogique. Résoudre les problèmes de permission individuels a été aléatoire et est devenu une douleur pérenne, je vais donc poser la question ici. Que puis-je faire pour que WP Just Work? Les types d'erreurs qu'ils obtiennent:
Installation du plug-in: Lightbox 2 2.9.2 Téléchargement du package d'installation à partir de http://downloads.wordpress.org/plugin/lightbox-2.2.9.2.Zip … Déballer le package… Impossible de créer le répertoire. /home/CIM140/public_html/wordpress/wp-content/upgrade/lightbox-2.tmp
Quand je su comme www-data (l'utilisateur Apache s'exécute comme dans Ubuntu), je peux rendre ce répertoire très bien. Mon instance de test wp installe parfaitement ce plugin, je ne comprends donc pas pourquoi il échoue pour eux.
@pwnguin,
J'avais les mêmes problèmes sous mod_php avec WordPress et je l'ai finalement compris.
# chown www-data:www-data /home/CIM140/public_html/wordpress/ -R
Tant que VOUS contrôlez la boîte, cela ne posera aucun problème de sécurité.
MODIFIER:
Vous devrez peut-être également changer votre umask en 022 pour que les nouveaux répertoires créés par WordPress disposent de 755 autorisations et les fichiers de 644 autorisations.
Une autre option consiste à remplacer les autorisations de fichier par défaut dans wp-config.php:
define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));
Vous pouvez également forcer la méthode du système de fichiers pour les mises à jour.
- (Préférence principale) "Direct" l'oblige à utiliser les demandes d'E/S de fichier directes à partir de PHP, ce qui entraîne de nombreux problèmes de sécurité sur des hôtes mal configurés. Cette option est automatiquement choisie si nécessaire.
- (Préférence secondaire) "ssh" force l'utilisation de l'extension SSH PHP.
- (3ème préférence) "ftpext" est de forcer l'utilisation de l'extension FTP PHP pour l'accès FTP, et enfin
- (4ème préférence) "ftpsockets" utilise la classe PHP Sockets pour l'accès FTP.
Ceux-ci peuvent être définis dans wp-config.php avec: define('FS_METHOD', 'ftpext');
Vous pouvez obtenir toutes les constantes actuellement définies en exécutant la commande print_r(@get_defined_constants()); en php.
Pour moi (sur Ubuntu), je devais ajouter umask 002 à /etc/Apache2/envvars afin de permettre à Wordpress de télécharger des plugins/images avec 775 autorisations au lieu de 755 (c'est-à-dire permettre à toute personne autre que Apache et root de modifier les fichiers téléchargés)
Afin de comprendre pourquoi vous rencontrez ces problèmes, vous devez comprendre les concepts sous-jacents de propriété.
En gros, vous savez qu'Apache est exécuté en tant qu'utilisateur www-data. C’est la raison pour laquelle il est judicieux de définir tout ce qui appartient à cet utilisateur, car WordPress vérifie qu’il peut créer des fichiers en tant qu’utilisateur propriétaire de ses propres fichiers. Donc, ce que vous faites est de rendre tout ce qui appartient à l'utilisateur qui possède les fichiers.
Si vous avez le contrôle total et complet de la machine, c'est très bien. D'autre part, s'il s'agit d'un serveur d'hébergement partagé, vous avez créé un trou de sécurité.
Normalement, les serveurs Web fonctionnent comme un utilisateur (comme www-data) qui exécute ensuite le code par d'autres utilisateurs (comme "otto", mon compte utilisateur). Dans cette situation, le serveur Web ne serait pas en mesure de créer des fichiers en tant que "otto" et ne pourrait donc pas créer correctement des fichiers en tant que mon compte. Ainsi, cette vérification par WordPress quant à la création de fichiers correctement détenus et donc l’installation de plugins ou la mise à jour de fichiers échouerait correctement, car les fichiers my appartenant à l’utilisateur shared serveur Web être un risque de sécurité.
Dans un tel cas, WordPress devrait correctement me demander des informations d'identification FTP, ou quelque chose de similaire. Cela permettrait de contourner le problème du compte d'utilisateur en s'authentifiant en tant qu'utilisateur devant écrire les fichiers, puis en les écrivant en tant qu'utilisateur.
Maintenant, vous essayez de résoudre ce problème en modifiant le nom de tous les fichiers WordPress appartenant au même compte que le serveur Web. L’approche la plus normale consiste à modifier la façon dont le serveur Web écrit les fichiers, afin de permettre au processus PHP d’être "détenu" par le compte utilisateur sous lequel il exécute les fichiers.
La réponse générale à cette question est "suphp". Cette version de PHP définit l'utilisateur que le processus PHP s'exécute sur le même utilisateur que le propriétaire des fichiers PHP qu'il exécute. Ceci est plus sûr pour les configurations d'hébergement partagé, car il garantit qu'un processus PHP exécuté par le serveur Web partagé s'exécute en tant que propriétaire des fichiers PHP et ne peut donc pas lire les autres utilisateurs. comptes et autres.
Sur Ubuntu, je pense que c'est la manière générale de le faire:
Installer suphp:
$ Sudo apt-get install libapache2-mod-suphp
Désactiver l'ancien mod_php
$ Sudo a2dismod php5
Redémarrer Apache
$ Sudo /etc/init.d/Apache2 restart
Et voila. Maintenant, ayez vos fichiers WordPress PHP appartenant au Normal leur propriétaire. Aucune astuce spéciale, aucune modification des autorisations ou de la propriété ou quoi que ce soit du genre. Puisque le processus PHP s'exécutera en tant que propriétaire de ces fichiers, il pourra alors leur écrire en tant que propriétaire. Les répertoires doivent être au nombre de 755, les fichiers au nombre de 644 (note, le suffixe ne plaît pas lorsque les fichiers sont inscriptibles par groupe, donc 755/644 est le jeu d'autorisations correct).