Bonjour,
Afin de créer un module pour créer facilement des services systèmes, je cherche à mieux comprendre systemv, ou init.d, u rc.d.
En fait, j'ai jamais compris ce truc, et cela ne c'est pas arrangé.
Déjà je voudrais savoir si c'est encore utilisé, ou si le support est déprécié.
Sinon, je voudrais comprendre si je dois utiliser la commande chkconfig, system, ou /etc/init.d/mon_service pour gérer/démarrer tout cela.
Enfin, je voudrais vous demander de partager des ressources simples d'accès pour travailler avec ce système d'init. Car j'en trouve bien peu en fait.
J'aurais surement bien d'autres questions, mais dans l'immédiat je voudrais lancer le sujet.
Merci,
a+
# SystemV RC est obsolète
Posté par Tonton Benoit . Évalué à 2.
Les systèmes d'init sont spécifiques à chaque distribution, il faut se référer à la documentation de chacune.
Cependant beaucoup de distributions ont adoptées Systemd, qui n'utilise pas des scripts mais des fichiers de configuration appelés "unit" https://www.freedesktop.org/software/systemd/man/systemd.unit.html
[^] # Re: SystemV RC est obsolète
Posté par mh-cbon . Évalué à 3.
ah systemd, il c'est bien fais cracher dessus, pourtant, j'ai trouvé que c'était rapide à prendre à main, et agréable à utiliser. En tout cas , je me galère moins avec systemd, ou même sc (!!), qu'avec les scripts d'init…
[^] # Re: SystemV RC est obsolète
Posté par freem . Évalué à 4.
Oh oui, il s'est fait beaucoup descendre… avec des raison bien foireuses pour la plupart (codé par lennart et abandon des scripts dans la config sont mes 2 préférées de ce point de vue la, mais certains invoquent aussi le fait que ce soit du linux-only) mais si moi je n'ai pas envie de l'utiliser, c'est tout simplement parce qu'il est envahissant et que le projet n'a pas l'air d'avoir de bornes clairement définies. Et je préfère aller vers un système dont je peux changer les composants séparément que vers un système monolithique.
Enfin, dans le genre système d'init qui à l'air sympa, il y a runit. Simple et efficace, je trouve. Je l'ai adopté sur une machine (debian), il est vraiment facile à mettre en place, assez pour me donner envie de tester voidlinux (distrib qui en fait son init par défaut).
Pour ce qui est de la mort de sysVinit, c'est probablement l'une des meilleures choses qui pouvaient arriver, quand on voit la tronche des scripts… erk! je comprend vraiment pas comment des gens ont pu sortir l'argument que sysVinit est "plus simple" à maîtriser que systemd…
[^] # Re: SystemV RC est obsolète
Posté par mh-cbon . Évalué à 1.
Bon, je ne promettrais pas d'intégrer runit, on verra !
Mais le fait que tu en parles m'a fait prendre conscience qu'il y en avait pléthore…
https://wiki.archlinux.org/index.php/init
du coup je vais surement me tourner vers un système de plugin pour laisser à d'autres le soins de remplir les trous le moment venu.
[^] # Re: SystemV RC est obsolète
Posté par freem . Évalué à 2.
Je ne suis pas trop sûr de savoir ce que tu veux faire en fait.
Si tu écrits un daemon, le mieux me semble de t'assurer que ton daemon se méfie de l'OS comme de la peste (en fait, l'OS et tous les processus externes doivent être considérés comme des utilisateurs, et donc pouvant dire de la merde, pour une sécurité maximale), et vérifie tous les pré-requis au minimum à l'initialisation. Dans le cas d'un outils de sécurité, tu devras aussi t'arranger pour chiffrer la RAM, mais, honnêtement, je n'ai jamais creusé. Sûrement un truc bien pénible à faire, et certainement pas la 1ère cause de problèmes.
Tout ça est souvent plus simple à faire dans le code exécutable plutôt que par le système d'init: il suffit de vérifier chaque retour de chaque fonction d'I/O pour être sûr que l'I/O s'est bien passée. C'est chiant, mais bon… Sinon, il y a les exceptions, mais c'est à éviter comme la peste si tu ne codes pas un binaire unique (édition des liens statique): il se pourrait que l'API ou l'ABI varie avec le temps, amenant des bugs particulièrement mesquins. La contrepartie d'une édition de liens statique, c'est un binaire potentiellement plus gros. Dans les faits, j'ai plus constaté un binaire plus petit… L'autre problème, c'est la difficulté de mise à jour. Elle ne se pose que peu pour un logiciel libre, surtout que de nos jours les CPU sont des monstres, mais pour un logiciel fermé, c'est différent.
Si tu ne peux pas, ou ne veux pas, vérifier tous les pré-requis correctement, alors tu te dois au minimum de les indiquer dans la doc… enfin, si tu prétends être fier de ton œuvre. Pour moi, soit le code vérifie de manière explicite les pré-requis, soit la doc les spécifie. Et l'idéal, c'est quand les deux sont réunis (mais, c'est rare, parce que c'est déjà chiant d'en faire un, alors les deux… argh!).
Si tu écris un système d'init, alors… hum, bon courage, mais dans ce cas tu sais probablement déjà ce que tu fais, ou alors tu cherches à apprendre pour le fun, donc pas de soucis.
[^] # Re: SystemV RC est obsolète
Posté par mh-cbon . Évalué à -1.
mhh au risque de te décevoir ce que je veux faire est bien plus simple que tout cela, je crois !
J'écris
undes modules pour installer des applications node en tant que service système, étant insatisfait des solutions existantes.Ce la ne s'adresse pas à des entreprises, elles devraient payer des gens compétents pour résoudre leurs besoins de manière adéquat, un sysadmin dans ce cas là, mais à l'installation d'application sur un système de tous les jours en dehors d'un système de gestion de paquet par distribution.
Dans l'absolu, ce n'est pas très compliqué, par contre je me cogne des flopées de difficultés supplémentaire (GENRE powershell) pour l'intégration des tests par OS / système d'init. Et puis des lourdeurs liées à la multiplicité des OS/système d'init, et aussi à la virtualisation qui nécessite de télécharger des images de macos de 15 GB (!!!!), ou de devoir nettoyer la box à chaque itération de test, ou encore de devoir tester x versions de tels systèmes.
..des trucs comme ça.. pas le plus fun. Mais nécessaire pour fournir un fine un paquet qui devrait pouvoir évoluer sans accrocs, étant convenu dès le départ qu'étant donné la multiplicité des OS / système d'init / versions il serait difficile de fournir une réponse parfaite du premier coup.
# les trois mon capitaine
Posté par NeoX . Évalué à 5.
tu stockes les infos de ton service dans /etc/init.d/tonservice.
suivant la distribution, tu utilises chkconfig/update-rc.d/system pour activer/desactiver un service au demarrage de la machine
ensuite tu utilises :
service tonservice start (reload, stop)
systemctl tonservce start (reload, stop)
/etc/init.d/tonservice start (reload, stop)
pour agir sur le service en question
[^] # Re: les trois mon capitaine
Posté par mh-cbon . Évalué à 1.
Ah cool merci!
C'est du pareil au même chkconfig/update-rc.d ?
Si je devais définir un fichier de PID / lock / répertoire de travail, sais tu si il y à une recommandation des chemins par distrib ou si je peux en trouver une générale pour tout le monde ?
Est ce qu'il y à une reco générale réponse-à-tout pour la wd d'une application serveur ?
Au sujet des runlevels, pour ce même genre d'application, et d'après ce que j'ai lu, [2345] c'est correct ?
Et aussi j'ai cherché à savoir si ces scripts d'init pouvait être définit par utilisateur, à la manière de systemd / launch, il me semble que non, le confirmes tu ?
Il y a encore beaucoup de distrib avec ce système d'init ?
Sais tu m'en citer une pour que je récupère une box vagrant adéquat par la suite.
Par curiosité, est ce que système gère la surveillance de process et leurs réactivation automatique ? Vu que ce sont de simple scripts bash, j'ai des doutes tout d'un coup !
Désolé de te bombarder de questions ! Et encore merci.
[^] # Re: les trois mon capitaine
Posté par NeoX . Évalué à 4.
pour les chemins PID/lock et WD, je penses que le mieux c'est de respecter la LSB
pour les runlevels, c'est assez standard mais c'est un heritage de SysV/Init.d
https://fr.wikipedia.org/wiki/Run_level
sous linux generalement, ce qui touche au systeme est parametré par le super utilisateur (donc root)
simplement pour des questions de sécurité.
maintenant rien ne t'empeche de mettre le service en demarrage pour l'utilisateur en question, à ce moment là c'est un service qui se lance quand l'utilisateur se loggue
ou si cela doit se lancer meme si personne n'est devant la machine, c'est à root de l'installer, quitte à faire appartenir le process à un utilisateur lambda pour limiter ses droits.
Systemd devient la tendance mais SysV à la peau dur, on en trouve des traces dans les distribs actuelles.
donc si tu prend une debian 6/7/8 tu verras par exemple les evolutions du systeme d'init
[^] # Re: les trois mon capitaine
Posté par mh-cbon . Évalué à 1.
Concrètement parlant, modifier le .bashrc ? ou .profile ?
Y mettre un /etc/init.d/mon_service start ?
Cela me fait réagir, est ce une bonne pratique de toujours créer un nouveau compte utilisateur par serveur ? quitte à pourrir la liste d'utilisateurs.
Ou bien un nobody adéquatement géré fera mieux l'affaire ?
[^] # Re: les trois mon capitaine
Posté par NeoX . Évalué à 3.
1°) pour ton utilisateur, ben ca depend
est-ce qu'il se loggue sur la machine avant de lancer le service ?
quel shell utilise-t-il ?
2°) nobody pour tout tes services : certains serveurs ne voudront pas demarré, et les serveurs entre eux pourraient communiquer ou acceder à des données de l'autre.
un compte par serveur : tu limites l'interaction entre les serveurs.
si tu regardes bien ta machine tu verras quand meme que c'est souvent un utilisateur par service (mysql, apache, ftp, bind/named, etc)
et les UID peuvent aller jusqu'a 65535, tu peux en mettre des serveurs sur la machine :D
[^] # Re: les trois mon capitaine
Posté par mh-cbon . Évalué à 1. Dernière modification le 30 mars 2016 à 16:46.
Des questions et remarques intéressantes en tout points.
Ce qui au final me fait réfléchir sur la quantité d'options à fournir / définir pour déclarer un service.
1/ En fait, cela dépendra de savoir comment l'administrateur désirera faire le setup ? Et si je voulais automatiser la chose, je pourrais partir sur des préférences définies par le mainteneur de l'application pour prendre des décisions automatiquement.
2/ clair, à priori des utilisateurs différent*. Avec les mêmes remarques que pour 1, car finalement, un admin peut explicitement vouloir exécuter deux serveurs avec le même compte.
* puisque ce n'est pas un système intégré, donc les serveurs ne se connaissent pas, à priori.
[^] # Re: les trois mon capitaine
Posté par NeoX . Évalué à 3.
voir ce que font les autres
dans la plupart des distribs, c'est le paquet d'installation du serveur qui determine un reglage "par defaut" avec un utilisateur si besoin, des actions de base, et un script (fichier de config) pour le mettre au demarrage de la machine
parfois le systeme d'installation pose quelques questions à l'utilisateur pour savoir si ca doit demarrer automatiquement au boot, si ca doit etre utilisé avec tel ou tel utilisateur.
[^] # Re: les trois mon capitaine
Posté par freem . Évalué à 4.
Debian permets de désinstaller systemd et de le remplacer par sysVinit. Tu as également la possibilité d'utiliser openrc ou upstart.
# laisser un mot
Posté par mh-cbon . Évalué à -6.
Pour vous signifier que malgré vous, et grâce à vos réponses, mes modules sortent du clavier, et ça c'est cool !
Alors merci a vous trois !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.