Sortie de NetBSD 4.0

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
0
20
déc.
2007
NetBSD
NetBSD est un système d'exploitation disponible sous licence BSD. Il est bien connu pour sa portabilité puisqu'il fonctionne sur 17 architectures de processeur.

Après une longue gestation, et quelques peu en avance pour Noël, l'équipe de NetBSD est heureuse de vous proposer la version 4.0 de NetBSD. Cette version est spécialement dédiée à la mémoire de Jun-Ichiro "itojun" Hagino.

Cette version présente de nombreuses améliorations, que ce soit concernant la gestion du réseau, dans les dispositifs de sécurités et la prise en charge de nouvelles plateformes. On notera en particulier le gestion de Xen3 en dom0, domU (avec ou sans prise en charge matériel).

NdM : merci à MilkaJinka de nous avoir également proposé une dépêche à ce sujet. De nombreux progrès ont été faits depuis la version précédente :

Du point de vue wifi, de nombreux pilotes ont été ajoutés (ral, rum, wpi...). On notera l'inclusion dans le système de base de wpa_supplicant pour se connecter à un réseau wpa, et hostapd pour créer un point d'accès facilement.
La prise en charge de ndis a été ajouté pour les cartes pour lesquelles NetBSD n'a pas de pilote.

Plus globalement, côté réseau, on retrouve l'intégration de CARP (Common Address Redundancy Protocol) qui permet de gérer la redondance. On notera la bonne intégration de PF (firewall) et ALTQ (gestion de la qualité de service). De plus, il est maintenant possible de faire du routage grâce à l'adresse source (options IPSELSRC).
Enfin, du point de vue réseau, on notera l'ajout d'une pile bluetooth complète.

De nombreux ajouts ont été apportés côté sécurité. L'implémentation ipsec FAST_IPSEC supporte maintenant IPv6. Par défaut, NetBSD utilise l'extension SSP de GCC. En plus de la traditionnelle protection W^X, des améliorations venant de PaX ont été intégrées, en particulier des restrictions sur mprotect(2). Enfin l'intégration de kauth, un framework de gestion des droits niveau noyau, permet d'écrire "facilement" des nouvelles politiques de sécurité.

D'autres améliorations en vrac :
  • Intégration de proplib(3), une interface de communication entre le noyau et l'espace utilisateur ;
  • Amélioration de la gestion du firewire (code venant de FreeBSD) ;
  • Amélioration de la prise en charge du midi ;
  • Utilisation de vesa pour la console sous x86 ;
  • Nouvelles plateformes pour evb{arm,mips} et deux nouveaux ports landisk et ews4800mips ;
  • De nombreux pilotes en plus ;
  • gcc 4.1 et gdb 6.5 par défaut ;
  • Utilisation de postifx à la place de sendmail, nouvelle version de bind 9
Et tant que j'y suis, parlons un peu du futur. La branche 4 ayant été créée il y a déjà fort longtemps, de nombreuses améliorations ont été apportées dans la version de développement (qui deviendra la future version 5.0). Un gros travail a été fait sur l'amélioration des performances en multi-processeur (diminution de l'utilisation du big lock). On notera beaucoup de travail aussi sur la gestion de l'énergie. Un framework de tests unitaires / de non-régression a aussi été intégré (sous le doux nom d'ATF). Et il y a aussi le travail sur PUFFS, REFUSE, RUMP permettant d'exécuter des systèmes de fichiers en espace utilisateur (avec rump, il est aujourd'hui possible d'exécuter le code ffs du noyau sans modification en userland).

Certains ont dit que NetBSD était mort. Cette nouvelle version montrera j'espère que NetBSD bouge encore bien. N'hésitez pas à faire un petit don si le projet NetBSD vous intéresse :D.

Aller plus loin

  • # Ca bouge !

    Posté par  . Évalué à 2.

    NetBSD est le seul système *BSD que je n'utilise pas. Il faut dire qu'il ne bouge pas assez vite comparé à Open et Free :-)
    Ca fait plaisir par contre de voir débarquer la 4.0 qui me contredit quand je pensais que le projet était quelque peu mort !

    Par contre, suprenant de voir Postfix inclut à la place de Sendmail !

    • [^] # Re: Ca bouge !

      Posté par  (site web personnel) . Évalué à 2.

      Pas si étonnant que cela pour Postfix, la décision a été prise il y a un moment.

      Dire que NetBSD ne bouge pas est clairement un troll, va voir les versions de développement et tu verras qu'ils travaillent d'arrache pied.

    • [^] # Re: Ca bouge !

      Posté par  (site web personnel) . Évalué à 0.

      Ca bouge. Car si tu regardes Wikipedia et l'historique des versions de BSD, tu vois que


      NetBSD 3.1, sorti le 4 novembre 2006...
      NetBSD 4.0, sorti le 19 décembre 2006, est la dernière version stable de NetBSD.


      En un mois, on est passé de la version 3.1 à la version 4! (Ca va plus vite que Debian...)

      Soit il y a une erreur sur la page de Wikipedia, soit Linuxfr a un de retard...

    • [^] # Re: Ca bouge !

      Posté par  . Évalué à 1.

      >>Par contre, suprenant de voir Postfix inclut à la place de Sendmail !

      Ce qui est surprenant, c'est que ça aurait deja du etre fait depuis longtemps..

    • [^] # Re: Ca bouge !

      Posté par  (site web personnel) . Évalué à 3.

      Je trouve étonnant que les autres BSD continuent de distribuer Sendmail. Sendmail a clairement été ciblé comme l'outil externe ayant le plus faille de securité, donc celui pour lequel le plus de travail était nécessaire ( à chaque fois, ca veut dire patcher sendmail dans les branches maintenus (deux branches maintenues) puis faire des rapports de sécurité, puis espèrer que tout le monde mette à jour assez vite). Postfix est globalement moins sale niveau code et moins entâché niveau sécurité. Et le fichier de config est lisible.

      Concernant la vitesse de dévelloppement de NetBSD, il serait intéressant de savoir comment tu compare la vitesse de developpement des différents systèmes. Faire des releases tous les 6 mois n'accèlérent pas vraiment le processus de dev mais ca donne l'impression de bouger plus. Une mesure intéressante serait de regarder le nombre de commit moyen par développeur et de regarder que les commits utiles (genre pas les whitespace, pas les typos, et pas les 'pull from master repo' (je ne cible personne :D)).

      I hope you will enjoy it.

      • [^] # Re: Ca bouge !

        Posté par  . Évalué à 1.

        > Sendmail a clairement été ciblé comme l'outil externe ayant le plus faille de securité,

        Il y a combien d'années ?
        Il n'y a rien de particulier niveau sécurité pour Sendmail depuis bien longtemps.

        Je serait curieux de savoir combien de trou de sécurité a eu Sendmail cette année et l'année précédente.

        > Postfix est globalement moins sale niveau code

        Lis le code de sendmail, c'est très propre.

        • [^] # Re: Ca bouge !

          Posté par  (site web personnel) . Évalué à 5.

          8 en 7 ans d'apres Secunia pour Sendmail
          1 en 7 ans d'apres Secunia pour Postfix.

          En particulier 2 en 2006 (pour Sendmail). Et la decision a été prise en 2006.

          Pour le reste, je vous laisse seule juge, j'ai exprimé les raisons du switch de NetBSD, vous n'êtes pas obligé d'être d'accord :).

          • [^] # Re: Ca bouge !

            Posté par  . Évalué à -1.

            > 8 en 7 ans d'apres Secunia pour Sendmail

            Mais ces deux ou trois dernières années ?
            Parce que si c'est 8 en 7 ans dont 8 la première année, alors ce n'est plus pertinant aujourd'hui.

            > vous n'êtes pas obligé d'être d'accord :)

            Ce que je veux dire, c'est qu'il n'est plus juste de critiquer Sendmail sur la sécurité car sendmail n'a pas eu de problème depuis bien longtemps.
            Après libre à chaqu'un de préférer PostFix ou Exim, mais pas en avançant des arguments douteux.

            • [^] # Re: Ca bouge !

              Posté par  . Évalué à 2.

              Tu devrais lire en entier le message auquel tu réponds, il n'est pas très long....

              2 en 2006, ca n'est pas 8 en 2000

              • [^] # Re: Ca bouge !

                Posté par  . Évalué à 1.

                > Tu devrais lire en entier le message auquel tu réponds, il n'est pas très long....

                Désolé. Pourtant j'ai tout lu, mais je n'ai pas "imprimé" :-)

                M'enfin, voyons dans la pratique par exemple RHEL 4 :
                https://rhn.redhat.com/errata/rhel4as-errata-security.html

                Ben Sendmail n'a pas plus de problème qu'un autre globalement. En gros un trou de sécurité par an en moyen (2 classés "low" et "seulement" 1 classé "critical" sur 3 ans). Certe, postfix a eu moins de trou de sécurité sur la même période (1 au-lieu de 3). Mais globalement sendmail reste très sûr et est dans les plus sûrs. Pour info, sur la même période, 6 failles pour Openssh, 11 pour php, 6 pour squid, Linux (le noyau) a eu 19 failles, idem pour Firefox. Ces derniers ont la réputation, justifiée, d'être sûr.

                M'enfin, si tu (ou NetBSD) préfères Postfix, pas de problème.

                Par contre ça m'énerve un peu de voir des sous-entendus sur la mauvaise sécurité de sendmail alors que dans les faits, même s'il n'est peut-être pas aussi génial que Postfix pour la sécurité, sendmail est tout à fait correct.

                • [^] # Re: Ca bouge !

                  Posté par  (site web personnel) . Évalué à 2.

                  C'est vrai que je trouve aussi l'argument de la sécurité assez mauvais.

                  Au boulot on va sans doute lâcher un peu Sendmail (pas pour tout), mais c'est pour d'autres problèmes qui peuvent se résumer à un seul, sendmail n'est plus à la mode.

                  Il est donc difficile de trouver de vrai compétences, et des moyens de se former.

      • [^] # Re: Ca bouge !

        Posté par  . Évalué à 1.

        Ben concernant la sécurité, Sendmail a un passé sécuritaire peu fructueux mais avec le temps, ça s'arrange.
        Concernant la non distribution de Postfix (ou tout autre MTA) à la place de Sendmail, c'est principalement pour des raisons de licence...

    • [^] # Re: Ca bouge !

      Posté par  . Évalué à 2.

      Regarde un peu NetBSD et son support Xen. C'est un seul gars qu s'en occupe, et ça marche très bien: on installe un dom0 ou un domU en 2 temps 3 mouvements depuis environs 2 ans, là ou les distribs Linux nécessitaient de faire d'infames manips assez tordu (je ne sais pas ce qui en est aujourd'hui, mais il y a environs 2 ans, c'était NetBSD qui s'en sortait le mieux)

      • [^] # Re: Ca bouge !

        Posté par  . Évalué à 1.

        > on installe un dom0 ou un domU en 2 temps 3 mouvements depuis environs 2 ans, là ou les distribs Linux nécessitaient de faire d'infames manips assez tordu

        Un petit exemple en vidéo d'introduction pour RHEL 5 (c'est la même chose pour FC6 et grosso modo la même chose pour FC5 (sortit il y a plus de 18 mois)) :
        https://www.redhat.com/v/training/ogg/RH184.ogg

        Facile, non ?

        Virt-manager rend aussi trivial la migration de machine virtuelle, tu peux te connecter à distance et graphiquement, etc...

        C'est encore mieux pour F7 et F8 (qui supporte Xen et KVM).

        Bref, ça dépend de la distribution que tu as utilisé pour comparer avec Linux.

        • [^] # Re: Ca bouge !

          Posté par  (site web personnel) . Évalué à 3.

          Linux devient aussi simple que Windows (à savoir des front-end partout pour pas faire grand chose comme ça, ça a l'air plus simple mais au final, on sait globalement pas du tout ce qu'on fait).

          Surtout que globalement, il y'a aucune plus value à l'installation de xen. Il aurait copié collé le fichier d'example de conf de xen, et editer les paramètres à la main, ca aurait été bien plus rapide.

          En plus, la partie tricky dans les installations de Xen sous Linux, c'est la mise en place du système de fichier qui va permettre l'installation (le .../pub dans l'example). Et ça evidemment, il a oublié de montrer comment il l'a mise en place. En plus j'aimerai bien voir comment il se débrouille avec d'autres distribs linux (genre pour voir comment ils s'en sort avec une debian ou une gentoo).

          Sous NetBSD, tu prend ton iso x86, tu lui fais pointer dessus, tu prend le kernel Xen_domU_install, tu fais pointer dessus et tu lance. Ah oui il a fallu éditer le fichier de conf à la main. So hard :). (non je n'ai pas de super vidéo à vous montrer :) (oui on utilise le processus d'install normal, après tout quelle est la différence ?)

          Et pas besoin d'installer super virtu-manager pour faire ça. La simplicité est ailleurs.

          • [^] # Re: Ca bouge !

            Posté par  . Évalué à 1.

            > Sous NetBSD, tu prend ton iso x86, tu lui fais pointer dessus, tu prend le kernel Xen_domU_install, tu fais pointer dessus et tu lance.

            Tu peux faire pareil avec Linux. Évidemment virt-manager le supporte.

            Libvirt/virt-manager est principalement, voire exclusivement, développé par Red Hat. Si tu as vu la vidéo, tu peux imaginer des scénarios où les machines virtuelles sont construites en 3 ou 5 minutes de façon automatique. La cible de Red Hat est actuellement les serveurs. Ceci combiné à lvm et GFS2 peut donner ça (amazon EC2) :
            http://www.redhat.com/about/news/prarchive/2007/amazon.html (actuellement en public beta)

            C'est-à-dire un fournisseur de machine virtuelle. Tu paies pour la quatité de cpu, mémoire et disque que tu utilises. Tout peut être changé à la volée.
            Red Hat est très ambitieux dans ce domaine.

            Pour un usage plus desktop (typiquement une installation d'un autre OS depuis les CD), c'est supporté :
            http://www.phoronix.com/scan.php?page=article&item=656&a(...)
            C'est une "démo" de Fedora 7, une version de test.
            Le test a été fait avec KVM (Fedora, et donc Red Hat/RHEL, va petit à petit abandonner Xen).

            Le développement de la virtualisation est très dynamique dans le monde Linux.

            • [^] # Re: Ca bouge !

              Posté par  (site web personnel) . Évalué à 2.

              En mode non hvm ? Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.

              Et je note que tous les tutoriaux que j'ai trouvé sur Internet implique de passer par debootstraop ou rpmstrap etc ... Si on pouvait simplement utiliser l'iso, pourquoi utiliser des méthodes si complexe (en particulier quand tu veux installer une debian domU dans un netbsd dom0, tu as pas forcement debootstrap ...).

              Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi. Je m'en sers majoritament pour faire des tests NetBSD.

              • [^] # Re: Ca bouge !

                Posté par  . Évalué à 1.

                > En mode non hvm ?

                Donc en mode Xen (j'y reviens plus loins).
                C'est actuellement quasiment la même chose. Les différences entre Xen et KVM sont génées par libvirt (utilisé par virt-manager). Actuellement RHEL 5.x n'utilise que Xen. Les dernières versions de Fedora utilise KVM par défaut, non car actuellement KVM est forcément mieux que Xen, mais seulement car KVM (et paravirt_ops) est vu comme l'avenir de la virtualisation et Fedora est principalement dédié à la communauté des développeurs. Bien que Red Hat ne communique pas sur ça, il y a fort à parier que RHEL 6 va passer à KVM (au moins par défaut).

                > Après c'est peut-etre juste les tutoriaux qui sont de mauvaise foi.

                Peut-être mais je ne crois pas. Il ne doivent pas être à jour.
                Le problème de l'installation en mode paravirtualisation est que l'installeur (qui est sur le CD par exemple) doit reconnaitre le matos qu'on lui propose. Tous les installeurs n'était pas au fait de Xen à ses début. Autre problème, c'est l'affichage, etc... Au début de Xen, il n'y avait pas de périphérique pour faire l'affichage. Donc on ne pouvait utiliser l'installeur et il fallait utiliser des "hacks". On pouvait faire tourner une installation de Linux mais pas son installeur.
                J'imagine que les "debootstraop ou rpmstrap" sont (ou étaient) là principalement pour contourner ce problème.

                > Parce que ton exemple montre l'utilisation dans un cadre 'support hardware'.

                Certes, mais ça va devenir hypra commun dans quelques années et la paravirtualisation de Xen va devenir obsolète (au moins pour les serveurs).
                Notons que la transition va se faire dans la douceur (plus ou moins). Fedora va mettre les bouchées doubles pour que paravirt_ops de F9 (qui n'aura pas XenSource) supporte Xen dom0 et domU. Donc si tu as une machine virtuelle qui tourne sous Xen (domU), elle tournera aussi sur une serveur qui n'utilise pas XenSource.
                Le plan sur la virtualisation pour F9 (jugé très ambitieux pour ne pas dire risqué) :
                http://fedoraproject.org/wiki/Features/XenPvops

  • # Ca va troller chérie !

    Posté par  (site web personnel) . Évalué à -1.

    De toute façon tout le monde sait que OpenBSD c'est le bien et que NetBSD saylemal !
    Encore une source de troll supplémentaire sur IRC moi je dis !

    Et puis zul : arrête d'écrire des journaux sur linuxfr et retourne travailler pour que je puissent faire des trucs crades sur IPv6 !

    ps : je sens que je vais me prendre un -10 (oui je suis devin à mes heures perdu)

  • # "NetBSD, un projet inutile ?" dixit un des créateurs du projet en 2006.

    Posté par  (site web personnel) . Évalué à 1.

    Sujet provocateur, mais c'est parce que cette news m'a fait penser au fameux article de Charles M. Hannum, cofondateur du projet, paru dans Linux Weekly News l'année dernière : http://lwn.net/Articles/197748/

    Je cite :
    The NetBSD Project has stagnated to the point of irrelevance. It has gotten to the point that being associated with the project is often more of a liability than an asset.


    Il faudra évidemment lire tout l'article avant de troller sur le sujet :)

    La situation a-t-elle changé, en bien ou en mal, depuis ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.