Re: w, finger et les autres
"Marc Lefranc" <lefranc.m@free.fr> wrote:
> Pierre Crescenzo <Pierre@crescenzo.nom.fr> wrote :
> > Salut,
> > J'ai remarqué que les commandes telles "w", "finger", "who" ou "users"
> > oublient régulièrement, sur ma machine, de me signaler des
> > utilisateurs pourtant bel et bien connectés. Est-ce normal ? Je
> > précise que je ne vois cela que pour des personnes connectées depuis
> > un terminal externe (avec une bannière xdm).
>
> J'avais déjà remarqué cela sous HP-UX, et ça a l'air d'être la même
> chose sous Linux.
> Les utilisateurs logués via xdm n'apparaissent que si ils ont un
> émulateur de terminal ouvert. S'ils se contentent de lancer une
> application graphique depuis l'environnement, ils sont invisibles.
>
> Je suppose que pour construire la liste des connectés le système se
> base sur la liste des terminaux et pseudo-terminaux en activité. Par
> contre, la commande last contient une trace du login. J'ai
> l'impression que tout cela date du temps où 1 utilisateur = 1 terminal.
Ce n'est pas général à tous les systèmes Unix. En fait le serveur xdm devrait lors de la connexion créer un enregistrement de la connexion dans wtmp, mentionnant l'origine de la connexion sur le système, de la même façon que le fait la commande login exécutée pour traiter les connexions depuis un terminal physique (port série, console ou autre), ou virtuel (pseuto-terminal alloué par les serveurs de connexion tels que rlogind, et rshd).
Rappelons tout de même que wtmp est un fichier journal contenant des enregistrements binaires sur les évènements relatifs à la sécurité du système, et il trace en particulier les connexions, mais aussi
Une fois sur le système, il n'y a pas beaucoup d'intérêt qu'ont les émulateurs de terminal lancés depuis un shell d'un utilisateur déjà connecté ou depuis un menu ou une interface graphique (exécutée automatiquement lors de la création de la session X), d'ajouter des entrées dans wtmp, même si ces émulateurs de terminaux (par exemple xterm, dtterm, hpterm, openterm, kdterm...) doivent allouer un pseudo-terminal de controle leur permettant d'exécuter un shell: en effet, ce sous-shell n'est pas un nouveau login, puisque cela reprend la même connexion que la session X connectée par XDM).
Néanmoins il faut bien voir que ces processus supplémentaires peuvent être créés de façon détachée ou être détachés du processus initial, et que le terminal utilisé lors de la connexion peut très bien ne plus être là alors que d'autres pseudo-terminaux sont toujours actifs pour la même connexion.
Aussi certains systèmes Unix ont introduit la notion de "Terminal Group", similaire à la notion de "Process Group" permettant de regrouper les processus ensembles dans le cas de la transmission des signaux. Le Terminal Group a comme nom l'un des terminaux présents dans le groupe, et la connexion utilisateur est attachée non pas à un terminal mais à ce groupe de terminaux. Ce système permet alors d'avoir un suivi plus exact des utilisateurs.
Mais sur la plupart des systèmes, cette notion a été détournée ou simplifiée: le terminal group permet d'attacher un lien de parenté entre des terminaux fils et un pseudo-terminal lié à la connexion, mais qui ne sera pas détruit quand le processus de connexion auquel il est lié sera terminé. Tous les autres pseudos-terminaux sont alors des fils de ce pseudo-terminal, et les processus attachés à ces pseudo-terminaux supplémentaires n'ont pas besoin d'inscrire un enregistrement dans wtmp (la seule indication du terminal attaché à chaque processus dans la table des processus suffit, cet attachement étant hérité lors de la création de processus fils).
D'autre part, chaque terminal ou pseudo-terminal dans la liste des terminaux contient alors l'attachement au terminal group auquel il appartient.
Ce système permet alors de simplifier l'administration des processus liés à une même connexion, évite de polluer wtmp, augmente les performances des systèmes servant simultanément de nombreux utilisateurs, par exemple les grappes de serveurs avec système de haute disponibilité, qui émulent une machine unique avec de nombreux processeurs indépendants: les processus sont répartis sur des machines différentes qui communiquent efficacement par des réseaux rapides à bande passante élevée (liaisons de plusieurs gigabits/s, par bus optique ou Fast-Ethernet ou SCSI), et les terminaux sont servis par un ou plusieurs serveurs frontaux qui gèrent les groupes de terminaux, le shell étant l'un des processus tournant sur les grappes de serveurs, et déplaçable d'un processeur à l'autre sous le contrôle du système de mémoire/machine virtuelle (capable de faire des échanges de mémoire virtuelle non seulement sur disque mais aussi de mémoire à mémoire par les liaisons rapides gérant aussi un cache de pages mémoire déjà échangées, le swap sur disque SCSI ou sur un rack mémoire SCSI venant en dernier recours).
A ce sujet, je n'ai pas trop regardé dans le détail la sémantique des terminaux dans Linux particulièrement dans l'optique du développement de la haute disponibilité sous Linux, de façon comparable pour l'instant à IBM HACMP (sous AiX), HP ServiceGuard (sous HP-UX) voire Microsoft Cluster Server (sous Windows NT), mais avec des fonctionnalités intéressantes à développer telles que la reprise des processus en cours sur un autre processeur non défaillant ou moins chargé, qui oblige à une gymnastique spéciale pour réaffecter les processus et terminaux qui y sont attachés si l'optique est de conserver la session utilisateur connectée.
Reply to: