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é :
- La licence, ce sera à priori http://creativecommons.org/licenses/by/2.0/fr/ une fois que j'aurais trouvé comment bien l'indiqué.
- La documentation est réalisé avec Sphinx ( http://sphinx.pocoo.org/ ).
# A4
Posté par B16F4RV4RD1N . Évalué à 10.
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 Thomas . Évalué à 1.
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 balzane . Évalué à 2.
=> 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 deleted_user . Évalué à 1.
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 Thomas . Évalué à 1.
À 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 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1.
# 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 balzane . Évalué à 2.
# aptitude install openssh-server apache2 libapache2-mod-php5 postfixtu perds un morceau de LAMP.
[^] # Re: Pas de tutoriel ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Pas de tutoriel ?
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Pas de tutoriel ?
Posté par geb . Évalué à 3.
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 kowalsky . Évalué à 5.
# Cool
Posté par Quentin Gibeaux (site web personnel) . Évalué à 2.
(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à.
[^] # Re: Cool
Posté par Maxime (site web personnel) . Évalué à 2.
# Très bonne initiative
Posté par Ellendhel (site web personnel) . Évalué à 2.
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 geb . Évalué à -1.
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 jeffcom . Évalué à 2.
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 geb . Évalué à 2.
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 jeffcom . Évalué à 2.
[^] # Re: Mouai...
Posté par Thomas . Évalué à 1.
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 geb . É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 leoboy . Évalué à 8.
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 geb . Évalué à -2.
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 leoboy . Évalué à 1.
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 geb . Évalué à 2.
[^] # Re: Mouai...
Posté par geb . Évalué à 2.
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 Krunch (site web personnel) . Évalué à -9.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et ça sert à quoi ?
Posté par Maclag . Évalué à 10.
-------------> [ ]
# aptitude vs apt
Posté par Grégory Landais (site web personnel) . Évalué à 3.
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 claudex . Évalué à 2.
« 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 Thomas Douillard . Évalué à 2.
[^] # Re: aptitude vs apt
Posté par claudex . Évalué à 2.
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 Thomas Douillard . Évalué à 3.
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 claudex . Évalué à 2.
« 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 Thomas Douillard . Évalué à 3.
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 claudex . Évalué à 1.
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 Maclag . Évalué à 3.
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 claudex . Évalué à 2.
« 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 allcolor (site web personnel) . Évalué à 2.
[^] # Re: aptitude vs apt
Posté par geb . Évalué à 2.
[^] # Re: aptitude vs apt
Posté par claudex . Évalué à 2.
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 Thomas . Évalué à 1.
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 geb . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 Maxime (site web personnel) . Évalué à 2.
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 Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: C'est plus que la mise en place
Posté par Thomas . Évalué à 1.
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 ultimat . Évalué à 5.
* 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 claudex . Évalué à 2.
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 campagnard . Évalué à 3.
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 claudex . Évalué à 2.
« 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 ultimat . Évalué à 2.
[^] # Re: quelques remarques
Posté par claudex . Évalué à 2.
« 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 Thomas . Évalué à 1.
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 krion . Évalué à 1.
# Conf apache : tunning mémoire
Posté par Maxime (site web personnel) . Évalué à 1.
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 Thomas . Évalué à 1.
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 geb . Évalué à 3.
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 Maxime (site web personnel) . Évalué à 1.
[^] # Re: Conf apache : tunning mémoire
Posté par geb . Évalué à 3.
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 Maxime (site web personnel) . Évalué à 2.
[^] # Re: Conf apache : tunning mémoire
Posté par Thomas . Évalué à 1.
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 geb . Évalué à 2.
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 Thomas . Évalué à 1.
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 geb . Évalué à 2.
[...]
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 Maxime (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.