je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes
pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de
gerer
d'assez fortes charges du serveur web, des connexions ssh/scp des
membres
pour edition(emacs)/transfert(scp) de leurs fichiers.
je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer d'assez fortes charges du serveur web, des connexions ssh/scp des membres pour edition(emacs)/transfert(scp) de leurs fichiers.
sans hésitation FreeBSD.
DDM
je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes
pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de
gerer d'assez fortes charges du serveur web, des connexions ssh/scp des
membres
pour edition(emacs)/transfert(scp) de leurs fichiers.
je cherche une solution pour faire un serveur web, efficace.
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer d'assez fortes charges du serveur web, des connexions ssh/scp des membres pour edition(emacs)/transfert(scp) de leurs fichiers.
sans hésitation FreeBSD.
DDM
DDM
Panic wrote:
DDM wrote:
sans hésitation FreeBSD.
Pour une/plusieures raison(s) en particulier ? :)
c'est vrai que ma réponse était rapide.
Comme je ne suis pas encore chez moi, je ferais encore une réponse ... rapide. D'ailleurs je suis étonné que personne n'ai répondu pour vanter les mérites des BSD. Différents tests trouvés sur Internet sur la charge d'un serveur mettait souvent FreeBSD vainqueur. Une partie de ces tests ont été refait par un petit groupe avec des moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat, windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus souvent le mieux. Il faudrait que je retrouve un semblant de lien pour preuve. ( et que les herbergeurs présents sur cette liste nous donne un avis...)
DDM
Panic wrote:
DDM wrote:
sans hésitation FreeBSD.
Pour une/plusieures raison(s) en particulier ? :)
c'est vrai que ma réponse était rapide.
Comme je ne suis pas encore chez moi, je ferais encore une réponse ...
rapide. D'ailleurs je suis étonné que personne n'ai répondu pour vanter
les mérites des BSD.
Différents tests trouvés sur Internet sur la charge d'un serveur mettait
souvent FreeBSD vainqueur.
Une partie de ces tests ont été refait par un petit groupe avec des
moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat,
windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus
souvent le mieux.
Il faudrait que je retrouve un semblant de lien pour preuve. ( et que
les herbergeurs présents sur cette liste nous donne un avis...)
Comme je ne suis pas encore chez moi, je ferais encore une réponse ... rapide. D'ailleurs je suis étonné que personne n'ai répondu pour vanter les mérites des BSD. Différents tests trouvés sur Internet sur la charge d'un serveur mettait souvent FreeBSD vainqueur. Une partie de ces tests ont été refait par un petit groupe avec des moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat, windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus souvent le mieux. Il faudrait que je retrouve un semblant de lien pour preuve. ( et que les herbergeurs présents sur cette liste nous donne un avis...)
DDM
manu
Panic wrote:
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer d'assez fortes charges du serveur web, des connexions ssh/scp des membres pour edition(emacs)/transfert(scp) de leurs fichiers.
Les trois font l'affaire. BSD est stable, BSD supporte la charge, et les 3 BSD sont des BSD. Si j'ose dire.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Panic <panic@nospam.no> wrote:
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant
aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer
d'assez fortes charges du serveur web, des connexions ssh/scp des
membres pour edition(emacs)/transfert(scp) de leurs fichiers.
Les trois font l'affaire. BSD est stable, BSD supporte la charge, et les
3 BSD sont des BSD. Si j'ose dire.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
On heberge un peu plus de 2000 pages persos, donc 2000 comptes pouvant aller jusqu'a 5-6000. Je cherche un BSD (si possible) capable de gerer d'assez fortes charges du serveur web, des connexions ssh/scp des membres pour edition(emacs)/transfert(scp) de leurs fichiers.
Les trois font l'affaire. BSD est stable, BSD supporte la charge, et les 3 BSD sont des BSD. Si j'ose dire.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
M.D
Dans l'article <blhn64$17q$, disait...
Panic wrote:
DDM wrote:
sans hésitation FreeBSD.
Pour une/plusieures raison(s) en particulier ? :)
Pour: L'extremement bonne qualité et cohérence de sa documentation.
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
c'est vrai que ma réponse était rapide. Comme je ne suis pas encore chez moi, je ferais encore une réponse ... rapide. D'ailleurs je suis étonné que personne n'ai répondu pour va nter les mérites des BSD. Différents tests trouvés sur Internet sur la charge d'un serveur mett ait souvent FreeBSD vainqueur. Une partie de ces tests ont été refait par un petit groupe avec des moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat, windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus souvent le mieux.
<off topic> Juste par curiosité: En quoi un Linux Debian avec le même noyau et les mêmes outils, le même FS peut-il être plus performant qu'un Linux RedHat ou Mandrake ? </off topic>
-- Marc
Dans l'article <blhn64$17q$1@news-reader4.wanadoo.fr>,
david.dimarcantonio@wynid.fr disait...
Panic wrote:
DDM wrote:
sans hésitation FreeBSD.
Pour une/plusieures raison(s) en particulier ? :)
Pour:
L'extremement bonne qualité et cohérence de sa documentation.
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)
c'est vrai que ma réponse était rapide.
Comme je ne suis pas encore chez moi, je ferais encore une réponse ...
rapide. D'ailleurs je suis étonné que personne n'ai répondu pour va nter
les mérites des BSD.
Différents tests trouvés sur Internet sur la charge d'un serveur mett ait
souvent FreeBSD vainqueur.
Une partie de ces tests ont été refait par un petit groupe avec des
moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat,
windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus
souvent le mieux.
<off topic>
Juste par curiosité: En quoi un Linux Debian avec le même
noyau et les mêmes outils, le même FS peut-il être plus
performant qu'un Linux RedHat ou Mandrake ?
</off topic>
Pour: L'extremement bonne qualité et cohérence de sa documentation.
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
c'est vrai que ma réponse était rapide. Comme je ne suis pas encore chez moi, je ferais encore une réponse ... rapide. D'ailleurs je suis étonné que personne n'ai répondu pour va nter les mérites des BSD. Différents tests trouvés sur Internet sur la charge d'un serveur mett ait souvent FreeBSD vainqueur. Une partie de ces tests ont été refait par un petit groupe avec des moyens un peu plus approximatif entre FreeBSD, Debian, Mandrake, Redhat, windows 2000, et grossomodo FreeBSD, et debian s'en sorte le plus souvent le mieux.
<off topic> Juste par curiosité: En quoi un Linux Debian avec le même noyau et les mêmes outils, le même FS peut-il être plus performant qu'un Linux RedHat ou Mandrake ? </off topic>
-- Marc
Erwan David
M.D écrivait :
Dans l'article <blhn64$17q$, disait...
Panic wrote:
DDM wrote:
sans hésitation FreeBSD.
Pour une/plusieures raison(s) en particulier ? :)
Pour: L'extremement bonne qualité et cohérence de sa documentation.
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Euh le noyau GENERIC fourni a tout ce qu'il faut pour ipf ou ipfw. Bon c'était pas le cas pour ipf en 4.2, mais maintenant y'a plus à recompiler le noyau pour ça.
M.D <mdnews@wanadoo.fr> écrivait :
Dans l'article <blhn64$17q$1@news-reader4.wanadoo.fr>,
david.dimarcantonio@wynid.fr disait...
Panic wrote:
DDM wrote:
sans hésitation FreeBSD.
Pour une/plusieures raison(s) en particulier ? :)
Pour:
L'extremement bonne qualité et cohérence de sa documentation.
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)
Euh le noyau GENERIC fourni a tout ce qu'il faut pour ipf ou
ipfw. Bon c'était pas le cas pour ipf en 4.2, mais maintenant y'a plus
à recompiler le noyau pour ça.
Pour: L'extremement bonne qualité et cohérence de sa documentation.
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Euh le noyau GENERIC fourni a tout ce qu'il faut pour ipf ou ipfw. Bon c'était pas le cas pour ipf en 4.2, mais maintenant y'a plus à recompiler le noyau pour ça.
pornin
According to M.D : [FreeBSD]
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche avec le noyau GENERIC, pourvu qu'on charge le module correspondant (kldload ipfw).
<off topic> Juste par curiosité: En quoi un Linux Debian avec le même noyau et les mêmes outils, le même FS peut-il être plus performant qu'un Linux RedHat ou Mandrake ? </off topic>
En l'occurrence ce n'est pas exactement le même noyau. Chaque distributeur Linux propose un ensemble de logiciels sous forme de packages, configurés et ajustés par le distributeur, et le noyau ne fait pas exception. Autrement dit, RedHat fournit des noyaux avec des patchs "RedHat", Mandrake fournit des noyaux avec des patchs "Mandrake", etc... Il y a aussi des paramètres configurables via sysctl ou /proc, et qui influent sur la performances.
Le fond de commerce de RedHat et (surtout) Mandrake, c'est le poste utilisateur, donc ces distributeurs favorisent l'interactivité, parfois au détriment des performances dans les usages de type "serveur". Ceci peut expliquer que Debian s'en sorte mieux sur les tests de charge de serveur.
Quant aux filesystems, justement, ils ont tendance à ne pas utiliser les mêmes. Debian tourne par défaut en ext2, qui est très rapide (en lecture comme ne écriture) mais peu sûr en cas de coupure de courant. Les gros serveurs sont de toutes façons sur un UPS donc ce n'est pas un problème ; les coupures de courant arrivent surtout sur les postes utilisateurs, parce que l'utilisateur se prend les pieds dans le câble d'alimentation. Donc, pour les mêmes raisons de "marché", RedHat et Mandrake privilégient les filesystems plus sûrs et fournissant la meilleure "user experience" (donc les filesystems journalisés, qui évitent un long fsck au reboot) mais dont les performances sont un peu en dessous.
Et puis il y a la mémoire. Une RedHat ou une Mandrake, par défaut, lance plus de choses qu'une Debian. Ça part rapidement dans le swap, mais ça augmente la pression sur le système de gestion de mémoire virtuelle, et ça peut se sentir (un peu) sur les performances.
Tout ceci contribue à faire de Debian un OS plus performant que Redhat et Mandrake pour un serveur. Notez bien que j'ai dit "performant" ; je n'ai pas dit "adapté".
Sinon, je recommande effectivement FreeBSD. Il est un peu plus optimisé que les autres BSD sur PC, et surtout il gère nettement mieux les PC à plusieurs processeurs. Quand on a un serveur avec pas mal de charge, on a souvent envie de mettre deux ou quatre processeurs en batterie.
--Thomas Pornin
According to M.D <mdnews@wanadoo.fr>:
[FreeBSD]
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche
avec le noyau GENERIC, pourvu qu'on charge le module correspondant
(kldload ipfw).
<off topic>
Juste par curiosité: En quoi un Linux Debian avec le même
noyau et les mêmes outils, le même FS peut-il être plus
performant qu'un Linux RedHat ou Mandrake ?
</off topic>
En l'occurrence ce n'est pas exactement le même noyau. Chaque
distributeur Linux propose un ensemble de logiciels sous forme de
packages, configurés et ajustés par le distributeur, et le noyau ne
fait pas exception. Autrement dit, RedHat fournit des noyaux avec
des patchs "RedHat", Mandrake fournit des noyaux avec des patchs
"Mandrake", etc... Il y a aussi des paramètres configurables via
sysctl ou /proc, et qui influent sur la performances.
Le fond de commerce de RedHat et (surtout) Mandrake, c'est le poste
utilisateur, donc ces distributeurs favorisent l'interactivité, parfois
au détriment des performances dans les usages de type "serveur". Ceci
peut expliquer que Debian s'en sorte mieux sur les tests de charge de
serveur.
Quant aux filesystems, justement, ils ont tendance à ne pas utiliser
les mêmes. Debian tourne par défaut en ext2, qui est très rapide (en
lecture comme ne écriture) mais peu sûr en cas de coupure de courant.
Les gros serveurs sont de toutes façons sur un UPS donc ce n'est pas
un problème ; les coupures de courant arrivent surtout sur les postes
utilisateurs, parce que l'utilisateur se prend les pieds dans le câble
d'alimentation. Donc, pour les mêmes raisons de "marché", RedHat et
Mandrake privilégient les filesystems plus sûrs et fournissant la
meilleure "user experience" (donc les filesystems journalisés, qui
évitent un long fsck au reboot) mais dont les performances sont un peu
en dessous.
Et puis il y a la mémoire. Une RedHat ou une Mandrake, par défaut,
lance plus de choses qu'une Debian. Ça part rapidement dans le swap,
mais ça augmente la pression sur le système de gestion de mémoire
virtuelle, et ça peut se sentir (un peu) sur les performances.
Tout ceci contribue à faire de Debian un OS plus performant que Redhat
et Mandrake pour un serveur. Notez bien que j'ai dit "performant" ; je
n'ai pas dit "adapté".
Sinon, je recommande effectivement FreeBSD. Il est un peu plus optimisé
que les autres BSD sur PC, et surtout il gère nettement mieux les PC à
plusieurs processeurs. Quand on a un serveur avec pas mal de charge, on
a souvent envie de mettre deux ou quatre processeurs en batterie.
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche avec le noyau GENERIC, pourvu qu'on charge le module correspondant (kldload ipfw).
<off topic> Juste par curiosité: En quoi un Linux Debian avec le même noyau et les mêmes outils, le même FS peut-il être plus performant qu'un Linux RedHat ou Mandrake ? </off topic>
En l'occurrence ce n'est pas exactement le même noyau. Chaque distributeur Linux propose un ensemble de logiciels sous forme de packages, configurés et ajustés par le distributeur, et le noyau ne fait pas exception. Autrement dit, RedHat fournit des noyaux avec des patchs "RedHat", Mandrake fournit des noyaux avec des patchs "Mandrake", etc... Il y a aussi des paramètres configurables via sysctl ou /proc, et qui influent sur la performances.
Le fond de commerce de RedHat et (surtout) Mandrake, c'est le poste utilisateur, donc ces distributeurs favorisent l'interactivité, parfois au détriment des performances dans les usages de type "serveur". Ceci peut expliquer que Debian s'en sorte mieux sur les tests de charge de serveur.
Quant aux filesystems, justement, ils ont tendance à ne pas utiliser les mêmes. Debian tourne par défaut en ext2, qui est très rapide (en lecture comme ne écriture) mais peu sûr en cas de coupure de courant. Les gros serveurs sont de toutes façons sur un UPS donc ce n'est pas un problème ; les coupures de courant arrivent surtout sur les postes utilisateurs, parce que l'utilisateur se prend les pieds dans le câble d'alimentation. Donc, pour les mêmes raisons de "marché", RedHat et Mandrake privilégient les filesystems plus sûrs et fournissant la meilleure "user experience" (donc les filesystems journalisés, qui évitent un long fsck au reboot) mais dont les performances sont un peu en dessous.
Et puis il y a la mémoire. Une RedHat ou une Mandrake, par défaut, lance plus de choses qu'une Debian. Ça part rapidement dans le swap, mais ça augmente la pression sur le système de gestion de mémoire virtuelle, et ça peut se sentir (un peu) sur les performances.
Tout ceci contribue à faire de Debian un OS plus performant que Redhat et Mandrake pour un serveur. Notez bien que j'ai dit "performant" ; je n'ai pas dit "adapté".
Sinon, je recommande effectivement FreeBSD. Il est un peu plus optimisé que les autres BSD sur PC, et surtout il gère nettement mieux les PC à plusieurs processeurs. Quand on a un serveur avec pas mal de charge, on a souvent envie de mettre deux ou quatre processeurs en batterie.
--Thomas Pornin
Erwan David
(Thomas Pornin) écrivait :
According to M.D : [FreeBSD]
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche avec le noyau GENERIC, pourvu qu'on charge le module correspondant (kldload ipfw).
Même pas, le module ipf existe de base...
pornin@nerim.net (Thomas Pornin) écrivait :
According to M.D <mdnews@wanadoo.fr>:
[FreeBSD]
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche
avec le noyau GENERIC, pourvu qu'on charge le module correspondant
(kldload ipfw).
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche avec le noyau GENERIC, pourvu qu'on charge le module correspondant (kldload ipfw).
Même pas, le module ipf existe de base...
talon
Thomas Pornin wrote:
According to M.D : [FreeBSD]
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche avec le noyau GENERIC, pourvu qu'on charge le module correspondant (kldload ipfw).
Plus exactement, sous FreeBSD-5.1 on est obligé de recompiler un noyau pour utiliser ipfilter (*), mais sous FreeBSD-4.8 il suffit de charger le module ipl.ko. En réalité les scripts de démarrage se chargent de faire kldload ipfw.ko ou kldload ipl.ko, donc il y a juste besoin de le mentionner dans /etc/rc.conf et de renseigner les fichiers de règles.
(*) Ceci à cause d'une option PFILL_HOOKS qui manque dans le noyau générique, de façon trés inappropriée.
--
Michel TALON
Thomas Pornin <pornin@nerim.net> wrote:
According to M.D <mdnews@wanadoo.fr>:
[FreeBSD]
Contre:
La nécessité de recompiler le noyau pour avoir le support de
filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche
avec le noyau GENERIC, pourvu qu'on charge le module correspondant
(kldload ipfw).
Plus exactement, sous FreeBSD-5.1 on est obligé de recompiler un noyau
pour utiliser ipfilter (*), mais sous FreeBSD-4.8 il suffit de charger le
module ipl.ko. En réalité les scripts de démarrage se chargent de faire
kldload ipfw.ko ou kldload ipl.ko, donc il y a juste besoin de le
mentionner dans /etc/rc.conf et de renseigner les fichiers de règles.
(*) Ceci à cause d'une option PFILL_HOOKS qui manque dans le noyau
générique, de façon trés inappropriée.
Contre: La nécessité de recompiler le noyau pour avoir le support de filtrage ip (même si c'est pas difficile)
Nuançons : il faut recompiler pour ipfilter, mais le support ipfw marche avec le noyau GENERIC, pourvu qu'on charge le module correspondant (kldload ipfw).
Plus exactement, sous FreeBSD-5.1 on est obligé de recompiler un noyau pour utiliser ipfilter (*), mais sous FreeBSD-4.8 il suffit de charger le module ipl.ko. En réalité les scripts de démarrage se chargent de faire kldload ipfw.ko ou kldload ipl.ko, donc il y a juste besoin de le mentionner dans /etc/rc.conf et de renseigner les fichiers de règles.
(*) Ceci à cause d'une option PFILL_HOOKS qui manque dans le noyau générique, de façon trés inappropriée.
--
Michel TALON
Eric Masson
"Erwan" == Erwan David writes:
Erwan> Même pas, le module ipf existe de base...
Pour une 4, c'est effectivement finger in ze noze.
Mais comme le disait Michel Talon récemment, sur une 5, l'option PFIL_HOOKS est devenue obligatoire pour pouvoir charger un packet filter autre qu'ipfw et cette option n'est pas intégrée dans GENERIC.
Tu me diras qu'une 5 n'est pas faite pour un environnement de production, certes.
Eric Masson
-- fgu> Je reviens sur mon post de 11h27 : Au lieu de :"2ème DD en fgu> Secondary Master (SM)" ce serait plutôt : "2ème DD en Primary Slave fgu> (PS)" -+-<http://www.le-gnu.net>-La dialectique du maître et de l'esclave -+-
"Erwan" == Erwan David <erwan@rail.eu.org> writes:
Erwan> Même pas, le module ipf existe de base...
Pour une 4, c'est effectivement finger in ze noze.
Mais comme le disait Michel Talon récemment, sur une 5, l'option
PFIL_HOOKS est devenue obligatoire pour pouvoir charger un packet filter
autre qu'ipfw et cette option n'est pas intégrée dans GENERIC.
Tu me diras qu'une 5 n'est pas faite pour un environnement de
production, certes.
Eric Masson
--
fgu> Je reviens sur mon post de 11h27 : Au lieu de :"2ème DD en
fgu> Secondary Master (SM)" ce serait plutôt : "2ème DD en Primary Slave
fgu> (PS)"
-+-<http://www.le-gnu.net>-La dialectique du maître et de l'esclave -+-
Pour une 4, c'est effectivement finger in ze noze.
Mais comme le disait Michel Talon récemment, sur une 5, l'option PFIL_HOOKS est devenue obligatoire pour pouvoir charger un packet filter autre qu'ipfw et cette option n'est pas intégrée dans GENERIC.
Tu me diras qu'une 5 n'est pas faite pour un environnement de production, certes.
Eric Masson
-- fgu> Je reviens sur mon post de 11h27 : Au lieu de :"2ème DD en fgu> Secondary Master (SM)" ce serait plutôt : "2ème DD en Primary Slave fgu> (PS)" -+-<http://www.le-gnu.net>-La dialectique du maître et de l'esclave -+-