Je pense de plus en plus à implémenter un init pour les BSDs avec les
mêmes possibilités qu'offre systemd. En effet, celui-ci offre des
avantages que l'on ne peut plus négliger pour un OS moderne.
Parmi ces avantages, on peut noter, par exemple, la possibilité
d'implémenter un monitoring de daemon évolué par rapport
à ce que permet l'init de BSD, la possibilité de gérer l'hard dans
l'init lui-même, d'avoir une journalisation digne de ce nom au format
binaire, s'il vous plait, de gérer des containers, etc. J'arrête là,
les avantages apporté par cet init qui, de fait, sont bien trop
nombreux pour qu'un humain ordinaire puisse tous les énumérer.
Certes, il reste peut-être quelques petites erreurs de jeunesse, qui
seront, à ne pas douter, rapidement corriger, les mainteneurs de systemd
étant particulièrement réceptifs aux corrections de bugs, mais tout
celà ne devrait pas empêcher une bonne intégration dans un système BSD,
d'autant plus si l'on implémente from scratch.
Pourquoi from scratch ? Le problème est que systemd est sous licence
GNU LGPL 1.2, et quand bien même il existe des logiciels sous
licence GNU dans le coeur des principaux BSDs, il serait préférable
d'utliser une vrai licence libre.
Enfin il reste le choix du premier BSD pour commencer cette
implémentation. Le choix de FreeBSD est évident. C'est le seul à
posséder un système de type MAC digne de ce nom grâce à Trusted BSD, ce
qui, de facto, démontre sans aucun doute que c'est le système le
plus sécurisé de la famille BSD.
Cependant, je ne suis pas assez familiarisé avec cet init
extraordinaire, d'où ma demande sur fcold aux divers spécialistes
des Linux qui ont très certainement d'autres arguments en faveur de
systemd, des conseils sur comment bien implémenter un journal binaire,
ce genre de choses, quoi.
A noter, si je ne crosspote pas avec fcob, c'est bien pour leur laisser
l'agréable surprise lorsque le nouvel init sera commité pour la
prochaine release de FreeBSD (la 11.1 donc).
Vu le nombre de PID disponible, t'as bien une chance sur 30,000 que ça arrive avant que tu puisses détecter que ton serveur est down avec n'importe quel système de monitoring.
Si ça arrive accidentellement, peut-être. Mais je trouve que 1/30000 comme risque d'incident, ça fait beaucoup. On ne doit pas avoir les mêmes exigences en termes de fiabilité.
En ce qui me concerne, je monitore par le nom et le nombre de process. Mon raisonnaement n'a strictement rien à voir avec mes exigences en terme de fiabilité. Je ne m'appuyerais certainement pas sur un PID pour un monitoring sérieux. Et pas à cause du cas débile que tu présentes.
Si ça arrive suite à des manoeuvres malicieuses, ton raisonnement ne vaut rien.
Si ça arrive à cause d'un météorite sur le datacenter, ton raisonnement ne vaut rien non plus. Et le tien non plus, d'ailleurs.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
"S.T." , dans le message <nu09hj$k2d$1@gioia.aioe.org>, a écrit :
Vu le nombre de PID disponible, t'as bien une chance sur 30,000 que ça
arrive avant que tu puisses détecter que ton serveur est down avec
n'importe quel système de monitoring.
Si ça arrive accidentellement, peut-être. Mais je trouve que 1/30000 comme
risque d'incident, ça fait beaucoup. On ne doit pas avoir les mêmes
exigences en termes de fiabilité.
En ce qui me concerne, je monitore par le nom et le nombre de process.
Mon raisonnaement n'a strictement rien à voir avec mes exigences en
terme de fiabilité.
Je ne m'appuyerais certainement pas sur un PID pour un monitoring
sérieux. Et pas à cause du cas débile que tu présentes.
Si ça arrive suite à des manoeuvres malicieuses, ton raisonnement ne vaut
rien.
Si ça arrive à cause d'un météorite sur le datacenter, ton raisonnement
ne vaut rien non plus. Et le tien non plus, d'ailleurs.
Vu le nombre de PID disponible, t'as bien une chance sur 30,000 que ça arrive avant que tu puisses détecter que ton serveur est down avec n'importe quel système de monitoring.
Si ça arrive accidentellement, peut-être. Mais je trouve que 1/30000 comme risque d'incident, ça fait beaucoup. On ne doit pas avoir les mêmes exigences en termes de fiabilité.
En ce qui me concerne, je monitore par le nom et le nombre de process. Mon raisonnaement n'a strictement rien à voir avec mes exigences en terme de fiabilité. Je ne m'appuyerais certainement pas sur un PID pour un monitoring sérieux. Et pas à cause du cas débile que tu présentes.
Si ça arrive suite à des manoeuvres malicieuses, ton raisonnement ne vaut rien.
Si ça arrive à cause d'un météorite sur le datacenter, ton raisonnement ne vaut rien non plus. Et le tien non plus, d'ailleurs.
Jo Engo
Le Sun, 16 Oct 2016 16:36:45 +0000, Nicolas George a écrit :
Jo Engo , dans le message , a écrit :
Comportement pathologique ou comportement normal ?
Qui effacerait le fichier de PID ?
ça c'est autre chose que la (belle) mort du démon.
Et comment on pallie à ça
En faisant en sorte que le processus père garde la trace, car lui, et lui seul, est notifié de la mort du processus et chargé de la finaliser.
C'est bien un script qui va lancer le père du processus (et pourquoi ça ne serait pas un script shell aussi ?) et lui aussi peut mourir. -- - Combien serai-je payé pour ce travail ? - Vous recevrez 1115 unités de la monnaie coréenne : « aurez mcxv wons. » -- Esposito-Farese, Gilles
Le Sun, 16 Oct 2016 16:36:45 +0000, Nicolas George a écrit :
Jo Engo , dans le message <pan.2016.10.16.15.58.56@icite.fr>, a écrit :
Comportement pathologique ou comportement normal ?
Qui effacerait le fichier de PID ?
ça c'est autre chose que la (belle) mort du démon.
Et comment on pallie à ça
En faisant en sorte que le processus père garde la trace, car lui, et
lui seul, est notifié de la mort du processus et chargé de la finaliser.
C'est bien un script qui va lancer le père du processus (et pourquoi ça
ne serait pas un script shell aussi ?) et lui aussi peut mourir.
--
- Combien serai-je payé pour ce travail ?
- Vous recevrez 1115 unités de la monnaie coréenne : « aurez mcxv wons. »
-- Esposito-Farese, Gilles
Le Sun, 16 Oct 2016 16:36:45 +0000, Nicolas George a écrit :
Jo Engo , dans le message , a écrit :
Comportement pathologique ou comportement normal ?
Qui effacerait le fichier de PID ?
ça c'est autre chose que la (belle) mort du démon.
Et comment on pallie à ça
En faisant en sorte que le processus père garde la trace, car lui, et lui seul, est notifié de la mort du processus et chargé de la finaliser.
C'est bien un script qui va lancer le père du processus (et pourquoi ça ne serait pas un script shell aussi ?) et lui aussi peut mourir. -- - Combien serai-je payé pour ce travail ? - Vous recevrez 1115 unités de la monnaie coréenne : « aurez mcxv wons. » -- Esposito-Farese, Gilles
S.T.
On 2016-10-16, Nicolas George <nicolas$ wrote:
En faisant en sorte que le processus père garde la trace, car lui, et lui seul, est notifié de la mort du processus et chargé de la finaliser.
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
En faisant en sorte que le processus père garde la trace, car lui, et lui
seul, est notifié de la mort du processus et chargé de la finaliser.
Et là arrive toute la logique de systemd, l'outil de la mort qui tout,
le café et le reste parce que tous les administrateurs systems sont
incapable de montrer leur propre système de monitoring.
En faisant en sorte que le processus père garde la trace, car lui, et lui seul, est notifié de la mort du processus et chargé de la finaliser.
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Nicolas George
Jo Engo , dans le message , a écrit :
C'est bien un script qui va lancer le père du processus (et pourquoi ça ne serait pas un script shell aussi ?) et lui aussi peut mourir.
Avec systemd, c'est systemd lui-même qui lance les différents services. Et pour les services qui s'acharnent à abandonner leur père, il les adopte puisqu'il a le PID 1.
Jo Engo , dans le message <pan.2016.10.16.17.16.05@icite.fr>, a écrit :
C'est bien un script qui va lancer le père du processus (et pourquoi ça
ne serait pas un script shell aussi ?) et lui aussi peut mourir.
Avec systemd, c'est systemd lui-même qui lance les différents services. Et
pour les services qui s'acharnent à abandonner leur père, il les adopte
puisqu'il a le PID 1.
C'est bien un script qui va lancer le père du processus (et pourquoi ça ne serait pas un script shell aussi ?) et lui aussi peut mourir.
Avec systemd, c'est systemd lui-même qui lance les différents services. Et pour les services qui s'acharnent à abandonner leur père, il les adopte puisqu'il a le PID 1.
Nicolas George
"S.T." , dans le message <nu0cm7$q41$, a écrit :
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que systemd. Mais si c'est développé par un admin dans son coin, ça le fait en général moins bien.
"S.T." , dans le message <nu0cm7$q41$2@gioia.aioe.org>, a écrit :
Et là arrive toute la logique de systemd, l'outil de la mort qui tout,
le café et le reste parce que tous les administrateurs systems sont
incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que
systemd. Mais si c'est développé par un admin dans son coin, ça le fait en
général moins bien.
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que systemd. Mais si c'est développé par un admin dans son coin, ça le fait en général moins bien.
Nicolas George
"S.T." , dans le message <nu0ck8$q41$, a écrit :
Si ça arrive à cause d'un météorite sur le datacenter, ton raisonnement ne vaut rien non plus. Et le tien non plus, d'ailleurs.
Je n'arrive pas à deviner si tu dit une idiotie pareille parce que tu n'as rien compris ou parce que tu me prends pour un idiot, mais la conclusion est la même : il n'y a qu'un idiot, dans l'histoire, et tous les deux c'est toi.
"S.T." , dans le message <nu0ck8$q41$1@gioia.aioe.org>, a écrit :
Si ça arrive à cause d'un météorite sur le datacenter, ton raisonnement
ne vaut rien non plus. Et le tien non plus, d'ailleurs.
Je n'arrive pas à deviner si tu dit une idiotie pareille parce que tu n'as
rien compris ou parce que tu me prends pour un idiot, mais la conclusion est
la même : il n'y a qu'un idiot, dans l'histoire, et tous les deux c'est toi.
Si ça arrive à cause d'un météorite sur le datacenter, ton raisonnement ne vaut rien non plus. Et le tien non plus, d'ailleurs.
Je n'arrive pas à deviner si tu dit une idiotie pareille parce que tu n'as rien compris ou parce que tu me prends pour un idiot, mais la conclusion est la même : il n'y a qu'un idiot, dans l'histoire, et tous les deux c'est toi.
S.T.
On 2016-10-16, Nicolas George <nicolas$ wrote:
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que systemd. Mais si c'est développé par un admin dans son coin, ça le fait en général moins bien.
Tu veux dire que systemd est capable de vérifier le taux de remplissage du swap, les espaces disques, le nombre de status en erreur dans une base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ? Le tout en envoyant des emails et des SMS d'alerte et avec une page web pour afficher l'ensemble des status des 300 tests de monitoring que requiert les plateformes que j'administre ? Faut le dire, parce qu'à ce jeu, j'ai toujours pas trouvé mieux que Nagios, mais on sait jamais, il y a peut-être des trucs meilleurs.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
Et là arrive toute la logique de systemd, l'outil de la mort qui tout,
le café et le reste parce que tous les administrateurs systems sont
incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que
systemd. Mais si c'est développé par un admin dans son coin, ça le fait en
général moins bien.
Tu veux dire que systemd est capable de vérifier le taux de remplissage
du swap, les espaces disques, le nombre de status en erreur dans une
base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Le tout en envoyant des emails et des SMS d'alerte et avec une page web
pour afficher l'ensemble des status des 300 tests de monitoring que
requiert les plateformes que j'administre ?
Faut le dire, parce qu'à ce jeu, j'ai toujours pas trouvé mieux que
Nagios, mais on sait jamais, il y a peut-être des trucs meilleurs.
Et là arrive toute la logique de systemd, l'outil de la mort qui tout, le café et le reste parce que tous les administrateurs systems sont incapable de montrer leur propre système de monitoring.
Un système de monitoring fiable va faire essentiellement la même chose que systemd. Mais si c'est développé par un admin dans son coin, ça le fait en général moins bien.
Tu veux dire que systemd est capable de vérifier le taux de remplissage du swap, les espaces disques, le nombre de status en erreur dans une base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ? Le tout en envoyant des emails et des SMS d'alerte et avec une page web pour afficher l'ensemble des status des 300 tests de monitoring que requiert les plateformes que j'administre ? Faut le dire, parce qu'à ce jeu, j'ai toujours pas trouvé mieux que Nagios, mais on sait jamais, il y a peut-être des trucs meilleurs.
S.T.
On 2016-10-16, Nicolas George <nicolas$ wrote:
Je n'arrive pas à deviner si tu dit une idiotie pareille parce que tu n'as rien compris ou parce que tu me prends pour un idiot, mais la conclusion est la même : il n'y a qu'un idiot, dans l'histoire, et tous les deux c'est toi.
Je dis ça parce que ta remarque n'avait strictement rien à voir avec le schmilblick. En fait, tu ne fais que justifier l'injustifiable par des raisons statistiquements anecdotiques, pour ne pas dire improbables. Si un mec a pris la main sur un serveur, c'est pas un systemd avec son monitoring des process enfants qui va l'arreter. Si un process meurt, aucun autre process ne va prendre son PID avant des heures et n'importe quel systeme de monitoring bien foutu aura déjà réagi bien avant que cela arrive. Surtout si tous les process de prod sont déjà monitorés par des tests complémentaires (test fonctionnel, test de présence, test sur les logs ...). Et ne me parle pas de niveaux d'exigences, je gère des vrais machines de prod, avec du traffic qui passe dessus, avec des vrais clients, avec des vraies connections et des millions d'utilisateurs derrière le tout pour des opérateurs téléphoniques nationaux. J'ai une assez bonne idée de ce qu'est un niveau d'exigence.
On 2016-10-16, Nicolas George <nicolas$george@salle-s.org> wrote:
Je n'arrive pas à deviner si tu dit une idiotie pareille parce que tu n'as
rien compris ou parce que tu me prends pour un idiot, mais la conclusion est
la même : il n'y a qu'un idiot, dans l'histoire, et tous les deux c'est toi.
Je dis ça parce que ta remarque n'avait strictement rien à voir avec le
schmilblick.
En fait, tu ne fais que justifier l'injustifiable par des raisons
statistiquements anecdotiques, pour ne pas dire improbables. Si un mec a
pris la main sur un serveur, c'est pas un systemd avec son monitoring
des process enfants qui va l'arreter.
Si un process meurt, aucun autre process ne va prendre son PID avant des
heures et n'importe quel systeme de monitoring bien foutu aura déjà
réagi bien avant que cela arrive. Surtout si tous les process de prod
sont déjà monitorés par des tests complémentaires (test fonctionnel,
test de présence, test sur les logs ...).
Et ne me parle pas de niveaux d'exigences, je gère des vrais machines
de prod, avec du traffic qui passe dessus, avec des vrais clients, avec
des vraies connections et des millions d'utilisateurs derrière le tout
pour des opérateurs téléphoniques nationaux. J'ai une assez bonne idée
de ce qu'est un niveau d'exigence.
Je n'arrive pas à deviner si tu dit une idiotie pareille parce que tu n'as rien compris ou parce que tu me prends pour un idiot, mais la conclusion est la même : il n'y a qu'un idiot, dans l'histoire, et tous les deux c'est toi.
Je dis ça parce que ta remarque n'avait strictement rien à voir avec le schmilblick. En fait, tu ne fais que justifier l'injustifiable par des raisons statistiquements anecdotiques, pour ne pas dire improbables. Si un mec a pris la main sur un serveur, c'est pas un systemd avec son monitoring des process enfants qui va l'arreter. Si un process meurt, aucun autre process ne va prendre son PID avant des heures et n'importe quel systeme de monitoring bien foutu aura déjà réagi bien avant que cela arrive. Surtout si tous les process de prod sont déjà monitorés par des tests complémentaires (test fonctionnel, test de présence, test sur les logs ...). Et ne me parle pas de niveaux d'exigences, je gère des vrais machines de prod, avec du traffic qui passe dessus, avec des vrais clients, avec des vraies connections et des millions d'utilisateurs derrière le tout pour des opérateurs téléphoniques nationaux. J'ai une assez bonne idée de ce qu'est un niveau d'exigence.
Nicolas George
"S.T." , dans le message <nu0e58$squ$, a écrit :
Tu veux dire que systemd est capable de vérifier le taux de remplissage du swap, les espaces disques, le nombre de status en erreur dans une base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Tu n'as rien compris, mais ça n'étonne personne. Reste dans ta fange.
"S.T." , dans le message <nu0e58$squ$1@gioia.aioe.org>, a écrit :
Tu veux dire que systemd est capable de vérifier le taux de remplissage
du swap, les espaces disques, le nombre de status en erreur dans une
base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Tu n'as rien compris, mais ça n'étonne personne. Reste dans ta fange.
Tu veux dire que systemd est capable de vérifier le taux de remplissage du swap, les espaces disques, le nombre de status en erreur dans une base de CDRs, l'état d'un port TCP, l'état d'une connection SS7 en TDL ?
Tu n'as rien compris, mais ça n'étonne personne. Reste dans ta fange.
Nicolas George
"S.T." , dans le message <nu0ek8$tj7$, a écrit :
Si un mec a pris la main sur un serveur
Et s'il n'a pas encore complètement la main mais peut à volonter faire crasher un certain processus, pouvoir s'en servir pour en faire tuer un autre peut lui permettre de progresser dans ses intentions.
Si un process meurt, aucun autre process ne va prendre son PID avant des heures
C'est la deuxième fois que tu invoques cet argument faux. Je te conseille de réfléchir un peu plus de deux secondes avant de l'invoquer une troisième fois. C'est bien gentil d'essayer de me casser du sucre sur le dos, mais là, tout ce que tu arrives à prouver, c'est que tu analyses mal la situation.
Et ne me parle pas de niveaux d'exigences, je gère des vrais machines de prod, avec du traffic qui passe dessus, avec des vrais clients, avec des vraies connections et des millions d'utilisateurs derrière le tout pour des opérateurs téléphoniques nationaux.
Ça fait peur. Tu peux donner le nom des opérateurs en question, que j'évite de leur donner ma clientèle ?
"S.T." , dans le message <nu0ek8$tj7$1@gioia.aioe.org>, a écrit :
Si un mec a
pris la main sur un serveur
Et s'il n'a pas encore complètement la main mais peut à volonter faire
crasher un certain processus, pouvoir s'en servir pour en faire tuer un
autre peut lui permettre de progresser dans ses intentions.
Si un process meurt, aucun autre process ne va prendre son PID avant des
heures
C'est la deuxième fois que tu invoques cet argument faux. Je te conseille de
réfléchir un peu plus de deux secondes avant de l'invoquer une troisième
fois. C'est bien gentil d'essayer de me casser du sucre sur le dos, mais là,
tout ce que tu arrives à prouver, c'est que tu analyses mal la situation.
Et ne me parle pas de niveaux d'exigences, je gère des vrais machines
de prod, avec du traffic qui passe dessus, avec des vrais clients, avec
des vraies connections et des millions d'utilisateurs derrière le tout
pour des opérateurs téléphoniques nationaux.
Ça fait peur. Tu peux donner le nom des opérateurs en question, que j'évite
de leur donner ma clientèle ?
Et s'il n'a pas encore complètement la main mais peut à volonter faire crasher un certain processus, pouvoir s'en servir pour en faire tuer un autre peut lui permettre de progresser dans ses intentions.
Si un process meurt, aucun autre process ne va prendre son PID avant des heures
C'est la deuxième fois que tu invoques cet argument faux. Je te conseille de réfléchir un peu plus de deux secondes avant de l'invoquer une troisième fois. C'est bien gentil d'essayer de me casser du sucre sur le dos, mais là, tout ce que tu arrives à prouver, c'est que tu analyses mal la situation.
Et ne me parle pas de niveaux d'exigences, je gère des vrais machines de prod, avec du traffic qui passe dessus, avec des vrais clients, avec des vraies connections et des millions d'utilisateurs derrière le tout pour des opérateurs téléphoniques nationaux.
Ça fait peur. Tu peux donner le nom des opérateurs en question, que j'évite de leur donner ma clientèle ?
