Journal Nouveau tutoriel sur la mise en place d'un serveur LAMP

Posté par .
Tags : aucun
16
21
juil.
2009
Partant du constat que peu de tutoriel sur la mise en place d'un serveur LAMP n'était suffisamment complet, nous avons décidé d'écrire le notre.

Pour situer le contexte de ce tutoriel, je vous recopie l'introduction :

---------------

Contexte

De nos jours on peut trouver des serveurs dédiés à bas prix. C’est une bonne solution pour ceux qui veulent héberger leur site Web pour un prix abordable tout en conservant la possibilité de configurer entièrement le système d’exploitation. Dans ce tutoriel, nous allons nous placer dans l’optique où plusieurs étudiants paient ensemble un serveur dédié, qu’ils se partagent pour héberger plusieurs sites Web. Par conséquent plusieurs concessions ont été faites, il n’est pas facile de trouver le juste milieu entre performance, sécurité et facilité d’utilisation.

En suivant ce tutoriel, vous obtiendrez juste un serveur suffisamment sécurisé et bien configuré pour héberger vos sites Web et éviter un minimum d’attaques malveillantes.

Finalité

  • Le système d’exploitation utilisé est une Debian Lenny 5.0.
  • Nous allons tout installé avec les paquets fournis par Debian Lenny 5.0 pour faciliter les mises à jour.
  • Le shell par défaut, Bash, sera conservé mais personnalisé.
  • Nous allons apprendre à nous servir de screen.
  • Apache et PHP seront configurés pour être le moins “bavard” possible.
  • Apache et PHP seront par défaut peu permissif. Les besoins particuliers des sites Web seront réglés au cas par cas dans le VirtualHost.
  • Nous allons configurer Postfix pour avoir une gestion minimale des emails (envoi par le système et PHP).
  • Nous allons créer un compte système par site Web, pour faciliter la gestion des droits.
  • Aucun serveur FTP ne sera installé ! À la place nous allons utilisé SFTP, un protocole plus sûr même si moins répandu.
  • Nous allons mettre en place un pare-feu, ainsi que Fail2ban, rkhunter et Monit.

---------------

Malgré le titre présomptueux ( Mettre en place un serveur LAMP efficace ) nous n'avons rien d'experts. Au contraire, la rédaction de ce tutoriel nous a permis de nous améliorer dans ce domaine et nous cherchons maintenant à avoir le retour d'experts). N'hésitez pas à nous faire vos remarques…

Le site du projet se trouve à cette adresse : https://labanquise.insa-rouen.fr/projects/asi10-ecaolamp/
Les explications pour récupérer les fichiers ici : https://labanquise.insa-rouen.fr/scm/?group_id=57
Et enfin, la dernière version PDF en date : https://labanquise.insa-rouen.fr/docman/view.php/57/102/Mett(...)

Deux points que je n'ai pas abordé :
  • # A4

    Posté par . Évalué à 10.

    Je ne suis pas du tout un expert sécurité, mais après avoir parcouru votre document, cela m'a l'air très bien.

    Une petite erreur : Quitte a utiliser un anglicisme, autant bien le conjuger :
    "nous allons aussi “chrooté” leur répertoire personnel => nous allons aussi “chrooter” leur répertoire personnel"

    De plus, j'ai vu que le document, destiné à des francophones, était en US Letter, peut-être qu'en A4 cela serait plus pratique à imprimer si nécessaire ?

    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: A4

      Posté par . Évalué à 1.

      Corrigé. Il y a sûrement plein d'autres erreurs de ce type…

      Concernant l'impression, nous sommes dépendant de Sphinx pour la génération du PDF (qui génère un HTML plutôt cool soit dit en passant). Je vais voir si je peux le configurer.
  • # Un vrai projet libre...

    Posté par . Évalué à 2.

    ... avec des morceaux de Not Invented Here dedans ?
    => Internet : Un wiki sur l'auto-hébergement https://linuxfr.org/2009/07/08/25706.html

    Les thématiques me semblent très proches, un peu dommage de ne pas chercher à mutualiser les savoirs, non ?
    • [^] # Re: Un vrai projet libre...

      Posté par . Évalué à 1.

      Tres libre meme.
      Parceque pour l'instant, la page du projet donne: License: Other/Proprietary License.

      Par contre, le wiki sur l'autohebergement, lui il est libre, et en plus, c'est clairement compréhensible pour accéder au savoir, alors que la forge de rouen, y'a mieux en ergonomie :)
      • [^] # Re: Un vrai projet libre...

        Posté par . Évalué à 1.

        Pour la licence affichée sur le site, c'est la faute à la forge non ergonomique qui ne connaît pas les licences CC. Du coup "Other" s'est retrouvé comme meilleur choix :o

        À l'époque où nous avions commencé la rédaction, il n'y avait pas autant de buzz sur l'auto-hébergement et nous n'avions pas vu ce genre de tutoriels/wikis.

        Évidemment maintenant, l'intérêt est dans la mutualisation :)
  • # Pas de tutoriel ?

    Posté par (page perso) . Évalué à -1.

    En même temps, pour faire :
    # aptitude install openssh-server apache2 libapache2-mod-php5 postfix

    ça ne m'étonne pas qu'il n'y ait pas de tutoriel extensif.

    Oui, je sais, ça va plus loin, votre initiative, vu que ça dépasse la mise en place de LAMP.
    • [^] # Re: Pas de tutoriel ?

      Posté par . Évalué à 2.

      En même temps, en faisant :
      # aptitude install openssh-server apache2 libapache2-mod-php5 postfix

      tu perds un morceau de LAMP.
    • [^] # Re: Pas de tutoriel ?

      Posté par . Évalué à 2.

      Toi, tu pêtes plus haut que ton cul et t'as oublié tes débuts ... Ça t'es venu invtuitivement par l'opération du Saint Esprit tout ça, ou t'as oublié les googlages et ta première doc Unix ... ou tes cours peut être.
      • [^] # Re: Pas de tutoriel ?

        Posté par . Évalué à 3.

        Je ne vois pas en quoi.
        Avec un one-liner un poil plus complet que le sien , tu fais autant voir plus que la doc.

        Le mien ressemblerait à

        dpkg-reconfigure debconf; apt-get install ssh harden-servers sudo unattended-upgrades sash busybox-static apache2 libapache2-mod-php5 mysql-server phpmyadmin postfix dovecot squirrelmail vsftpd monit bastille tiger chkrootkit rkhunter smartctl hdparm lmsensors logcheck munin ethtool; bastille; sensors-detect; a2enmod userdir; a2ctrl restart;

        (oui ça demande à être complété: (il faut modifier le /etc/debian_version pour bastille, faire un peu de postconfiguration qui peut le plus souvent être faite à grand coup de sed, voir même compiler un noyau avec grsec via make-kpkg)

        Ps: la poutre et la plume ( oh le beau -10 ! )
    • [^] # Re: Pas de tutoriel ?

      Posté par . Évalué à 5.

      Et ta commande, tu la tape sur le L de LAMP ! Le L, il va s'installer tout seul ?!!! Les utilisateurs vont se créer tout seul ?
  • # Cool

    Posté par (page perso) . Évalué à 2.

    Vraiment intéressant comme tutoriel, merci ! =)
    (Et quelle surprise de voir ".insa-rouen.fr", je savais pas qu'il y avait d'autres insaïens ici =) !)

    ps : Je passe en 2ème année là.
  • # Très bonne initiative

    Posté par (page perso) . Évalué à 2.

    Je trouve l'idée intéressante, il y a toujours besoin de ce genre de document pour aider les personnes à débuter.

    Je regarde tout cela demain à tête reposée.

    Par contre il me semble qu'il y ait un certain nombre de fautes de français (accords, ...) je tâcherai de les signaler dans la mesure du possible :-)
  • # Mouai...

    Posté par . Évalué à -1.

    Je vais me faire taper sur les doigts et c'est dommage car le doc est très bien, mais ...

    C'est bien beau les tuto pour faire louer des dédiés aux Jean-Kevins mais c'est pas avec ça qu'on va faire baisser le nombre de zombies ni de messages debilesde demande d'aide dans les forums/irc etc...

    Bien sûr il faut apprendre etc mais bon ... admin c'est un metier, laisser croire a quelqu'un qu'une doc de 20 pages suffit pour maitriser l'installation d'un dédié archi-secure++ c'est sans doute louable mais bon...
    • [^] # Re: Mouai...

      Posté par . Évalué à 2.

      ben justement

      En suivant ce tutoriel, vous obtiendrez juste un serveur suffisamment sécurisé et bien configuré pour héberger vos sites Web et éviter un minimum d’attaques malveillantes.

      ce qui n'a pas grand chose à voir avec

      une doc de 20 pages suffit pour maitriser l'installation d'un dédié archi-secure++
      • [^] # Re: Mouai...

        Posté par . Évalué à 2.

        Tout dépend de la manière dont tu interprète la première phrase et le "suffisament",

        Pour moi, le problème de ce type de doc c'est que cela amène à,
        - un faux sentiment de sécurité
        - un faux sentiment de maîtrise
        Les deux étant plus ou moins liés, mais avec des concéquences bien spécifiques.

        Je trouve toutefois l'initiatives louable et intéressante mais,
        - le coté tutoriel pas à pas sans grande explication me gène un peu. ( => faux sentiment de maîtrise)
        - niveau sécurité, il y a des manques flagrants ( => faux sentiment de sécurité ), au hasard:
        echo "apt-get update && apt-get upgrade -y" > /etc/cron.weekly/maj; chmod+x /etc/cron.weekly/maj
        • [^] # Re: Mouai...

          Posté par . Évalué à 2.

          Eh bien c'est un projet libre, il ne tiens qu'à toi de contribuer pour en faire quelque chose de mieux
        • [^] # Re: Mouai...

          Posté par . Évalué à 1.

          Je suis tout à fait d'accord. Je vais préciser un peu plus le contexte pour éviter de donner un faux sentiment de sécurité/maîtrise.

          Cependant, c'est toujours mieux que de suivre http://www.howtoforge.com/perfect_setup_debian_etch qui bien que "perfect" utilise FTP, configure peu Apache, ne met pas en place de pare-feu, etc.
          • [^] # Re: Mouai...

            Posté par . Évalué à 2.

            :)

            Il serait sans doute intéressant de mettre des pointeurs vers d'autres documentations, comme
            http://formation-debian.via.ecp.fr/ ou les manuels de références. Et de fortement conseiller de les lire.
    • [^] # Re: Mouai...

      Posté par . Évalué à 8.

      T'as bien raison, on ne devrait pas divulguer l'information à tout va, comme ça. Trop dangereux, les gens "moyens" ne sauraient pas gérer.

      De la même manière, il faudrait que Casto arrête de distribuer des brochures sur comment repeindre un mur ou planter des clous. C'est vrai, quoi, bricoleur, c'est un métier. Je ne parle même pas des livres de cuisine qui sont vendus à la fnac, faire à manger, ça c'est un métier, un vrai.

      On l'a toujours dit, diffuser le savoir c'est dan-ge-reux. Alors faites-moi le plaisir de virer toutes ces docs qui expliquent comment installer les logiciels de vos sites web et serveurs. Gardons le savoir pour nous, beaux et forts admins que nous sommes. Les autres ont qu'à faire les écoles pour admins comme les autres. Na !
      • [^] # Re: Mouai...

        Posté par . Évalué à -2.

        Tu fleurtes dangereusement avec le point godwin toi, c'est tout juste si tu ne m'accuses pas de vouloir bruler les livres (hop ça c'est fait :p).

        Vu que tu semble aimer les exemples caricaturaux, et la rhétorique bête et méchante:


        Si je te dis que j'ai bricollé moi même la direction et le freinage de ma voiture, à partir d'une doc de 20 pages trouvés sur le net, tu seras content de rouler à mes cotés ?

        Si je te dis que j'ai refais moi même l'electricité de mon appart quasi sans rien y connaitre, tu seras content d'habiter au dessus ?


        Sinon, tu es souvent confrontés à des jean kev1 qui s'improvisent admin en herbe et demandes de l'aide sur irc/forums à grands coups de :

        "
        ge ve installé un phorum sur mn dedier plesk 9, hellllllllpppppp svp
        hellpp
        allllléééééé
        "

        Moi oui...
        Et crois moi c'est beaucoup plus commun que tu sembles le croire,
        Tout comme les dédiés tout troués chez ovh/dedibox/whatever,
        tu veux voir mes logs ? :p
        • [^] # Re: Mouai...

          Posté par . Évalué à 1.

          Tss tss, c'était pas à prendre au pied de la lettre... c'était de l'humour.

          N'empêche que c'est à l'aide de ce genre de tutoriel / howto / doc que la plupart des admins système se sont formés, finalement. Ca reste globalement un métier qui s'apprend "sur le tas", les technologies changent tellement vite dans ce monde...

          En attendant, les serveurs ne mettent pas en danger la vie des gens (ou, en tout cas, pas encore) lorsqu'ils sont mal installés et que l'admin s'appelle Jean Kevin. Donc rien de grave au final.

          Tu fais quoi comme travail ? On t'oblige à répondre aux Jean Kevin dans ton boulot ?
          Sinon, tu réponds plus, ou.... tu fais payer la prestation de dépannage... C'est la crise, hein ! On fait comme on peut.

          (Bon, allez, pour abonder un ptit peu dans ton sens : j'administre un dédié, et effectivement, je rigole bien. 1.500.000 tentatives d'auth sur le ssh en 1 an... c'est pas mal !)
    • [^] # Re: Mouai...

      Posté par . Évalué à 2.

      Pour info, ovh est un des plus gros relais a spam et a zombis,
      J'y ai des dédiés tout comme j'en ai eu chez dédibox,
      J'y reçois tout et n'importe quoi, dont des broadcast samba (mouarf ... et ça n'est pas le pire exemple ... heuresement que j'ai mieux a faire que de monter un ntpd fake :p ).
      Une majorité des tentatives de bruteforce que je reçois viennent également de ces deux hebergeurs (même pour vers boxes en ADSL)

      Et puis, pour les curieux , allez donc faire un tour sur les forums ovh ou l'irc dédibox, vous allez voir c'est funny.

      Enfin, j'invites ceux qui moissent sans argumenter à passer autant que moi à aider les gens à admin leur serveur ... et on en reparle après :) ?
  • # Et ça sert à quoi ?

    Posté par (page perso) . Évalué à -9.

    Concrêtement ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: Et ça sert à quoi ?

      Posté par . Évalué à 10.

      À encourager les gens à faire des commentaires de 1 seul mot en réussissant l'exploit de quand même faire une faute.

      -------------> [ ]
  • # aptitude vs apt

    Posté par (page perso) . Évalué à 3.

    Debian recommande l'utilisation d'aptitude pour gérer les paquets

    http://www.debian.org/doc/manuals/debian-faq/ch-uptodate.fr.(...)

    Peut-être faudrait-il utiliser celui-ci dans la documentation afin de donner directement les bonnes habitudes?
    • [^] # Re: aptitude vs apt

      Posté par (page perso) . Évalué à 2.

      Comment se fait-il que d'après la doc, aptitude utilise apt mais que je n'ai pas eu les même résultats pour la même commande de désinstallation?

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: aptitude vs apt

        Posté par . Évalué à 2.

        Ça eut dire quoi "aptitude utilise apt" ? À ma conaissance aptitude a ses propres algorithmes, c'est pas étonnant que le résultat soit différent.
        • [^] # Re: aptitude vs apt

          Posté par (page perso) . Évalué à 2.

          Je cite le lien donné plus haut:

          aptitude est le gestionnaire de paquets recommandé pour les systèmes Debian GNU/Linux. C'est une interface en mode texte à APT qui utilise la bibliothèque curses et peut être utilisé pour améliorer la gestion des tâches de façon rapide et facile.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: aptitude vs apt

            Posté par . Évalué à 3.

            Advanced_Packaging_Tool Il n'existe pas de commande apt en tant que tel. APT est essentiellement une bibliothèque C++ de fonctions utilisées par plusieurs programmes de gestion de paquets.

            apt != apt-get ... j'imagine que apt permet de la souplesse dans les algo de résolution des dépendances, d'installation et de désinstallation, tant que le tout reste cohérent ...
            • [^] # Re: aptitude vs apt

              Posté par (page perso) . Évalué à 2.

              Mais si les 2 outils utilisent les même algo, ils devraient donnés le même résultat.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: aptitude vs apt

                Posté par . Évalué à 3.

                Ils utilisent pas les mêmes algos ...

                je sais pas si apt-get le fait maintenant, mais dans aptitude t'as un marquage des paquets qui dit si ils ont été installé par l'utilisateur ou en dépendance à une demande de l'utilisateur.

                Ce qui permettait de virer les paquets "dépendance" (une lib par exemple) si plus aucun programme ne l'utilisait, et si l'utilisateur n'avait pas demandé explicitement la lib.

                Deborphan faisait ce genre de boulot pour les libs, mais c'était plus limité.

                apt-get ne gérait pas ça, donc les algos étaient forcément différents ...

                Par contre apt comme aptitude utilisent les fonctionalités de la libapt pour faire leur boulot.
                • [^] # Re: aptitude vs apt

                  Posté par (page perso) . Évalué à 1.

                  Par contre apt comme aptitude utilisent les fonctionalités de la libapt pour faire leur boulot.

                  Ok, mais d'après Wikipedia, APT gère les dépendance, c'est qu'au moins un des deux (apt-get ou aptitude) n'utilise pas cette fonction (ce que je ne savais pas).

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: aptitude vs apt

                    Posté par . Évalué à 3.

                    Les deux gèrent bien les dépendances et très comme il faut.
                    Supposons que tu installes un paquet trucmachin.
                    Le paquet trucmachin dépend de libtrucmachin, donc, aptitude tout comme apt-get installent trucmachin et libtrucmachin, mais aptitude note en plus que libtrucmachin a été installé comme une dépendance à trucmachin, et pas explicitement sur demande de l'utilisateur.

                    Ensuite, tu veux supprimer trucmachin:
                    apt-get supprime trucmachin, mais laisse libtrucmachin (il ne sait pas si tu veux la conserver, cette lib après tout, tu peux vouloir t'en servir pour autre chose!)
                    aptitude supprime trucmachin, et voyant que libtrucmachin a été installé en même temps, et comme une dépendance, il supprime également libtrucmachin, supposant que ça ne t'intéresse pas plus que ça.

                    Voilà, j'espère que c'est clair.

                    (En même temps, je suis pas sûr d'avoir bien compris ce que tu entends par "n'utilise pas cette fonction", donc si ça tombe t'avais déjà compris et ce commentaire ne servira qu'à ceux qui n'avaient pas compris et qui ont quand même pris la peine de lire jusqu'au bout, ceux-là je les félicite pour leur persévérance et pour justifier l'existence de ce commentaire, à vous les studios!)
                    • [^] # Re: aptitude vs apt

                      Posté par (page perso) . Évalué à 2.

                      J'avais bien compris, désolé que tu ai écris tout ça pour rien. Ce que je voulais dire, c'est que apt-get et aptitude se base sur apt. Ce dernier fourni des fonctions de résolution de dépendance. Comme apt-get et aptitude n'ont pas la même manière de résoudre les dépendance, je suppose qu'au moins un des deux n'utilise pas les fonctions de apt alors que je pensais que les deux se basais sur apt.

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: aptitude vs apt

                        Posté par (page perso) . Évalué à 2.

                        Mais non les 2 utilises apt, juste que aptitude marque les paquets installé par dépendance comme aillant été installé automatiquement et les désinstalle lorsque plus aucun paquet installé ne les références, alors qu'avec apt-get il ne le fait pas. La résolution des dépendances est la même. Aptitude propose aussi d'installer les paquets inscrits en recommandé. Maintenant je crois que apt-get propose maintenant aussi de virer les paquets installé automatiquement par dépendance avec l'option autoremove.
                        • [^] # Re: aptitude vs apt

                          Posté par . Évalué à 2.

                          apt-get autoremove (--purge)
                          • [^] # Re: aptitude vs apt

                            Posté par (page perso) . Évalué à 2.

                            Il me semblait bien qu'il y avait une commande semblable (mais ça fait longtemps que j'ai plus utilisé apt-get, donc j'étais pas sûr).

                            Il n'y a donc toujours pas de raison d'utiliser aptitude à la place d'apt-get.

                            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: aptitude vs apt

      Posté par . Évalué à 1.

      Éventuellement. Au début c'est ce que nous avions fait d'ailleurs, avant qu'on (un prof) nous demande de changer pour d'obscures raisons.

      J'ai l'impression (et les commentaires le confirme) qu'au final personne ne sait vraiment expliquer pourquoi utiliser aptitude et pas apt-get :)

      Il y a bien une histoire de gestion de dépendances, mais on s'approche de l'enculage de mouche.
      • [^] # Re: aptitude vs apt

        Posté par . Évalué à 2.

        Lorsque tu cherches a installer/mettre à jour un paquet qui va en supprimer d'autre, aptitude cherche un peu mieux a resoudre un peu mieux les conflits (par exemple en te proposant de mettre à jour le paquet qui pose problème si le soucis est au niveau de la version).

        D'ou le fait qu'on le recommande, pour les débutants et pour les dist-upgrades entre autre.
        Pour installer apache... nul besoin
  • # C'est plus que la mise en place

    Posté par (page perso) . Évalué à 2.

    Je viens de comprendre. Le titre est trompeur, votre document vise bien plus que la mise en place d'un service web dynamique avec base de données. C'est carrément la découverte complète d'un système d'exploitation dans ce but.

    Donc, je verrais bien « Découvrir Debian pour mettre en place un service LAMP complet ».
    • [^] # Re: C'est plus que la mise en place

      Posté par (page perso) . Évalué à 2.

      Tout à fait d'accord ! Le titre est trompeur. Il doit il y avoir 20% du document qui parle de l'install/config d'apache/php/mysql, le reste c'est de l'utilisation de Linux à destination de débutants (bien qu'on trouve des passages instructifs et intéressants).

      Alors forcément, je suis déçu, car moi ce qui m'intéresse quand je consulte de la doc sur la mise en place d'un serveur LAMP, c'est la configuration avancé d'apache. (tunning mémoire, sécurisation, hébergement mutualisé, perfs)

      Enfin bon, à l'occasion il faudrait aussi que je prenne le temps de sortir des documentations, c'est toujours plus simple de pointer du doigt ce qui va pas :).
      En tout cas, c'est bien que des gens fassent cet effort visant à faciliter l'usage de solutions libres.
    • [^] # Re: C'est plus que la mise en place

      Posté par . Évalué à 1.

      Bonne remarque.

      Cependant j'estime qu'on ne fait pas tant découvrir Debian que ça (il faudrait un livre entier, qui existe déjà d'ailleurs).

      C'est assez dur de se fixer des limites quand on écrit ce genre de tutoriel. Il faut arriver à évaluer les compétences du lecteur : a t-il déjà utiliser Linux ? a t-il déjà utiliser la ligne de commande ? sait-il déjà mettre en place un serveur LAMP sans toucher du tout à l'aspect sécurité ? :/
  • # quelques remarques

    Posté par . Évalué à 5.

    Mon avis générale : c'est toujours une bonne initiative de faire de la doc. Après il y a quelques petites imperfections :

    * la version beta m'a fait sourire, vous avez tester le document et il ne passe pas sur tous les lecteurs pdf ?

    * pour la connexion en root, vous conseillez 'su', personnellement je pense que sudo n'est pas une tare (pas compliqué à installer non plus), et en plus j'aurai utilisé 'su -' (vu que la doc veut être blindée)

    * pas mal de point discutables sur des détails : nano/vi, les alias (surtout '..' qui me surprend), verbosité des logs, ...

    * petite erreur dans la doc d'iptable : pour l'interface de sortie (-o/-i)

    * pour la protection SYN/ACK, plutôt que de taper dans /proc, il faut mieux éditer le fichier /etc/sysctl.conf, ça évite de perdre les modifications au redémarrage

    * attention aux avis péremptoires, surtout sur la configuration de PHP (appli mal codée...)

    * je suis mitigé sur l'utilité des scripts à la fin de la doc. Le but de la doc est de permettre aux lecteurs de comprendre et savoir ce qu'il fait ; si derrière on lui fait tout le boulot automatiquement c'est la porte ouverte à toutes les erreurs de sa part. Et puis pour qu'ils soient utiles, il faudrait peut-être les mettre en téléchargement, le copier/coller n'est pas toujours très efficace.

    * c'est pas pour faire le vieux con, mais en introduction du document faudrait peut-être indiquer au lecteur de faire un 'man' sur toutes les commandes avant de les lancer pour la première fois, c'est instructif, ne serait-ce que pour lire le paragraphe d'intro des commande.
    • [^] # Re: quelques remarques

      Posté par (page perso) . Évalué à 2.

      * la version beta m'a fait sourire, vous avez tester le document et il ne passe pas sur tous les lecteurs pdf ?

      Je pense qu'une version beta d'une doc n'est pas inutile. Il se peut qu'il y ait des erreurs dans la doc qui peuvent être très gênante (faute de frappe dans les commande, erreur dans la doc d'iptables, l'oubli du rappel d'utilisation de man, l'attente d'avis extérieur sur l'utilisation de sudo, l'utilité de script, ... :-) ).

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: quelques remarques

        Posté par . Évalué à 3.

        Pour cela on donne une version aux docs normalement.
        Ici, a la place de béta on pourrait l'appeler v0.1.
        C'est vrai que béta normalement ca fait reference à un beta-test, donc non-applicable à une doc.

        M'enfin je suis d'accord, c'est clairement du chipotage
        • [^] # Re: quelques remarques

          Posté par (page perso) . Évalué à 2.

          C'est quand même un beta-test de la documentation, dans le sens où elle est utilisé pour trouver des erreurs, comme un logiciel. (C'est effectivement du chipotage).

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: quelques remarques

            Posté par . Évalué à 2.

            oui je chipote, mais je pense que le beta a été placé ici plus par un effet de mode que pour signifier autre chose. Comme dit plus haut, il suffit de commencer à 0.1. Voir même, ils l'appelaient '2.0' et lorsqu'ils auraient corriger les fautes il l'appelaient '2.0.1'.
            • [^] # Re: quelques remarques

              Posté par (page perso) . Évalué à 2.

              Je ne vois pas de différence entre mettre 0.1 et beta, ça veut un peut dire la même chose pour moi (surtout si le 0.1 est en vue d'une version 1.0).

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: quelques remarques

      Posté par . Évalué à 1.

      Salut,

      Le choix de la version 2 d'une part et beta d'autre part s'est fait suite à un intense débat de 10 secondes avec moi-même juste avant la publication de ce journal :)

      Pour sudo, je ne savais pas si ça valait vraiment le coup, je vais regarder.

      Ok pour iptables, corrigé. Idem pour SYN/ACK, je vais regarder.

      Pour les scripts à la fin, c'était juste une demande d'un professeur. De mon point de vue il n'est pas suffisamment "stable". Si un truc foire en plein milieu, bonjour les problèmes. On va réfléchir à les enlever.
  • # Bug report

    Posté par . Évalué à 1.

    Vu que j'ai pas trouvé sur le site du projet comment reporter un bug, je vous en communique un supposé dans le script à la page 24 sur la commande mysql GRANT. La commande est coupée probablement à cause de la mise en page.
  • # Conf apache : tunning mémoire

    Posté par (page perso) . Évalué à 1.

    Pour éviter qu'apache n'utilise trop de mémoire en cas de forte fréquentation du serveur, il est bon de jouer sur le "MaxClients" :

    Déjà tu regardes combien tes process consomment en mémoire (disons 20 mo) et la taille maximale que tu veux laisser à apache (disons 1000 mo).

    Ce qui fait dans notre exemple : MaxClients = 1000 / 20 = 50.

    Voila, si par malheur le serveur se met à swapper et qu'on accepte trop de clients, les requêtes vont s'accumuler et ça peut empirer la situation.
    • [^] # Re: Conf apache : tunning mémoire

      Posté par . Évalué à 1.

      J'ai juste survoler le "problème" mais n'y a t-il tout simplement pas plus performant et sécurisé que Apache en mode prefork et php en module ?

      D'après ce que j'ai compris, si on apache en mode worker et PHP via FCGI, d'une part ça prend moins de ressources et d'autre part chaque virtualhost est exécuté avec ses propres droits et non ceux de www-data.

      Tout ceci reste à confirmer bien sûr, quelqu'un ? :)
      • [^] # Re: Conf apache : tunning mémoire

        Posté par . Évalué à 3.

        Oui,

        Les process sont lancés avec l'id de chaque "propriétaire" (enfin tu peux le config comme tu veux mais c'est la manière la plus courante).

        Ils ont des timeout etc, donc , si tu as un client qui visite un site, tu as un process php et un seul, et non X fois le module php chargé dans apache.

        Par contre c'est un setup autrement plus complexe
        • [^] # Re: Conf apache : tunning mémoire

          Posté par (page perso) . Évalué à 1.

          La dernière fois où j'ai fait une install sur un serveur avec plusieurs utilisateurs, j'ai choisi la solution suPHP. Mais je sais pas si c'était vraiment le meilleur choix (ça marche, même si j'ai perdu en perf), alors si quelqu'un pouvait m'aiguiller sur l'intérêt de choisir plutôt suPHP ou fcgi ?
          • [^] # Re: Conf apache : tunning mémoire

            Posté par . Évalué à 3.

            suphp ne te permet que de faire le premier point:
            Les process sont lancés avec l'id de chaque "propriétaire" (enfin tu peux le config comme tu veux mais c'est la manière la plus courante).

            Tu reste avec le système du module apache: une instance de php est chargée dans chaque process apache.

            Fastcgi, te permet un découpage plus fin:
            - apache ne fera que de servir les pages (php ne sera pas chargé dans chaque process, y compris ceux qui vont envoyer du static).
            - si besoin un process php sera créé en fastcgi, il aura une durée de vie etc.

            Je te laisse deviner les implications en terme de consommation mémoire par exemple (ou pour les Xcache/APC etc)
            • [^] # Re: Conf apache : tunning mémoire

              Posté par (page perso) . Évalué à 2.

              Est-ce qu'il y a des inconvénients à utiliser fcgi ? Dans quel cas suphp est préférable ? (ie, qu'est-ce qui justifie l'existence de suphp ?)
              • [^] # Re: Conf apache : tunning mémoire

                Posté par . Évalué à 1.

                À priori suPHP fonctionne avec mod CGI mais pas FCGI. Par contre FGCI + suExec serait le bien.

                Je me suis aussi penché sur suhosin (patch de sécurité supplémentaire non inclut par défaut dans PHP). Sur le dépôt officiel Debian il n'y a que les sources de suhosin, il faut donc recompiler PHP donc bof… C'est là que j'ai découvert un dépôt spécial Debian pour serveur LAMP : http://www.dotdeb.org
                Reste à voir si c'est prudent d'utiliser ces paquets au lieu de ceux officiels.

                Quelques liens :
                http://www.seaoffire.net/fcgi-faq.html
                http://www.dedibox-news.com/sujet-4690-choix-entre-suphp-sue(...)
                • [^] # Re: Conf apache : tunning mémoire

                  Posté par . Évalué à 2.

                  Je ne voulais pas rentrer dans les détails , un peu de recherche personnelle ne fait pas de mal :)

                  C'est surtout la mise en place plus complexe le problème, mais les avantages sont rééls, j'ai ai oublié un: tu n'est plus obligé d utiliser apache2-mpm-prefork, avec les gains de performances que ça implique.

                  apt-get install php5-suhosin marche très bien. Par contre cela a des implications, par exemple pour phpmyadmin qui va t'afficher un warning. Au final, c'est le genre d'outil qui demande à être configuré et maîtrisé (comme la majorité des outils de sécurité en fait) car il risque de bloquer certaines choses (GET et POST trop longs, pouvant être utilisé pour du json) et l'utilisateur ne comprendra pas forcément pourquoi.

                  Pour dotdeb, je ne l'ai jamais utilisé donc je n'ai pas d'avis dessus, sur le principe je prefere m'en tenir au paquets debian pour tous les logiciels un tant soit peu critiques.
                  • [^] # Re: Conf apache : tunning mémoire

                    Posté par . Évalué à 1.

                    Je vais regarder du côté de suhosin quand même. Et de mod_security, le truc qui peut vite être chiant si on le maîtrise pas non plus ou si on "l'oublie" ;)

                    J'ai vu que pour utiliser le suExec il y a des contraintes. Les paramètres de ce programme sont en dur, dont le dossier de bas equi est /var/www/ dans le dossier Debian. Or dans mon tutoriel j'utilise /home/site.fr/ pour stocker les données. Donc soit je recompile suExec (pas mon but) soit je met les dossiers /home dans /var/www/site.fr/ au final.

                    J'ai bon ?
                    • [^] # Re: Conf apache : tunning mémoire

                      Posté par . Évalué à 2.

                      mercure:/# apt-cache search suexec
                      [...]
                      apache2-suexec - Standard suexec program for Apache 2 mod_suexec
                      apache2-suexec-custom - Configurable suexec program for Apache 2 mod_suexec

                      Ca répond à ta question :) ?

                      Le deuxieme est tout de même moins recommandé, vu que le fait que ces parametres soient en hard est sensé apporter un peu plus de sécurité, après, c'est je pense , mieux que rien.

                      Je reste d'avis que fastcgi/suexec sont compliqués à mettre en oeuvre, débugguer, maitriser etc. C'est intéréssant, clairement, mais pour moi ça dépasse le cadre d'un tutoriel simple. A voir :)
                      • [^] # Re: Conf apache : tunning mémoire

                        Posté par (page perso) . Évalué à 2.

                        Si le document est bien organisé, on peut aborder des configurations complexes, tout le monde n'est pas obligé de se lancer dans une telle configuration. En plus, des tutos simples, il y en a des tonnes sur internet donc ça n'a pas beaucoup d'intérêt.
                        Donc si Thomas est motivé pour approfondir ses recherches sur la sécu, je pense qu'il devrait le faire.

Suivre le flux des commentaires

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