Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est Emmanuel> en branche stable pour vax et alpha depuis belle lurette.
Euh, le smp n'est pas implémenté de la même manière sur toutes les archis, genre services md spécifiques à chaque archi et support mi pour les fonctionnalités générales ?
Si, si. Et justement la qualité du code md n'est pas la même d'une plate-forme à l'autre, ce qui explique les différences de stabilité, si l'on ne tient pas compte des bugs mi.
Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est
Emmanuel> en branche stable pour vax et alpha depuis belle lurette.
Euh, le smp n'est pas implémenté de la même manière sur toutes les
archis, genre services md spécifiques à chaque archi et support mi pour
les fonctionnalités générales ?
Si, si. Et justement la qualité du code md n'est pas la même d'une
plate-forme à l'autre, ce qui explique les différences de stabilité, si
l'on ne tient pas compte des bugs mi.
Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est Emmanuel> en branche stable pour vax et alpha depuis belle lurette.
Euh, le smp n'est pas implémenté de la même manière sur toutes les archis, genre services md spécifiques à chaque archi et support mi pour les fonctionnalités générales ?
Si, si. Et justement la qualité du code md n'est pas la même d'une plate-forme à l'autre, ce qui explique les différences de stabilité, si l'on ne tient pas compte des bugs mi.
Benjamin Pineau
Le 09 Jun 2004 00:07:15 GMT, db écrivais:
Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre de paquets. Ce serait même une hérésie : traiter du contenu au niveau du noyau. Mais
gageons que nous en arriverons toute de même là, dans un souci de faire tout et officiellement pour des << petits >> besoins.
Encore une fois, il ne s'agit pas de filtrer du contenu au niveau du fw. Je crois par contre que les outils de filtrages gagnent a offrir des interfaces propres pour "dialoguer" avec le userland. Et reciproquement, les outils userland à savoir causer au firewall.
Iptables (mark, QUEUE, ULOG, netlink ...) et pf (tables et anchor, logs au format pcap, interface virtuelle pour les logs ...) sont au point sur cet aspect.
J'ai plutôt l'impression que les outils userland sachant interagir _proprement_ avec le firewall sont moins nombreux qu'il pourraient être (antivirus, proxys, ids, polices ipsec/isakmp, authentification, filtres divers etc.) pour un secteur si prometeur.
On s'en remet plus volontier aux bricolages en shell script, ou on joue avec la redirection/duplication de traffic (pas très beau non plus) pour éviter de coller des interfaces en promisc...
Bref, les initiatives userland visant une integration de qualité avec le firewall méritent, amha, toute notre attention.
De quoi irriguer ce thread d'un nouvau thème non ? ;) d'une certaine manière ça rejoint le thread plus bas sur les firewalls personels, et même le sujet initial de ce thread sur l'inconstance des patchs (vs l' intégration de qualité ?).
Un truc intéressant (enfin !) dans iptables et vous me direz si cela existe dans ipf c'est la capacité de mémoirisation du filtre à savoir un test établi n'est vrai que si (en plus du test) l'adresse source, destination (et peut-être à l'avenir les ports) a déjà été rencontrée n fois au cours des s secondes passées.
A ma connaissance ça n'existe pas sous ipf ni sous pf (note: ipf != pf). Pour pf, et dans certains cas seulement, on peut obtenir un résultat approchant en jouant avec les options limit, timeout et/out tag mais bon, c'est assez pauvre au regard de cet objectif.
Le 09 Jun 2004 00:07:15 GMT,
db <nospam@spam.int> écrivais:
Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre
de paquets.
Ce serait même une hérésie : traiter du contenu au niveau du noyau. Mais
gageons que nous en arriverons toute de même là, dans un souci de faire
tout et officiellement pour des << petits >> besoins.
Encore une fois, il ne s'agit pas de filtrer du contenu au niveau du fw.
Je crois par contre que les outils de filtrages gagnent a offrir des
interfaces propres pour "dialoguer" avec le userland. Et reciproquement,
les outils userland à savoir causer au firewall.
Iptables (mark, QUEUE, ULOG, netlink ...) et pf (tables et anchor, logs
au format pcap, interface virtuelle pour les logs ...) sont au point sur
cet aspect.
J'ai plutôt l'impression que les outils userland sachant interagir
_proprement_ avec le firewall sont moins nombreux qu'il pourraient être
(antivirus, proxys, ids, polices ipsec/isakmp, authentification, filtres
divers etc.) pour un secteur si prometeur.
On s'en remet plus volontier aux bricolages en shell script, ou on joue
avec la redirection/duplication de traffic (pas très beau non plus) pour
éviter de coller des interfaces en promisc...
Bref, les initiatives userland visant une integration de qualité avec le
firewall méritent, amha, toute notre attention.
De quoi irriguer ce thread d'un nouvau thème non ? ;) d'une certaine
manière ça rejoint le thread plus bas sur les firewalls personels, et
même le sujet initial de ce thread sur l'inconstance des patchs (vs l'
intégration de qualité ?).
Un truc intéressant (enfin !) dans iptables et vous me direz si cela existe
dans ipf c'est la capacité de mémoirisation du filtre à savoir un test
établi n'est vrai que si (en plus du test) l'adresse source, destination
(et peut-être à l'avenir les ports) a déjà été rencontrée n fois au cours
des s secondes passées.
A ma connaissance ça n'existe pas sous ipf ni sous pf (note: ipf != pf).
Pour pf, et dans certains cas seulement, on peut obtenir un résultat
approchant en jouant avec les options limit, timeout et/out tag mais
bon, c'est assez pauvre au regard de cet objectif.
Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre de paquets. Ce serait même une hérésie : traiter du contenu au niveau du noyau. Mais
gageons que nous en arriverons toute de même là, dans un souci de faire tout et officiellement pour des << petits >> besoins.
Encore une fois, il ne s'agit pas de filtrer du contenu au niveau du fw. Je crois par contre que les outils de filtrages gagnent a offrir des interfaces propres pour "dialoguer" avec le userland. Et reciproquement, les outils userland à savoir causer au firewall.
Iptables (mark, QUEUE, ULOG, netlink ...) et pf (tables et anchor, logs au format pcap, interface virtuelle pour les logs ...) sont au point sur cet aspect.
J'ai plutôt l'impression que les outils userland sachant interagir _proprement_ avec le firewall sont moins nombreux qu'il pourraient être (antivirus, proxys, ids, polices ipsec/isakmp, authentification, filtres divers etc.) pour un secteur si prometeur.
On s'en remet plus volontier aux bricolages en shell script, ou on joue avec la redirection/duplication de traffic (pas très beau non plus) pour éviter de coller des interfaces en promisc...
Bref, les initiatives userland visant une integration de qualité avec le firewall méritent, amha, toute notre attention.
De quoi irriguer ce thread d'un nouvau thème non ? ;) d'une certaine manière ça rejoint le thread plus bas sur les firewalls personels, et même le sujet initial de ce thread sur l'inconstance des patchs (vs l' intégration de qualité ?).
Un truc intéressant (enfin !) dans iptables et vous me direz si cela existe dans ipf c'est la capacité de mémoirisation du filtre à savoir un test établi n'est vrai que si (en plus du test) l'adresse source, destination (et peut-être à l'avenir les ports) a déjà été rencontrée n fois au cours des s secondes passées.
A ma connaissance ça n'existe pas sous ipf ni sous pf (note: ipf != pf). Pour pf, et dans certains cas seulement, on peut obtenir un résultat approchant en jouant avec les options limit, timeout et/out tag mais bon, c'est assez pauvre au regard de cet objectif.
Arnaud Launay
Le Wed, 9 Jun 2004 07:20:02 +0200, Emmanuel Dreyfus écrivit:
Et plus sérieusement, je n'ai pas vu tous les correctifs vfs et lockmgr de pk passer en stable... pourtant, ils sont nécessaires pour que le qualificatif de stable soit mérité. Question de point de vue. Pour moi c'est stable quand ca ne
plante pas :)
Et quand on n'a pas besoin de réinstaller pour mettre à jour.
Arnaud.
Le Wed, 9 Jun 2004 07:20:02 +0200, Emmanuel Dreyfus écrivit:
Et plus sérieusement, je n'ai pas vu tous les correctifs vfs et lockmgr
de pk passer en stable... pourtant, ils sont nécessaires pour que le
qualificatif de stable soit mérité.
Question de point de vue. Pour moi c'est stable quand ca ne
plante pas :)
Et quand on n'a pas besoin de réinstaller pour mettre à jour.
Le Wed, 9 Jun 2004 07:20:02 +0200, Emmanuel Dreyfus écrivit:
Et plus sérieusement, je n'ai pas vu tous les correctifs vfs et lockmgr de pk passer en stable... pourtant, ils sont nécessaires pour que le qualificatif de stable soit mérité. Question de point de vue. Pour moi c'est stable quand ca ne
plante pas :)
Et quand on n'a pas besoin de réinstaller pour mettre à jour.
Arnaud.
Benjamin Pineau
Le 09 Jun 2004 05:15:05 GMT, Cedric Blancher écrivais:
Tu as un bon document sur la gestion de la QoS via les marques dans le LARTC et sur le site L7filter (c'est pas du pom ;))).
Tient profitons de l'occasion pour signaler au passage un autre outil de filtrage offrant une solution QoS basique mais vraiment très simple et agréable à utiliser: ipfw (dummynet). A ma connaissance, seulement pour FreeBSD pour les versions récentes.
Avec la cible QUEUE, on doit pouvoir faire pas mal de trucs dans ce genre.
Effectivement, je viens de trouver spamcannibal qui sait faire ça.
En matière de round robbin, voir la cible NTH.
Je viens de regarder la doc ; on dirait qu'il manque un moyen d'assurer la constance nécessaire pour les protocoles applicatifs à état (eg. sessions http), par exemple en s'assurant qu'une ip source donnée aura toujours la même destination (source-hash sous pf). Tu confirme ? Idem d'ailleur pour les états layer 4. J'imagine qu'on doit pouvoir obtenir ça en jouant avec 'mark' mais ... bof.
Pour les changements atomiques : iptables-restore.
Oui bien sûr. Mais pas précisément commode pour modifier un ruleset avant de le recharger "atomiquement" il me semble. Dans mon cas, j'insère ou modifie d'abord les nouvelles règles, une à une, dans le firewall actif (pas très atomique donc), puis iptables-save. Le restore ne me sert qu'en de rares occasion. Je suis sûr que ce n'est pas la meilleure façon de s'y prendre, donc si vous avez des suggestions/best-practices pour les modifications de firewalls sous netfilter, je suis preneur (en excluant la modification manuelle des dumps d'iptables-save, faut pas déconner ;).
Pour les tests de ruleset, l'équipe de développement de Netfilter a produit un outil de test userspace d'un fremawork Netfilter. Ça permet non seulement de tester des rulesets, mais ça permet aussi de tester l'intégration de nouvelles extensions (en fait, c'est surtout fait pour ça). Cf. les archives de la ML de dev, j'ai la flemme de chercher ;)
Ok bin je vais tester ça. Ca pourrait m'epargner un ulcère ;)
Le 09 Jun 2004 05:15:05 GMT,
Cedric Blancher <blancher@cartel-securite.fr> écrivais:
Tu as un bon document sur la gestion de la QoS via les marques dans le
LARTC et sur le site L7filter (c'est pas du pom ;))).
Tient profitons de l'occasion pour signaler au passage un autre outil de
filtrage offrant une solution QoS basique mais vraiment très simple et
agréable à utiliser: ipfw (dummynet). A ma connaissance, seulement pour
FreeBSD pour les versions récentes.
Avec la cible QUEUE, on doit pouvoir faire pas mal de trucs dans ce genre.
Effectivement, je viens de trouver spamcannibal qui sait faire ça.
En matière de round robbin, voir la cible NTH.
Je viens de regarder la doc ; on dirait qu'il manque un moyen d'assurer
la constance nécessaire pour les protocoles applicatifs à état (eg.
sessions http), par exemple en s'assurant qu'une ip source donnée aura
toujours la même destination (source-hash sous pf). Tu confirme ?
Idem d'ailleur pour les états layer 4. J'imagine qu'on doit pouvoir
obtenir ça en jouant avec 'mark' mais ... bof.
Pour les changements atomiques : iptables-restore.
Oui bien sûr. Mais pas précisément commode pour modifier un ruleset
avant de le recharger "atomiquement" il me semble.
Dans mon cas, j'insère ou modifie d'abord les nouvelles règles, une à
une, dans le firewall actif (pas très atomique donc), puis iptables-save.
Le restore ne me sert qu'en de rares occasion.
Je suis sûr que ce n'est pas la meilleure façon de s'y prendre, donc si
vous avez des suggestions/best-practices pour les modifications de
firewalls sous netfilter, je suis preneur (en excluant la modification
manuelle des dumps d'iptables-save, faut pas déconner ;).
Pour les tests de ruleset, l'équipe de développement de Netfilter a
produit un outil de test userspace d'un fremawork Netfilter. Ça permet
non seulement de tester des rulesets, mais ça permet aussi de tester
l'intégration de nouvelles extensions (en fait, c'est surtout fait pour
ça). Cf. les archives de la ML de dev, j'ai la flemme de chercher ;)
Ok bin je vais tester ça. Ca pourrait m'epargner un ulcère ;)
Le 09 Jun 2004 05:15:05 GMT, Cedric Blancher écrivais:
Tu as un bon document sur la gestion de la QoS via les marques dans le LARTC et sur le site L7filter (c'est pas du pom ;))).
Tient profitons de l'occasion pour signaler au passage un autre outil de filtrage offrant une solution QoS basique mais vraiment très simple et agréable à utiliser: ipfw (dummynet). A ma connaissance, seulement pour FreeBSD pour les versions récentes.
Avec la cible QUEUE, on doit pouvoir faire pas mal de trucs dans ce genre.
Effectivement, je viens de trouver spamcannibal qui sait faire ça.
En matière de round robbin, voir la cible NTH.
Je viens de regarder la doc ; on dirait qu'il manque un moyen d'assurer la constance nécessaire pour les protocoles applicatifs à état (eg. sessions http), par exemple en s'assurant qu'une ip source donnée aura toujours la même destination (source-hash sous pf). Tu confirme ? Idem d'ailleur pour les états layer 4. J'imagine qu'on doit pouvoir obtenir ça en jouant avec 'mark' mais ... bof.
Pour les changements atomiques : iptables-restore.
Oui bien sûr. Mais pas précisément commode pour modifier un ruleset avant de le recharger "atomiquement" il me semble. Dans mon cas, j'insère ou modifie d'abord les nouvelles règles, une à une, dans le firewall actif (pas très atomique donc), puis iptables-save. Le restore ne me sert qu'en de rares occasion. Je suis sûr que ce n'est pas la meilleure façon de s'y prendre, donc si vous avez des suggestions/best-practices pour les modifications de firewalls sous netfilter, je suis preneur (en excluant la modification manuelle des dumps d'iptables-save, faut pas déconner ;).
Pour les tests de ruleset, l'équipe de développement de Netfilter a produit un outil de test userspace d'un fremawork Netfilter. Ça permet non seulement de tester des rulesets, mais ça permet aussi de tester l'intégration de nouvelles extensions (en fait, c'est surtout fait pour ça). Cf. les archives de la ML de dev, j'ai la flemme de chercher ;)
Ok bin je vais tester ça. Ca pourrait m'epargner un ulcère ;)
Djoume SALVETTI
Comme il semble que ce soit la fin : http://www.grsecurity.org/ (à moins d'un effet d'annonce)
Le projet semble reparti :
http://grsecurity.net/news.php
-- Djoumé SALVETTI
Comme il semble que ce soit la fin :
http://www.grsecurity.org/
(à moins d'un effet d'annonce)
Comme il semble que ce soit la fin : http://www.grsecurity.org/ (à moins d'un effet d'annonce)
Le projet semble reparti :
http://grsecurity.net/news.php
-- Djoumé SALVETTI
manu
Miod Vallat wrote:
Ca marche bien aussi sous sparc ! Sparc étant l'architecture qui va détrôner le PC dans les années à venir, il ne faut pas l'oublier ;-) Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre le fait. C'est pas encore une release, mais c'est déjà plus -current.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat <miod@online.fr> wrote:
Ca marche bien aussi sous sparc ! Sparc étant l'architecture qui va
détrôner le PC dans les années à venir, il ne faut pas l'oublier ;-)
Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre
le fait. C'est pas encore une release, mais c'est déjà plus -current.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Ca marche bien aussi sous sparc ! Sparc étant l'architecture qui va détrôner le PC dans les années à venir, il ne faut pas l'oublier ;-) Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre le fait. C'est pas encore une release, mais c'est déjà plus -current.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu
Eric Masson wrote:
Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est Emmanuel> en branche stable pour vax et alpha depuis belle lurette.
Euh, le smp n'est pas implémenté de la même manière sur toutes les archis, genre services md spécifiques à chaque archi et support mi pour les fonctionnalités générales ?
Ben si. Au moment de la sortie de 1.6, les morceaux machines dependants n'etaient au point que sur vax et alpha.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Eric Masson <emss@free.fr> wrote:
Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est
Emmanuel> en branche stable pour vax et alpha depuis belle lurette.
Euh, le smp n'est pas implémenté de la même manière sur toutes les
archis, genre services md spécifiques à chaque archi et support mi pour
les fonctionnalités générales ?
Ben si. Au moment de la sortie de 1.6, les morceaux machines dependants
n'etaient au point que sur vax et alpha.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est Emmanuel> en branche stable pour vax et alpha depuis belle lurette.
Euh, le smp n'est pas implémenté de la même manière sur toutes les archis, genre services md spécifiques à chaque archi et support mi pour les fonctionnalités générales ?
Ben si. Au moment de la sortie de 1.6, les morceaux machines dependants n'etaient au point que sur vax et alpha.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Thierry Boudet
On 2004-06-07, Miod Vallat wrote:
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que ton "constateur (cTMr)" nécessite un upgrade, voire un remplacement par une technologie plus appropriée.
-- Bien plus zen que le Contrat Social, et ouvert à tous: http://tth.vaboofer.com/Cette/cafe_social.html
On 2004-06-07, Miod Vallat <miod@online.fr> wrote:
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que
ton "constateur (cTMr)" nécessite un upgrade, voire un
remplacement par une technologie plus appropriée.
--
Bien plus zen que le Contrat Social, et ouvert à tous:
http://tth.vaboofer.com/Cette/cafe_social.html
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que ton "constateur (cTMr)" nécessite un upgrade, voire un remplacement par une technologie plus appropriée.
-- Bien plus zen que le Contrat Social, et ouvert à tous: http://tth.vaboofer.com/Cette/cafe_social.html
Miod Vallat
Il était question de la branche 1.6 stable, dans laquelle le port sparc n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre le fait. C'est pas encore une release, mais c'est déjà plus -current.
Oui mais 2.0 est nettement moins -stable pour le moment.
Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre
le fait. C'est pas encore une release, mais c'est déjà plus -current.
Oui mais 2.0 est nettement moins -stable pour le moment.
Il était question de la branche 1.6 stable, dans laquelle le port sparc n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre le fait. C'est pas encore une release, mais c'est déjà plus -current.
Oui mais 2.0 est nettement moins -stable pour le moment.
Miod Vallat
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que ton "constateur (cTMr)" nécessite un upgrade, voire un remplacement par une technologie plus appropriée.
Non, nous nous contenterons de le supplicier en le forçant à coder le support COMPAT_MIOD dans NetBSD/brain.
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que
ton "constateur (cTMr)" nécessite un upgrade, voire un
remplacement par une technologie plus appropriée.
Non, nous nous contenterons de le supplicier en le forçant à coder le
support COMPAT_MIOD dans NetBSD/brain.
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que ton "constateur (cTMr)" nécessite un upgrade, voire un remplacement par une technologie plus appropriée.
Non, nous nous contenterons de le supplicier en le forçant à coder le support COMPAT_MIOD dans NetBSD/brain.
