Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Quelques temps - ca fait moins d'un an. Je crois que l'annonce de Lennart date du 21 juin 2013. On savait déjà que les cgroups allaient être unifiés (et c'est une bonne chose) mais le coup du controleur unique accessible uniquement via DBus ca fait bizarre.
Ca fait bizarre pour deux raisons :
- la première c'est qu'un processus acquiert son cgroup au lancement, et là soit il se retrouve dans le même cgroup que son père, soit on veut le mettre dans un autre cgroup. Mais si on veut le mettre dans un autre cgroup il faut être capable de dire à systemd d'une façon ou d'une autre "attention le prochain processus que je vais lancer doit aller dans le cgroup /bidule/truc" parce que une fois que le processus est lancé c'est rapé (du moins jusqu'à ce qu'on puisse balader un processus d'un cgroup à un autre.)
A partir de là il faut bien s'assurer que la session depuis laquelle on est ne va pas lancer un autre processus avant celui que l'on veut mettre en cgroup. C'est extrèmement facile à faire pour un service qui s'initialise, mais pour une session utilisateur ou encore pour une commande lancée par uns ervice après initialisation c'est tout de suite plus complexe, il faut bien faire attention aux conditions de courses et autres ratage de lancement (par exemple si je prépare un cgroup, mais que mon processus ne se lance pas - on fait quoi ?). Reste la solution de créer une nouvelle session par processus - Mais ca peut devenir assez problématique assez vite.
- la seconde est liée au comportement même des cgroups en mode comptabilité. Si j'utilise les cgroups pour mesurer la consommation de ressources de mes processus (très utile quand un client a l'habitude de faire du while 1 fork; sans le vouloir). A aujourd'hui, mon appli avec son propre temps CPU peut checker la consommation quand elle le veut. Mais demain si tout passe par DBus je me fais un peu de soucis, parceque gérer 3000 processus qui vont venir le questionner à tour de rôle ca peut être lourd à digérer.
Maintenant il s'agit juste de réflexions en me basant sur l'existant et sur ce qui a été dit. Ca me casse les pieds de faire évoluer mes archis pour prendre en compte les nouveaux cgroups, mais ca n'est pas fondammentalement mauvais. J'attend de voir ce qui sort pour donner un avis plus complet sur la question.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Il ne s'agit pas de faire faire du correctif à Nagios (Même si c'est faisable, et même plutôt salvateur sur certaines config, on va pas déranger un admin à chaque fois qu'il faut relancer un php??-?gi, on a pas les moyens d'embaucher assez de monde) - mais plutôt de pouvoir déclencher facilement des sondes supplémentaires quand un comportement anormal est détecté.
Typiquement je surveille le temps d’exécution moyen d'une requête. Et quand il augmente je lance d'autres sondes pour savoir si ca vient de grosses requêtes qui sont lancées, des I/Os qui foirent ou de la mémoire vive qui est pleine. Comme ça je lance un minimum de sondes et je ne passe sur des sondes plus fortes que si le besoin s'en fait sentir et seulement là ou j'en ai besoin.
Pour la majorité des sondes il suffit de chopper les logs et/ou se connecter via un canal spécial à l'appli en mode client. Pour d'autres sondes il faut aller triffouiller plus loin ce qui implique soit un reload de la config du serveur qui pose soucis, soit le chargement de certains modules par l'appli,soit carrément un restart avec une autre config.
Tout ceci se faisait avant très simplement en ligne de commande en balançant des commandes de type
/etc/init.d/monservice -reload -with module2 -activate stacktrace -verbosity 5 Sur l'ensemble des commandes "de l'ancien temps" il n'y a guère que le reload que je sache faire passer aujourd'hui et encore en ayant les droits root (que ce soit via DBus ou via systemctl reload, restart, start, stop, enable et disable nécessitent les droits root sinon => Access Denied).
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que je ne la connais pas. Et j'ai beau chercher et ouvrir des tickets chez RH je n'ai pas encore eu de réponses satisfaisantes. (parceque très honnêtement modifier les pre,env et les posts d'un fichier unit avant de le réenregistrer et de faire un restart n'est pas une réponse satisfaisante).
Oui, il y a cette solution, mais elle implique une bonne baffe en performance (10 à 15%) lors de mes tests, le 7% annoncé par fedora me parait très optimiste. En plus SELinux c'est quand même pas évident à gérer et très facile à casser (ce qui en langage hypervisuer veut dire plus personne ne peut rien faire tant qu'on a pas rebooter la machine en single user et passé SELinux en audit only). Comme les modifications ne s'appliquent qu'au redémarrage dans la plupart des cas, on a assez fréquemment de mauvaises surprises.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 7.
Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.
Quelques temps - ca fait moins d'un an. Je crois que l'annonce de Lennart date du 21 juin 2013. On savait déjà que les cgroups allaient être unifiés (et c'est une bonne chose) mais le coup du controleur unique accessible uniquement via DBus ca fait bizarre.
Ca fait bizarre pour deux raisons :
- la première c'est qu'un processus acquiert son cgroup au lancement, et là soit il se retrouve dans le même cgroup que son père, soit on veut le mettre dans un autre cgroup. Mais si on veut le mettre dans un autre cgroup il faut être capable de dire à systemd d'une façon ou d'une autre "attention le prochain processus que je vais lancer doit aller dans le cgroup /bidule/truc" parce que une fois que le processus est lancé c'est rapé (du moins jusqu'à ce qu'on puisse balader un processus d'un cgroup à un autre.)
A partir de là il faut bien s'assurer que la session depuis laquelle on est ne va pas lancer un autre processus avant celui que l'on veut mettre en cgroup. C'est extrèmement facile à faire pour un service qui s'initialise, mais pour une session utilisateur ou encore pour une commande lancée par uns ervice après initialisation c'est tout de suite plus complexe, il faut bien faire attention aux conditions de courses et autres ratage de lancement (par exemple si je prépare un cgroup, mais que mon processus ne se lance pas - on fait quoi ?). Reste la solution de créer une nouvelle session par processus - Mais ca peut devenir assez problématique assez vite.
- la seconde est liée au comportement même des cgroups en mode comptabilité. Si j'utilise les cgroups pour mesurer la consommation de ressources de mes processus (très utile quand un client a l'habitude de faire du while 1 fork; sans le vouloir). A aujourd'hui, mon appli avec son propre temps CPU peut checker la consommation quand elle le veut. Mais demain si tout passe par DBus je me fais un peu de soucis, parceque gérer 3000 processus qui vont venir le questionner à tour de rôle ca peut être lourd à digérer.
Maintenant il s'agit juste de réflexions en me basant sur l'existant et sur ce qui a été dit. Ca me casse les pieds de faire évoluer mes archis pour prendre en compte les nouveaux cgroups, mais ca n'est pas fondammentalement mauvais. J'attend de voir ce qui sort pour donner un avis plus complet sur la question.
Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.
Il ne s'agit pas de faire faire du correctif à Nagios (Même si c'est faisable, et même plutôt salvateur sur certaines config, on va pas déranger un admin à chaque fois qu'il faut relancer un php??-?gi, on a pas les moyens d'embaucher assez de monde) - mais plutôt de pouvoir déclencher facilement des sondes supplémentaires quand un comportement anormal est détecté.
Typiquement je surveille le temps d’exécution moyen d'une requête. Et quand il augmente je lance d'autres sondes pour savoir si ca vient de grosses requêtes qui sont lancées, des I/Os qui foirent ou de la mémoire vive qui est pleine. Comme ça je lance un minimum de sondes et je ne passe sur des sondes plus fortes que si le besoin s'en fait sentir et seulement là ou j'en ai besoin.
Pour la majorité des sondes il suffit de chopper les logs et/ou se connecter via un canal spécial à l'appli en mode client. Pour d'autres sondes il faut aller triffouiller plus loin ce qui implique soit un reload de la config du serveur qui pose soucis, soit le chargement de certains modules par l'appli,soit carrément un restart avec une autre config.
Tout ceci se faisait avant très simplement en ligne de commande en balançant des commandes de type
/etc/init.d/monservice -reload -with module2 -activate stacktrace -verbosity 5
Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que je ne la connais pas. Et j'ai beau chercher et ouvrir des tickets chez RH je n'ai pas encore eu de réponses satisfaisantes. (parceque très honnêtement modifier les pre,env et les posts d'un fichier unit avant de le réenregistrer et de faire un restart n'est pas une réponse satisfaisante).
dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl
Oui, il y a cette solution, mais elle implique une bonne baffe en performance (10 à 15%) lors de mes tests, le 7% annoncé par fedora me parait très optimiste. En plus SELinux c'est quand même pas évident à gérer et très facile à casser (ce qui en langage hypervisuer veut dire plus personne ne peut rien faire tant qu'on a pas rebooter la machine en single user et passé SELinux en audit only). Comme les modifications ne s'appliquent qu'au redémarrage dans la plupart des cas, on a assez fréquemment de mauvaises surprises.
Ensuite (mais honnêtement je ne sais pas si c'est encore vrai) SELinux ne fonctionnait avec systemd que dans le cadre d'une descente de privilèges. C'est à dire plus pour empêcher un processus root d'interagir avec des services que pour autoriser un service non root à le faire.
La page de RH ne donne pas non plus d'exemple d'élévation : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/chap-Security-Enhanced_Linux-Systemd_Access_Control.html on y parle que de réduire les droits.
Es-tu sur que l'élévation de droits marche ? (Vraie question)