Forum général.général commande de reconnaissance de la distribution hôte

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
0
13
juil.
2013

Salut les Linuxiens de tous bords,
Je voudrai savoir si il existe une commande utilitaire Coreutils présent par défaut dans toutes les distribution Linux qui revoie le nom de la distribution hôte de la machine.
Avec Ubuntu il est possible de voir ça avec la commande:
uname -v

75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013

donc un:
uname -v | grep Ubuntu

ferait l'affaire mais ce n'est pas le cas de toutes les distributions Linux.
Je vous serai donc reconnaissant si vous connaissez une commande qui répond a ce besoin spécifique de connaître la distribution ou si vous avez une autre solution a me proposer sachant que:
Je cherche surtout a connaître le moyen de mettre un script au démarrage avec les dossier /etc/init.d/ (de l'ancien système de démarrage init) encore compatible grâce a l'édition de liens symbolique avec des outils spécifique a la distribution comme:
-chkconfig (Fedora, Red Hat)
-insserv (Suse)
-updaterc.d (Ubuntu et affilier Debian)

Je peut le faire manuellement en reconnaissant la distribution, le but bien sur est de créer un script qui marche sur la plupart des distribution.

Merci pour vos réponses.

  • # Peut-être une piste

    Posté par  (site web personnel) . Évalué à 2. Dernière modification le 13 juillet 2013 à 14:21.

    Je ne suis pas certain qu'il y est une méthode universelle. Pour Fedora/RHEL ce serait la commande cat /etc/redhat-release pour Debian apparemment (j'en ai pas sous la main maintenant) ce serait cat /etc/debian_version.

    Essai peut-être d'écrire un script avec une condition qui test la présence de chacun de ces fichiers avant d'exploiter le résultat.

    Au fait ckconfig c'est terminé pour Fedora et la prochaine RHEL ; c'est systemctl maintenant qu'il faut privilégier.

  • # C'est crade…

    Posté par  . Évalué à 8.

    Personnellement je ne supporte pas ce genre d'initative. Si j'installe un logiciel j'ai envie de l'installer, pas lancer le démon automatiquement, pas qu'il modifie mes fichiers de conf pour ajouter une icone sur mon bureau, pas qu'il modifie mon crontab pour faire je ne sais quoi…

    J'ai installé freenet une fois, et ce qu'ils ont fait, cette bande de porcs (désolé, pas d'autre mot, c'est mérité) c'est ajouter automatiquement une règle @reboot dans le cron de l'utilisateur… Bordel de merde… Il m'arrive de me connecter avec ma machine à des réseau sur lesquels ce genre de chose est hautement interdites.
    C'est impardonnable.

    Bref, mauvaise idée, c'est pas toi de faire ça. Si les packagers ont envie de le faire, ils le feront.

    Please do not feed the trolls

    • [^] # Re: C'est crade…

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

      Ça dépend énormément du type de programme. Déja-Dup par exemple je pense, modifie le crontab et, en l'occurence, c'est parfaitement justifié.

      • [^] # Re: C'est crade…

        Posté par  . Évalué à 3.

        Non il utilise ~/.config/autostart, c'est fait pour ça. Et là encore je sais pas comment ça se passe quand on installe la version « upstream », mais je pense qu'il ne devrait pas être actif par défaut.

        Please do not feed the trolls

        • [^] # Re: C'est crade…

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

          Je veux bien (je n'ai pas de Deja-Dup sous la main pour vérifier) mais à quoi sert cron et anacron alors ? C'est vrai que Dja-Dup est un mauvais exemple mais d'autres programme n'ont pas le choix de passer par cron ; en environnement serveur par exemple.

      • [^] # Re: C'est crade…

        Posté par  . Évalué à 2.

        En l'occurrence, /etc/cron.d/ existe, il suffit d'y poser le micro bout de crontab spécifique au démon installé.
        Modifier la crontab dynamiquement est immonde et peu robuste.

        • [^] # Re: C'est crade…

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

          Il y a une erreur de jugement de mon programme ou plutôt concernant ma démarche, le script d'installation doit connaître le système de lancement car c'est un outil de sécurité empêchant de démarrer le système si vous n'êtes pas là, c'est tout.
          Et concernant ma démarche j'ai poster sur d'autre forums et lsb_release serai la meilleurs solution mais ont peut tout a fait faire un switch case avec les nom des distributions, qui a moins de ne pas connaître le nom de sa distribution, ferai choisir le client interactivement…
          Merci pour vos nombreuse réponses.

  • # lsb_release

    Posté par  . Évalué à 6.

    lsb_release pourrait probablement faire l'affaire :

    $ lsb_release -ds
    Ubuntu 13.04
    

    C'est peut-être même relativement standard :
    http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/lsbrelease.html

  • # cat /proc/version

    Posté par  . Évalué à 1.

    Sans se lancer la question de savoir si c'est bien ou pas de vouloir installer des scripts de démarrage sans avertir l'utilisateur,

    cat /proc/version
    

    Il donne même la version de gcc avec laquelle la distribution a été compilée.
    ça peut s'avérer utile si le programme que l'on essaye d'installer nécessite une compilation de module.

    Testé sur ubuntu, debian, opensuse, fedora.

    L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

  • # ici lsb_release semble le plus pertinent.

    Posté par  . Évalué à 3.

    ubuntu :

    :~$ cat /proc/version
    Linux version 3.8.0-26-generic (buildd@panlong) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013

    :~$ cat /etc/issue
    Ubuntu 13.04 \n \l

    :~$ lsb_release -ds
    Ubuntu 13.04

    debian lenny chez mon hebergeur :

    :~$ cat /proc/version
    Linux version 2.6.26-2-686 (Debian 2.6.26-24) (dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Mon Jun 21 05:58:44 UTC 2010

    :~$ cat /etc/issue
    Debian GNU/Linux 4.0
    Linux machine.example.com 2.6.26-2-686 #1 SMP Mon Jun 21 05:58:44 UTC 2010 i686 GNU/Linux
    server : xxxxxx
    ip : AA.BBB.CCC.DD
    hostname : machine.example.com

    :~$ lsb_release -ds

    Debian GNU/Linux 5.0.10 (lenny)

    debian squeeze chez mon hebergeur :

    :~$ cat /proc/version
    Linux version 2.6.34.6-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #3 SMP Fri Sep 17 16:06:38 UTC 2010

    :~$ cat /etc/issue
    Linux machine.example.com 2.6.34.6-xxxx-grs-ipv6-64 #3 SMP Fri Sep 17 16:06:38 UTC 2010 x86_64 GNU/Linux
    server : xxxxxx
    ip : aaa.bbb.ccc.ddd
    hostname : machine.example.com

    :~$ lsb_release -ds
    Debian GNU/Linux 6.0.7 (squeeze)

    • [^] # Re: ici lsb_release semble le plus pertinent.

      Posté par  . Évalué à 0. Dernière modification le 16 juillet 2013 à 21:56.

      Pour voir la pertinence, il faut tester dans beaucoup de cas de figure, même les plus improbables :

      /etc/issue n'est qu'un message d'acceuil après connexion qui peut se modifier manuellement, donc en ce qui me concerne, cette option n'est pas envisageable.

      reste lsb-release et cat /proc/version.

      Dans les exemples que tu as donné lsb-release indiquent une distrib, mais cat /proc/version est bien plus parlant. on voit que se sont des versions migrées sur la partie applicative. Par contre Les kernels sont d'origine. Compréhensible vu que les noyaux sont LTS (enfin plus le premier) et que sur des serveurs de prod on ne migre pas les noyaux comme ça. Dans le cas d'une installation qui nécessite une compilation de module (Par exemple un logiciel de virtualisation), une détection avec lsb-release peut s'avérer problématique.

      Personnellement j'ai fait beaucoup de tests avec lsb-release dans le cadre du développement d'un applicatif d'inventaire, et ça ne fonctionne pas dans tous les cas. raison pour laquelle je l'ai relégué en dernier plan pour mes programmes d'inventaires. Petit test bête sur une distrib cliente modifiée uniquement sur la partie noyaux (modifs minimes sur la partie applicative).

      Bien que ridicule, j'ai fait un cat /etc/issue :

      Benjamin@rw-asus-01:~> cat /etc/issue
      Welcome.
      

      avec lsb-release :

      Benjamin@rw-asus-01:~> lsb-release -a
      LSB Version:    n/a
      Distributor ID: n/a
      Description:    (none)
      Release:    n/a
      Codename:   n/a
      

      avec /proc/version :

      Benjamin@rw-asus-01:~> cat /proc/version
      Linux version 3.10.1-desktop (root@rw-asus-01.farscape.lan) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP Mon Jul 15 22:58:14 CEST 2013
      

      Dans le cas présent seul cat /proc/version a été capable de me donner une info fiable.

      L'intelligence, c'est le seul outil qui permet à l'homme de mesurer l'étendue de son malheur. (Pierre Desproges)

  • # Merci pour vos nombreuse réponses.

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

    Merci pour vos nombreuses réponses.
    La solution la plus bête mais la plus efficasse serai de faire un switch case avec le nom des distributions pris en charge, qui ne connaît pas le nom de sa distribution ?
    J'ai lu que le nouveau système de lancement ne serai pas rétrocompatible avec le bon anciens init…
    Ce qui serai gênant dans le cas de mon script pour le futur.
    Encore merci pour vos nombreuse réponses qui me serai utile pour une éventuelle option d'auto détection si l'utilisateur aurai une panne de cerveau pendant l'installation et aurai oublier le nom de sa distribution.
    (Désolé cette idée m'est venue après avoir poster)

Suivre le flux des commentaires

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