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.
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.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.
[^] # Re: Le vendredi c'est permis.
Posté par Misc (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
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.
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.
Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.
Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.
Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.
Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.