[Q] quelle version de Freebsd pour un 'petit' site WEB ?
29 réponses
Ronald Van Assche
Quelle peut être la release de FreeBSD[1] la plus stable/efficace en
charge pour le bouzin suivant :
Carte mère Bi Pro Xeon 2.8, 2 Go de ram.
Serveur Apache + perl4 , site dynamique qui sert[2] entre autre des
fichiers de grandes tailles (fichiers zip etc..) via NFS.
Disques locaux : 3* IBM SCSI-UW3 10Ktour
il y'a entre 500 et 1200 sockets http d'ouverts en permanence...
Et on trouve quelques dizaines d'attaques' par des script KIddIes et
autres z0mBi3z sous Windows verolées par jours (ssh, ftp :o) )
la 5.3 est elle très stable sur du bi-pro Intel ?
elle semble entre autre,comporter des ajouts à 'ipfw' utiles.
Merci.
[1] Freebsd only, désolé pour les autres.
[2] je ne peux pas donner trop de détails , NDA etc...
J'ai presque le meme: BiPro Xeon 2.0 , 1 Go de RAM, il marche pas trop mal sous FreeBSD 5.x depuis la 5.1. J'ai eu de gros problemes a un moment ou j'ai utilisé SCHED_ULE, mais utiliser FreeBSD 5.3-BETA2 sur un serveur n'étant sans doute pas une bonne idée... Depuis que je suis repassé a SCHED_4BSD, je n'ai aucun probleme.
Serveur Apache + perl4 , site dynamique qui sert[2] entre autre des fichiers de grandes tailles (fichiers zip etc..) via NFS.
Il utilise NFS (en tant que client) mais vers un serveur Windows, et ca marchouille quand le serveur Windows marche. Note que ca marchouille mieux avec le client FreeBSD que le client Linux...
Et on trouve quelques dizaines d'attaques' par des script KIddIes et autres z0mBi3z sous Windows verolées par jours (ssh, ftp :o) )
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je pense que ca ne change rien.
Voila, la date du dernier reboot pour mettre a jour le noyau.
elle semble entre autre,comporter des ajouts à 'ipfw' utiles.
Et aussi pf, le firewall d'OpenBSD qui me semble plus performant, j'ai peut-etre une impression eronnée, mais c'est aussi plus "facile" de faire du nat avec pf.
-- Nicolas Le Scouarnec
Carte mère Bi Pro Xeon 2.8, 2 Go de ram.
J'ai presque le meme: BiPro Xeon 2.0 , 1 Go de RAM, il marche pas trop
mal sous FreeBSD 5.x depuis la 5.1. J'ai eu de gros problemes a un
moment ou j'ai utilisé SCHED_ULE, mais utiliser FreeBSD 5.3-BETA2 sur
un serveur n'étant sans doute pas une bonne idée... Depuis que je suis
repassé a SCHED_4BSD, je n'ai aucun probleme.
Serveur Apache + perl4 , site dynamique qui sert[2] entre autre des
fichiers de grandes tailles (fichiers zip etc..) via NFS.
Il utilise NFS (en tant que client) mais vers un serveur Windows, et ca
marchouille quand le serveur Windows marche. Note que ca marchouille
mieux avec le client FreeBSD que le client Linux...
Et on trouve quelques dizaines d'attaques' par des script KIddIes et
autres z0mBi3z sous Windows verolées par jours (ssh, ftp :o) )
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je
pense que ca ne change rien.
Voila, la date du dernier reboot pour mettre a jour le noyau.
elle semble entre autre,comporter des ajouts à 'ipfw' utiles.
Et aussi pf, le firewall d'OpenBSD qui me semble plus performant, j'ai
peut-etre une impression eronnée, mais c'est aussi plus "facile" de
faire du nat avec pf.
J'ai presque le meme: BiPro Xeon 2.0 , 1 Go de RAM, il marche pas trop mal sous FreeBSD 5.x depuis la 5.1. J'ai eu de gros problemes a un moment ou j'ai utilisé SCHED_ULE, mais utiliser FreeBSD 5.3-BETA2 sur un serveur n'étant sans doute pas une bonne idée... Depuis que je suis repassé a SCHED_4BSD, je n'ai aucun probleme.
Serveur Apache + perl4 , site dynamique qui sert[2] entre autre des fichiers de grandes tailles (fichiers zip etc..) via NFS.
Il utilise NFS (en tant que client) mais vers un serveur Windows, et ca marchouille quand le serveur Windows marche. Note que ca marchouille mieux avec le client FreeBSD que le client Linux...
Et on trouve quelques dizaines d'attaques' par des script KIddIes et autres z0mBi3z sous Windows verolées par jours (ssh, ftp :o) )
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je pense que ca ne change rien.
Voila, la date du dernier reboot pour mettre a jour le noyau.
elle semble entre autre,comporter des ajouts à 'ipfw' utiles.
Et aussi pf, le firewall d'OpenBSD qui me semble plus performant, j'ai peut-etre une impression eronnée, mais c'est aussi plus "facile" de faire du nat avec pf.
-- Nicolas Le Scouarnec
Ronald Van Assche
Nicolas Le Scouarnec wrote:
J'ai presque le meme: BiPro Xeon 2.0 , 1 Go de RAM, il marche pas trop mal sous FreeBSD 5.x depuis la 5.1. J'ai eu de gros problemes a un moment ou j'ai utilisé SCHED_ULE, mais utiliser FreeBSD 5.3-BETA2 sur un serveur n'étant sans doute pas une bonne idée... Depuis que je suis repassé a SCHED_4BSD, je n'ai aucun probleme.
oui, le peu que j'ai lu ici ou via google sur ce SCHED_ULE ne m'a pas
rassuré, mais a première vue ce n'est pas en standart dans le kernel. Et d'après ce que j'ai lu, plus on avance dans le x de 5.x plus les performances en SMP sont bonnes. Il y'a quelques benchs qui trainent, mais comme toujours les résultats sont à lire avec attention, surtout quand ils ont été fait avec des versions 5.1 :o)
Il utilise NFS (en tant que client) mais vers un serveur Windows, et ca marchouille quand le serveur Windows marche. Note que ca marchouille mieux avec le client FreeBSD que le client Linux...
Vers un serveur Windows : ouah, ça veut dire que le client FreeBSD est
solide ;o) Dans mon cas, le serveur NFS est lui aussi sous FreeBSD et fonctionne déja correctement.
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je pense que ca ne change rien.
Oui, d'ailleurs il me semble qu'ipfw contient des nouveaux trucs depuis la 4.x et que cela permet de s'occuper mieux de ces zombies.
Et aussi pf, le firewall d'OpenBSD qui me semble plus performant, j'ai peut-etre une impression eronnée, mais c'est aussi plus "facile" de faire du nat avec pf.
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun sur une passerelle de réseau local : interdire aux Win* d'aller sur internet...
-- --------------------------------------------------- Rva, http://www.neuneu.org Neu^2 partout et pas ceux qu'on croit.
Nicolas Le Scouarnec wrote:
J'ai presque le meme: BiPro Xeon 2.0 , 1 Go de RAM, il marche pas trop
mal sous FreeBSD 5.x depuis la 5.1. J'ai eu de gros problemes a un
moment ou j'ai utilisé SCHED_ULE, mais utiliser FreeBSD 5.3-BETA2 sur
un serveur n'étant sans doute pas une bonne idée... Depuis que je suis
repassé a SCHED_4BSD, je n'ai aucun probleme.
oui, le peu que j'ai lu ici ou via google sur ce SCHED_ULE ne m'a pas
rassuré, mais a première vue ce n'est pas en standart dans le kernel.
Et d'après ce que j'ai lu, plus on avance dans le x de 5.x plus les
performances en SMP sont bonnes.
Il y'a quelques benchs qui trainent, mais comme toujours les résultats
sont à lire avec attention, surtout quand ils ont été fait avec des
versions 5.1 :o)
Il utilise NFS (en tant que client) mais vers un serveur Windows, et ca
marchouille quand le serveur Windows marche. Note que ca marchouille
mieux avec le client FreeBSD que le client Linux...
Vers un serveur Windows : ouah, ça veut dire que le client FreeBSD est
solide ;o) Dans mon cas, le serveur NFS est lui aussi sous FreeBSD et
fonctionne déja correctement.
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je
pense que ca ne change rien.
Oui, d'ailleurs il me semble qu'ipfw contient des nouveaux trucs depuis
la 4.x et que cela permet de s'occuper mieux de ces zombies.
Et aussi pf, le firewall d'OpenBSD qui me semble plus performant, j'ai
peut-etre une impression eronnée, mais c'est aussi plus "facile" de
faire du nat avec pf.
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun
sur une passerelle de réseau local : interdire aux Win* d'aller sur
internet...
--
---------------------------------------------------
Rva, http://www.neuneu.org
Neu^2 partout et pas ceux qu'on croit.
J'ai presque le meme: BiPro Xeon 2.0 , 1 Go de RAM, il marche pas trop mal sous FreeBSD 5.x depuis la 5.1. J'ai eu de gros problemes a un moment ou j'ai utilisé SCHED_ULE, mais utiliser FreeBSD 5.3-BETA2 sur un serveur n'étant sans doute pas une bonne idée... Depuis que je suis repassé a SCHED_4BSD, je n'ai aucun probleme.
oui, le peu que j'ai lu ici ou via google sur ce SCHED_ULE ne m'a pas
rassuré, mais a première vue ce n'est pas en standart dans le kernel. Et d'après ce que j'ai lu, plus on avance dans le x de 5.x plus les performances en SMP sont bonnes. Il y'a quelques benchs qui trainent, mais comme toujours les résultats sont à lire avec attention, surtout quand ils ont été fait avec des versions 5.1 :o)
Il utilise NFS (en tant que client) mais vers un serveur Windows, et ca marchouille quand le serveur Windows marche. Note que ca marchouille mieux avec le client FreeBSD que le client Linux...
Vers un serveur Windows : ouah, ça veut dire que le client FreeBSD est
solide ;o) Dans mon cas, le serveur NFS est lui aussi sous FreeBSD et fonctionne déja correctement.
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je pense que ca ne change rien.
Oui, d'ailleurs il me semble qu'ipfw contient des nouveaux trucs depuis la 4.x et que cela permet de s'occuper mieux de ces zombies.
Et aussi pf, le firewall d'OpenBSD qui me semble plus performant, j'ai peut-etre une impression eronnée, mais c'est aussi plus "facile" de faire du nat avec pf.
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun sur une passerelle de réseau local : interdire aux Win* d'aller sur internet...
-- --------------------------------------------------- Rva, http://www.neuneu.org Neu^2 partout et pas ceux qu'on croit.
Nicolas Le Scouarnec
oui, le peu que j'ai lu ici ou via google sur ce SCHED_ULE ne m'a pas rassuré, mais a première vue ce n'est pas en standart dans le kernel.
Il est desactivé, pour que personne n'essaye de l'utiliser.
Et d'après ce que j'ai lu, plus on avance dans le x de 5.x plus les performances en SMP sont bonnes. Il y'a quelques benchs qui trainent, mais comme toujours les résultats sont à lire avec attention, surtout quand ils ont été fait avec des versions 5.1 :o)
Les perfs en SMP sont sensées devenir bonne avec SCHED_ULE justement, sauf que SCHED_ULE s'il marche bien en monoproc plante de manière très systématique en SMP :-) . Enfin, après la "cata" juste avant le lancement de 5.3, je pense qu'ils vont faire très attention...
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je pense que ca ne change rien. Oui, d'ailleurs il me semble qu'ipfw contient des nouveaux trucs depuis
la 4.x et que cela permet de s'occuper mieux de ces zombies.
Aussi, mais tant qu'a refaire mon script de firewall, j'ai pris pf pour pouvoir faire du nat sans utiliser natd.
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf' faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun sur une passerelle de réseau local : interdire aux Win* d'aller sur
:-)
-- Nicolas Le Scouarnec
oui, le peu que j'ai lu ici ou via google sur ce SCHED_ULE ne m'a pas
rassuré, mais a première vue ce n'est pas en standart dans le kernel.
Il est desactivé, pour que personne n'essaye de l'utiliser.
Et d'après ce que j'ai lu, plus on avance dans le x de 5.x plus les
performances en SMP sont bonnes.
Il y'a quelques benchs qui trainent, mais comme toujours les résultats
sont à lire avec attention, surtout quand ils ont été fait avec des
versions 5.1 :o)
Les perfs en SMP sont sensées devenir bonne avec SCHED_ULE justement,
sauf que SCHED_ULE s'il marche bien en monoproc plante de manière très
systématique en SMP :-) . Enfin, après la "cata" juste avant le
lancement de 5.3, je pense qu'ils vont faire très attention...
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je
pense que ca ne change rien.
Oui, d'ailleurs il me semble qu'ipfw contient des nouveaux trucs depuis
la 4.x et que cela permet de s'occuper mieux de ces zombies.
Aussi, mais tant qu'a refaire mon script de firewall, j'ai pris pf pour
pouvoir faire du nat sans utiliser natd.
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun
sur une passerelle de réseau local : interdire aux Win* d'aller sur
oui, le peu que j'ai lu ici ou via google sur ce SCHED_ULE ne m'a pas rassuré, mais a première vue ce n'est pas en standart dans le kernel.
Il est desactivé, pour que personne n'essaye de l'utiliser.
Et d'après ce que j'ai lu, plus on avance dans le x de 5.x plus les performances en SMP sont bonnes. Il y'a quelques benchs qui trainent, mais comme toujours les résultats sont à lire avec attention, surtout quand ils ont été fait avec des versions 5.1 :o)
Les perfs en SMP sont sensées devenir bonne avec SCHED_ULE justement, sauf que SCHED_ULE s'il marche bien en monoproc plante de manière très systématique en SMP :-) . Enfin, après la "cata" juste avant le lancement de 5.3, je pense qu'ils vont faire très attention...
Oh, il doit bien etre attaqué par quelques Windows vérolés, mais je pense que ca ne change rien. Oui, d'ailleurs il me semble qu'ipfw contient des nouveaux trucs depuis
la 4.x et que cela permet de s'occuper mieux de ces zombies.
Aussi, mais tant qu'a refaire mon script de firewall, j'ai pris pf pour pouvoir faire du nat sans utiliser natd.
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf' faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun sur une passerelle de réseau local : interdire aux Win* d'aller sur
:-)
-- Nicolas Le Scouarnec
talon
Ronald Van Assche wrote:
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun sur une passerelle de réseau local : interdire aux Win* d'aller sur internet...
Il y a surtout que pf est "fine-grained" verrouillé et pas les deux autres, si bien que les performances sont bien meilleures. Sur ma machine au bureau qui est sur un switch 100mb/s je sature la bande passante avec pf, pas avec ipf. Comme j'ai pu mettre mon fichier de conf ipf dans pf sans modification (il n'était pas bien compliqué) c'est autant de pris. Par contre attention il faut recompiler le module de pf (ou de ipf) sans support de IPV6 si on l'a viré du noyau, sinon ils ne se chargent pas (je me suis fait avoir 2 fois!).
--
Michel TALON
Ronald Van Assche <ronald@branlos.org> wrote:
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun
sur une passerelle de réseau local : interdire aux Win* d'aller sur
internet...
Il y a surtout que pf est "fine-grained" verrouillé et pas les deux autres, si
bien que les performances sont bien meilleures. Sur ma machine au bureau qui
est sur un switch 100mb/s je sature la bande passante avec pf, pas avec ipf.
Comme j'ai pu mettre mon fichier de conf ipf dans pf sans modification (il
n'était pas bien compliqué) c'est autant de pris. Par contre attention il faut
recompiler le module de pf (ou de ipf) sans support de IPV6 si on l'a viré du
noyau, sinon ils ne se chargent pas (je me suis fait avoir 2 fois!).
Je n'ai pas besoin de nat sur l'engin, j'ai vu qu'on pouvait avec 'pf'
faire des trucs tres drôles comme filtrer sur l'OS, cela peut etre fun sur une passerelle de réseau local : interdire aux Win* d'aller sur internet...
Il y a surtout que pf est "fine-grained" verrouillé et pas les deux autres, si bien que les performances sont bien meilleures. Sur ma machine au bureau qui est sur un switch 100mb/s je sature la bande passante avec pf, pas avec ipf. Comme j'ai pu mettre mon fichier de conf ipf dans pf sans modification (il n'était pas bien compliqué) c'est autant de pris. Par contre attention il faut recompiler le module de pf (ou de ipf) sans support de IPV6 si on l'a viré du noyau, sinon ils ne se chargent pas (je me suis fait avoir 2 fois!).
--
Michel TALON
talon
Nicolas Le Scouarnec nospam. invalid> wrote:
Les perfs en SMP sont sensées devenir bonne avec SCHED_ULE justement,
Non, c'est uniquement le HTT que SCHED_ULE est censé gérer de façon supérieure. Les perfs en SMP générales dépendent surtout du fait qu'on arrive à mettre un maximum de choses sur des verrous fins pour diminuer la contention sur le verrou global. Pour le moment il n'y a que le réseau et les disques ATA qui ont les verrous fins, mais ni la couche VFS, ni CAM, donc les résultats ne sont pas trés probants. En outre ça dépend si tu utilises un Athlon ou un Pentium. Il paraît que le coût des instructions de verrouillage atomiques sur le Pentium est absolument monstrueux, si bien que les Athlons font bien meilleure figure à ce jeu.
sauf que SCHED_ULE s'il marche bien en monoproc plante de manière très systématique en SMP :-) . Enfin, après la "cata" juste avant le lancement de 5.3, je pense qu'ils vont faire très attention...
--
Michel TALON
Nicolas Le Scouarnec <root@india.ath.cx. nospam. invalid> wrote:
Les perfs en SMP sont sensées devenir bonne avec SCHED_ULE justement,
Non, c'est uniquement le HTT que SCHED_ULE est censé gérer de façon
supérieure. Les perfs en SMP générales dépendent surtout du fait qu'on arrive
à mettre un maximum de choses sur des verrous fins pour diminuer la contention
sur le verrou global. Pour le moment il n'y a que le réseau et les disques ATA
qui ont les verrous fins, mais ni la couche VFS, ni CAM, donc les résultats ne
sont pas trés probants. En outre ça dépend si tu utilises un Athlon ou un
Pentium. Il paraît que le coût des instructions de verrouillage atomiques sur
le Pentium est absolument monstrueux, si bien que les Athlons font bien
meilleure figure à ce jeu.
sauf que SCHED_ULE s'il marche bien en monoproc plante de manière très
systématique en SMP :-) . Enfin, après la "cata" juste avant le
lancement de 5.3, je pense qu'ils vont faire très attention...
Les perfs en SMP sont sensées devenir bonne avec SCHED_ULE justement,
Non, c'est uniquement le HTT que SCHED_ULE est censé gérer de façon supérieure. Les perfs en SMP générales dépendent surtout du fait qu'on arrive à mettre un maximum de choses sur des verrous fins pour diminuer la contention sur le verrou global. Pour le moment il n'y a que le réseau et les disques ATA qui ont les verrous fins, mais ni la couche VFS, ni CAM, donc les résultats ne sont pas trés probants. En outre ça dépend si tu utilises un Athlon ou un Pentium. Il paraît que le coût des instructions de verrouillage atomiques sur le Pentium est absolument monstrueux, si bien que les Athlons font bien meilleure figure à ce jeu.
sauf que SCHED_ULE s'il marche bien en monoproc plante de manière très systématique en SMP :-) . Enfin, après la "cata" juste avant le lancement de 5.3, je pense qu'ils vont faire très attention...
--
Michel TALON
talon
Xavier wrote:
Marwan Burelle wrote:
Si j'ai bien compris ce que j'ai lu dans les annonces et sur stable@, la 4.11 est plus là pour offrir une upgrade stable des 4.10 existantes, et retarder le passage en 5.x lorsque ce n'est pas possible.
(Note : J'ai été désabonné d'office, à force de bouncer tous les <censuré> qui annoncent du charset big5 pour écrire en anglais. Faut que je me réabonne chez moi, lorsque TimeDoubler 1.0 sera sorti)
Donc, si je comprends bien : la recommandation de ne *PAS* upgrader les 4.10 en prod (et là, je pense bien sûr à mon firewall) n'est plus d'actualité ?
Je ne sais pas ce que tu appelles "en production", mais s'il s'agit de machines dont tu as absolument besoin qu'elles marchent de façon parfaitement fiable, je garderais peut être bien la série 4, même si la 5.3 est beaucoup plus plaisante. Pourquoi? J'ai 2 machines sous 5.3 toutes deux avec des cartes Intel, driver fxp, sur du 100Mb/s. Certes elles n'ont pas crashé, elles marchent bien, mais j'ai de temps en temps des bizarreries sur le réseau, genre connection ssh qui se termine inopinément, transfer ftp qui meurt en plein milieu, etc. D'abord j'ai pensé à un pb matériel, mais comme ça se produit sur les 2 machines je n'y crois pas. Il s'agit des mêmes symptomes qui existaient sur les cartes syskonnect, et étaient dues à une erreur de verrouillage dans le driver. Je suspecte qu'il en est de même avec fxp.
XAv
--
Michel TALON
Xavier <xavier@groumpf.org> wrote:
Marwan Burelle <burelle@lri.fr> wrote:
Si j'ai bien compris ce que j'ai lu dans les annonces et sur stable@, la
4.11 est plus là pour offrir une upgrade stable des 4.10 existantes, et
retarder le passage en 5.x lorsque ce n'est pas possible.
(Note : J'ai été désabonné d'office, à force de bouncer tous les
<censuré> qui annoncent du charset big5 pour écrire en anglais. Faut que
je me réabonne chez moi, lorsque TimeDoubler 1.0 sera sorti)
Donc, si je comprends bien : la recommandation de ne *PAS* upgrader les
4.10 en prod (et là, je pense bien sûr à mon firewall) n'est plus
d'actualité ?
Je ne sais pas ce que tu appelles "en production", mais s'il s'agit de machines
dont tu as absolument besoin qu'elles marchent de façon parfaitement fiable,
je garderais peut être bien la série 4, même si la 5.3 est beaucoup plus
plaisante. Pourquoi? J'ai 2 machines sous 5.3 toutes deux avec des cartes
Intel, driver fxp, sur du 100Mb/s. Certes elles n'ont pas crashé, elles
marchent bien, mais j'ai de temps en temps des bizarreries sur le réseau,
genre connection ssh qui se termine inopinément, transfer ftp qui meurt en
plein milieu, etc. D'abord j'ai pensé à un pb matériel, mais comme ça se
produit sur les 2 machines je n'y crois pas. Il s'agit des mêmes symptomes
qui existaient sur les cartes syskonnect, et étaient dues à une erreur de
verrouillage dans le driver. Je suspecte qu'il en est de même avec fxp.
Si j'ai bien compris ce que j'ai lu dans les annonces et sur stable@, la 4.11 est plus là pour offrir une upgrade stable des 4.10 existantes, et retarder le passage en 5.x lorsque ce n'est pas possible.
(Note : J'ai été désabonné d'office, à force de bouncer tous les <censuré> qui annoncent du charset big5 pour écrire en anglais. Faut que je me réabonne chez moi, lorsque TimeDoubler 1.0 sera sorti)
Donc, si je comprends bien : la recommandation de ne *PAS* upgrader les 4.10 en prod (et là, je pense bien sûr à mon firewall) n'est plus d'actualité ?
Je ne sais pas ce que tu appelles "en production", mais s'il s'agit de machines dont tu as absolument besoin qu'elles marchent de façon parfaitement fiable, je garderais peut être bien la série 4, même si la 5.3 est beaucoup plus plaisante. Pourquoi? J'ai 2 machines sous 5.3 toutes deux avec des cartes Intel, driver fxp, sur du 100Mb/s. Certes elles n'ont pas crashé, elles marchent bien, mais j'ai de temps en temps des bizarreries sur le réseau, genre connection ssh qui se termine inopinément, transfer ftp qui meurt en plein milieu, etc. D'abord j'ai pensé à un pb matériel, mais comme ça se produit sur les 2 machines je n'y crois pas. Il s'agit des mêmes symptomes qui existaient sur les cartes syskonnect, et étaient dues à une erreur de verrouillage dans le driver. Je suspecte qu'il en est de même avec fxp.
XAv
--
Michel TALON
xavier
Michel Talon wrote:
Je suspecte qu'il en est de même avec fxp.
Ah, ben c'est pas de chance, j'en ai justement 3 sur ce firewall...
-- Xavier HUMBERT INJEP - NetBSD, parce que je le vaux bien
Michel Talon <talon@lpthe.jussieu.fr> wrote:
Je suspecte qu'il en est de même avec fxp.
Ah, ben c'est pas de chance, j'en ai justement 3 sur ce firewall...
--
Xavier HUMBERT
INJEP - NetBSD, parce que je le vaux bien
Le Mon, 31 Jan 2005 11:38:47 +0100, Xavier HUMBERT écrivit:
Je suspecte qu'il en est de même avec fxp. Ah, ben c'est pas de chance, j'en ai justement 3 sur ce firewall...
Pareil ici, dont une double. Jamais eu aucun problème.
Jamais de connection ssh ou de transfer ftp(*) en carafe? Ca m'est arrivé 5 ou 6 fois sur une machine et 2 fois sur l'autre. Je trouve ça un peu bizarre quand même. Evidemment j'ai l'option préemption et tous les autres trucs rigolos.
(*) La dernière fois ça m'est arrivé en transférant FreeBSD-4.11 de chez Free. Il y avait un débit formidable, saturant la bande passante, mais ça s'est interrompu au bout de 200 megs. Je l'ai repris avec wget -c tout s'est terminé correctement, et le md5 était correct. Ca c'est sur la machine plus récente dont je suis sûr du bon fonctionnement. L'autre j'ai plus de doutes.
Arnaud.
--
Michel TALON
Arnaud Launay <asl@launay.org> wrote:
Le Mon, 31 Jan 2005 11:38:47 +0100, Xavier HUMBERT écrivit:
Je suspecte qu'il en est de même avec fxp.
Ah, ben c'est pas de chance, j'en ai justement 3 sur ce firewall...
Pareil ici, dont une double. Jamais eu aucun problème.
Jamais de connection ssh ou de transfer ftp(*) en carafe? Ca m'est arrivé
5 ou 6 fois sur une machine et 2 fois sur l'autre. Je trouve ça un peu bizarre
quand même. Evidemment j'ai l'option préemption et tous les autres trucs
rigolos.
(*) La dernière fois ça m'est arrivé en transférant FreeBSD-4.11 de chez Free.
Il y avait un débit formidable, saturant la bande passante, mais ça s'est
interrompu au bout de 200 megs. Je l'ai repris avec wget -c tout s'est terminé
correctement, et le md5 était correct. Ca c'est sur la machine plus récente
dont je suis sûr du bon fonctionnement. L'autre j'ai plus de doutes.
Le Mon, 31 Jan 2005 11:38:47 +0100, Xavier HUMBERT écrivit:
Je suspecte qu'il en est de même avec fxp. Ah, ben c'est pas de chance, j'en ai justement 3 sur ce firewall...
Pareil ici, dont une double. Jamais eu aucun problème.
Jamais de connection ssh ou de transfer ftp(*) en carafe? Ca m'est arrivé 5 ou 6 fois sur une machine et 2 fois sur l'autre. Je trouve ça un peu bizarre quand même. Evidemment j'ai l'option préemption et tous les autres trucs rigolos.
(*) La dernière fois ça m'est arrivé en transférant FreeBSD-4.11 de chez Free. Il y avait un débit formidable, saturant la bande passante, mais ça s'est interrompu au bout de 200 megs. Je l'ai repris avec wget -c tout s'est terminé correctement, et le md5 était correct. Ca c'est sur la machine plus récente dont je suis sûr du bon fonctionnement. L'autre j'ai plus de doutes.
Arnaud.
--
Michel TALON
Arnaud Launay
Le Mon, 31 Jan 2005 11:10:19 +0000 (UTC), Michel Talon écrivit:
Pareil ici, dont une double. Jamais eu aucun problème. Jamais de connection ssh ou de transfer ftp(*) en carafe?
Non. Des heures de connections ssh où il ne se passe rien parce que j'ai oublié le term, et je n'ai pas besoin de me reconnecter. Le ftp, pareil, même sur des (très) gros transferts, je n'ai jamais vu un seul soucis. FreeBSD 4.10 et fxp dans la machine.
Le Mon, 31 Jan 2005 11:10:19 +0000 (UTC), Michel Talon écrivit:
Pareil ici, dont une double. Jamais eu aucun problème.
Jamais de connection ssh ou de transfer ftp(*) en carafe?
Non. Des heures de connections ssh où il ne se passe rien parce
que j'ai oublié le term, et je n'ai pas besoin de me reconnecter.
Le ftp, pareil, même sur des (très) gros transferts, je n'ai
jamais vu un seul soucis. FreeBSD 4.10 et fxp dans la machine.
Le Mon, 31 Jan 2005 11:10:19 +0000 (UTC), Michel Talon écrivit:
Pareil ici, dont une double. Jamais eu aucun problème. Jamais de connection ssh ou de transfer ftp(*) en carafe?
Non. Des heures de connections ssh où il ne se passe rien parce que j'ai oublié le term, et je n'ai pas besoin de me reconnecter. Le ftp, pareil, même sur des (très) gros transferts, je n'ai jamais vu un seul soucis. FreeBSD 4.10 et fxp dans la machine.
