nullisimo a écrit 173 commentaires

De ce que je me souviens de mes cours d'histoire, c'est en grande partie la crise et le désespoir du peuple allemand...
Les miens semblent etre plus precis. On m'y apprend que le diktat allait jusqu'a annihiler la nation allemande. On a dit au peuple ce qu'il voulait entendre. Ils n'etaient pas plus cons ou plus mechants. C'est juste qu'ils n'avaient peu de "moyen" pour se reconstruire en tant que nation. Le desespoir allemand n'etait pas germano-germanique. Nous avons, indirectement, en imposant des contraintes enormes sur les "vaincus", contribue aussi a ce qui s'est passe.

Alors la solidarite entre pays...

Je reconnais que mes connaissances en architecture sont assez limitées, mais tous ces articles parlent de failles pour BSD, mais je vois nul part un problème concernant Linux.
Tous les acteurs principaux du monde linux ont ete avertis il y a, au minimum, deux mois. Selon Colin, ils se prennent bien la tete dessus ;-) mais bon, c'est partial comme point de vue :-)

la branche des 4.x et celle des 5.x c'est pas trop le même truc.
Ca je le sais. Tu parlais de "releases FreeBSD", ce n'est donc pas specifique a FreeBSD 5.x.

Tu pense qu'un type qui tourne sous 5.3 va se précipiter pour installer la 4.11 quand elle va sortir 3 mois après ?
Certains l'ont fait ;-)

A l'epoque ou il y avait 1 seule branche "a release", la 4.x, et bien les releases etaient espacees de 3/4 mois, et non 6. C'est un intervalle de temps qui permet le dev + la preparation de la release.
Plusieurs equipes sont impactees pour _chaque_ release (release engineering (bien sur), ports, etc.). C'est negliger ce travail la, pas forcement super plaisant, que tu balayes d'un coup en considerant que la seule vraie release c'est la 4.11.

Tu as encore quelques backports sur la 4.x, l'EOL est prevu pour dans 15 mois ,et peut-etre meme 21. Et le support pour les ports ne devrait pas s'arreter avant quelques temps (meme si les maintainers commencent a se lasser du support de la 4.x).

3) 24h de retard est-ce crucial sachant qu'une release de FreeBSD c'est environ tous les 6 mois ?
Theoriquement c'est tous les 3 mois.
Petit historique:
- Novembre 2004: 5.3
- Fevrier 2005: 4.11
- Mai 2005: 5.4
- Septembre(?) 2005: 6.0

Juste une petite precision, pour eviter le "FUD" que gnumdk craint.
FreeBSD dans ce cas la est + responsive, mais il ne faut pas s'y meprendre :
Les perfs disques sont un poil plus faibles. En tweakant un peu, on evite les pbs de lenteur de lecture en raid 5. Out of the box c'est un ratio 1/3 en lecture/ecriture dans le pire des cas. La base de donnees MySQL est aussi plus "lente", c'est de l'ordre de 10/15% (ce n'est pas un facteur critique dans mon cas, si ca l'avait ete, je n'aurai pas switcher le serveur sous FreeBSD).
FreeBSD est plus reactif sur la couche reseaux, et lors des allocs memoires sous tres haute charge et ce malgre une plethore de configs de la VM linux (la ca m'a surpris).

Pour info, ce sont les memes versions des softs, le "tuning" est equivalent, sauf pour la VFS sous FreeBSD.

Idem, lors d'une monté en charge(compilation, ...), les applis sont bien plus réactive sous Linux!
Et bien vois-tu, j'ai un contre exemple.
Un serveur FTP/web/MySQL sous linux (2.4.20 ou 2.6.9) quand on le solicite bien, il laggue a mort et ca fait gueuler nagios. Je l'ai passe sous FreeBSD 5.4-RC, il repond desormais a toutes mes requetes. Et surtout, nous ne sommes plus reveilles la nuit par nagios :-)

J'ai qu'un problème, J'ai toujours pas trouvé le moyen de démarrer ssh sans modifier le rc.conf(je veux pas qu'il démarre au boot mais uniquement quand j'en ai besoin), si quelqu'un à une idée...

dans /etc/rc.conf
if [ "${I_REALLY_WANT_SSH}" = "yes" ] ; then
sshd_enable="YES"
fi

et tu start/stop ssh a coup de :
I_REALLY_WANT_SSH=yes /etc/rc.d/sshd {start|stop}

libre a toi d'ecrire un wrapper pour ca ;-)

clem

Mon petit cousin:
- ecoute de la musique qui passe partout ! Le pire c'est qu'il aime ca, _MOI_ a son age je passais tout mon pognon en matos et en heures d'enregistrement dans les home studios des potes
- il a un scooter chrome, et quand sa meule toussaute, la reparation c'est pour bibi ! Il est meme pas foutu de changer la bougie ! Il s'en sert comme un moyen de transport ! je suis consterne. _MOI_, a son age je tunais ma meule pour la faire monter a 70 km/h !
- allume la lumiere tous les jours ! son installation electrique est pourrie, mais il s'en fout, il continue a s'en servir meme si il y a des risques ! C'est pathetique d'etre aussi negligent, _MOI_, a son age, je maitrise le "petit electricien"

etc...

FreeBSD a choisi de multiplier les conditions de locking, tu peux ne verouiller que ce que tu as besoin. C'est mieux en perf mais c'est plus casse geule. Et FreeBSD essuis encore un peu les platres de ce choix.
Pour le moment, FreeBSD 5.x/6-CURRENT n'est pas giant free. Seule la pile reseau l'est (enfin presque partout) et la VM l'est sous -CURRENT only (cf debug.mpsafenet et debug.mpsafevm). Ce qui est peu pour assurer des perfs "convenables".
Actuellement, les efforts se portent principalement sur la -CURRENT. Les patches de jeffr pour un Giant-free VFS ou le phk_bufwork sont prometteurs.

Pour en revenir a "la chute de FreeBSD", tout s'est fait rapidement en fait. Beaucoup de nouveautes sont apparues tardivement, a cause de la sacro-sainte (chez FreeBSD) conservation ABI/API, juste avant le (vrai) features freeze. Ce qui a fait que pendant les 3 derniers mois, le bugtracking a ete ardu. Le timing d'intregration a parfois ete fatal: integration SMPng + KSE en meme temps, merge de la branche netperf, gcc 3.4 qui a paralyse le ports tree, le support TLS, etc...
Tout ca s'est fait dans la plus grande precipitation. C'est pour cela aussi qu'il y a eu un changement dans le cycle des releases : eviter le plus possible ce genre de problemes, en laissant les nouvelles features pourrir le moins longtemps possible.

Aujourd'hui FreeBSD 5.x souffre du syndrome FreeBSD 3.x. Note positive, FreeBSD commence a s'ouvrir vers de nouveaux horizons au lieu de se confiner dans ses certitudes (cf wishlist de scottl http://lists.freebsd.org/pipermail/freebsd-hackers/2004-December/00(...) ).

FreeBSD 5.x a bcp d'avantages, on arrive a en tirer des choses pas mal comme serveur, il ne faut pas tout jeter qd meme, mais elle decoit un peu. N'ayons pas peur d'esperer un retour a la normale prochainement ;-)

estat.com aussi.

Tu as raison, il ne faut jamais dire jamais :-)

Je recommence parce que t'es dur de la feuille.
Ca se voit tant que ca ?

Je dis : "la faille n'a pas été exploité".
On va se mettre d'accord :)
Exploitee comment? Par qui ? Et pourquoi ?
Je vais faire un tour de passe-passe intellectuel. On se limite a l'hypotetique exploitation de la faille avant la publication. Nous, en tant que communs des mortels, ne pouvons rien y faire. Une faille qui a ete introduite depuis deja quelques mois (voire annees) a plus de chance d'etre exploitee avant le disclosure que celle introduite dans une release sortie deux jours auparavent.

Car la majorité des failles ne sont pas exploités. Donc, jusqu'à preuve du contraire, "la faille n'a pas été exploité" est plus vrai que "la faille a été exploité".
Je ne m'avancerai pas la dessus. Je n'ai pas le pouvoir de savoir ca. Si tu te dis qu'une faille de tel ou tel type n'a pas ete exploite avant, tu en as la certitude pour tes serveurs a toi. Generalement les boites ne crient pas sur les toits que leurs serveurs ont ete victimes d'un hack. Donc tu ne peux pas savoir, si c'est pas une boite qui a eu un pb de secu et a paye une boite de consultant qui a determine la faille, a code un fix et a publie la vulnerabilite.


Dire "la faille a peut-être été exploité" est certe vrai aussi mais relève du FUD.
Ah oui ? Je suis admin, j'ai des machines sous linux, je participe a un proj ou ma fonction est d'etre sensible a ca. Pour moi, c'est de la conscience pro. Si j'utilises un kernel x.x.x et que je lis "augmentation des privileges", je ne fais pas que mettre a jour/fix, je regarde si ca n'as pas etait utilise contre/sur une de mes machines. Pour le moment, j'ai eu un seul probleme. C'est peu compare aux centaines de vulnerabilites annuelles, mais ca me concerne, le "au cas ou" est de rigueur. J'ai des data et des services qui sont plus ou moins sensibles, ma responsabilite est aussi d'etre sur que seul les ayant droits y ont acces.

Je n'ai pas dit que la faille était non exploitable j'ai dit qu'elle n'a pas été exploité.
Jusqu'a nouvel ordre je sais lire. Pour l'expression je ne sais pas si parfois je suis aussi explicite que je le voudrais. Bref...
Je donne ca comme exemple, pour illustrer qu'en matiere de faille de securite, il ne vaut mieux pas aller vite en besogne.
Si t'es assez balaise pour savoir qu'une faille de secu n'a jamais ete exploitee, tu devrais pouvoir comprendre un pauvre post sur linuxfr.

Combien utilisée ? Sûrement 0. Peut-être une.
Faut que tu me dises ou tu as appris a etre omniscient, car franchement ca m'interresse.

Utilisees par qui ? comment ? pourquoi ?
Si c'est alterer l'intregrite de ton OS/data en visitant une page web ou en recevant un mail, c'est sur que que ce n'est pas "utilise". Mais si c'est un serveur d'un ISP que tu convoites, le petit serveur perso d'un type que tu peux pas blairer, ou bien tout simplement l'envie de descendre une machine au pif ou en r00ter une pour stimuler ta libido, alors crois moi, elles seront utilisees.

Il existe des dizaines de vulnerabilites dites "non exploitables" qui le sont pleinement. Rapelle toi de la faille chunk encoding d'apache. Au depart elle a ete vendue comme "non exploitable" juste un "vulgaire" DoS.
Resultat:
http://www.cse.msu.edu/~westrant/symlink/pages/exploits/apache_vuln(...)

Les worms apache, qui sevissaient sous FreeBSD, j'en avais plein mes logs _AVANT_ que la faille ne soit rendue publique.

L'exploitation d'une faille depend de plusieurs facteurs (la liste est loin d'etre exhaustive):
- qui la decouvre et comment
Certaines failles de secu sont decouvertes par inadvertance, juste parce que y'a eu un core dans un coin. Ceux qui veulent vraiment r00ter une machine, vont prendre du temps a lire le code des services qui tourne pour trouver la faille et ils ne s'en vanteront pas forcement sur les mailing list du proj.
- La nature de la faille
cf plus haut le passage sur les "non exploitables"
- Le public vise
C'est sur que sous windows, on exploite a fond les faiblesses du design de l'OS, parceque ca touche du monde et que tu es sur d'etre gagnant. Je doute que ca suscite autant d'interet que d'exploiter le design de SkyOS.

Outre la licence, la motivation de ce fork est aussi que le dev de CVS ralentit de jour en jour. Les fixes prennent plus de temps a etre integres. OpenBSD prend donc ses distances avec CVS et ne sera plus dependant d'une autre team, au prix de dizaines d'heure de code. On est jamais mieux servi que par soit meme.

Je savais, mais n'es-ce pas à la méthode de Linux 2.0 avec un gros lock dans le noyau ?
Effectivement c'etait du "GIANT locking", et c'est pas un support SMP ? C'est suboptimal, mais c'est un support SMP. Si tu pars dans ce petit jeu, on peut aller loin et ca peut durer jusqu'a l'annee prochaine.

Les *BSD sont les bienvenus. Mais critiquer le compromis fonctionnalité/risque de Linux alors qu'il n'y a pas mieux ailleur, je trouve ça lourdingue.
Tu te trompes d'interlocuteur je crois. Soit tu penses que j'ai suppute ca, ce qui est faux, soit tu me prends pour un psychotherapeute, ce qui est tout aussi faux.

Il y a plus sûr que Linux (par exemple *BSD) mais ce n'est pas parce qu'il y a plus sûr que Linux, qu'il faut conclure que Linux n'est pas sûr.
C'est pas plus sur. Je ne crois pas a ce genre de pipeau. Plus un OS est utilise, plus il est decortique, donc tu trouves plus de bugs, donc plus de failles. Ensuite a chacun ses regles du jeu. Sous linux, il ne faut plus s'attendre a avoir un API/ABI stable, sous *BSD, ca reste des que c'est -STABLE. Et voila. Tu preferes la premiere ? c'est parfait.

Ce qui est malheureux avec le "linux n'est pas sûr, mon *BSD est sûr" c'est que tu es obligé de répondre "ton *BSD est has been".
FreeBSD 5.x est has been, et crois moi, on le sait tous. Les directives pour FreeBSD 5.x ont ete faites il y a maintenant + de 4 ans. La branche 5.x est la meme chose que la branche 3. Une sorte de branche intermediaire sans grand interet. Ce n'est pas pour rien que les releases cycles ont change.

À un troll tu réponds un autre troll.
Faudra qu'on m'explique ou est le troll...

Allez voir du côté de *BSD. Peu de bug, peu de fonctionnalité (le smp vient d'être intégré) et ça évolue peu.

Malheureux, tu lances un troll foireux...
Le support SMP vient d'etre integre dans OpenBSD uniquement. FreeBSD et NetBSD supporte le SMP depuis longtemps.
Dans la famille peu de code et peu de fonctionnalites, je te conseille de sortir la tete de ton trou. L'evolution des BSD n'est pas aussi rapide en terme de fonctionnalites, mais ils n'ont pas a rougir.
Regarde DragonFlyBSD, NetBSD 2.0, FreeBSD 5.3/6-CURRENT et meme OpenBSD (caramba j'en dis du bien ;)).
Mais il est vrai que tu as peu de code et beaucoup d'envie sur les servers features (telles que LVM, LVS, GFS, etc.). Mais ca viendra...

Sendmail 8 est vraiment libre.

Faut en profiter, sendmail X a aussi droit a une nouvelle licence...

.. nous avions tous des machines a cafe personnelles, souvent a filtre, nourries au "cafe"(!) Grand-Mere. Ce parc grevait considerablement notre budget. Nous avions pourtant une magnifique machine a cafe, dite "a capsules" qui, malgre son cout de fonctionnement prohibitif, assurait la perenite de notre bugdet maintenance cafeine. La qualite de cette derniere etait inegalee (au moins dans nos locaux) et son debit faisait rougir les plus puisssants des percolateurs; cerise sur le gateau, elle pouvait aussi faire office de bouilloire ou de machine a chocolat chaud.

Il ne se passait pas une semaine sans perturbation, au moins une cafetiere de notre parc :
- se fellait
- fuyait
- s'encrassait
- etait travestie en bouilloire
- etait kidnappee

J'ai donc fait passer une note de services en faveur de notre cafetiere centralisee. Car elle est:
- plus rapide
- peu de maintenance (elle ne se salit guere)
- plus conviviale
- un bon remede au cafe-chaussette

Le probleme etait qu'il fallait faire bouger les gens de leur chaises pour prendre leur cafe.
Le probleme fut resolu en l'installant a cote de l'imprimante reseau.

si quelqu'un a une idée je prends

comme
CFLAGS="-I/usr/X11R6/include" ./configure
?

Personnellement, je sens bien l'erreur hadware (mémoire ou disque, ou autre).
Generalement, quand ca compile, c'est un proc trop chaud qui est en cause.

Ben disons que sans licence tu n'as le droit de rien faire, donc certainement pas de redistribu>er.
oui et non.
Ca depend de la legislation locale:
http://cr.yp.to/softwarelaw.html(...)
Si tu as eu legalement le soft, tu peux en faire tout ce que tu veux tant que ca reste dans le cadre d'un usage personnel.

"sous Linux ce serait si facile".
Certes... mais "si facile" pour qui ? ;-)

>"kern.hz a 1000", peux-tu expliquer pour un non "freebsdiste" comme moi?
Ca existe aussi sous linux ;-)
kern.hz est une variable que tu peux definir des le loader ou dans le kernel (options HZ=XXXX)
HZ = frequence du timer du kernel.
Ca evite d'avoir cette impression d'accoups en ssh.
C'est d'autant plus important sous FreeBSD que dummynet (ce qui permet de faire du trafic shaping) est directement lie a cette variable.

pour plus d'infos:
http://linuxfr.org/2002/10/21/9984.html(...)

> c'est basé sur FREEBSD 4.1

FreeBSD-4.XX-RELEASE meme ;-) (ou XX est la + recente)
Perso je conseille au bidouilleur de tous poils de mettre kern.hz a 1000 pour avoir un peu plus de fluidite dans les sessions "interactives" (ex: ssh) shappees.
pour ceux qui n'aiment pas les soekris, il existe les WRAP* chez http://www.pcengines.ch/,(...) un poil moins cher que ces dernieres.

voila qq liens:
ssh + shell + tools
http://www.xs4all.nl/~fredmol/m0n0/(...)

snort:
http://xoomer.virgilio.it/ortaj/m0n0/(...)

des que l'on sait comment m0n0wall fonctionne c'est assez simple de le modif.
par contre, plus l'image est grande, plus ca bouffe de la RAM. donc sur une petite config les add-ons ne sont pas forcement une bonne chose.