Modifications de la configuration Apache/Linux pour faciliter la mise à niveau automatique
J'ai lu desmessages qui semblent toucher à ce sujet ( ou peut-être en parler, mais ça me dépasse la tête). Unix n'est pas mon point fort.
J'ai hérité d'un serveur Fedora un peu chaotique en ce qui concerne les mises à niveau automatiques.
Deux choses que j'ai remarquées: 1. Cela me demande l'utilisateur FTP et le mot de passe. J'aimerais éliminer cela SANS recourir à la codification en dur des informations d'identification (pour un certain nombre de raisons) 2. La dernière mise à jour 3.3.1 échoue pour des raisons de permission (les mises à jour précédentes n'ont pas échoué). La solution consiste à utiliser Sudo chmod -R g + w ./* dans le répertoire principal de wp, mais j'en ai marre de le faire à chaque fois.
En bout de ligne: les choses fonctionnent, mais c'est plus de travail que je ne le voudrais.
À l'heure actuelle, tout semble fonctionner sous l'utilisateur 'Apache', qui est membre de mon groupe de 'développeurs', qui est le même groupe pour les différentes personnes qui FTP et modifie/édite les fichiers/dossiers. Mais tous les nouveaux fichiers/dossiers créés par ces utilisateurs n'ont pas leur mode d'écriture de groupe défini, donc je dois le faire manuellement ...
Des pensées? J'aurai besoin d'un peu étape par étape puisque je suis un crétin Unix.
Merci!
T
La réponse la plus simple est:
Tant que vous utilisez un serveur RedHat/CentOS/Fedora relativement standard, assurez-vous que tout ce qui se trouve dans votre répertoire WordPress appartient à Apache: apache. Cela empêchera l'invite pour les informations d'identification FTP.
L'avantage de procéder de cette façon est que, dans presque TOUTES les situations, Apache a/bin/false ou/sbin/nologin configuré en tant que son shell. Cela empêche quiconque d'exploiter l'utilisateur Apache pour obtenir un accès Shell à votre boîte.
Je pense que vous êtes probablement surpris par des répertoires héritant des autorisations d'utilisateurs avec des shells valides dont les masques sont définis de manière amusante. Essayez de tout chowner à Apache: apache et faites quelques mises à jour de test pour voir si cela ne résout pas 99% des problèmes que vous rencontrez.
La réponse à cette question est plutôt compliquée.
Sur un serveur partagé (exécutant plusieurs sites Web), l'utilisation d'un processus setuid pour PHP (par quelque moyen que ce soit) offre une sécurité supplémentaire intra-utilisateur. Si deux personnes ont accès à un serveur et que leurs scripts s'exécutent sous le nom d'utilisateur "Apache" unique, une personne accédant à un site via le Web ne gagne que les privilèges de cet utilisateur, pas ceux de "Apache", ce qui sera plus grand (Apache peut voir les fichiers Web de tout le monde, par exemple, afin de les exécuter, mais "otto" ne peut pas voir les fichiers de "bob").
Dans ce cas, WordPress sera exécuté en tant que "otto" et non "Apache". Puisqu'il fonctionne en tant que "otto" et que les fichiers WP appartiennent à "otto", il peut simplement écrire les fichiers directement et ne nécessite pas d'informations d'identification FTP.
Vous voyez, tout est une question de propriété. Si les fichiers appartiennent au même utilisateur que WP en cours d'exécution en tant que, il utilisera la méthode directe. Sinon, il faut alors recourir à la méthode FTP (ou autre), car lors de la mise à niveau, l'important est que la propriété du fichier ne change pas. S'il essayait de les écrire directement en tant qu'utilisateur Apache, alors "Apache" serait propriétaire des fichiers résultants. Ce qui pourrait être un risque de sécurité sur un serveur dédié.
Pour un serveur dédié, le fait de posséder les fichiers appartenant à un utilisateur autre qu'Apache tout en ayant PHP exécuté sous 'Apache' est le plus sûr. Peut-être même la configuration d'un utilisateur spécial juste pour posséder ces fichiers pourrait être préférable et plus sécurisante dans une telle situation. Ensuite, les informations d'identification à mettre à niveau pourraient être placées dans le fichier wp-config et, même si elles étaient volées d'une manière ou d'une autre, ne constitueraient pas une menace, car ces informations d'identification pourraient être bloquées là où elles n'auraient pratiquement accès WP les fichiers eux-mêmes. Ensuite, si quelqu'un s'introduisait, il serait soit en tant que "Apache" (qui avait des privilèges limités), soit en mesure d'exécuter du code en tant qu'utilisateur personnalisé WP (qui avait également des privs limités).
L'idée est de limiter les capacités d'un utilisateur qui trouve une faille dans le système. Lorsque quelqu'un trouvera un point faible, il sera davantage limité par les privilèges de l'utilisateur en tant que tel.
La réponse courte est d'activer suPHP sur votre serveur, afin que WordPress puisse s'exécuter en tant que son propre utilisateur, plutôt qu'en tant qu'Apache.