Klive, pour faire partager la version de son noyau et plein d'autres choses

Posté par (page perso) . Modéré par Amaury.
Tags :
0
13
jan.
2006
Noyau
Après un article sur Ketchup, logiciel permettant de mettre à jour facilement les sources de son noyau, celui-ci portera sur la diffusion de cette version à tous.

En effet, lors du Linux Kernel Developers Summit 2005, les développeurs du noyau se rendirent compte qu'ils n'avaient aucun ordre de grandeur concernant le nombre d'utilisateurs testant les versions git, rc ou pre de la prochaine version stable du noyau.

Le projet Klive a donc été créé.

Il s'appuie sur des utilisateurs volontaires qui, avec un petit logiciel, informent la communauté et les développeurs du noyau en place sur leur machine.

Klive n'a pas besoin d'être compilé ni d'être exécuté avec les permissions du superutilisateur. Klive est un projet sous licence GPL.
Il se compose d'une partie client et d'une partie serveur, toutes deux disponibles.

C'est la partie cliente qui est utilisée par les utilisateurs, c'est donc vers elle que se portera cet article.

Le fonctionnement de Klive est simple : le logiciel récupère les informations sur la machine hôte qu'il va envoyer sur le serveur centralisant toutes les données.

Une tâche cron est utilisée pour effectuer cette action régulièrement.

Le script effectue l'installation automatiquement : il télécharge le client, le copie dans un répertoire aléatoire et intègre une nouvelle tâche dans cron pour l'éxécuter à intervalle régulier.

Depuis peu, Klive récupère également des informations sur les bus PCI et sur les modules chargés dans le noyau.

Le client et le serveur ont été réalisés avec Python et python-twisted. Ce sont les seules dépendances requises. Cependant, une version réalisé en pur Python a été écrite et est en développement. Pour plus d'informations, rendez vous sur le Wiki Klive.

Si vous voulez vous impliquer dans le projet, sachez que la mailing-list de Klive est très réactive sans avoir un débit trop important.

Aller plus loin

  • # Et Cron ?

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

    > Python et python-twisted. Ce sont les seules dépendances requises

    Il y a aussi Cron comme dépendance. Si on utilise par exemple fcron, le script refuse d'installer klive, ou alors (après bidouille faite de liens symboliques entre les commandes fcron et celles de cron) ne détecte pas que fcron est en fonctionnement et refuse de s'installer.
    • [^] # Re: Et Cron ?

      Posté par . Évalué à 3.

      ouais alors ça je comprends pas. Je fais tourner klive depuis un bon moment. Je le lance à la main, c'est tout simplement un daemon. Donc je vois pas cron la dedans.

      Sauf s'il s'agit d'un
      @reboot

      pour que ça démarre tout seul en utilisateur.
    • [^] # Re: Et Cron ?

      Posté par . Évalué à 1.

      Heuu ...

      Calculating dependencies ...done!
      [ebuild N ] net-zope/zopeinterface-3.0.1 -doc 105 kB
      [ebuild N ] dev-python/pyopenssl-0.6 -tetex 275 kB
      [ebuild N ] dev-python/twisted-2.1.0 +crypt +gtk -serial 1,052 kB
      [ebuild N ] app-misc/klive-0.7-r2 18 kB

      voila pour les dependances

      A+
      • [^] # Re: Et Cron ?

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

        Il ne parle pas d'une dépendance du paquet mais plutôt d'un logiciel requis pour que l'application fonctionne.
        • [^] # Re: Et Cron ?

          Posté par . Évalué à 3.

          Il ne parle pas d'une dépendance du paquet mais plutôt d'un logiciel requis pour que l'application fonctionne. »

          Elle me parait bien subtile ta distinction : pour moi, si c'est requis pour un bon fonctionnement, ça devrait être une dépendance du paquet, non ?

          Enfin quoi qu'il en soit, KLive marche très bien chez moi depuis des mois alors que je n'utilise que fcron. Les gens qui voudraient voir comment il est installé et lancé sous Gentoo pour faire pareil avec leur mimines, ou pour faire un paquet pour leur distrib', peuvent jeter un oeil à l'ebuild et à l'init script qui sont ici :
          http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-mis(...)
          http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/app-mis(...)
          • [^] # Re: Et Cron ?

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

            Tout à fait d'accord, cela "devrait être" une dépendance, mais visiblement, ce n'en est pas une. Le post ci-dessus prouve cela justement mais il a été fait sur un ton du style "regarde, tu te trompes : dans les dépendances du paquet, on ne trouve pas cron". Or, les deux posts ne sont pas contradictoires. Voilà.
            • [^] # Re: Et Cron ?

              Posté par . Évalué à 2.

              Ok, je vois ce que tu voulais dire maintenant.

              « visiblement, ce n'en est pas une. Le post ci-dessus prouve cela »
              En fait même pas, le post si dessus ne prouve pas grand chose puisqu'il liste juste les dépendances que cet utilisateurs n'avait pas d'installées (c'est une sortie de "emerge -p klive").

              Mais ça ne comprends pas :
              - d'éventuelles autres dépendances qu'il aurait eu de déjà installées ;
              - des choses éventuellement nécéssaires aussi mais qui sous Gentoo ne sont jamais explicitées dans les dépendances parcequ'elles sont obligatoirement installées sur tous les systèmes (le genre glibc, etc.).

              Le plus simple pour avoir les dépendances du paquet Gentoo, c'est encore de regarder l'ebuild, et il ne liste que Python et Twisted (les autres trucs cités au dessus étant des dépendances indirectes venant de Twisted).

              Mais pour en revenir à "cron", je confirme qu'il n'y en a nul besoin (j'ai même lu les sources pour vérifier cette fois). Le paquet installe les fichiers suivants :
              /usr/share/doc/klive-0.16/README.gz
              /usr/share/klive/klive.tac
              /etc/init.d/klive
              ...où le script d'init lance twisted sur le klive.tac et puis voilà, après ça tourne. Bref, faut pas hésiter à se faire une installation manuelle, ou un paquet, c'est vraiment trivial.
  • # Distribs?

    Posté par . Évalué à 1.

    A quand les packages pour les distrib les plus populaires?
    • [^] # Re: Distribs?

      Posté par . Évalué à -10.

      > Klive n'a pas besoin d'être compilé ni d'être exécuté avec les permissions du superutilisateur.

      Je précise au passage que c'est vrai pour 90% des logiciels présentés ici...

      > A quand les packages pour les distrib les plus populaires?

      On vous "recommande" d'installer un logiciel en tant qu'utilisateur normal, vous demandez à l'installer en root... Y'a de la mdk dans l'air...
      • [^] # Re: Distribs?

        Posté par . Évalué à 10.

        On vous "recommande" d'installer un logiciel en tant qu'utilisateur normal, vous demandez à l'installer en root... Y'a de la mdk dans l'air...


        On ne recommande rien du tout, on dit juste qu'il n'a pas besoin d'être root. Personnelement, même si je peux installer un programme en tant qu'user, je préfère en faire un package. C'est tellement plus simple pour le virer plus tard quand on ne sait même plus dans quel répertoire on l'a installé. Et j'imagine que c'est pour la pluspart des gens la même chose, rien à voir avec mdk.
        • [^] # Re: Distribs?

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

          Gentoo dispose d'un package pour klive depuis le 10 janvier.
          http://packages.gentoo.org/ebuilds/?klive-0.16
          • [^] # Re: Distribs?

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

            J'ai voulu aller plus vite que la musique, résultat je dis des bétises.
            Klive-0.7 à été inclus dans portage le 11 Sep 2005.
            Il ne s'agit donc pas d'une nouveauté.
        • [^] # Re: Distribs?

          Posté par . Évalué à -10.

          C'est que tu n'as rien compris à la notion d'ustilisateur et surtout de super-utilisateur...

          Tu sacrifies grandement la sécurité pour qqes avantages de rapiditié d'installation...

          Je pleure d'entendre des debianeux dire des choses pareilles...
          • [^] # Re: Distribs?

            Posté par . Évalué à 8.

            Euh tu es sur d'avoir tout compris ? Installer un package ne veut pas dire qu'il va tourner nécessairement en root.
      • [^] # Re: Distribs?

        Posté par . Évalué à -9.

        Tu utilises une Debian... pardon...

        J'me demande d'ailleurs pourquoi tous ces gens installent des debian/unbutu, ils feraient mieux de rester sous mdk jusqu'à vraiment savoir ce qu'est linux et l'info en général, ça évitrait les trolls dui style :

        YYY : "debian ça rocks !"
        Moi : "pourquoi ?"
        YYY : "paske" (ou des fois pour les plus au courant : "paske c'est plus sécurisé", laissez moi rire...)

        (excusez je suis méchant, d'habitude c'est pas dans ma nature, mais les réponse comme celle de ce monsieur ça me dépasse...)
        • [^] # Re: Distribs?

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

          T'as bien regardé les notes de tes commentaires là ? Je ne pense pas que ce soit parceque tu es méchant, mais parceque tu te trompes et tu persistes.
        • [^] # Re: Distribs?

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

          En suivant TA logique, vu le niveau de tout ce que tu dis, tu ferais mieux de rester sous Windows Xp...
      • [^] # portnawak

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

        installer un package (via su/sudo) ne signifie pas que le programme sera lancé par root ni qu'il sera su-bitisé ! heureusement.. ça permet juste à tout-le-monde de pouvoir utiliser le programme (étant installé dans dans /usr/* ou /usr/local/*)

        Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. \n -- Jules Claretie

  • # Idée à généraliser

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

    Je pense que ce qui s'applique pour le noyau s'applique de manière aussi, voire encore plus critique pour le serveur X.

    Automatiser le rapport : je fais fonctionner telle version de telle carte, avec telle moniteur, telle souris, à telle résolution, etc. vers un serveur public, ce serait pratique pour les developpeurs (retour sur ce qu'ils font) et pour les utilisateurs (est-ce qu'un gars a un jour réussi avec une telle combinaison, etc. avant d'acheter le matos) d'un certain niveau cela va de soi...

    A priori tout ce qui touche au matériel aurait grand besoin de reporting.

    Reste à assurer : la confiance en celui qui collecte les données (que son script fasse pas n'importe quoi) et en celui qui les envoie (qu'on pourrisse pas la base avec des données fausses.)

    Enfin cela dit, je connais rien au python. En fait, j'en ai même plutôt peur. Ca etouffe ou ça empoisonne, ces bêtes-là ?
    • [^] # Re: Idée à généraliser

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

      Automatiser le rapport : [...] avec telle moniteur

      s/moniteur/monitrice

      ----tout schuss--->[]
    • [^] # Re: Idée à généraliser

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

      Ubuntu a un outil qui reporte le matériel utilisé.
      Il existe aussi un script (en Perl) chez LinuxCounter qui rapporte quelques infos à intervalles réguliers, comme le processeur utilisé, le type de kernel ou le nombre de comptes utilisateurs créés :
      http://counter.li.org/scripts/

      Il suffirait de les étendre un peu plus et d'augmenter leurs possibilités pour avoir des informations fiables.
  • # Pourquoi un répertoire aléatoire?

    Posté par . Évalué à 3.

    Le script effectue l'installation automatiquement : il télécharge le client, le copie dans un répertoire aléatoire et intègre une nouvelle tâche dans cron pour l'éxécuter à intervalle régulier.

    Pourquoi le copier dans un répertoire alétoire? J'ai beau chercher, je ne vois pas l'utilité...

    "Il faut" (Ezekiel 18:4) "forniquer" (Corinthiens 6:9, 10) "avec des chiens" (Thessaloniciens 1:6-9) "morts" (Timothée 3:1-10).

    • [^] # Re: Pourquoi un répertoire aléatoire?

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

      J'imagine une question de sécurité : si le répertoire était connu, "on" pourrait tenter de récupérer les informations, qui pourraient être précieuses pour organiser une attaque.
      Genre "ah, mon ami, tu as un noyau 2.6.6 de chez XXX... parfait, tu n'es pas protégé contre telle attaque...

      bon, bien sûr, faut AUSSI que l'attaquant puisse lire le fichier sur le système. Mais 2 précautions valent mieux qu'une !
  • # C'est pour qui ?

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

    Est-ce que c'est une bonne idée que des utilisateurs "standard" (au sens utilisation bureautique, internet et qui ne recompilent pas leur noyau) diffusent leur numéro de version ?

    A ce que dit la nouvelle, ce logiciel a été créé pour savoir combien de gens testent les -git, -rc et -pre : est-ce utile de s'ajouter si on utilise un noyau stable ?
    • [^] # Re: C'est pour qui ?

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

      visiblement, il y a les branches mandriva, redhat etc...
      et les noyaux présents sont les stables dans ces branches, donc je pense que l'on peut !
      après dire si c'est nécessaire...

Suivre le flux des commentaires

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