"Marc Lefranc" <[EMAIL PROTECTED]> wrote: > Pierre Crescenzo <[EMAIL PROTECTED]> 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.
