Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est. C'est marrant, ces deux points sont justement en plein travail.
Rhooo, Miod! Tu fais du vaproware, maintenant?
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat <miod@online.fr> wrote:
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un
serveur moderne (et moins moderne), je sais pas ce que c'est.
C'est marrant, ces deux points sont justement en plein travail.
Rhooo, Miod! Tu fais du vaproware, maintenant?
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est. C'est marrant, ces deux points sont justement en plein travail.
Rhooo, Miod! Tu fais du vaproware, maintenant?
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Loin de moi cette idée. Je me borne à constater des faits.
Patrice Auffret
On 07 Jun 2004 15:18:52 GMT VANHULLEBUS Yvan wrote:
[..]
Et au passage, pour un OS qui se dit "secure", avoir des portions de code qui "encouragent" la surcharge CPU (donc pourquoi pas un DOS), ca me parait moyen...... [..]
Alors que ici: http://www.openbsd.org/security.html#default [..] All non-essential services are disabled. [..]
C'est clair que timserver et daytime c'est essentiel.
On 07 Jun 2004 15:18:52 GMT
VANHULLEBUS Yvan <vanhu@nospam_free.fr> wrote:
[..]
Et au passage, pour un OS qui se dit "secure", avoir des portions de
code qui "encouragent" la surcharge CPU (donc pourquoi pas un DOS), ca me
parait moyen......
[..]
On 07 Jun 2004 15:18:52 GMT VANHULLEBUS Yvan wrote:
[..]
Et au passage, pour un OS qui se dit "secure", avoir des portions de code qui "encouragent" la surcharge CPU (donc pourquoi pas un DOS), ca me parait moyen...... [..]
Alors que ici: http://www.openbsd.org/security.html#default [..] All non-essential services are disabled. [..]
C'est clair que timserver et daytime c'est essentiel.
Thomas Nemeth
Le lun 07 jun 2004 à 18:10, Djoume SALVETTI a tapoté : | > On 07 Jun 2004 13:38:50 GMT | > Djoume SALVETTI wrote: | > | > > Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on | > > commence à rajouter du code non officiellement supporté, Open pert | > > beaucoup de son intéret (code audité, etc...). | > | > Je penses que vous n'avez pas regarder l'arbre des ports de NetBSD | > depuis un petit moment (actuellement, s'il l'on prend la liste brut des | > pkg dispo, elle fait 4701 lignes ... ) | | Il y en a quasiment le double dans Debian Stable (et plus du triple dans | Debian Testing).
La différence n'est plus si grande que ça si on vire les packages dédiés à la doc et aux -dev...
Thomas -- BOFH excuse #282: High altitude condensation from U.S.A.F prototype aircraft has contaminated the primary subnet mask. Turn off your computer for 9 days to avoid damaging it.
Le lun 07 jun 2004 à 18:10, Djoume SALVETTI a tapoté :
| > On 07 Jun 2004 13:38:50 GMT
| > Djoume SALVETTI <salvetti@crans.org> wrote:
| >
| > > Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on
| > > commence à rajouter du code non officiellement supporté, Open pert
| > > beaucoup de son intéret (code audité, etc...).
| >
| > Je penses que vous n'avez pas regarder l'arbre des ports de NetBSD
| > depuis un petit moment (actuellement, s'il l'on prend la liste brut des
| > pkg dispo, elle fait 4701 lignes ... )
|
| Il y en a quasiment le double dans Debian Stable (et plus du triple dans
| Debian Testing).
La différence n'est plus si grande que ça si on vire les packages
dédiés à la doc et aux -dev...
Thomas
--
BOFH excuse #282:
High altitude condensation from U.S.A.F prototype aircraft has contaminated the
primary subnet mask. Turn off your computer for 9 days to avoid damaging it.
Le lun 07 jun 2004 à 18:10, Djoume SALVETTI a tapoté : | > On 07 Jun 2004 13:38:50 GMT | > Djoume SALVETTI wrote: | > | > > Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on | > > commence à rajouter du code non officiellement supporté, Open pert | > > beaucoup de son intéret (code audité, etc...). | > | > Je penses que vous n'avez pas regarder l'arbre des ports de NetBSD | > depuis un petit moment (actuellement, s'il l'on prend la liste brut des | > pkg dispo, elle fait 4701 lignes ... ) | | Il y en a quasiment le double dans Debian Stable (et plus du triple dans | Debian Testing).
La différence n'est plus si grande que ça si on vire les packages dédiés à la doc et aux -dev...
Thomas -- BOFH excuse #282: High altitude condensation from U.S.A.F prototype aircraft has contaminated the primary subnet mask. Turn off your computer for 9 days to avoid damaging it.
Cedric Blancher
Le Mon, 07 Jun 2004 14:44:54 +0000, jdc a écrit :
De plus il me semble "injuste" - mais je m'en remettrai - qu'on fasse ce reproche à OpenBSD, un OS dont le but n'est pas de faire avec un serveur applicatif.
Faudra que je l'envoie à Theo, Niels et autres celle-là, ça va leur faire plaisir.
C'est quoi l'intérêt d'avoir des packages audités de Apache, BIND, Postfix, PGSQL, MySQL, PHP4, etc. si le but n'est pas de faire des serveurs applicatifs comme des serveurs Web, des serveurs SMTP, etc. ? Paraît même qu'il y en a qui en font des stations de travail...
Maintenant si on me dit qu'il faut vraiment un bipro pour faire tourner un fw sur OpenBSD moi je n'ai rien contre.
Jamais dit qu'il fallait un bipro pour faire un firewall, mais il me semble qu'il est des champs d'application d'OpenBSD où un bipro ne ferait pas de mal. Mais bon, moi ce que j'en dis...
--
les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!! define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl -+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-
Le Mon, 07 Jun 2004 14:44:54 +0000, jdc a écrit :
De plus il me semble "injuste" - mais je m'en remettrai - qu'on fasse
ce reproche à OpenBSD, un OS dont le but n'est pas de faire avec un
serveur applicatif.
Faudra que je l'envoie à Theo, Niels et autres celle-là, ça va leur
faire plaisir.
C'est quoi l'intérêt d'avoir des packages audités de Apache, BIND,
Postfix, PGSQL, MySQL, PHP4, etc. si le but n'est pas de faire des
serveurs applicatifs comme des serveurs Web, des serveurs SMTP, etc. ?
Paraît même qu'il y en a qui en font des stations de travail...
Maintenant si on me dit qu'il faut vraiment un bipro pour faire tourner
un fw sur OpenBSD moi je n'ai rien contre.
Jamais dit qu'il fallait un bipro pour faire un firewall, mais il me
semble qu'il est des champs d'application d'OpenBSD où un bipro ne ferait
pas de mal. Mais bon, moi ce que j'en dis...
--
les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!!
define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl
-+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-
De plus il me semble "injuste" - mais je m'en remettrai - qu'on fasse ce reproche à OpenBSD, un OS dont le but n'est pas de faire avec un serveur applicatif.
Faudra que je l'envoie à Theo, Niels et autres celle-là, ça va leur faire plaisir.
C'est quoi l'intérêt d'avoir des packages audités de Apache, BIND, Postfix, PGSQL, MySQL, PHP4, etc. si le but n'est pas de faire des serveurs applicatifs comme des serveurs Web, des serveurs SMTP, etc. ? Paraît même qu'il y en a qui en font des stations de travail...
Maintenant si on me dit qu'il faut vraiment un bipro pour faire tourner un fw sur OpenBSD moi je n'ai rien contre.
Jamais dit qu'il fallait un bipro pour faire un firewall, mais il me semble qu'il est des champs d'application d'OpenBSD où un bipro ne ferait pas de mal. Mais bon, moi ce que j'en dis...
--
les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!! define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl -+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-
Benjamin Pineau
Le 07 Jun 2004 13:38:50 GMT, F. Senault écrivais:
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
Ok ne nous emballons pas, je crois qu'il s'agit d'un quiproquos de lexique. La question du SMP n'était pas comprise dans mon acception de la portabilité (je parlai d'architecture, au sens même ou NetBSD est considéré comme plutôt portable bien que la branche stable ne soit pas encore SMP): OpenBSD tourne sur, par ex, un biproc x86, mais il n'utilise qu'un seul proc (sûr, c'est pas très interessant ;). Les deux points cités (ia64 et SMP) sont actuellement en intense developpement.
Le 07 Jun 2004 13:38:50 GMT,
F. Senault <fred@lacave.net> écrivais:
La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un
serveur moderne (et moins moderne), je sais pas ce que c'est.
Ok ne nous emballons pas, je crois qu'il s'agit d'un quiproquos de
lexique. La question du SMP n'était pas comprise dans mon acception
de la portabilité (je parlai d'architecture, au sens même ou NetBSD
est considéré comme plutôt portable bien que la branche stable ne soit
pas encore SMP): OpenBSD tourne sur, par ex, un biproc x86, mais il
n'utilise qu'un seul proc (sûr, c'est pas très interessant ;).
Les deux points cités (ia64 et SMP) sont actuellement en intense
developpement.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
Ok ne nous emballons pas, je crois qu'il s'agit d'un quiproquos de lexique. La question du SMP n'était pas comprise dans mon acception de la portabilité (je parlai d'architecture, au sens même ou NetBSD est considéré comme plutôt portable bien que la branche stable ne soit pas encore SMP): OpenBSD tourne sur, par ex, un biproc x86, mais il n'utilise qu'un seul proc (sûr, c'est pas très interessant ;). Les deux points cités (ia64 et SMP) sont actuellement en intense developpement.
talon
Benjamin Pineau wrote:
Le 07 Jun 2004 13:38:50 GMT, F. Senault écrivais:
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
Ok ne nous emballons pas, je crois qu'il s'agit d'un quiproquos de lexique. La question du SMP n'était pas comprise dans mon acception de la portabilité (je parlai d'architecture, au sens même ou NetBSD est considéré comme plutôt portable bien que la branche stable ne soit pas encore SMP): OpenBSD tourne sur, par ex, un biproc x86, mais il n'utilise qu'un seul proc (sûr, c'est pas très interessant ;). Les deux points cités (ia64 et SMP) sont actuellement en intense developpement.
Oui mais comme il a fallu compter plusieurs années entre un système SMP plus ou moins fonctionnel et rééllement fonctionnel sous Linux et FreeBSD, ça remet à peu prés les choses aux calendes grecques pour Open, il me semble.
--
Michel TALON
Benjamin Pineau <ben@zouh.org> wrote:
Le 07 Jun 2004 13:38:50 GMT,
F. Senault <fred@lacave.net> écrivais:
La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un
serveur moderne (et moins moderne), je sais pas ce que c'est.
Ok ne nous emballons pas, je crois qu'il s'agit d'un quiproquos de
lexique. La question du SMP n'était pas comprise dans mon acception
de la portabilité (je parlai d'architecture, au sens même ou NetBSD
est considéré comme plutôt portable bien que la branche stable ne soit
pas encore SMP): OpenBSD tourne sur, par ex, un biproc x86, mais il
n'utilise qu'un seul proc (sûr, c'est pas très interessant ;).
Les deux points cités (ia64 et SMP) sont actuellement en intense
developpement.
Oui mais comme il a fallu compter plusieurs années entre un système
SMP plus ou moins fonctionnel et rééllement fonctionnel sous
Linux et FreeBSD, ça remet à peu prés les choses aux calendes grecques
pour Open, il me semble.
La portabilité ? j'ai l'impression que la désinformation a vite gagnée ce thread. Dites moi quelle architecture manque qui fasse objection au déploiment de cet OS sur de serveurs modernes.
Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un serveur moderne (et moins moderne), je sais pas ce que c'est.
Ok ne nous emballons pas, je crois qu'il s'agit d'un quiproquos de lexique. La question du SMP n'était pas comprise dans mon acception de la portabilité (je parlai d'architecture, au sens même ou NetBSD est considéré comme plutôt portable bien que la branche stable ne soit pas encore SMP): OpenBSD tourne sur, par ex, un biproc x86, mais il n'utilise qu'un seul proc (sûr, c'est pas très interessant ;). Les deux points cités (ia64 et SMP) sont actuellement en intense developpement.
Oui mais comme il a fallu compter plusieurs années entre un système SMP plus ou moins fonctionnel et rééllement fonctionnel sous Linux et FreeBSD, ça remet à peu prés les choses aux calendes grecques pour Open, il me semble.
--
Michel TALON
Benjamin Pineau
Le 07 Jun 2004 13:38:50 GMT,
Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence
Par rapport à la problématique que vous interessait si: ils sont très nombreux.
à rajouter du code non officiellement supporté, Open pert beaucoup de son intéret (code audité, etc...).
Au passage: les ports natifs ne sont pas non plus supportés (et beaucoup moins audités).
Le 07 Jun 2004 13:38:50 GMT,
Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence
Par rapport à la problématique que vous interessait si: ils sont très
nombreux.
à rajouter du code non officiellement supporté, Open pert beaucoup de
son intéret (code audité, etc...).
Au passage: les ports natifs ne sont pas non plus supportés (et beaucoup
moins audités).
Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence
Par rapport à la problématique que vous interessait si: ils sont très nombreux.
à rajouter du code non officiellement supporté, Open pert beaucoup de son intéret (code audité, etc...).
Au passage: les ports natifs ne sont pas non plus supportés (et beaucoup moins audités).
Benjamin Pineau
Le 07 Jun 2004 14:01:44 GMT, Cedric Blancher écrivais:
Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être discutée dans certains cas de figure. L'absence de support d'ALG comme FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin, pour une machine sur laquelle aucun port n'est ouvert...
Effectivement, le ftp est moins pratique (il faut passer par le proxy-ftp natif, quitte à utiliser la redirection transparente). L'interet d'un firewall sous pf (puisque l'objet est la comparaison avec Linux) peut néanmoins, selon les besoins, être réel (surtout si l'on omet les linux patch-o-matisés, moins audités/stables/...).
A mon sens, le premier avantage est la (toute récente) possibilité de faire des firewall redondant avec pfsync et carp (avec replication des tables d'états etc.) pour une très haute ha des routeurs/firewall (et sans fouler les brevets cisco sur vrrp). Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour gestion du traffic selon l'OS source, avec altq (pour le QoS), avec l'outil de filtrage de spam natif, algos de load-balancing pour la redirection, filtrage vraiment statefull d'IPv6, blindages des stacks IPs fragiles (modulate state, random-id, syn proxy), authentification, grammaire de mieux en mieux fichue, outil de test de syntaxe + changements atomiques, etc.
Dans d'autres cas Linux/netfilter présente des avantages (comme la possibilité de filtrage au niveau applicatif ou le NAT sur certains protos plus rares).
L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs applicatifs sécurisés, parce que les applications sont auditées, parce qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un bipro parce que mon Web a besoin de puissance de calcul, ben paf. Considérer que le bipro est un guizmo à la mode me semble clairement _très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me font travailler sur une autre plate-forme.
Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent moins pertinent.
Comme toujours en ce qui concerne le choix d'architecture, il n'y a pas une et une seule solution valable dans tout les cas. L'important est alors de connaître les choix possibles à un instant t. A ce titre les utilisateurs de fcos qui ne connaissaient pas l'existence d'autres systèmes robustes (que Linux ou Kerio, visiblement les plus populaires) pourraient être intéréssés par une telle discussion, en dépit des detours trollistiques ;)
Le 07 Jun 2004 14:01:44 GMT,
Cedric Blancher <blancher@cartel-securite.fr> écrivais:
Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être
discutée dans certains cas de figure. L'absence de support d'ALG comme
FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait
sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin,
pour une machine sur laquelle aucun port n'est ouvert...
Effectivement, le ftp est moins pratique (il faut passer par le
proxy-ftp natif, quitte à utiliser la redirection transparente).
L'interet d'un firewall sous pf (puisque l'objet est la comparaison
avec Linux) peut néanmoins, selon les besoins, être réel (surtout si
l'on omet les linux patch-o-matisés, moins audités/stables/...).
A mon sens, le premier avantage est la (toute récente) possibilité de
faire des firewall redondant avec pfsync et carp (avec replication des
tables d'états etc.) pour une très haute ha des routeurs/firewall (et
sans fouler les brevets cisco sur vrrp).
Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais
qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour
gestion du traffic selon l'OS source, avec altq (pour le QoS), avec l'outil
de filtrage de spam natif, algos de load-balancing pour la redirection,
filtrage vraiment statefull d'IPv6, blindages des stacks IPs fragiles
(modulate state, random-id, syn proxy), authentification, grammaire de
mieux en mieux fichue, outil de test de syntaxe + changements atomiques,
etc.
Dans d'autres cas Linux/netfilter présente des avantages (comme la
possibilité de filtrage au niveau applicatif ou le NAT sur certains
protos plus rares).
L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs
applicatifs sécurisés, parce que les applications sont auditées, parce
qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un
bipro parce que mon Web a besoin de puissance de calcul, ben paf.
Considérer que le bipro est un guizmo à la mode me semble clairement
_très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me
font travailler sur une autre plate-forme.
Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à
des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent moins
pertinent.
Comme toujours en ce qui concerne le choix d'architecture, il n'y a pas
une et une seule solution valable dans tout les cas. L'important est
alors de connaître les choix possibles à un instant t.
A ce titre les utilisateurs de fcos qui ne connaissaient pas l'existence
d'autres systèmes robustes (que Linux ou Kerio, visiblement les plus
populaires) pourraient être intéréssés par une telle discussion, en
dépit des detours trollistiques ;)
Le 07 Jun 2004 14:01:44 GMT, Cedric Blancher écrivais:
Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être discutée dans certains cas de figure. L'absence de support d'ALG comme FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin, pour une machine sur laquelle aucun port n'est ouvert...
Effectivement, le ftp est moins pratique (il faut passer par le proxy-ftp natif, quitte à utiliser la redirection transparente). L'interet d'un firewall sous pf (puisque l'objet est la comparaison avec Linux) peut néanmoins, selon les besoins, être réel (surtout si l'on omet les linux patch-o-matisés, moins audités/stables/...).
A mon sens, le premier avantage est la (toute récente) possibilité de faire des firewall redondant avec pfsync et carp (avec replication des tables d'états etc.) pour une très haute ha des routeurs/firewall (et sans fouler les brevets cisco sur vrrp). Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour gestion du traffic selon l'OS source, avec altq (pour le QoS), avec l'outil de filtrage de spam natif, algos de load-balancing pour la redirection, filtrage vraiment statefull d'IPv6, blindages des stacks IPs fragiles (modulate state, random-id, syn proxy), authentification, grammaire de mieux en mieux fichue, outil de test de syntaxe + changements atomiques, etc.
Dans d'autres cas Linux/netfilter présente des avantages (comme la possibilité de filtrage au niveau applicatif ou le NAT sur certains protos plus rares).
L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs applicatifs sécurisés, parce que les applications sont auditées, parce qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un bipro parce que mon Web a besoin de puissance de calcul, ben paf. Considérer que le bipro est un guizmo à la mode me semble clairement _très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me font travailler sur une autre plate-forme.
Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent moins pertinent.
Comme toujours en ce qui concerne le choix d'architecture, il n'y a pas une et une seule solution valable dans tout les cas. L'important est alors de connaître les choix possibles à un instant t. A ce titre les utilisateurs de fcos qui ne connaissaient pas l'existence d'autres systèmes robustes (que Linux ou Kerio, visiblement les plus populaires) pourraient être intéréssés par une telle discussion, en dépit des detours trollistiques ;)
Cedric Blancher
Le Tue, 08 Jun 2004 14:09:53 +0000, Benjamin Pineau a écrit :
A mon sens, le premier avantage est la (toute récente) possibilité de faire des firewall redondant avec pfsync et carp (avec replication des tables d'états etc.) pour une très haute ha des routeurs/firewall (et sans fouler les brevets cisco sur vrrp).
Cisco n'a pas de brevet sur VRRP, qui fait l'objet d'une RFC, mais sur HSRP. Sinon, pfsync/carp, c'est vraiment excellent. J'espère que les gars de Netfilter vont y jeter un coup d'oeil rapidement parce que leur projet à eux, non content d'être compliqué, n'a pas pondu le moindre code utilisable...
Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour gestion du traffic selon l'OS source
Done, cf. patch'o'matic.
avec altq (pour le QoS),
Linux possède une gestion de la QoS très efficace.
avec l'outil de filtrage de spam natif,
Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre de paquets.
algos de load-balancing pour la redirection,
Idem.
filtrage vraiment statefull d'IPv6,
Gros manque de Linux, clairement un gros manque. Et puis beaucoup de branlette intellectuelle pour mettre sur pied des usines à tout faire...
blindages des stacks IPs fragiles (modulate state, random-id, syn proxy),
Existe fous Linux. Pour les IDs random, Linux utilise l'approche ID=0 systématique qui donne les mêmes résultats.
authentification,
Oui, authpf, c'est super pratique.
grammaire de mieux en mieux fichue,
Question de goût, mais bon, c'est vrai que la syntaxe iptables suxe pas mal quand même.
outil de test de syntaxe + changements atomiques,
Dispo aussi.
Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent moins pertinent.
Tout à fait. À part faire tourner l'usine à gaz et la GUI qui va avec pour certains trucs commerciaux, aucun intérêt, tout le monde est d'accord je pense.
-- Il s'est sans doute laissé impressionner par les cris d'orfraie du quarteron de fufopithèques en furie. -+- MB in: Guide du Cabaliste Usenet - Bien configurer son MB -+-
Le Tue, 08 Jun 2004 14:09:53 +0000, Benjamin Pineau a écrit :
A mon sens, le premier avantage est la (toute récente) possibilité de
faire des firewall redondant avec pfsync et carp (avec replication des
tables d'états etc.) pour une très haute ha des routeurs/firewall (et
sans fouler les brevets cisco sur vrrp).
Cisco n'a pas de brevet sur VRRP, qui fait l'objet d'une RFC, mais sur
HSRP.
Sinon, pfsync/carp, c'est vraiment excellent. J'espère que les gars de
Netfilter vont y jeter un coup d'oeil rapidement parce que leur projet à
eux, non content d'être compliqué, n'a pas pondu le moindre code
utilisable...
Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais
qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour
gestion du traffic selon l'OS source
Done, cf. patch'o'matic.
avec altq (pour le QoS),
Linux possède une gestion de la QoS très efficace.
avec l'outil de filtrage de spam natif,
Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre
de paquets.
algos de load-balancing pour la redirection,
Idem.
filtrage vraiment statefull d'IPv6,
Gros manque de Linux, clairement un gros manque. Et puis beaucoup de
branlette intellectuelle pour mettre sur pied des usines à tout faire...
blindages des stacks IPs fragiles (modulate state, random-id, syn proxy),
Existe fous Linux. Pour les IDs random, Linux utilise l'approche ID=0
systématique qui donne les mêmes résultats.
authentification,
Oui, authpf, c'est super pratique.
grammaire de mieux en mieux fichue,
Question de goût, mais bon, c'est vrai que la syntaxe iptables suxe pas
mal quand même.
outil de test de syntaxe + changements atomiques,
Dispo aussi.
Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à
des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent moins
pertinent.
Tout à fait.
À part faire tourner l'usine à gaz et la GUI qui va avec pour certains
trucs commerciaux, aucun intérêt, tout le monde est d'accord je pense.
--
Il s'est sans doute laissé impressionner par les cris d'orfraie du
quarteron de fufopithèques en furie.
-+- MB in: Guide du Cabaliste Usenet - Bien configurer son MB -+-
Le Tue, 08 Jun 2004 14:09:53 +0000, Benjamin Pineau a écrit :
A mon sens, le premier avantage est la (toute récente) possibilité de faire des firewall redondant avec pfsync et carp (avec replication des tables d'états etc.) pour une très haute ha des routeurs/firewall (et sans fouler les brevets cisco sur vrrp).
Cisco n'a pas de brevet sur VRRP, qui fait l'objet d'une RFC, mais sur HSRP. Sinon, pfsync/carp, c'est vraiment excellent. J'espère que les gars de Netfilter vont y jeter un coup d'oeil rapidement parce que leur projet à eux, non content d'être compliqué, n'a pas pondu le moindre code utilisable...
Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour gestion du traffic selon l'OS source
Done, cf. patch'o'matic.
avec altq (pour le QoS),
Linux possède une gestion de la QoS très efficace.
avec l'outil de filtrage de spam natif,
Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre de paquets.
algos de load-balancing pour la redirection,
Idem.
filtrage vraiment statefull d'IPv6,
Gros manque de Linux, clairement un gros manque. Et puis beaucoup de branlette intellectuelle pour mettre sur pied des usines à tout faire...
blindages des stacks IPs fragiles (modulate state, random-id, syn proxy),
Existe fous Linux. Pour les IDs random, Linux utilise l'approche ID=0 systématique qui donne les mêmes résultats.
authentification,
Oui, authpf, c'est super pratique.
grammaire de mieux en mieux fichue,
Question de goût, mais bon, c'est vrai que la syntaxe iptables suxe pas mal quand même.
outil de test de syntaxe + changements atomiques,
Dispo aussi.
Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent moins pertinent.
Tout à fait. À part faire tourner l'usine à gaz et la GUI qui va avec pour certains trucs commerciaux, aucun intérêt, tout le monde est d'accord je pense.
-- Il s'est sans doute laissé impressionner par les cris d'orfraie du quarteron de fufopithèques en furie. -+- MB in: Guide du Cabaliste Usenet - Bien configurer son MB -+-
