Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine
Ca fait un petit moment qu'on évalue les différentes beta. Mais je te rassure on a encore rien en prod - et pour l'instant la question est plus "est-ce que" que "quand".
La doc officiel comme ça :
Il s'agit ici de modifier un la configuration d'un CGroup donné. Pas de placer un processus dans un autre cgroup que celui par défaut ou encre de déplacer un processus d'un cgroup à l'autre. (à ma connaissance le kernel ne permet de toute façon pas le déplacement à chaud en ce moment.)
Par exemple si tu veux mettre tous les processus d'un client au sein d'un même cgroups pour pouvoir contrôler les ressources en un seul point central - ben c'est compliqué.
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
J'ai bien conscience d'être assez difficile à suivre vu que a) je n'ai pas franchement des problèmes communs (systemd marche très bien 95% du temps) et que b) je ne peux pas franchement donner d'exemples concrets pour cause de contrats à la con. J'avoue que ça n'aide pas.
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Je parle en mode hyperviseur. Bien sur tu testes avant de passer en prod, bien sur tu audites pendant un moment avant d'ajouter la règle en dur (IE tu passes quelques semaines avec setenforce à permissive - c'est ce que je voulais dire par mode "audit only") Mais à un moment ou à un autre il faut bien passer en vraie prod. Et là parfois pour tout un tas de raisons (fin de mois, mise à jour des logiciels du client, changement du sens du vent - que sais-je) le container va faire une action ou avoir besoin d'une ressource que tu n'avais pas prévu. Et là on repart en permissive, on récupère le container client à la pince à épiler (parceque bien entendu c'était pendant une écriture en base de données que le bug a eu lieu - sinon c'est pas drole - et bien entendu la base c'est pas Postgresql - c'est une grosse base de données commerciale qui vit très mal le fait de plus pouvoir écrire sur le disque d'une seconde à l'autre). On fait de plates excuses au client. Une fois, deux fois et puis on arrête SELinux.
Alors ca c'est ennormément amélioré au cours des trois dernières années (et on a appris de nos erreurs aussi) mais ca reste un sujet sensible (chat échaudé toussa.)
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine
Ca fait un petit moment qu'on évalue les différentes beta. Mais je te rassure on a encore rien en prod - et pour l'instant la question est plus "est-ce que" que "quand".
La doc officiel comme ça :
Il s'agit ici de modifier un la configuration d'un CGroup donné. Pas de placer un processus dans un autre cgroup que celui par défaut ou encre de déplacer un processus d'un cgroup à l'autre. (à ma connaissance le kernel ne permet de toute façon pas le déplacement à chaud en ce moment.)
Par exemple si tu veux mettre tous les processus d'un client au sein d'un même cgroups pour pouvoir contrôler les ressources en un seul point central - ben c'est compliqué.
Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.
J'ai bien conscience d'être assez difficile à suivre vu que a) je n'ai pas franchement des problèmes communs (systemd marche très bien 95% du temps) et que b) je ne peux pas franchement donner d'exemples concrets pour cause de contrats à la con. J'avoue que ça n'aide pas.
je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.
Je parle en mode hyperviseur. Bien sur tu testes avant de passer en prod, bien sur tu audites pendant un moment avant d'ajouter la règle en dur (IE tu passes quelques semaines avec setenforce à permissive - c'est ce que je voulais dire par mode "audit only") Mais à un moment ou à un autre il faut bien passer en vraie prod. Et là parfois pour tout un tas de raisons (fin de mois, mise à jour des logiciels du client, changement du sens du vent - que sais-je) le container va faire une action ou avoir besoin d'une ressource que tu n'avais pas prévu. Et là on repart en permissive, on récupère le container client à la pince à épiler (parceque bien entendu c'était pendant une écriture en base de données que le bug a eu lieu - sinon c'est pas drole - et bien entendu la base c'est pas Postgresql - c'est une grosse base de données commerciale qui vit très mal le fait de plus pouvoir écrire sur le disque d'une seconde à l'autre). On fait de plates excuses au client. Une fois, deux fois et puis on arrête SELinux.
Alors ca c'est ennormément amélioré au cours des trois dernières années (et on a appris de nos erreurs aussi) mais ca reste un sujet sensible (chat échaudé toussa.)