Bonjour,
Je souhaite lancer un programme à l’ouverture d’une session utilisateur sur debian 8 et un autre à la fermeture de celle-ci. Ces programmes doivent être lancés en tant que root et doivent pouvoir récupérer simplement le nom de l’utilisateur qui ouvre sa session.
Merci pour votre aide.
Salut,
Pourquoi à la fermeture?
Je n’y connais pas grand chose en programmation, mais tu peux peut-être faire un script qui va renvoyer la valeur de “whoami” ou “$USER” vers un fichier de log, le tout orchestré avec le runlevel adéquat si sous sysvinit, ou bien avec une unité créee par tes soins si sous systemd?
Ce n’est qu’une idée… 
C’est pas logind qui fait déjà un suivi des connexions utilisateur ?
Bonjour
Tu as quoi comme bureau?
Je veux que ça se lance en tant que root, du coup, whoami va retourner root.
Je ne sais pas…
C’est MATE. Je me sers déjà de l’autostart de MATE pour les scripts de l’utilisateur, mais ils sont lancés en tant que l’utilisateur.
Je verrai bien un service alors.
En fait c’est pour faire quoi exactement que tu veux récuperer ça? Si tu nous en disais un peu plus.
OK.
Nous avons une collections de scripts, rassemblés de façon cohérente selon le contexte.
Donc, un premier dossier, system qui contient les scripts lancés pendant la phase de démarrage du système, un deuxième dossier greeter pour les scripts lancés à l’affichage de la mire de login, un troisième dossier login, lancé en tant que root à la connexion d’un utilisateur, un quatrième dossier logout, lancé en tant que root à la déconnexion de l’utilisateur et un dernier dossier user qui est lancé à la connexion de l’utilisateur, er tant que cet utilisateur.
Pour le moment, nous pouvons lancer les scripts system et user sans problème, ceux du greeter sont en passe de devenir obsolètes, je cherche juste à lancer login et logout.
Sincèrement je ne comprends pas ce que tu veux faire, ton explication est floue pour moi… C’est qui “nous”? quelle collection de scripts? Tu parles des scripts déjà présents ou de script que tu (ou “vous”, je ne sais combien vous êtes… ) as concocté…
Lancer login et logout ok, mais c’est vague…
Après si je m’en réfère à ton premier post, s’il s’agit simplement de récuperer qui se connecte ou se déconnecte avec un programme (je présume que tu veux parler de script bash ou similaire) que tu vas lancer en root, tu peux construire un script auquel tu vas donner les droits uniquement à root, et qui va te récuperer les connexions des différents utilisateurs en fouillant dans “/var/log/syslog” par exemple …
En general si je ne me trompe pas, et à moins de le spécifier manuellement, les utilisateurs à la création de leur “compte” se voient attribuer un UID de 1000 ou plus.
Il suffirait peut-etre d’ecrire un script à l’aide de “cat, grep, awk, ou similaire…” pour lire syslog et en extraire les utilisateurs qui se connectent et deconnectent en extrayant au fur et a mesure leur UID (c’est bien distinct dans syslog s’il s’agit de Starting User Manager ou Stopping User Manager).
Apres il faudrait trier les UID et retrouver le proprietaire, et pour ça tu as le fichier “/etc/group”, là avec awk tu devrais facilement pouvoir te debrouiller pour sortir la 1ere colonne qui contient l’utilisateur.
Enfin pour demarrer ce script au login et logout, là comme je l’ai deja dit, si tu es sous sysvinit il faudrait peut etre voir du cote des “rc.d”, si sous systemed il faudra te pencher sur la maniere de construire des fichiers unités.
Nous sommes l’équipe informatique d’une association.
Nous sommes deux, cette collection de scripts a été faite par nous même afin de personnaliser l’expérience utilisateur de façon homogène (déploiement de raccourcis, de logiciels, d’automatismes et de configurations).
En fait, on lance les scripts du dossier qui les contient avec run-parts.
Non, ça, c’est la méthode compliquée, celle que je ferai si je n’ai pas d’autres solutions.
Ce ne sont pas des utilisateurs locaux, mais ils sont tous dans le même groupe.
Moi, à la limite, je cherche juste à lancer un script à la connexion et à la déconnexion des utilisateurs.
Ces scripts doivent être lancés en tant que root si j’ai bien compris.
Autant faire un service qui écoute systemd-logind sur dbus et agit en conséquence.
Tu sais comment on fait ça ? Je ne trouve pas quand je cherche comment écouter logind sur dbus.
Le man de systemd-logind renvoit vers cette page (logind D-Bus API Documentation) qui donne les signaux envoyés par logind :
logind # Signals
En se branchant sur l’interface dbus qui va bien (org.xxx), un “client” (le service à inventer) peut écouter et agir.
Hein, mais je ne comprend rien à ce truc, je suis idiot ou quoi ?
J’ai essayé gdbus monitor --system --dest org.freedesktop.login1, mais je n’ai aucun événement qui arrive et je ne comprend pas pourquoi.
Non, ça doit être plutôt la fatigue 
De mon côté, pas de souci avec la commande monitor.
La lancer sur une console hors session (CTRL ALT F1), se déconnecter, se reconnecter et lire sur la console plein de lignes.
Monitoring signals from all objects owned by org.freedesktop.login1
The name org.freedesktop.login1 is owned by :1.1
/org/freedesktop/login1/session/_38: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Session', {'Active': <false>}, @as [])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', {'ActiveSession': <('', objectpath '/')>}, @as [])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', {'Sessions': <[('10', objectpath '/org/freedesktop/login1/session/_310'), ('8', '/org/freedesktop/login1/session/_38'), ('6', '/org/freedesktop/login1/session/_36')]>}, @as [])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionNew ('10', objectpath '/org/freedesktop/login1/session/_310')
/org/freedesktop/login1/user/_1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', {'Sessions': <[('10', objectpath '/org/freedesktop/login1/session/_310'), ('8', '/org/freedesktop/login1/session/_38'), ('6', '/org/freedesktop/login1/session/_36')]>, 'Display': <('6', objectpath '/org/freedesktop/login1/session/_36')>}, @as [])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', {'Sessions': <[('10', objectpath '/org/freedesktop/login1/session/_310'), ('8', '/org/freedesktop/login1/session/_38'), ('6', '/org/freedesktop/login1/session/_36')]>, 'ActiveSession': <('10', objectpath '/org/freedesktop/login1/session/_310')>}, @as [])
/org/freedesktop/login1: org.freedesktop.login1.Manager.SessionRemoved ('10', objectpath '/org/freedesktop/login1/session/_310')
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', {'ActiveSession': <('', objectpath '/')>}, @as [])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', {'Sessions': <[('10', objectpath '/org/freedesktop/login1/session/_310'), ('8', '/org/freedesktop/login1/session/_38'), ('6', '/org/freedesktop/login1/session/_36')]>}, @as [])
/org/freedesktop/login1/user/_1000: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.User', {'Sessions': <[('10', objectpath '/org/freedesktop/login1/session/_310'), ('8', '/org/freedesktop/login1/session/_38'), ('6', '/org/freedesktop/login1/session/_36')]>, 'Display': <('6', objectpath '/org/freedesktop/login1/session/_36')>}, @as [])
/org/freedesktop/login1/session/_38: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Session', {'Active': <true>}, @as [])
/org/freedesktop/login1/seat/seat0: org.freedesktop.DBus.Properties.PropertiesChanged ('org.freedesktop.login1.Seat', {'ActiveSession': <('8', objectpath '/org/freedesktop/login1/session/_38')>}, @as [])Ah, je crois que je viens de comprendre. En fait, il ne s’agit pas d’une connexion d’un compte local, du coup, ça n’affiche rien.
L’authentification se fait avec un serveur samba dans un domaine NT4.
Cette authentification n’utiliserait donc pas pam_systemd
EDIT (/etc/pam.d/common-session)
session optional pam_systemd.so
Non, je crois que ça utilise pam_pas_systemd. Bon, il ne me reste plus que la solution bourraine à base de polling.
salut
je ne sais pas si c’est utilisable dans ton cas, mais
tu pourrais aussi utiliser un utilisateur intermédiaire qui a les droits nécessaires pour savoir qui est connecté ( ou autre ) et qui autorise l’exécution par le groupe, dont tu ferais parti.
je pensais à un truc similaire au lp/lpadmin et à la fonction escputil ; tant que l’utilisateur n’est pas dans les groupes lp/lpadmin on ne peut pas utiliser escputil; dès qu’il y ait c’est bon.
Sinon, plus simple :
tu rajoute une ligne dans bashrc, ( avec un chmod a-w) genre
date >> /root/qui.log && whoami >> /root/qui.log
PS dommage que google soit présent sur ce site
Ce n’est pas pour un seul utilisateur, ni pour un seul ordinateur, du coup ce serait un peu compliqué.
En plus, c’est pour un bureau graphique, du coup, le bashrc ne serait pas évalué.
Ah bon ? Mais, ils utilisent Debian ? Je ne savais même pas.