Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Copier les droits des fichiers/répertoire d'un serveur à un autre

couik

Bonjour,

J'ai deux serveur sous Ubuntu 18.04 server LTS
Sur chacun sont installé PHP, Nginx et tout cela fonctionne bien

L'un des deux serveurs a eu un soucis, qui a obligé la migration sur un autre. Bien que les données ont pu être sauvées, les droit des fichiers et répertoire ont été mis à 777.

Cela fonctionne, mais l'ajout de certain module du soft en php n'apprécient pas.

Je recherche une solution, sans copier les fichier d'un serveur sur l'autre, de mettre les mêmes drroit des fichiers .php et des répertoire à l'identique sur les deux serveurs. En prenant en référence le premier serveur qui lui n'a pas eu de soucis

Voilou.

Je seche... Si vous aviez des piste, je vous en serez reconnaissant 😉

Couik

kamaris

Si tu as la même arborescence de part et d'autre, avec les mêmes noms de fichiers / répertoires, tu pourrais utiliser l'option --reference de chmod, dans une boucle de ce type :

shopt -s globstar dotglob
for f in source/**/*; do
  chmod --reference="$f" "cible/${f#source/}"
done

Tu peux mettre un echo devant le chmod dans un premier temps, histoire de voir si ça fait bien ce que tu veux au niveau des chemins.

couik

Bonjour,

Impressionnant la rapidité de la réponse

Oui il y a la même arborescence. mais tout comme pour un forum donnée, l'arborescence est la même avec les variable lié au thème, module, etc...

J'ai utilisé

tree -dp >> firchier.txt

dans un premier temps pour avoir un aperçu des droits.

A l'exception d'un répertoire spéfifique, les droit sont 755 sur le serveur ok, et quasi tous en 777 sur le serveur qui a eu des ratés.

Cela reste simple à corriger, mais restais la problématique des fichiers

Je vais tester sur une copie du site (je ne touche pas à la prod 😛)

Mille merci, je vais tester des demain au levé

Cordialement
Couik

kamaris

Sinon, si les fichiers source / cible sont les mêmes (même taille, même date de modification du contenu), et que seules les permissions diffèrent, tu peux utiliser rsync :

rsync -av source cible

rsync ne copiera pas les fichiers sources, seulement leurs permissions, mais il faut être sûr que c'est le même contenu en source et en cible.
Tu peux ajouter l'option --dry-run dans un premier temps : aucune copie ne doit être listée.
Si tu peux faire ça (quitte à avoir quelques copies de fichiers dont tu pourrais t’accommoder), ça sera quand même moins bourrin que d'appeler chmod pour chaque fichier :rolleyes:

krodelabestiole

à mon avis plutôt que copier simplement les permissions d'un serveur à l'autre juste parce que "ça marche" tu ferais mieux d'en profiter pour gérer finement les permissions en comprenant ce que tu fais pour améliorer le niveau de sécurité.

en gros avec 777 ou même 755, tu rends exécutable tous les fichiers contenus dans ces répertoires, et ce pour tous les utilisateurs / process de ton serveur.
or il n'y a absolument aucun intérêt à rendre le moindre fichier PHP exécutable : le fichier doit simplement être lisible pour l'utilisateur qui exécute PHP (avec nginx probablement celui qui exécute php-fpm, sinon celui qui exécute apache quand on utilise le module libapache2-mod-php). en général il s'agit de www-data.
dans le cas contraire il est possible d'exécuter directement n'importe quel code qui aurait été injecté ou oublié là. et avec 777 il est justement possible pour tout le monde de modifier les contenus des fichiers et répertoire et d'y injecter du code.
pour assurer un niveau de sécurité correct il faut limiter les permissions au strict nécessaire.

pour comprendre comment gérer les permissions sur un serveur web (que ce soit apache ou nginx, dans le cas ou un seul dev sera amené à maintenir ces fichiers) voir le chapitre 10.1 Permissions : https://doc.ubuntu-fr.org/apache2#permissions

kamaris

Je pense que couik ne parlait que des répertoires pour les droits 755 et 777 :

couik a écritJ'ai utilisé
tree -dp >> firchier.txt
dans un premier temps pour avoir un aperçu des droits.

A l'exception d'un répertoire spéfifique, les droit sont 755 sur le serveur ok, et quasi tous en 777 sur le serveur qui a eu des ratés.

Cela reste simple à corriger, mais restais la problématique des fichiers

Je suppose que les fichiers sur la source ont des droits plus divers, ce qui oblige précisément à copier leurs droits un à un (ou plus finement en tout cas qu'avec un chmod -R 755 cible).

krodelabestiole

je ne pense pas 😉

couik a écritles droit des fichiers et répertoire ont été mis à 777.

sans même parler de tous les tutos qui conseillent de se débarrasser des problèmes de permission avec des chmod -R sans même prendre en compte les propriétaires des fichiers...

kamaris

Oui mais ça c'est sur la cible, qu'il veut changer.
Sur la source dont il veut partir pour faire sa copie des droits, je pense qu'il n'y a que les répertoires qui sont en 755 ou 777.
Ou alors j'ai pas compris, ce qui est tout à fait possible : couik nous précisera ça à son retour 😉.

couik

Bonjour,

Merci de tous ces conseils 🙂

Petites mise au point par rapport à certaines réponses :

Autant je sais monter un serveur avec Nginx/PHP/MariaDB, autant en terme de sécurité, je ne suis pas du tout compétant. C'est un fait, j'assume et je n'hésite pas à solliciter de l'aide en la matière
Lors de la remise en état du site E.commerce, je n'ai pas fait attention plus que ça.
Le premier serveur fonctionne et est sécurisé, d'où le prendre en modèle
Certains modules de l'application n'acceptent pas le 777 (moi non plus d'ailleurs :S)
Le soucis concerne autant les répertoire ui peuvent être eux, gérer à l'instant, mais concerne aussi les fichiers qui sont quant à eux liés au module lui même et sont parfois modifier par ces mdules.
Enfin, je ne demande pas des conseils en cherchant à me faire de la pub, d'où la non communication des deux URLs (Je respecte le travail de chacun ici et je les en remercie 🙂 )

Aussi, ma première piste serait de rétablir les droits initiaux, permettant alors d'être sûr que le dysfonctionnement. D'autant que dans les logs, il n'y a rien qui permettent de justifier ce genre de soucis.

Après, rien ne me dit que c'est la bonne méthode. Mais au moins ce sera un peu mieux sécurisé 🙂

Voilou
Couik

PS : Je regarde toutes vos propositions ce weekend et je vous rendrai compte du résultat pour en faire profiter tout le monde 🙂