Alors on commence par la fin :
J'utilise toujours ifconfig. Sur mes vms j'ai des cartes réseaux qui sont rajoutés dynamiquement, des VPN et des émulateurs ports com qui viennent se mettre par dessus en fonction des besoins et malgré plusieurs tentatives je ne vois pas comment gérer ce genres de choses avec ifup, ip et consors. Surtout que je n'ai pas forcément besoin de TCP/IP sur ces cartes, et que je ne veux pas surtout pas de link-local/mDNS.
Donc sur mes cartes dynamiques, c'est des sets de règles udev et des scripts à base d'ifconfig qui se lancent.
Par contre route, clairement je l'utilise quand j'ai besoin. ifconcig ne pas faire grand chose niveau route.
En ce qui concerne le lancement du wrapper, il est lancé par systemd dans le mode le plus bête possible (pas de surveillance, pas de restart, forcé dans un slice dégénéré avec des droits sur la majorité des cgroups etc.) Le fait que systemd ait été choisit par Debian m'impacte peu. Je vais utiliser les outils Debian dans la mesure du possible, mais très vite je diverge de ce qui est fourni. Pour Apache, Nginx, Postgres/PostGIS, postfix, Nagios/Zabbix, Java/Tomcat etc. J'utilise mes propres packages avec mes propres scripts d'init. Dans la majorité des cas les choix fait par Debian ne sont pas les choix optimaux pour ma production. Pour moi Debian est une base (et un très bonne base, j'aime vraiment beaucoup cette distribution) mais je n'ai aucune hésitation à m'écarter de cette base si ça m'apporte quelque chose.
En ce qui concerne systemd strictement, la réponse courte est que systemd a trop de lacunes par rapport aux systèmes d'init historiques pour me permettre de faire tout ce dont j'ai besoin. J'ai besoin de services dynamiques, j'ai besoin de pouvoir forcer certains démarrages en mode séquentiel sans pour autant qu'il y ait dépendance (i.e le service b doit se lancer après le service a et ce même si le service a échoue à se lancer - ce genre de condition sont très courantes quand on fait du fencing notamment) et par dessus tout j'ai besoin que des utilisateurs des machines distantes et des services puissent relancer d'autres services sans nécessairement avoir les droits root (et également sans avoir à créer des slices dégénérés tous les quatre matin)
Pour finir avec ton tutorial, je l'ai lu comme un exemple simple à compléter (que ce soit avec de l'ansible, du saltstack ou des recette cook) et j'ai bien conscience que la pédagogie va parfois à l'encontre de la propreté/qualité. La méthode qui consiste à donner un exemple qui fonctionne et que tout le monde comprend - avant d'expliquer pourquoi il ne faut jamais faire comme ça - est tout à fait valable.
C'est juste la réaction de Christophe B. avec notamment son "En plus j'aime bien comment tu gères systemd / finalement c'est pas si compliqué" qui m'a fait froid dans le dos.
[^] # Re: Merci
Posté par Kaane . En réponse au journal Zabbix, autossh, systemd. Évalué à 1.
Alors on commence par la fin :
J'utilise toujours ifconfig. Sur mes vms j'ai des cartes réseaux qui sont rajoutés dynamiquement, des VPN et des émulateurs ports com qui viennent se mettre par dessus en fonction des besoins et malgré plusieurs tentatives je ne vois pas comment gérer ce genres de choses avec ifup, ip et consors. Surtout que je n'ai pas forcément besoin de TCP/IP sur ces cartes, et que je ne veux pas surtout pas de link-local/mDNS.
Donc sur mes cartes dynamiques, c'est des sets de règles udev et des scripts à base d'ifconfig qui se lancent.
Par contre route, clairement je l'utilise quand j'ai besoin. ifconcig ne pas faire grand chose niveau route.
En ce qui concerne le lancement du wrapper, il est lancé par systemd dans le mode le plus bête possible (pas de surveillance, pas de restart, forcé dans un slice dégénéré avec des droits sur la majorité des cgroups etc.) Le fait que systemd ait été choisit par Debian m'impacte peu. Je vais utiliser les outils Debian dans la mesure du possible, mais très vite je diverge de ce qui est fourni. Pour Apache, Nginx, Postgres/PostGIS, postfix, Nagios/Zabbix, Java/Tomcat etc. J'utilise mes propres packages avec mes propres scripts d'init. Dans la majorité des cas les choix fait par Debian ne sont pas les choix optimaux pour ma production. Pour moi Debian est une base (et un très bonne base, j'aime vraiment beaucoup cette distribution) mais je n'ai aucune hésitation à m'écarter de cette base si ça m'apporte quelque chose.
En ce qui concerne systemd strictement, la réponse courte est que systemd a trop de lacunes par rapport aux systèmes d'init historiques pour me permettre de faire tout ce dont j'ai besoin. J'ai besoin de services dynamiques, j'ai besoin de pouvoir forcer certains démarrages en mode séquentiel sans pour autant qu'il y ait dépendance (i.e le service b doit se lancer après le service a et ce même si le service a échoue à se lancer - ce genre de condition sont très courantes quand on fait du fencing notamment) et par dessus tout j'ai besoin que des utilisateurs des machines distantes et des services puissent relancer d'autres services sans nécessairement avoir les droits root (et également sans avoir à créer des slices dégénérés tous les quatre matin)
Pour finir avec ton tutorial, je l'ai lu comme un exemple simple à compléter (que ce soit avec de l'ansible, du saltstack ou des recette cook) et j'ai bien conscience que la pédagogie va parfois à l'encontre de la propreté/qualité. La méthode qui consiste à donner un exemple qui fonctionne et que tout le monde comprend - avant d'expliquer pourquoi il ne faut jamais faire comme ça - est tout à fait valable.
C'est juste la réaction de Christophe B. avec notamment son "En plus j'aime bien comment tu gères systemd / finalement c'est pas si compliqué" qui m'a fait froid dans le dos.