Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
Allez hop zou juste avec OpenVPN qui est une des solutions soutenue par Fedora/RH :
1) On peut pas lancer tout un tas de tunnels en une seule commande (un peu con pour le PPoE+VPN) https://bugzilla.redhat.com/show_bug.cgi?id=744244
En fait on ne peut même pas activer les services dont les fichiers de conf sont basés sur des templates : https://bugzilla.redhat.com/show_bug.cgi?id=752774
Au final il faut créer les liens symboliques à la main si on veut plusieurs VPN/VNC/VSFTPD etc. Toute la lourdeur des vieux sysvInit au service de la rigidité systemd.
Confirmé sur le site officiel de Fedora : http://fedoraproject.org/wiki/Openvpn, à partir de Fedora16 il faut éditer les liens symboliques à la main…
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Interfaces actives, possibilité d'envoyer et de recevoir des trames.
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
Le truc c'est que ca fait beaucoup trop.
J'ai besoin d'activer iptables AVANT tcp/ip (enfin besoin est un bien grand mot - disons que ca m'évite de patienter/tuer dhclient à la main et de relancer les scripts à la main.) Sauf systemd a besoin que tout network remonte d'un bloc (sinon il panique).
Voici ce que je voudrais qu'il se passe :
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) chargement des iptables (dont j'ai besoin pour mes VPN)
c) connection pptp
d) connection VPN
e) chargement IP et initialisation de la couche IP pour int0
Ce qu'il se passe
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) Tout network rapplique avec IP et tout le toutim
c) chargement de iptables
c - en parallèle et je peux rien y changer) La couche IP s'initialise pour int0, dhclient commence à tourner dans le vide
d) connection pptp
e) connection VPN : echec vu que IP et dhclient ont déjà la main sur int0
f) login prompt
g) à la mano on down int0
h) à la mano on relance VPN
i) à la mano on up int0
Alors bien sur on peut tricher en ne créant le bridge et le VPN qu'une fois que tout le reste a démarré, mais ca ralenti le boot, et les config deviennent chiante à lire, surtout qu'il ne faut pas oublier d'effacer/refaire les liens symboliques en cas de changement.
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload.
Et tu fais ca comment en systemd ? Il y a deux reload en systemd
systemctl nomduservice reload -> recharge la config compilée pour nomduservice, ignore complètement le fichier ini
systemctl daemon-reload -> recompile toutes les configs de tous les services activés.
Ben que je suis en maintenance, je ne veux ni l'un ni l'autre et il n'y en a pas de troisième.
ATTENTION : systemctl enable et systemctl disable lancent aussi une recompilation de toutes les configs.
Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part"
Et comment je dis à systemd de faire un reload d'un service mais avec un autre fichier de config ? J'ai 0 commande pour le faire, le seul truc que je peux faire c'est créer à la main des liens symboliques, éteindre le service et le relancer avec un autre nom en utilisant la conf du lien symbolique. Mais faire un reload depuis un nouveau fichier de config n'est pas possible en systemd (et vu la gestion des dépendances auto-évaluées ca ne le sera probablement jamais.)
si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse
Sans sytemd je suis propre (un seul fichier coherent avec lui même qui gère tout ce qui a besoin d'être pris en compte du début à la fin) avec systemd je ne sais pas faire. Donc oui je sauvegarde des fichiers temporaires et je les lits dans un autre script et oui c'est crade et oui je voudrais faire autrement, mais je peux pas.
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd".
a) C'est pas que la version "utilise le fichier PID" ne me plait pas, au contraire j'adorerai l'utiliser. C'est qu'elle ne marche pas vu que systemd ne relit pas le fichier régulièrement. Il le lit une fois, met les infos en mémoire et c'est fini.
b) Faire plusieurs unit ne fonctionne pas non plus.
En init classique mon premier programme de synchro récupère pleins de paramètres et lance le second programme avec ces paramètres. Hors je ne sais pas passer de paramètres d'une unit à l'autre en systemd. (Et là pourtant j'ai cherché) setenv ne fonctionne que dans l'inti et est accessible à tous les enfants (donc vachement pratique si on veut lancer plusieurs serveurs).
Pour finir j'ai pas besoin d'une unit pour le logiciel de sync, qui va nécessairement s’arrêter et qui n'a jamais besoin d'être lancé seul (limite ca serait même une très mauvaise idée).
Comme je suppose que tu va me dire "j'utilise pas pam"
Si j'utilise pam, mais le problème n'est pas là. C'est très bien que pam déplace les instance sshd d'un cgroup à l'autre. Mais ca me rajoute encore un truc de plus pour que ca fonctionne normalement. Et en plus même si j'ai pam, tout le monde ne se logue pas nécessairement via pam. Si je me logue par certif il se passe quoi ? Et par kerberos ? Et par ldap ? Et si le process d'authentification n'est pas sur la même machine que le ssh ? Et si c'est même pas un linux ?
Est-ce que ca marche si j'oblige tout le monde à passer par pam et que j'utilise les modules pam-* qui vont bien ? Et quand je met à jour il se passe quoi ?
Le truc c'est pas que ce soit impossible, c'est que ca me complique horriblement la vie. Et j'aime pas monter une usine à gaz pour retomber sur exactement le même résultat qu'avant.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner),
Ca doit pas être trop difficile à deviner vu que tu t'en sors.
que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd
Oui mais si on reprend les point précédents, à savoir
- systemd ne lance pas automatiquement les fichiers basé sur templates, il faut rajouter les liens symboliques à la main
- chaque serveur peut avoir plusieurs workers, donc plusieurs processus et j'aimerais bien tuer tous les processus d'un serveur sans abimer les autres (par exemple relancer tomcat admin mais pas les applis)
- les fichiers de config ne sont pas raffraichits automatiquement quand on les modifie.
Tu mets tout ça ensemble et tu arrives a des situations sympas avec ta solution :
Par exemple si un dev veut modifier le catalina ou créer un nouveau serveur, il faut qu'il te passe un coup de fil (ou qu'il ait les droits admin - et ça, c'est pas possible).
Comment tomcat admin va-t-il faire pour raccrocher les wagons ? Qu'est-ce qu'il se passe si je relance un site depuis tomcat-admin et pas depuis systemctl ?
Si j'ai un worker qui déconne ? Comment je le tue ? (je veux dire à part avec les droits root et un bon gros SIGKILL dans sa face) ?
[^] # Re: Questions
Posté par Kaane . En réponse au journal Linux from scratch face à udev. Évalué à 3.
Si c'est un gros point de ralage, tu va sans doute pouvoir donner des urls de tout ces gens qui ralent, voir un rapport de bug, qu'on puisse parler de trucs concrets, pas de "j'ai ce problème vague, et à chaque fois qu'un mec file une solution je sort un autre problème vague".
Allez hop zou juste avec OpenVPN qui est une des solutions soutenue par Fedora/RH :
1) On peut pas lancer tout un tas de tunnels en une seule commande (un peu con pour le PPoE+VPN)
https://bugzilla.redhat.com/show_bug.cgi?id=744244
En fait on ne peut même pas activer les services dont les fichiers de conf sont basés sur des templates :
https://bugzilla.redhat.com/show_bug.cgi?id=752774
Au final il faut créer les liens symboliques à la main si on veut plusieurs VPN/VNC/VSFTPD etc. Toute la lourdeur des vieux sysvInit au service de la rigidité systemd.
Confirmé sur le site officiel de Fedora : http://fedoraproject.org/wiki/Openvpn, à partir de Fedora16 il faut éditer les liens symboliques à la main…
Visiblement "avoir besoin de network", ça veut dire une chose bien précise pour toi, mais pas pour le reste du monde. Donc "avoir besoin de network", ça veut dire quoi pour toi ?
Interfaces actives, possibilité d'envoyer et de recevoir des trames.
Pour systemd ( et j'aurais tendance à dire pour les systéme d'init depuis des années ), ça veut dire que le sous système network est la, genre tu as l'interface lo qui est disponible à minima, et un programme qui peut avoir besoin d'une interface réseau non spécifique va réussir à se lancer, et raisonnablement supposer que le routage marche pour aller sur internet ou le réseau local, si besoin.
Le truc c'est que ca fait beaucoup trop.
J'ai besoin d'activer iptables AVANT tcp/ip (enfin besoin est un bien grand mot - disons que ca m'évite de patienter/tuer dhclient à la main et de relancer les scripts à la main.) Sauf systemd a besoin que tout network remonte d'un bloc (sinon il panique).
Voici ce que je voudrais qu'il se passe :
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) chargement des iptables (dont j'ai besoin pour mes VPN)
c) connection pptp
d) connection VPN
e) chargement IP et initialisation de la couche IP pour int0
Ce qu'il se passe
a) creation du pont ext0 interface réseau publique, int0 interface réseau privée
b) Tout network rapplique avec IP et tout le toutim
c) chargement de iptables
c - en parallèle et je peux rien y changer) La couche IP s'initialise pour int0, dhclient commence à tourner dans le vide
d) connection pptp
e) connection VPN : echec vu que IP et dhclient ont déjà la main sur int0
f) login prompt
g) à la mano on down int0
h) à la mano on relance VPN
i) à la mano on up int0
Alors bien sur on peut tricher en ne créant le bridge et le VPN qu'une fois que tout le reste a démarré, mais ca ralenti le boot, et les config deviennent chiante à lire, surtout qu'il ne faut pas oublier d'effacer/refaire les liens symboliques en cas de changement.
pour la maintenance, non je pige toujours pas. Quand je fait ça, je modifie la config, et je fait un reload.
Et tu fais ca comment en systemd ? Il y a deux reload en systemd
systemctl nomduservice reload -> recharge la config compilée pour nomduservice, ignore complètement le fichier ini
systemctl daemon-reload -> recompile toutes les configs de tous les services activés.
Ben que je suis en maintenance, je ne veux ni l'un ni l'autre et il n'y en a pas de troisième.
ATTENTION : systemctl enable et systemctl disable lancent aussi une recompilation de toutes les configs.
Donc si tu es parti sur "je refait les scripts d'init plutot que de faire un script de maintenance à part"
Et comment je dis à systemd de faire un reload d'un service mais avec un autre fichier de config ? J'ai 0 commande pour le faire, le seul truc que je peux faire c'est créer à la main des liens symboliques, éteindre le service et le relancer avec un autre nom en utilisant la conf du lien symbolique. Mais faire un reload depuis un nouveau fichier de config n'est pas possible en systemd (et vu la gestion des dépendances auto-évaluées ca ne le sera probablement jamais.)
si tu le fait pas et que tu rajoutes exprès des communications entre ton shell sous forme de variable et le script d'init, désolé, mais tu fais les choses de façon porcasse
Sans sytemd je suis propre (un seul fichier coherent avec lui même qui gère tout ce qui a besoin d'être pris en compte du début à la fin) avec systemd je ne sais pas faire. Donc oui je sauvegarde des fichiers temporaires et je les lits dans un autre script et oui c'est crade et oui je voudrais faire autrement, mais je peux pas.
Enfin, pour ton truc qui lance des services super long à démarrer au point de confondre systemd, vu que la suggestion "utilise le fichier pid" semble pas te plaire, je propose plus simplement "sépare ton script en plusieurs unités systemd".
a) C'est pas que la version "utilise le fichier PID" ne me plait pas, au contraire j'adorerai l'utiliser. C'est qu'elle ne marche pas vu que systemd ne relit pas le fichier régulièrement. Il le lit une fois, met les infos en mémoire et c'est fini.
b) Faire plusieurs unit ne fonctionne pas non plus.
En init classique mon premier programme de synchro récupère pleins de paramètres et lance le second programme avec ces paramètres. Hors je ne sais pas passer de paramètres d'une unit à l'autre en systemd. (Et là pourtant j'ai cherché) setenv ne fonctionne que dans l'inti et est accessible à tous les enfants (donc vachement pratique si on veut lancer plusieurs serveurs).
Pour finir j'ai pas besoin d'une unit pour le logiciel de sync, qui va nécessairement s’arrêter et qui n'a jamais besoin d'être lancé seul (limite ca serait même une très mauvaise idée).
Comme je suppose que tu va me dire "j'utilise pas pam"
Si j'utilise pam, mais le problème n'est pas là. C'est très bien que pam déplace les instance sshd d'un cgroup à l'autre. Mais ca me rajoute encore un truc de plus pour que ca fonctionne normalement. Et en plus même si j'ai pam, tout le monde ne se logue pas nécessairement via pam. Si je me logue par certif il se passe quoi ? Et par kerberos ? Et par ldap ? Et si le process d'authentification n'est pas sur la même machine que le ssh ? Et si c'est même pas un linux ?
Est-ce que ca marche si j'oblige tout le monde à passer par pam et que j'utilise les modules pam-* qui vont bien ? Et quand je met à jour il se passe quoi ?
Le truc c'est pas que ce soit impossible, c'est que ca me complique horriblement la vie. Et j'aime pas monter une usine à gaz pour retomber sur exactement le même résultat qu'avant.
Pour tomcat, je suppose (parce que comme d'hab, tu dit rien de précis donc faut deviner),
Ca doit pas être trop difficile à deviner vu que tu t'en sors.
que le souci vient du fait que quand tu relances tomcat, tu veux pas relancer chaque appli qui tourne à l'intérieur mais faire les choses de façon plus fine. Pour ça, pareil, je pense qu'il faut traiter chaque applications comme un service séparé, et trouver le moyen d'intégrer ça à systemd
Oui mais si on reprend les point précédents, à savoir
- systemd ne lance pas automatiquement les fichiers basé sur templates, il faut rajouter les liens symboliques à la main
- chaque serveur peut avoir plusieurs workers, donc plusieurs processus et j'aimerais bien tuer tous les processus d'un serveur sans abimer les autres (par exemple relancer tomcat admin mais pas les applis)
- les fichiers de config ne sont pas raffraichits automatiquement quand on les modifie.
Tu mets tout ça ensemble et tu arrives a des situations sympas avec ta solution :
Par exemple si un dev veut modifier le catalina ou créer un nouveau serveur, il faut qu'il te passe un coup de fil (ou qu'il ait les droits admin - et ça, c'est pas possible).
Comment tomcat admin va-t-il faire pour raccrocher les wagons ? Qu'est-ce qu'il se passe si je relance un site depuis tomcat-admin et pas depuis systemctl ?
Si j'ai un worker qui déconne ? Comment je le tue ? (je veux dire à part avec les droits root et un bon gros SIGKILL dans sa face) ?
etc. etc.