Ca me parait logique de "tuer" tout ce qui est lié à un utilisateur quand il se déloggue (car il... se déloggue).
Faut développer un peu parce que ton propos est laconique.
Quand un DBA se connecte à un serveur pour effectuer des opérations de maintenance sur la database, il n'a pas beaucoup le choix que de prendre l'identité du compte technique qui exécute le produit. Donc bien souvent le user oracle et dans certaines implémentations/normes, le user d'instance (qui peut être séparé).
Les bonnes pratiques veulent que le DBA se connecte avec un compte nominatif sur le serveur puis passe "dba" via un "su" ou un "sudo".
Lorsqu'il a terminé ses opérations, ben il se déloggue.
Avec "sudo", on peut aussi simuler un login. C'est très pratique pour bénéficier des variables d'environnement puisqu'on source le profile.
En somme, le ménage proposé par systemd me parait très cavalier...
[^] # Re: Moui
Posté par Dabowl_75 . En réponse au journal systemd: attention à RemoveIPC. Évalué à 10.
Faut développer un peu parce que ton propos est laconique.
Quand un DBA se connecte à un serveur pour effectuer des opérations de maintenance sur la database, il n'a pas beaucoup le choix que de prendre l'identité du compte technique qui exécute le produit. Donc bien souvent le user oracle et dans certaines implémentations/normes, le user d'instance (qui peut être séparé).
Les bonnes pratiques veulent que le DBA se connecte avec un compte nominatif sur le serveur puis passe "dba" via un "su" ou un "sudo".
Lorsqu'il a terminé ses opérations, ben il se déloggue.
Avec "sudo", on peut aussi simuler un login. C'est très pratique pour bénéficier des variables d'environnement puisqu'on source le profile.
En somme, le ménage proposé par systemd me parait très cavalier...