Journal Site web et enfer des droits

Posté par Etienne Bagnoud (site web personnel) le 24 juin 2010 à 18:53.

Étiquettes :

juin

2010

Je testais un peu comme ça passerait une migration d'un serveur web Debian vers un serveur web FreeBSD (genre de choses qu'on fait quand on a une idée plus profonde derrière la tête, mais ce n'est pas le sujet).

Ce qu'il faut savoir c'est qu'on a plein de petites applications web créées par des apprentis, des étudiants, des professionnels, ... en interne. Lorsqu'on fait ce genre de migration (juste un test, là), on se rend compte que certaines (toutes) de ces applications ont presque besoin d'un droit différent par répertoire et par fichier.
Il y a le répertoire où on écrit la donnée si elle vient de l'utilisateur, celui où on écrit quelques logs, celui où on écrit un état, celui où écrit pour pas qu'il soit jaloux des autres, ...

Bref ça donne un enfer de changement de droits et on en arrive à donner les droits en écriture partout. Ensuite on les supprime petit à petit sans casser l'application (pour finalement se rendre compte qu'il faut les droits en écriture partout).

Afin de ne pas avoir à trucider les prochains qui viendraient faire une nouvelle petite application web, j'ai écrit un petit guide de comment je voulais la chose (parce que c'est moi qui souffre au final).

Je viens de finir de l'écrire et je me suis dit que des critiques externes pourraient être utiles, donc : http://www.tchetch.net/wiki/website/guideline/fr (et peut-être intéresser/inspirer d'autres personnes)

# Des chemins bizarres

Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 juin 2010 à 19:19. Évalué à 8.

/srv/www/…

OK.

/var/spool/…

OK, quoique /var/local/spool serait plus approprié.

/var/cache/…

OK, quoique /var/local/cache serait plus approprié.

/usr/local/etc

OK.

Tu devrais jeter un œil au brouillon de charte Debian pour les applications web [http://webapps-common.alioth.debian.org/draft/html/].
- [^] # Re: Des chemins bizarres
  
  Posté par Etienne Bagnoud (site web personnel) le 24 juin 2010 à 19:22. Évalué à 4.
  
  En effet, j'ai loupé /var/local dans la FHS ... Je vais corriger.
  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
  - [^] # Re: Des chemins bizarres
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 juin 2010 à 22:48. Évalué à 5.
    
    La FHS. Je vois qu'on a les mêmes références. D'ailleurs je suis plutôt choqué par /usr/local/etc, mais bon, c'est la norme, si moche soit-elle.
    
    Sinon, tu as un autre mode pour tes logiciels : /opt, un répertoire par logiciel, tout dedans sauf… Ça donne :
    /opt/logiciel/lib
    /opt/logiciel/bin
    /opt/logiciel/ce_qu'il_veut
    /etc/opt/logociel
    /var/opt/logiciel
    - [^] # Re: Des chemins bizarres
      
      Posté par zebra3 le 25 juin 2010 à 12:20. Évalué à 5.
      
      Pour ma part, j'avoue que j'ai encore du mal à saisir l'intérêt de /usr/local par rapport à /opt, et de la même manière, entre /var et /srv.
      
      Est-ce qu'ils ont des rôles si précis ?
      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
      - [^] # Re: Des chemins bizarres
        
        Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 13:20. Évalué à 3.
        
        Dans /opt je mets les applications qui n'ont pas forcément une philosophie Unix dans la conception et qui ont des noms de répertoire genre : configuration, programs ... et pas de etc, bin, ...
        
        Dans /usr/local je mets les applications qui ont une philosophie unix mais qui ne viennent pas de la distribution.
        
        /srv c'est pour tous ce qui service de donné par Internet (web, ftp, ...)
        
        /var c'est plus un répertoire de travail pour les applications, mais qui doit pas être effacé en cas de redémarrage.
        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
        
        [^] # Re: Des chemins bizarres
        
        Posté par zebra3 le 25 juin 2010 à 13:27. Évalué à 2.
        
        Bon, je vois à peu près pour /opt et /usr/local, mais pour /srv c'est encore ténu : par défaut, les sites web sont dans /var/www/, et les partages FTP dans /var/ftp/. J'imagine que pour les autres services, c'est ça aussi (/var/named, etc).
        
        Après, je suppose que c'est affaire d'habitude et de goût.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Des chemins bizarres
        
        Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 14:12. Évalué à 7.
        
        Oui Debian utilise /var/www parce que /srv ne doit _pas_ être utilisé par la distribution. C'est l'administrateur du système qui gère comme il le souhaite.
        
        Tu peux par exemple faire par service :
        /srv/www
        /srv/ftp
        /srv/ldap
        /srv/mysql
        
        ou alors par groupe si ton organisation est plus grande :
        /srv/genetic/www
        /srv/genetic/ftp
        /srv/physic/www
        /srv/physic/ftp
        
        Mais chacun fait ce qu'il souhaite dans /srv, c'est pourquoi /var est utilisé par les distributions, c'est le répertoire qui se prête le mieux _après_ /srv.
        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
        
        [^] # Re: Des chemins bizarres
        
        Posté par zebra3 le 25 juin 2010 à 16:21. Évalué à 2.
        
        Très bien, c'est plus clair comme ça. Merci.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Des chemins bizarres
        
        Posté par Kerro le 25 juin 2010 à 16:16. Évalué à 2.
        
        Pour ma part, j'en suis toujours à me demandre où stocker les sauvegardes locales :-)
        
        Par exemple la sauvegarde quotidienne de /etc je suis sensé la mettre où en local ? Ce n'est ni un service fourni à l'extérieur (donc pas /srv), ça n'a rien à faire dans /var, etc.
        Et pour les sauvegardes de /srv/www même problème philosophique.
        Pour la sauvegarde distante c'est facile. Sur la machine distante c'est dans /srv/sauvegardes/xxxx
        
        [^] # Re: Des chemins bizarres
        
        Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 16:36. Évalué à 2.
        
        /var/backups est une bonne solution. FHS indique que ce répertoire ne doit pas être utilisé par des applications car ça risque d'entrer en conflit avec des pratiques existantes.
        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
        
        [^] # Re: Des chemins bizarres
        
        Posté par zebra3 le 25 juin 2010 à 18:04. Évalué à 3.
        
        Les vrais hommes mettent leur sauvegardes dans /var/ftp/pub et laissent Internet s'occuper de la réplication.
        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
        
        [^] # Re: Des chemins bizarres
        
        Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 18:14. Évalué à 5.
        
        Les vrais hommes barbus utilisent /srv/ftp/pub ...
        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# tar

Posté par NeoX le 24 juin 2010 à 19:24. Évalué à 2.

et faire une archive avec tar et les options qui vont bien

pour la decompresser ensuite sur le systeme de destination ?
ca ne suffirait pas ?
- [^] # Re: tar
  
  Posté par zebra3 le 24 juin 2010 à 19:29. Évalué à 2.
  
  Ça implique que les UID et GID correspondent, et je ne sais pas si c'est le cas par défaut (je ne connais pas du tout FreeBSD).
  
  Bon, ça peut se changer manuellement, mais faut se méfier et n'en oublier aucun.
  
  Après, cette migration peut être l'occasion de remettre tout ça au propre. Quitte à changer de système, autant corriger les erreurs précédentes.
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
  - [^] # Re: tar
    
    Posté par NeoX le 24 juin 2010 à 19:56. Évalué à 3.
    
    rien ne t'empeche de placer les UID/GID comme tu le souhaites au moment de faire l'installation de ton nouveau systeme ?
    
    sinon effectivement cela peut permettre de tout remettrea au propre en se posant les bonnes questions.
    - [^] # Re: tar
      
      Posté par Etienne Bagnoud (site web personnel) le 24 juin 2010 à 20:03. Évalué à 4.
      
      rien ne t'empeche de placer les UID/GID comme tu le souhaites au moment de faire l'installation de ton nouveau systeme ?
      
      Non c'est pas un problème parce que ça vient d'un annuaire LDAP. Mais sinon, c'est un problème, j'aurais pas envie de modifier ça chaque fois que j'installe un paquet parce que X utilise 80 (FreeBSD) pour le serveur web et Y 33 (Debian) ...
      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
- [^] # Re: tar
  
  Posté par Etienne Bagnoud (site web personnel) le 24 juin 2010 à 19:31. Évalué à 2.
  
  Non pour deux raisons :
  
  - Je préfère prendre ça depuis le dépôt (une étape en moins)
  - Si le code n'est pas un minimum adapté, ça va pas mieux marcher.
  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
# Question idiote

Posté par Jerome Herman le 24 juin 2010 à 20:45. Évalué à 5.

Tu es au courant pour les liens fichiers et les ACL ?

Parceque les problèmes que tu rencontres (et que je rencontre aussi quotidiennement) je les résouds à coup de ln et de setfacl...

(Bon j'utilise aussi des régles de redirection de ports en interne pour pas que ce soit root qui lance apache, mais c'est optionnel)

Accesoirement il vaut mieux éviter d'utiliser les fichiers .htaccess, les include apache les remplaçant avantageusement.

De plus pour qu'un ensemble de règles assez strictes soient adoptées il faut mettre des explications sur le pourquoi du comment de la chose et il faut éviter les emphases à répétition qui ennervent les techniciens aguerris et paniquent les newbies.
- [^] # Re: Question idiote
  
  Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 13:10. Évalué à 2.
  
  Oui les ACL et les liens symboliques c'est bien, mais j'aimerais juste obtenir le site depuis le dépôts et ne pas à avoir à lire la documentation pour chaque truc, juste déployé et ça marche.
  
  Les fichiers .htaccess je les utilise pas. Mais comme le serveur de test va les utiliser, je fais juste de les inclure dans la configuration d'apache directement quand il y a besoin.
  
  Ça c'est la traduction française, mon document est en anglais à l'origine et c'est plus direct.
  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
- [^] # Re: Question idiote
  
  Posté par campagnard le 25 juin 2010 à 14:13. Évalué à 2.
  
  "(Bon j'utilise aussi des régles de redirection de ports en interne pour pas que ce soit root qui lance apache, mais c'est optionnel)"
  
  AAAh ca m'interesse !
  
  J'avais justement lu quelque part que c'etait toujours root qui lancait apache parce que seul root a le droit d'ouvrir un port, du coup j'ai du configurer /etc/sudoers pour que l'utilisateur puisse lancer apache sans avoir à lui donner le mot de passe root.
  
  Tu peux me donner plus d'infos sur cette astuce ? (ou bien me rediriger vers ladockivabien)
  - [^] # Re: Question idiote
    
    Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 15:37. Évalué à 2.
    
    Les ports <1024 ne peuvent être ouvert que par root, les autres peuvent être ouvert par un utilisateur, si c'est ça ta question.
    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
  - [^] # Re: Question idiote
    
    Posté par Jerome Herman le 25 juin 2010 à 19:22. Évalué à 1.
    
    AAAh ca m'interesse !
    
    J'avais justement lu quelque part que c'etait toujours root qui lancait apache parce que seul root a le droit d'ouvrir un port, du coup j'ai du configurer /etc/sudoers pour que l'utilisateur puisse lancer apache sans avoir à lui donner le mot de passe root.
    
    Tu peux me donner plus d'infos sur cette astuce ? (ou bien me rediriger vers ladockivabien)
    
    Ca dépend pas mal de la distrib.
    Généralement il faut refaire le script d'init du serveur pour ne plus qu'il utilise root au démarrage et binder apache sur des port > 1024 (8080,8443,9080,9443 sont populaires)
    
    Après il faut faire un règle firewall qui redirige en dur le port standard (80 ou 443) vers un autre port.
    
    Autre solution plus jolie pour les utilisateurs :
    Créer un alias sur la carte réseau concernée (ou une autre) vers une IP privée non utilisée sur le réseau avec un masque full. Genre 10.254.0.1/32
    Ensuite faire une règle de NAT du port 80 IP publique vers le port 8080 IP privée.
# Mauvaise solution

Posté par Corentin Chary (site web personnel) le 24 juin 2010 à 23:04. Évalué à 4.

Pour moi, avoir à jouer avec les droits est une mauvaise solution, surtout que souvent, on en arrive à des sites qui ont accès en écriture, et en lecture, à tout est n'importe quoi.

Suivant le nombre d'utilisateurs, et la charge, il y'a plusieurs solutions possibles. Personellement j'utilise une instance de lighttpd par utilisateur, lancée avec les bons droits. Et une en frontal, qui fait office de reverse proxy, et qui gère les trucs généraux dans /var/www/. Avec ça, chacun à son /home/user/ en 700, et aucun problème.

Et pour rajouter un utilisateur ? il suffit de faire un petit script, ça s'automatise assez bien.

Après, c'est l'une des solutions, il en existe pas mal (mpm-itk, mpm-peruser, etc...).
- [^] # Re: Mauvaise solution
  
  Posté par DLFP est mort le 25 juin 2010 à 00:24. Évalué à 5.
  
  Tu as raison, et je suis désespéré par les sysadmins qui n'ont pas compris que tant qu'ils ne feront pas ça, n'importe quelle appli aura accès aux données des autres.
  DLFP >> PCInpact > Numerama >> LinuxFr.org
  - [^] # Re: Mauvaise solution
    
    Posté par Etienne Bagnoud (site web personnel) le 25 juin 2010 à 13:16. Évalué à 2.
    
    Ce n'est pas vraiment le sujet. C'est pas des trucs "par utilisateur" mais plutôt plein de petites applications interne (celle qui lance un blast sur le cluster, celle qui transforme des fichiers de sortie de la machine X vers un format pour le linkage, ...)
    
    Donc le but n'est pas d'empêcher l'accès aux données, au contraire on a des applications qui vont chercher dans les résultats d'autres applications, mais bien de me simplifier la tâche autant que possible.
    
    Parce que bon la sécurité, à la limite je m'en tape. Y'a un apprenti qui nous a fait une application qui créé les requêtes SQL en javascript et les envoies à un script php qui "mysql_query" sans aucune validation !!! Donc tu vois, mon souci de sécurité est un peu différent.
    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
    - [^] # Re: Mauvaise solution
      
      Posté par yellowiscool le 25 juin 2010 à 19:42. Évalué à 2.
      
      Waouh, c'est une super idée ça :-)
      Envoyé depuis mon lapin.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.