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.

QoQ-CoT (depuis la version 5.0 Mac Bec) gère désormais aussi les connexions VDI¹⁾ (c'est juste génial, non ? ).

La conséquence pour l'interface de suivi de connexion est la possibilité de rechercher aussi bien sur le terminal que sur la VM…

Le « terminal » correspond à l'objet connecté sur lequel l'utilisateur est « physiquement » connecté.

• Hors contexte VDI, le système d'exploitation qui héberge le poussin est installé et exécuté sur le terminal. C'est l'installation classique, un OS en local sur un PC.
• En VDI, par contre, le terminal est simplement le terminal d'exécution (le PC, client léger ou smartphone etc. qui est connecté et dispose d'un nom et d'une IP propres) qui permet d'exécuter une VM distante (qui dispose elle aussi d'un nom et d'une IP propres).²⁾

On parlera encore de « machine » pour désigner de façon générique une installation d'OS, qu'elle soit virtuelle, ou classiquement associée à un PC.

Le but premier de l'interface de recherche est de trouver qui était connecté sur telle machine (désignée par son nom) ou telle IP à telle heure. Il est donc logique de ne pas différencier dans le formulaire de recherche le nom du terminal et le nom de la VM, de même que leurs IP respectives. En effet, on cherche un certain nom ou, depuis la v5.0 Mac Bec, une certaine IP³⁾, sans qu'on sache a priori s'ils correspondent à un terminal d'exécution (le nom et l'IP sortiront alors dans le tableau de résultats dans les colonnes « Nom terminal » et « IP terminal ») ou une VM (le nom et l'IP sortiront alors dans le tableau de résultats dans les colonnes « nom VM » et « IP VM », et il y aura un autre nom et une autre IP dans les colonnes « Nom terminal » et « IP terminal »). Et si vous avez bien suivi – comme personne n'en doute – vous aurez deviné que si l'on est sur une installation classique, le nom et l'IP sortiront seulement dans les colonnes terminal, tandis que les colonnes VM seront vides.

• Notons en préalable que la recherche ne s'effectuera que parmi les connexions associées au « site »⁴⁾ choisi dans le bandeau supérieur de l'interface. Si le site n'est pas renseigné, la recherche se fait sur l'ensemble des connexions présentes en base (donc tous sites confondus).

• signification des champs du formulaire de recherche :
  • Le formulaire se décompose comme suit : Connexions actives entre <champ1> et <champ2> Nom terminal/VM <champ3> IP terminal/VM <champ4> OS <champ5> Login <champ6>
  • Les champs permettent classiquement de restreindre le résultat de la recherche aux seules connexions qui correspondent aux valeurs saisies
    • champ1 et champ2 sont des dates au format JJ/MM/AAAA HH:MM qui correspondent respectivement au début et à la fin de la fenêtre temporelle dans laquelle on va rechercher
    • champ3 est le nom de machine qu'on recherche (qui peut être une VM, une installation classique ou encore un simple terminal d'exécution)
    • champ4 est l'IP de la machine qu'on recherche (même remarque que pour le champ précédent)
    • champ5 est l'OS recherché
    • champ6 est le login recherché

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

• Pour les champs « Nom du terminal / VM », « IP Terminal / VM » et « login », depuis la version 5. Mac Bec, la recherche se fait exactement sur la chaîne saisie (quand on saisit « X », on cherche exactement « X ») alors que dans les versions précédentes, on recherchait sur tout ou partie de la chaîne saisie (avec « X », on cherchait « *X* »).
  • Pourquoi ce changement ? Parce qu'on ne pouvait pas, par exemple, chercher « ce qui commence par bt-31 », car sortait certes alors ce qui commençait par « bt-31 » mais aussi ce qui contenait, à n'importe quelle position, « bt-31 »…
  • Donc, désormais, il faut faire figurer explicitement les caractères jokers (à savoir « % », à la mode SQL). Ainsi « iut » en nom de terminal/VM n'affichera ni les connexions de « iut23 », ni celles de « salle-234-iut-marseille-01 ». Avec « iut% », on aurait eu les « iut23 », mais toujours pas les « salle-234-iut-marseille-01 » : pour les avoir il aurait fallu soit « salle-234-iut-marseille-01 », soit « salle% » ou « %iut% ». De même il faudra taper « %na% » en login pour obtenir les connexions de « anna » et de « canardvibrant ». Bref, vous avez compris…

• Les différents champs renseignés sont reliés par des « ET » : on affiche donc les connexions entre date début et date fin ET qui concernent le terminal ou la VM « terminal_ou_VM » 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.

Nous postulons, et ce à partir de la publication de la version 4.0 Rocky, que toutes vos machines (virtuelles ou pas) sont désormais équipées du poussin (disponible depuis la version 3.0 commandant Poulard). Nous ne traitons plus du cas des connexions issues des anciennes méthodes de collecte antérieures à la version 3.0 commandant Poulard soit nxlog, syslog…

• 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 »), fichier présent sur chaque machine.

• 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