Le sc\u00e9nario est le suivant : vous installez la derni\u00e8re version de votre framework<\/em> pr\u00e9f\u00e9r\u00e9, vous vous rendez sur la page Web de configuration http:\/\/monsite\/app_dev.php comme on vous l’a dit et l\u00e0, c’est le drame :<\/p>\n RuntimeException: Unable to create the cache directory (\/var\/www\/Symfony\/app\/cache\/dev)<\/p><\/blockquote>\n Rien de choquant, j’ai d\u00e9compress\u00e9 l’archive en tant qu’utilisateur seb<\/em>, c’est donc lui qui poss\u00e8de tous les droits sur l’arborescence, que j’ai simplifi\u00e9e dans l’exemple pour ne garder que les r\u00e9pertoires :<\/p>\n ls -l Symfony L’utilisateur par d\u00e9faut de mon serveur HTTP Apache est www-data<\/em> : lorsque le malheureux tente de cr\u00e9er le r\u00e9pertoire de cache, il \u00e9choue lamentablement, faute de droits suffisants ! Comment faire ?<\/p>\n Et si nous mettions www-data<\/em> et notre user seb<\/em> dans le m\u00eame panier ? Apr\u00e8s tout, ils vont se partager l’acc\u00e8s aux diff\u00e9rents r\u00e9pertoires, autant officialiser leur collaboration ! Nous n’aurions plus qu’\u00e0 donner les droits au groupe et nos deux utilisateurs pourraient enfin se partager cette arborescence dans la joie et la bonne humeur (et accessoirement, l’efficacit\u00e9 !)<\/p>\n Je vais ajouter seb<\/em> \u00e0 mon groupe www-data<\/em>, dont fait partie l’utilisateur www-data<\/em>. Je r\u00e9p\u00e8te : il existe un groupe www-data<\/em>, dont l’utilisateur principal est lui-m\u00eame nomm\u00e9 www-data<\/em>, attention \u00e0 ne pas confondre ! Rien ne vous interdit d’y rajouter d’autres utilisateurs ! C’est m\u00eame ce que nous allons faire de suite, notre utilisateur seb<\/em> va rejoindre le groupe www-data<\/em> :<\/p>\n sudo<\/strong> usermod -aG www-data votre_utilisateur<\/p><\/blockquote>\n N’oubliez pas l’option -a (append<\/em>) ! Si vous l’omettez, vous \u00e9crasez l’ensemble des groupes auxquels vous appartenez avec le nouveau groupe ! Pour vous assurer que le changement a bien \u00e9t\u00e9 pris en compte, tapez la commande groups<\/strong> :<\/p>\n seb@debian:\/var\/www$ groups Mission (presque) accomplie : il vous faut en effet vous d\u00e9connecter\/reconnecter pour que ces changements soient pris en compte par le syst\u00e8me d’exploitation. <\/p>\n Ah, les lectures de jeunesse…<\/p><\/div>\n Nous avons deux utilisateurs qui font partie du m\u00eame groupe mais \u00e0 ce stade, une arborescence qui est toujours la propri\u00e9t\u00e9 de l’utilisateur qui l’a cr\u00e9\u00e9e. Il faut donc la changer ! Disons dans un premier temps qu’elle appartient dor\u00e9navant au groupe www-data<\/em> :<\/p>\n chgrp -R www-data Symfony\/<\/p><\/blockquote>\n Puis, que tout utilisateur membre de ce groupe poss\u00e8de les droits en \u00e9criture dessus :<\/p>\n chmod -R g+w Symfony\/<\/p><\/blockquote>\n Regardons l’impact du changement :<\/p>\n A ce stade l\u00e0, la joie nous anime et nous retournons imm\u00e9diatement sur l’URL de notre page de config’ pour contempler avec satisfaction les cons\u00e9quences du changement : TOUT MARCHE, c’est magnifique ! Alors nous param\u00e9trons la connexion \u00e0 notre base de donn\u00e9es ! Tout se d\u00e9roule parfaitement, nous prenons un moment pour nous extasier sur la d\u00e9mo Hello World<\/em> puis tr\u00e8s vite, nous d\u00e9veloppons nos premiers contr\u00f4leurs d’action, nos premi\u00e8res entit\u00e9s, nos premiers templates<\/em> Twig…Et un beau jour, nous d\u00e9cidons de nettoyer le cache en ligne de commande avec la c\u00e9l\u00e8bre commande app\/console cache:clear – -env=dev<\/strong> (le env \u00e9tant optionnel car valant dev par d\u00e9faut). La sanction est imm\u00e9diate :<\/p>\n [UnexpectedValueException] Un d\u00e9veloppeur qui vient de faire son premier cache:clear en CLI<\/p><\/div>\n Mais…attendez une seconde…je ne comprends pas, j’ai deux utilisateurs du m\u00eame groupe maintenant, pourquoi tant de haine \u00e0 mon \u00e9gard ? Si vous regardez le fichier incrimin\u00e9 (qui se trouve dans le r\u00e9pertoire de logs et pas de cache), voici ce que vous y verrez :<\/p>\n SCANDALE ! Ce sagouin de www-data n’est pas partageur, il n’a pas donn\u00e9 les droits d’\u00e9criture au groupe ! Mon utilisateur seb<\/em> qui utilise la ligne de commande ne peut donc pas \u00e9crire dans ce fichier ! Que faire ? M’accaparer de force les droits d’\u00e9criture sur le r\u00e9pertoire logs ? Allons-y !<\/p>\n Mon utilisateur seb<\/em> n’a pas cr\u00e9e ces fichiers, il doit donc passer par sudo<\/strong> pour faire cette modification :<\/p>\n sudo chmod -R g+w app\/logs\/<\/p><\/blockquote>\n A la bonne heure ! Si www-data ne pr\u00eate pas, je lui arrache des mains ! [RuntimeException] Le r\u00e9flexe primaire du d\u00e9veloppeur contrari\u00e9 : la bord\u00e9e d’injures !<\/p><\/div>\n Sans surprise, je constate les m\u00eames d\u00e9g\u00e2ts dans le r\u00e9pertoire cache :<\/p>\n Pourtant j’avais bien dit \u00e0 chmod<\/em> de donner les droits en \u00e9criture sur ce maudit r\u00e9pertoire ! On dirait qu’il ne les a pas propag\u00e9s aux sous-r\u00e9pertoires…Bizarre. sudo chmod -R g+w app\/cache\/<\/p><\/blockquote>\n ENFIN JE TRIOMPHE ! *rire d\u00e9moniaque* seb@debian:\/var\/www\/Symfony$ app\/console cache:clear –env=dev Passablement ragaillardi par cette victoire sur la machine, je retourne donc en d\u00e9coudre avec la programmation, puis je fais un F5 sur mon client HTTP favori. H-O-R-R-E-U-R !!!<\/p>\n RuntimeException: Failed to write cache file \u00ab\u00a0\/var\/www\/Symfony\/app\/cache\/dev\/classes.php\u00a0\u00bb.<\/p><\/blockquote>\n Ce coup-ci c’en est trop, des tas d’id\u00e9es vous passent par la t\u00eate et notamment la reconversion professionnelle…C’est s\u00fbr et certain, la machine vous en veut !<\/p>\n Regardons le r\u00e9pertoire de cache :<\/p>\n Bon sang, l’utilisateur seb<\/em> a os\u00e9 imposer SON groupe en lieu et place de celui que j’avais d\u00e9fini !!! De deux choses l’une, soit je trouve une solution \u00e0 ce probl\u00e8me et vite, soit je joue \u00e9ternellement au ping-pong avec les droits de mes deux utilisateurs et je ne garantis aucunement de continuer de jouir de l’ensemble de mes facult\u00e9s mentales \u00e0 la fin de la journ\u00e9e. Pire : d\u00e9go\u00fbt\u00e9 de ce cirque, je pourrais me tourner vers Zend ! (je plaisante, ne tapez pas !)<\/p>\n Mes utilisateurs acc\u00e8dent en concurrence aux m\u00eames r\u00e9pertoires : d\u00e8s que je modifie les permissions de l’un, c’est l’autre qui se voit refuser l’\u00e9criture. \u00c7a peut durer longtemps ! J’\u00e9tais sur la bonne piste en d\u00e9cidant de cr\u00e9er un seul groupe, mais je ne suis pas all\u00e9 au bout de la solution !<\/p>\n Un de mes probl\u00e8mes vient du fait qu’un utilisateur, www-data<\/em> ou seb<\/em>, ne respecte pas les droits du r\u00e9pertoire parent dans lequel il cr\u00e9e le sien. Pour cela, il me faut faire usage de l’option +s de chmod, voyez plut\u00f4t :<\/p>\n chmod g+s cache\/ logs\/<\/p><\/blockquote>\n Cette option setgid<\/strong> (set group id<\/em>), lorsqu’elle est appliqu\u00e9e sur un r\u00e9pertoire, permet de dire la chose suivante : \u00ab\u00a0tout fichier\/r\u00e9pertoire cr\u00e9\u00e9 dans CE r\u00e9pertoire h\u00e9ritera des droits DE GROUPE du r\u00e9pertoire de base au lieu d’h\u00e9riter des droits DU GROUPE de l’utilisateur qui l’a cr\u00e9e\u00a0\u00bb. Ceci va r\u00e9soudre une partie de mon probl\u00e8me car seb ne s’arrogera pas le droit d’\u00e9craser la valeur de groupe www-data<\/em> par la sienne (seb<\/em>) ! Cependant, il faut un moyen de dire que nous souhaitons que nos deux utilisateurs maintiennent les droits EN ECRITURE de leur groupe commun, qui rappelons le est www-data<\/em> !<\/p>\n Nous voulons pouvoir dire :<\/p>\n Nous avons d\u00e9j\u00e0 assur\u00e9 la premi\u00e8re partie, comment garantir que mes deux utilisateurs donneront le droit d’\u00e9criture \u00e0 leur groupe en toutes circonstances ?<\/p>\n En positionnant le umask<\/strong> de l’un et de l’autre \u00e0 la m\u00eame valeur : 0002. Pour voir l’\u00e9tat de votre umask<\/em>, et donc de voir s’il y a besoin de le modifier, tapez simplement umask<\/strong> en ligne de commande.<\/p>\n Il y a de fortes chances pour qu’il soit par d\u00e9faut \u00e0 0022, dans ce cas l\u00e0 il faudra le changer en faisant simplement umask 0002<\/strong> puis umask<\/strong> pour v\u00e9rifier que le bon s’affiche dor\u00e9navant. Attention toutefois, ce changement ne dure que le temps de votre session<\/strong>, il faudra penser \u00e0 reporter cette commande dans votre fichier .bashrc, par exemple.<\/p>\n Un seul utilisateur a bascul\u00e9 son umask, c’est l’utilisateur CLI ! Il faut faire la m\u00eame chose c\u00f4t\u00e9 utilisateur Web, www-data, donc ! Nous rajoutons cette ligne au d\u00e9but des fichiers app_dev.php et console.php : umask(0002);<\/strong><\/p>\n Ainsi, que nous cr\u00e9ions des objets dans le filesystem<\/em> avec la commande Symfony console, avec l’utilisateur Web via l’appel au contr\u00f4leur frontal de dev ou encore directement avec l’utilisateur qui manipule la ligne de commande, nous aurons \u00e0 terme les m\u00eames droits !<\/p>\n Il est dit qu’il faut privil\u00e9gier les ACL au d\u00e9triment du umask car umask n’est pas totalement fiable. Soyons francs, quand on d\u00e9bute, on n’a pas forc\u00e9ment envie de s’improviser sysadmin<\/em> et de s’attaquer aux ACL (de plus on peut tr\u00e8s bien ne pas y avoir acc\u00e8s, en entreprise par exemple). Pour d\u00e9buter ou encore d\u00e9velopper en environnement local, nul besoin de mettre la barre trop haut, une modification du umask suffira largement.<\/p>\n Je vous recommande dans tous les cas la lecture \u00e0 l’URL suivant : http:\/\/symfony.com\/doc\/current\/book\/installation.html#configuration-and-setup<\/a><\/p>\n La TODO list, pour finir :<\/p>\n Bon d\u00e9veloppement \u00e0 tous et \u00e0 toutes !<\/p>\n
\ntotal 120
\ndrwxr-xr-x 6 seb seb 4096 mai 15 10:23 app
\ndrwxr-xr-x 2 seb seb 4096 mai 15 10:23 bin
\ndrwxr-xr-x 3 seb seb 4096 mai 15 10:23 src
\ndrwxr-xr-x 13 seb seb 4096 mai 15 10:23 vendor
\ndrwxr-xr-x 3 seb seb 4096 avril 27 20:36 web\n<\/p><\/blockquote>\nBougredane et Bougredandouille ne font qu’un, mes users aussi !<\/h1>\n
\nseb www-data lpadmin<\/p><\/blockquote>\n![\"Extrait](\"http:\/\/www.lafabriquedecode.com\/blog\/wp-content\/uploads\/2014\/05\/dicentim-1.gif\")
<\/a>Changer les droits d’acc\u00e8s \u00e0 l’arborescence de Symfony<\/h1>\n
\r\ndrwxrwxr-x 6 seb www-data 4096 mai 15 10:23 app\r\ndrwxrwxr-x 2 seb www-data 4096 mai 15 10:23 bin\r\ndrwxrwxr-x 3 seb www-data 4096 mai 15 10:23 src\r\ndrwxrwxr-x 13 seb www-data 4096 mai 15 10:23 vendor\r\ndrwxrwxr-x 3 seb www-data 4096 avril 27 20:36 web\r\n<\/pre>\n
\n The stream or file \u00ab\u00a0\/var\/www\/Symfony\/app\/logs\/dev.log\u00a0\u00bb could not be opened: failed to open stream: Permission denied <\/strong><\/p><\/blockquote>\n<\/a>\r\n-rw-r--r-- 1 www-data www-data 94637 mai 15 11:01 dev.log\r\n-rw-r--r-- 1 www-data www-data 2626 mai 15 11:00 prod.log\r\n<\/pre>\n
\nS\u00fbr de moi je relance un app\/console cache:clear<\/strong> et je manque de m’\u00e9trangler !<\/p>\n
\n Unable to write in the \u00ab\u00a0\/var\/www\/Symfony\/app\/cache\/dev\u00a0\u00bb directory <\/strong><\/p><\/blockquote>\n<\/a>\r\ndrwxr-xr-x 7 www-data www-data 4096 mai 15 11:00 dev\r\ndrwxr-xr-x 5 www-data www-data 4096 mai 15 11:00 prod\r\n<\/pre>\n
\nQu’\u00e0 cela ne tienne, je continue dans ma logique Rambo, je les aurais tous \u00e0 la force de la Ranger cir\u00e9e !<\/p>\n
\nJe viens de lancer le nettoyage du cache en dev et il s’est effectu\u00e9 comme il faut, la preuve !<\/p>\n
\nClearing the cache for the dev environment with debug true<\/p><\/blockquote>\n\r\nseb@debian:\/var\/www\/Symfony$ ls -l app\/cache\/\r\ntotal 8\r\ndrwxrwxr-x 6 seb seb 4096 mai 15 11:32 dev\r\ndrwxrwxr-x 5 www-data www-data 4096 mai 15 11:00 prod\r\n<\/pre>\n
Ou\u00e8re iz zeu probl\u00e8me ?<\/h1>\n
Victime de chmod, tel est ton nom de code !<\/h1>\n
Umask to the rescue !<\/h1>\n
\n
\nPourquoi ce 0002 ? Le premier 0 indique une notation octale, mais ce n’est pas tr\u00e8s int\u00e9ressant…Ce qui nous int\u00e9resse c’est 002 ! 0 correspond aux droits de l’utilisateur (U), le second 0 aux droits du groupe (G) et le 2 aux autres (O, pour others<\/em>), un bon moyen mn\u00e9motechnique consiste \u00e0 retenir le pr\u00e9nom Hugo pour se souvenir de la place de chacun (U-G-O).
\nBref, ce masque nous dit en gros \u00ab\u00a0voici ce que j’enl\u00e8ve lorsque tu cr\u00e9e un fichier ou un r\u00e9pertoire\u00a0\u00bb et donc il nous dit dans notre cas \u00ab\u00a0J’enl\u00e8ve le droit d’\u00e9criture aux autres\u00a0\u00bb. Souvenez-vous que les droits sont les suivants : lecture = 4, \u00e9criture = 2, ex\u00e9cution = 1.
\nEn positionnant mon umask \u00e0 0002, je dis en substance \u00ab\u00a0enl\u00e8ve les droits d’\u00e9criture \u00e0 others et laisse le reste intact\u00a0\u00bb, donc j’aurais finalement 775 comme droits sur tout ce que je m’appr\u00eate \u00e0 cr\u00e9er !<\/p>\nNous y sommes ! Enfin, presque !<\/h1>\n
Que dit la doc ?<\/h1>\n
R\u00e9sum\u00e9<\/h1>\n
\n