Le suivi des connexions n'apparaît au sein de l'interface QoQ-CoT que pour les usagers déclarés “Admin” par… un autre “Admin”. Le classique principe du club. Trouvez-vous donc un parrain

Les admins disposent donc en plus de l'onglet “Graphes”, d'un onglet “Suivi des connexions” qui donne accès au monde mystérieux décrit ci-après.

• Si on ne remplit aucun champ, seules les connexions du jour en cours (depuis 00h00) apparaîtront.

• Pour les champs “Nom de la machine” et “login”, la recherche fera la complétion sur tout ou partie de la chaîne saisie (si on saisit “X”, on cherche “*X*”). Ainsi “iut” en nom de machine affichera les connexions de “iut23”, “salle-234-iut-marseille-01”, etc. De même “na” en login affichera les connexions de “nathalie” et de “anna” et de “canaille”.

• Les différents champs sont reliés par des “ET” : on affiche donc les connexions entre date début et date fin ET qui concerne la machine “machine” ET l'OS “Linux” ET le login “Jeannot”…

• Initialement, les connexions sont triées par ordre décroissant de date de début de connexion (la connexion initiée le plus récemment est listée en premier)

• On peut trier les connexions en ordre croissant ou décroissant selon chaque champ (un à la fois seulement, pas de tri imbriqué) en cliquant une fois (croissant) ou deux fois (décroissant) sur le titre de la colonne correspondante.

Cas des connexions issues des machines équipées du poussin (disponible à partir de la version 3.0 commandant Poulard). L'idée est de déployer le poussin sur toutes vos machines, la fiabilité des remontées étant bien meilleure.

• Le principe du poussin est de ne pas attendre la déconnexion de l'utilisateur pour envoyer la date de fin, mais plutôt de mettre à jour en permanence la date de fin tout au long de la durée de connexion (un fonctionnement dans l'idée de la veille automatique ferroviaire souvent appelé « dispositif de l'homme mort »). La date de fin de connexion évolue donc jusqu'à la déconnexion de l'utilisateur (on pourrait dire « dispositif de la connexion morte »…). On élimine ainsi tous les problèmes de « ratage » de la déconnexion qui pouvaient survenir avec l'ancienne méthode.
• Il faut donc ici bien comprendre que le fait qu'une connexion dispose d'une date de fin ne signifie pas qu'elle est terminée : c'est troublant, on peut le concéder… Pour savoir si une connexion est terminée, il faut vérifier que la date de fin ne varie pas pendant un intervalle de temps supérieur à la période de remontée d'information du poussin, que vous avez indiquée dans le fichier de configuration poussin.yml (paramètre send), déployé sur chaque machine.

Cas des connexions issues des machines utilisant les méthodes proposées dans les anciennes versions de QoQ-CoT (< 3.0 Commandant Poulard), soit nxlog, syslog… L'idée est de déployer au plus vite le poussin sur ces machines.

• Si la date de fin n'est pas renseignée, c'est que la connexion n'est pas encore fermée… Le champ sera rempli une seule fois, lors de la déconnexion de l'utilisateur.
• Mais l'expérience a prouvé que certaines connexions ne se ferment jamais… non pas parce que l'utilisateur s'est fossilisé devant la machine, mais parce qu'un événement particulier a fait que la fin de connexion n'a pas été transmise à QoQ-CoT. Au choix, on peut avoir, selon les versions de l'OS, l'arrêt de la machine en lieu et place de la sortie de session, l'arrachage de la prise de courant, la désintégration par torche à plasma, etc.

• Les connexions qui durent plusieurs jours sont “éclatées” en connexions de 24h, essentiellement pour des raisons de gestion des jours de la semaine ¹⁾ Ainsi si on est connecté du 3 janvier 2h17 au 5 janvier 18h03, on aura 3 connexions dans la base :
  • 3 janvier 2h17 → 3 janvier 23h59'59“, mardi
  • 4 janvier 0h00 → 4 janvier 23h59'59”, mercredi
  • 5 janvier 0h00 → 5 janvier 18h03, jeudi

Si vous utilisez le (fantastique) poussin (disponible à partir de la version 3.0 commandant Poulard) sur toutes vos machines, ce qui suit ne vous concerne plus, tout est désormais beau et simple, le peuplement de la base est permanent et automatique, sans besoin de process serveur.

Si par contre, il vous reste encore des machines utilisant les anciennes méthodes de remontées de connexions (version QoQ-CoT < 3.0 commandant Poulard), soit nxlog, syslog…, alors soit vous lisez les 20 lignes suivantes, soit vous nous croyez sur parole lorsque nous disons que nous avons tout fait pour éviter les faux doublons de connexions dans la base.

• L'algorithme de peuplement de la base, depuis la version 2.0 Bernadette, ne récupère qu'une connexion pour un quadruplet donné (Date de début initiale, Date de début, machine, login). En effet, on postule qu'il ne peut y avoir 2 connexions simultanées du même usager sur la même machine. Ceci évite, en cas, par exemple, d'exécution concurrente du script de peuplement (accidentelle en général, le plus souvent car le temps d'exécution est supérieur à l'intervalle de lancement programmé par cron), de générer des doublons dans la base, qui faussent les calculs des graphes.

• Néanmoins, il y a un cas particulier. Pour les admins, sous Windows 7 (et peut-être aussi pour 8 voire 10, va-t-on savoir), 2 événements de connexions sont générés, différenciés uniquement par l'id process associé. Parmi ces 2 connexions, seule la 2nde sera fermée, la 1re n'a pas de suite. Microsoft l'a rêvé, on l'a patché… Donc, pour régler ce cas, on permet, lorsqu'on rencontre au peuplement une connexion qui a le même quadruplet (Date de début initiale ²⁾ , Date de début, machine, login) qu'une connexion précédente, de seulement mettre à jour l'id process de la connexion initiale avec l'id Process de la nouvelle connexion. Ceci règle le cas des doubles connexions admin en ne gardant en base que la 2nde connexion, celle avec l'id Process qui se fermera…