Journal Être à jour de son noyau et le faire savoir ...

Posté par (page perso) .
Tags : aucun
0
12
oct.
2005
Bonjour à tous,
Comme tout bon g33k, vous êtes pointilleux pour être à jour de votre noyau.
Vous allez tous les jours (ou toutes les 10 minutes pour ceux qui n'ont rien à faire :) sur http://kernel.org(...) , où, si vous êtes modernes agrégez le fil [1].

Mais ce temps est révolu !
Merci à Thomas, ses résumés francophones [2] et ses posts sur linuxfr [3] pour m'avoir fait découvrir Ketchup [4], ainsi que Klive [5].

Ce petit logiciel en python de moins de 600 lignes (bien aéré) permet entre autres de patcher récursivement le noyau : on se place dans les sources du noyau, on fait ketchup 2.6 et ketchup télécharge les patchs jusqu'à la dernière version [ici du 2.6])

Ketchup supporte les versions :
  • 2 branches 2.4 :
    1. 2.4
    2. 2.4-pre
  • 8 branches 2.6
    1. 2.6
    2. 2.6-bk
    3. 2.6-mjb
    4. 2.6-mm
    5. 2.6-pre
    6. 2.6-rc
    7. 2.6-tiny
    8. 2.6-tip

ketchup 2.6-rc permet de télécharger les patchs de la dernière version du noyau en release-candidate et de les appliquer automatiquement.
Ketchup gère la signature GPG des patchs si on prend la peine de télécharger la clé du ftpmaster@kernel.org.

Ketchup sait aussi n'afficher que la dernière version de la version du noyau selectionné : ketchup 2.6-mm

En s'arrangeant un peu, on peut s'arranger pour que le script s'exécute au démarrage de la machine et indique s'il y a nouvelle version.
(je lui ai dit de m'envoyer un email, n'étant pas tout le temps présent au moment du boot).

Je ne suis pas allé jusqu'à automatiser la compilation, ça ressemble trop à Gentoo après ...

Les problèmes (ou les prochaines feature ?) sont :
  • Le support du FTP : ketchup ne gère pas le FTP
  • Certains miroirs de kernel.org : au lieu de classer 2.6.1/2.6.2/.../2.6.11, certains serveurs (celui de www.fr.kernel.org par ex) classe 2.6.1/2.6.11/.../2.6.2. Ketchup prenant le dernier lien, on se retrouve avec le 2.6.9 ...


Votre noyau étant maintenant maintenu à jour (ou pas d'ailleurs), on peut contribuer au Libre en informant les developpeurs du noyau quel est la version du noyau que l'on utilise et quelques infos (uptime / CPU / RAM, etc.).
Ça ne coûte pas grand chose (installer python-twisted), executer un klive --install (qui met une entrée pour cron) et c'est parti !
C'est totalement transparent, on ne se rend compte de rien mais on voit le résultat ici : http://klive.cpushare.com/(...) . Au bout de 10 minutes, on est ajouté à la base de donnée. Quand on clique sur son adresse IP à droite, on voit une page avec toutes les infos qu'on a envoyées.

À noter que Ketchup et live sont totalement indépendant, l'un permettant d'upgrader son noyau facielement, l'autre permettant d'en informer la communauté.
Je suis actuellement sur la dernière rc de la branche 2.6 (2.6.14-rc4) et je n'ai eu aucun problème ...

Alors faites le chez vous ! C'est pour le bien de tous et ça ne coute rien :-)

  1. http://kernel.org/kdist/rss.xml(...)
  2. http://www.selenic.com/ketchup/wiki/index.cgi/ExampleUsage(...)
  3. http://klive.cpushare.com(...) (Les infos pour le logiciel Klive sont en bas de page


NDR : L'écriture des journaux est un vrai calvaire, soit on désactive les retours chariots et aucun balise ne permet de passer la ligne proprement, soit on les active et les listes sautent des lignes a chaque puce ...
  • # Encore un moyen de troller

    Posté par . Évalué à 1.

    En faisant mumuse avec Klive, j'obtient les stats suivantes :

    Distrib Max Uptime Avg Uptime
    Fedora 33d 3d
    Red Hat 34d 15d
    Debian 45d 5d
    Mandriva 1d 14:14:48h
    SUSE 34d 1d

    Qui a dit que les noyaux mdk étaient super stable :)
    • [^] # Re: Encore un moyen de troller

      Posté par . Évalué à 5.

      faut aussi voir le type d'utilisateurs hein ;)

      papy ou m'gamin qui installe une mdk pour pas devoir payer windoze, et qui éteind sagement son pc le soir pour savoir dormir et éviter de faire plaisir à edf, ou bien le geek ultime qui héberge les sites de ses copains sur sa ligne espéciale ip fixe (si tu te reconnais; salut toi :))
    • [^] # Re: Encore un moyen de troller

      Posté par . Évalué à 4.

      Pour être plus juste, il faudrait mettre le nombre d'entrées, et là on se rend compte que les stats pour Mandriva ne représentent pas grand chose :

      Distro - Nombre d'entrées
      SUSE - 354
      Mandriva - 9 (!!)
      Fedora - 362
      Debian - 116
      Red Hat - 4

      Pour Red Hat, ça s'explique, ce sont des versions serveurs.
      De plus, on remarque que le noyaux de Mandriva rapportés sont ceux de la 2006 qui est quand même très jeune : difficile de faire 373 jours d'uptime avec une distro sortie il y a même pas une semaine ;)
      • [^] # Re: Encore un moyen de troller

        Posté par (page perso) . Évalué à 2.

        A noter que ce sont la classification est faite non pas part rapport à la distribution, mais à la version du noyau utilisé :
        Je tourne sous gentoo avec un noyau qui vient de kernel.org -> je ne suis pas dans les stats de Gentoo

        Il faut compiler un noyau gentoo pour etre compte comme "gentoo".

        On peut de ce fait imaginer que la proportion de mandriva est tres faible, ceux compilant leur propre noyau telecharge depuis kernel.org n'apparaissent pas dans la section mandriva ...

        À terme, et si ça peut aider les developpeurs du noyau, klive installe par defaut ou presque serait peut-être pas mal ... (parce que les stats sont souvent faussées : ceux qui installent klive en connaissent l'existence, sont plus au courant de l'actualité du noyau et auront très certainemenbt une version à jour ...)
        • [^] # Re: Encore un moyen de troller

          Posté par (page perso) . Évalué à 4.

          À terme, et si ça peut aider les developpeurs du noyau, klive installe par defaut ou presque serait peut-être pas mal ... (parce que les stats sont souvent faussées : ceux qui installent klive en connaissent l'existence, sont plus au courant de l'actualité du noyau et auront très certainemenbt une version à jour ...)

          À l'origine, le but de KLive c'est de mesurer combien de gens testent les noyaux -rcX. C'est issu de discussions au LKS de cette année, durant lequel les développeurs noyau se demandaient comment les noyaux -rcX étaient testés, par combien de personnes, etc. Donc finalement, le fait de savoir qu'il y a 728712 quidams qui utilisent le noyau pré-packagé Mandriva, ce n'est pas directement intéressant pour les développeurs du noyau.
    • [^] # Re: Encore un moyen de troller

      Posté par . Évalué à 2.

      Ah les concours d'uptime... On a l'impression que c'est à celui qui polluera le plus.
    • [^] # Re: Encore un moyen de troller

      Posté par . Évalué à 3.

      mais, d'totu maniere, il sagit bien de mettre a jour son kernel non ?
      c-a-d que tu va rebooter apres cette operation (j'ai pas encore entendu parlé de kernel hot-plug)
      donc, bon, on ne parle pas de stabilité là...
      en plus comme dejà dit : 9 hosts c'est pas representatif, et aussi, moi petit utilisateur mdk, j'eteins "gentillement" (ca veux pas dire bêtement) mon PC le soir, parceque ca fais du bruit, et que j'ai passé l'age de jouer a celui qui à la plus grosse ! non mais :)
  • # Résumés...

    Posté par (page perso) . Évalué à 4.

    Merci à Thomas, ses résumés francophones [2]

    Thomas, qui est d'ailleurs bien à la bourre pour la suite des résumés... ce qui confirme ce que je disais au début: je ne tiendrais pas le rythme.

    Sinon, j'utilise également ketchup, c'est très très pratique. En gros:
    ketchup 2.6-rc
    make oldconfig
    (répondre aux 2-3 questions)
    make
    make install
    make modules_install
    et zou, reboot.
    • [^] # Re: Résumés...

      Posté par . Évalué à 2.

      tu fais pas de make modules ?
      Dans certains cas, le make modules_install m'avait fait n'importe quoi (installation de vieux modules) et ca avait fait tres mal au reboot.
  • # Pourquoi je ne participerai pas à klive

    Posté par (page perso) . Évalué à 10.

    Ca dérange personne un site qui te liste les IP de machines ayant le kernel d'une version donné ?
    Ca permet de trouver en quelques secondes une listes de machines ayant un trou de sécu connu le jour ou il y en a un nouveau !
    • [^] # Re: Pourquoi je ne participerai pas à klive

      Posté par (page perso) . Évalué à 2.

      En même temps le but de klive comme dit plus haut c'est de compter le nombre de personnes ayant testés une version donnée -rcX en général
      Et en général les personnes la sont des geek qui ont généralement une passerelle NAT
      Bon après si klive se met à supporter l'ipv6 je sais pas.... (euh il le supporte pas déjà? faudrait que je voie)
    • [^] # Re: Pourquoi je ne participerai pas à klive

      Posté par (page perso) . Évalué à 2.

      Les adresses IP n'ont pas l'air d'être stockées dans la base de données.
      Un hash de celle-ci ainsi que de ton adresse réseau est stockée (au moins affichée) sur le site.. À moins que cela ne soit un numéro attribué à chacun, en incrémentation ...

      Donc si la base de données se trouve un jour corrompue, on ne pourra normalement pas retrouver quels PCs ont telle version ....

      Et puis ceux qui ont Klive sont ceux qui testent les rc du noyau, donc on peut espérer qu'ils mettent leur rc à jour -> ils ont moins de chance d'avoir un kernel avec une faille de sécurité ...
    • [^] # Re: Pourquoi je ne participerai pas à klive

      Posté par (page perso) . Évalué à 2.

      Ca dérange personne un site qui te liste les IP de machines ayant le kernel d'une version donné ?


      C'est ce que je me suis dit tout au début en lisant le journal. Ça a attisé ma curiosité. Je me suis rendu dessus, mais tout ce que j'ai trouvé, c'est un packet de filtres dont le filtre sur l'ip qui propose deux options : all ou ton ip actuelle.

      On peut modifier l'addresse ip directement dans les paramètres php, mais c'est un peu lourd comme solution pour une attaque massive.

      Sinon en sélectionnant une version donnée d'un noyau, on a des hosts, une sorte de hash, mais je me demande dans quelle mesure il est possible de récupérer l'adresse ip à partir de ça en un temps raisonnable.
  • # chtite question

    Posté par . Évalué à 2.

    Bien le bonjour messieurs,

    Est ce que ca marche toujours si par hasard mon kernel est patché avec des sources "exotiques" (skas : patch pour UML) et que certain de mes modules sont recompilés à partir de sources qui ne sont pas livrées avec celle du noyau (ipw2200 : wireless) ?

    Faut il que je me mette à Python ? Y a t il de super option pour Ketchup ? ou mes petits scripts shell développés avec amour me suivront encore un bon bout de temps ?

    La question ici (non, pas le troll) est la suivante : à quoi cela sert il d'etre sous *n?x si c'est pour faire bêtement comme tout le monde sans comprendre ce qui se passe réellement ? Patcher un noyau, c'est bien, en abuser ca craint ! Etre en toute dernière version de noyau n'a d'intérêt pour moi que si l'on est capable de soumettre des rapports de bug afin de faire avancer le shimilibilik.

    Mais de quoi je me melle moi ! après tout faites comme bon vous semble. Chacun est Libre(c)(tm) de faire ce qu'il lui plait ! (je fais c'que j'veux avec mes ch'veux)

    Merci quand même à ceux qui prennent la peine de poster quelques journaux afin de nous faire (re)découvrir des petits soft toujours sympatiques (car développés avec Amouuuur)

    SP23 ~~~> do_Ob
  • # git?

    Posté par (page perso) . Évalué à 1.

    Je ne vois pas trop l'intéret[1] de ketchup par rapport à git :
    $ git clone\
    rsync://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
    linux
    $ cd linux
    $ git checkout


    (je ne trouve pas comment avoir un tag particulier, mais cà doit exister)

    J'ai loupé quelquechose?

    [1] http://kerneltrap.org/node/5686(...)
    • [^] # Re: git?

      Posté par . Évalué à 2.

      Hum peut-être de préserver ses doigts pour autre chose...
      $ cd /usr/src/linux
      $ ketchup 2.6

Suivre le flux des commentaires

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