Demande #10456
Pb-Gestion de poste et distribution de devoirs en présence d'un script d'élévation de pouvoir
Description
Pb récurrent avec l'outil gestion de poste notamment pour la distribution de devoirs.Ce pb nous est signalé par les utisateurs. Il se traduit par 2 messages d'erreurs au lancement de l'outil. voir copies d'ecran en PJ.
Vu avec Klaas,
AU lancement de gestion de poste, on retrouve dans /var/log/controle-vnc/main.log/main.log des lignes du style:
2015/01/30 16:00:00 CET [Broker,7777,10.100.140.141] Appel de la fonction remote_groupes par 10.100.140.141 2015/01/30 16:00:00 CET [Broker,7776,10.100.140.141] Appel non autorisé (non prof) de remote_get_bloc_list par 10.100.140.141 2015/01/30 16:00:00 CET [Broker,7775,10.100.140.141] Appel de la fonction remote_classes_et_groupes par 10.100.140.141 2015/01/30 16:00:03 CET [Broker,7778,10.100.140.141] Appel de la fonction remote_service_start par 10.100.140.141 : 801-15-W764 (Vista), mac=F8:BC:12:91:E8:77 2015/01/30 16:00:09 CET [Broker,7779,10.100.140.141] Appel non autorisé (non prof) de remote_get_devoirs par 10.100.140.141
/usr/share/eole/controlevnc/autorisations.py
On dirait que get_user_from_ip ne trouve personne ??...
/usr/share/eole/controlevnc/connexions.py
## des informations depuis une IP ## def get_user_from_ip(self, ip): """renvoie le dernier <login> a s'être connecté sur <ip> à l'ouverture de session, le client dé-reconnecte au mauvais moment 'net status sessions' ne renverrait rien pour l'IP donc utilisation de l'historique """ for username, prigrp, nom_mach, os, ip_adr in self.sessions: if ip_adr == ip: return True, (username, prigrp, nom_mach, os, ip) for username, prigrp, nom_mach, os, ip_adr in self.connexions: if ip_adr == ip: return False, (username, prigrp, nom_mach, os, ip) raise Exception("Personne ne s'est connecte sur %s"%ip) def get_active_user(self, ip): user = self.get_user_from_ip(ip) if user[0]: return user[1][0]
net status sessions
renvoie 12306 proftest professeurs 801-15-w764 (10.100.140.141)
Je suis disponible pour mettre en évidence le pb dans un établissement.
Merci
Sous-tâches
Demandes liées
Historique
#1 Mis à jour par Joël Cuissinat il y a plus de 9 ans
- Description mis à jour (diff)
#2 Mis à jour par Daniel Dehennin il y a plus de 9 ans
- Tâche parente mis à #10329
#3 Mis à jour par Klaas TJEBBES il y a plus de 9 ans
Je n'ai pas pu reproduire avec le scribe 2.2 du parc, ni avec mes 2.4 de tests.
J'ai pris RDV avec Fred Lamy pour débugger directement sur un de leur serveur à problème.
#4 Mis à jour par Klaas TJEBBES il y a plus de 9 ans
- Temps estimé mis à 0.00 h
- Restant à faire (heures) mis à 0.0
#5 Mis à jour par Fabrice Barconnière il y a plus de 9 ans
- Tâche parente changé de #10329 à #10573
#6 Mis à jour par Klaas TJEBBES il y a plus de 9 ans
Besançon a mis en place un script d'élévation de pouvoir permettant d'effectuer des actions administrateur à l'ouverture de session. Il s'agissait de paramétrer ou installer des logiciels.
Il semblerait que ce script d'élévation de pouvoir ait un effet de bord sur la reconnaissance du bon login connecté sur un poste donné par le serveur Scribe, ce dernier voyant plusieurs identité sur un même poste (celui de la personne qui se connecte et celui du compte d'élévation de pouvoir et même le compte machine).
Le fait que le compte machine apparaisse dans la liste des identités explique que controle_vnc_serveur.py refuse l'accès aux fonctions gestion-postes. Le compte machine ne faisant effectivement PAS partie du groupe "professeurs", "autorisations.py" refuse l'accès.
#7 Mis à jour par Joël Cuissinat il y a plus de 9 ans
- Sujet changé de Pb-Gestion de poste et distribution de devoirs à Pb-Gestion de poste et distribution de devoirs en présence d'un script d'élévation de pouvoir
- Tâche parente
#10573supprimé
#8 Mis à jour par Daniel Dehennin il y a plus de 9 ans
- Tâche parente mis à #10573
#9 Mis à jour par Klaas TJEBBES il y a plus de 9 ans
Du debug a été ajouté sur le serveur à problème, en attente d'information de Besançon donc.
#10 Mis à jour par Joël Cuissinat il y a plus de 9 ans
- Temps estimé changé de 0.00 h à 5.00 h
- Tâche parente changé de #10573 à #10814
- Restant à faire (heures) changé de 0.0 à 2.0
- Distribution changé de EOLE 2.3 à Toutes
#11 Mis à jour par Frederic LAMY il y a environ 9 ans
Le fait que le compte machine apparaisse dans la liste des identités explique que controle_vnc_serveur.py refuse l'accès aux fonctions gestion-postes. Le compte machine ne faisant effectivement PAS partie du groupe "professeurs", "autorisations.py" refuse l'accès.
smbstatus -b
Avec smbstatus -b, je constate à chaque fois pour les seven un pid en double, un au nom de l'utilisateur, un au nom de la machine
6841 s214-w7-01$ DomainComputers s214-w7-01 (10.100.4.162)
6841 audrey.gauchet professeurs s214-w7-01 (10.100.4.162)
si je kill le process 6841 gestion de poste fonctionne
Je ne trouve pas d'où peut venir ce phénomène. Mais on l'a sur tout nos scribe, et uniquement sur les seven...
on pourrait soit:
- au lancement de gestion de poste;, lister et killer les process samba dont le group est DomainComputers (smbstatus b|grep DomainComputers) parser différement pour éliminer les process machines de la liste
La seconde solution semble plus judicieuse.
Merci
#12 Mis à jour par Frederic LAMY il y a plus de 8 ans
Bonjour,
UP.
j'ai quasiment la moitié des établissemnts concernés maintenant.
Peut-on régler une fois pour toute ce pb?
parser différement pour éliminer les process machines de la liste
merci
#13 Mis à jour par Klaas TJEBBES il y a plus de 8 ans
#14 Mis à jour par Daniel Dehennin il y a plus de 8 ans
- Tracker changé de Tâche à Demande
- Tâche parente
#10814supprimé
Inversion entre la demande et la tâche.
Cela permettra d’avoir un suivi utilisateur correcte.
#15 Mis à jour par Daniel Dehennin il y a plus de 8 ans
- Assigné à mis à Daniel Dehennin
#16 Mis à jour par Daniel Dehennin il y a plus de 8 ans
La résolution de la demande #13531 a permis d’exclure les comptes machines.
Cette correction a été intégrée à la version EOLE 2.5.1.
#17 Mis à jour par Daniel Dehennin il y a plus de 8 ans
- Statut changé de Nouveau à Fermé
Demande résolue par #13531.
Une nouvelle demande peut être ouverte si un dysfonctionnement apparaît.