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 Ermaion (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 seraitcat /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'estsystemctl
maintenant qu'il faut privilégier.# C'est crade…
Posté par Zylabon . É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 Ermaion (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 Zylabon . É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 Ermaion (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 symoon . É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 Linuxator (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 bernie . Évalué à 6.
lsb_release pourrait probablement faire l'affaire :
C'est peut-être même relativement standard :
http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/lsbrelease.html
[^] # Re: lsb_release
Posté par Ermaion (site web personnel) . Évalué à 2. Dernière modification le 13 juillet 2013 à 15:05.
Je confirme que ça marche pour CentOS 6.
"CentOS release 6.4 (Final)"
[^] # pas pour Archlinux
Posté par pralines . Évalué à 2.
la liste des distributions certifiées LSB
https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb
Envoyé depuis mon Archlinux
[^] # Re: pas pour Archlinux
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Debian n'est pas dans la liste et il y a des paquetages lsb… Ces certifications sont certainement payantes donc non faite par les distributions communautaires.
# cat /proc/version
Posté par Benjamin_Perdrielle . É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,
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 NeoX . Évalué à 3.
ubuntu :
debian lenny chez mon hebergeur :
debian squeeze chez mon hebergeur :
[^] # Re: ici lsb_release semble le plus pertinent.
Posté par Benjamin_Perdrielle . É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 :
avec lsb-release :
avec /proc/version :
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 Linuxator (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.