Skip to content

Linux Attitude

Le libre est un état d'esprit

Archive

Tag: Interface graphique

Niveau :      
Résumé : clusterssh, clusterm, konsole, dsh, pssh

Bonjour à tous, très honoré d'être à la tribune de ce blog, mais on m'a forcé la main !

Pour rebondir sur un post récent (tout juste un an !), voici quelques outils pour travailler efficacement sur un groupe de machines.

Konsole et dsh, les ancêtres

Comme Peck l'avait présenté, pour envoyer une même suite de commandes sur un groupe de machines, on peut soit le faire à l'aveugle avec Konsole (si on supporte KDE), soit lancer ses commandes coûte que coûte avec dsh, mais sans contrôle encore une fois sur le déroulement.

Avec Konsole : préparez dans une même fenêtre une machine à contrôler par onglet, puis dans les menus : View > Send Input to All Sessions. Désormais, tout ce que vous tapez est répété dans toutes les fenêtres.

Avec dsh :

 dsh -m machine1 -m machine2 commande

Attention, n'oubliez pas que votre commande est d'abord interprétée par votre shell. Ainsi, comparez :

 dsh -m machine1 -m machine2 -m ... "echo $HOSTNAME"
 dsh -m machine1 -m machine2 -m ... 'echo $HOSTNAME'

Relisez l'article pour apprendre comment créer des groupes de machines avec dsh.

clusterssh et clusterm

Mais si on désire surveiller ce qui se passe sur toutes les machines, et ainsi avoir un contrôle visuel, et au besoin effectuer une correction sur une machine en particulier, alors des outils graphiques rendent bien service, en affichant dans un terminal distinct chacune des machines que l'on contrôle. Par ici pour des captures d'écran, et un petit article de présentation de clusterssh !

Vous pouvez définir vos groupes de machines dans le fichier /etc/clusters :

groupe1 machine1 machine2 machine3 machine4 machine5 machine6 machine7 machine8 machine9
groupe2 machine10 machine11 machine12 machine13 machine14 machine15
all groupe1 groupe2

continue reading...

Niveau :      
Résumé : kdmctl

Un chanteur me faisait justement remarquer hier que j'oubliais la population kdeiste au profit des gnominés (et encore on peut très bien utiliser kdm avec gnome). Comme je ne suis pas sectaire je vais de ce pas réparer cette injustice.

Nous cherchons donc une commande permettant de commander kdm, et comme par hasard, elle existe. Commençons par lancer un ouvel écran de connexion :

$ kdmctl reserve

Tout comme gdmflexiserver, kdmctl locke l'écran en cours. Par contre, il ne permet pas de lancer la nouvelle connexion sur un Xnest, à la place il propose une option permettant de fermer cet écran automatiquement au bout d'un timeout.

Le manuel de kdmtcl nous révèle d'autres commandes :

# Change le serveur en cours d'affichage
$ kdmctl activate :2

Vous trouverez aussi une commande pour éteindre proprement la machine ou pour connecter automatiquement un utilisateur après un timeout donné.

Voila, vous pouvez maintenant scripter kdm aussi bien que gdm.

Niveau :      
Résumé : gdmflexiserver

Il existe une commande bien sympathique qui permet de lancer une nouvelle session gdm sans couper la dernière. En effet, lorsque vous avez une session ouverte avec gdm, le serveur X est occupé et ne vous permet donc pas de vous connecter sous un autre utilisateur. Ceux qui ont une distribution bien léchée ont déjà un bouton changer d'utilisateur qui permet ce genre de chose. Comment se fait-ce ?

Celles-ci utilisent la commande gdmflexiserver. Cette commande demande directement à gdm de lancer un nouveau serveur X et d'y ouvrir un nouvel écran de connexion.

$ gdmflexiserver

Notez au passage que gdm locke le serveur d'origine, ce qui empêchera le nouveau venu de faire un petit ctrl-alt-Fx pour se faire passer pour vous sans votre mot de passe.

Petite option utile, gdmflexiserver permet d'ouvrir la nouvelle session dans une fenêtre à l'intérieur de la première en utilisant Xnest. Grâce à quoi vous pourrez par exemple lancer une session gnome propre plutôt que de vous embêter à gérer le lancement de votre Xnest à la main.

$ gdmflexiserver -n

En pratique gdmflexiserver implémente une communication générique avec le démon gdm, ce qui veut dire qu'il peut être utilisé pour d'autres choses. Par exemple, récupérer la version de gdm qui tourne :

gdmflexiserver -c VERSION

La liste des commandes disponibles ne se trouve que dans le source de gdm, mais elles sont tout de même documentées. Pour les trouver, cherchez les constantes commençant par GDM_SUP_ dans gdm.h. Notez que certaines commandes nécessitent une authentification préalable (avec l'option -a) :

$ gdmflexiserver -a -c QUERY_VT

Grâce à cette commande, vous pourrez scripter ce qui vous intéresse. Essayez par exemple changer la configuration de gdm en direct.

Niveau :      
Résumé : esd -tcp -public

Au commencement était la carte perforée, Puis il y eut le clavier et l'imprimante, qu'on améliora en terminal. Et enfin il y eut le terminal X, mais la course ne s'arrête pas là. Il nous manque encore le son.

Hé bien, nous allons nous y mettre ! Je ne vous parlerai que du cas de gnome, probablement adaptable à kde. Écrivez moi si vous avez la recette.

Tout d'abord, il vous faut une machine sous gnome et un dm (gdm, kdm, xdm ...) qui accepte les connexions XDMCP (ce n'est pas indispensable, mais tellement plus pratique).

Connectez-vous d'abord sous gnome, puis lancez

$ gstreamer-properties

Modifiez le plugin de sortie pour esd, et faites un test pour vérifier que le son fonctionne.

Maintenant déconnectez-vous et mettez-vous sur une autre machine. Lancez esd, puis xorg :

$ esd -tcp -public -nobeeps -terminate &
$ Xorg -query lamachine distante

Et voilà, après vous être connecté sous gnome, vous aurez le son pour les applications gnome.

Si vous n'êtes pas en xdmcp, ou si vous voulez faire fonctionner le son pour une application seulement, il vous faudra changer une variable juste avant de lancer l'application en question

$ export ESPEAKER=machine.avec.esd:16001

Maintenant supposons que votre machine faisant l'affichage soit un windows. C'est toujours possible !

Utilisons Xming, ainsi que esd pour windows.

Il vous faudra un Xming installé et un fichier xlaunch fonctionnel : lancez xlaunch et juste avant de lancer le serveur X, cliquez sur sauvegarder. Il vous faudra aussi avoir extrait le paquet esound pour windows.

Et créons un batch pour tout ceci :

call c:\esd.bat
c:\xming\xlaunch.exe -run c:\linux.xlaunch

Et dans le esd.bat

c:\esd\esd -tcp -public -nobeeps -terminate

Bien, sûr, adaptez à vos emplacements. Notez au passage que Xming supporte très bien l'openGL et par conséquent, un certain nombre de jeux fonctionneront mieux à distance sous windows que sous linux (moins depuis l'existence de AIGLX).

Niveau :      
Résumé : xrestop && xwininfo && xev && x2x && import

Si vous avez lancé une application graphique chez vous et que, comme moi, vous êtes parti au boulot sans cliquer sur sauvegarder, c'est rageant de ne pas pouvoir le faire à distance. Eh bien je vais vous proposer une solution à l'aveugle qui marche.

On commence par se connecter sur la machine portant l'affichage distant et on fait en sorte de se connecter au serveur X. En cas de problèmes de droits, lire l'article sur xauth :

$ ssh mamachine.net.net
$ export DISPLAY=:0

Maintenant il nous faut le pid du processus concerné, rien de plus simple :

$ pgrep -l firefox
> 4908 firefox-bin
$ PID=4908

Ensuite on cherche les fenêtres appartenant à ce processus et en particulier leur titre :

$ xrestop -b -m 1 | grep -A 15 "PID: $PID"
> 0 - Linux attitude - Iceweasel ( PID: 4908 ):
>  [... blah ...]

$ TITLE="Linux attitude - Iceweasel" 

De ce titre on peut déduire l'ID de la fenêtre :

$ xwininfo -name "$TITLE" 
> xwininfo: Window id: 0x2400276 "Linux attitude - Iceweasel"
>  [... blah ...]
$ ID=0x2400276

Ça y est nous avons notre info, nous allons pouvoir commencer à travailler. Rappelez-vous, nous sommes aveugles, il nous faut obtenir le toucher, nous allons donc percevoir ce qui ce passe sur cette fenêtre :

$ xev -id $ID

continue reading...

Niveau :      
Résumé : mplayer -speed 1.5 -af ladspa=tap_pitch:tap_pitch:0:-33:-90:0 foo.avi

Aujourd'hui nous allons voir comment regarder deux films en moins de 2h. Plusieurs possibilités : soit vous trouvez 2 films d'une heure et là tout va bien sauf le choix des films. Soit vous passez les 2 côte sur deux écrans, et là il vous faut un cerveau multitâches efficace. Une dernière possibilité est de les passer en accéléré, et là il vous faut juste un cerveau plus rapide (quoique, ça dépend du film).

Étudions cette dernière possibilité, l'inconvénient est qu'avec un lecteur normal vous aurez du mal à comprendre les dialogues à cause de la voix déformée des acteurs. Heureusement, une solution existe.

Mplayer vient avec un système de plugins sonores nommé ladspa. Tom, un gentil libriste a fait quelques plugins ladspa dont un permettant de corriger le pitch d'une bande son (ce plugin est disponible dans le paquet tap-plugins chez debian).

Vous pouvez donc lancer mplayer avec ce plugin et obtenir un son normal.

$ mplayer -speed 1.5 -af ladspa=tap_pitch:tap_pitch:0:-33:-90:0 toto.avi

Pour les paramètres du plugin ils sont expliqué sur le site :

  • Le 0 veut dire que l'unité est le pourcentage.
  • Le -33 se calcule par la formule suivante : (1 - 1.5) / 1.5 * 100 : 1.5 étant le multiplicateur de vitesse précédent
  • Le -90 veut dire qu'on supprime le son original
  • Le 0 veut dire qu'on garde le son calculé

Le problème de cette technique est que la correction du pitch ne peut pas se faire en live. Dommage, si quelqu'un veut s'amuser à coder un patch mplayer pour que ça marche, ça serait gentil.

Sinon pour les détails, le billet original se trouve ici : http://markplusplus.wordpress.com/2006/10/01/pitch-correct-play-speed-with-mplayer/. Il contient un certain nombre de commentaires intéressants, lisez-les.

Niveau :      
Résumé : Xdmx

Si vous avez plusieurs écrans, vous voudriez bien avoir un seul couple clavier/souris ainsi qu'un seul window manager pour gérer l'ensemble. Si vous êtes en local, c'est simple. Il suffit de lancer un unique serveur X avec plusieurs écrans définis ou avec un seul écran viruel (ça marche même s'il s'agit de plusieurs cartes vidéos et non d'une carte multitête). Mais si vous devez avoir plusieurs serveurs X à cause d'un bug du driver ou, plus excusable, des écrans sur des machines différentes, vous pouvez regrouper plusieurs serveurs X en un seul. Imaginez une mosaïque de 16 écrans répartis sur 4 machines !

Xdmx sert justement à ça :

$ Xdmx -display machine1:0 machine2:0 :1

Notez que Xdmx ne prend pas nécessairement pour input le clavier/souris des display concernés. Vous pouvez prendre celui de n'importe quelle autre machine existante, ou celui de la machine sur laquelle il tourne si c'est en console.

# on utilise un autre display comme source d'input
$ Xdmx -display machine1:0 machine2:0 -input machine3:0 :1
# on utilise le clavier local à Xdmx
$ Xdmx -display machine1:0 machine2:0 -input local,kbd,ps2 :1

Par défaut Xdmx crée un unique display avec plusieurs écrans (:1.0 et :1.1 dans notre exemple), ce qui est finalement peu intéressant par rapport à l'utilisation de x2x. Mais on peut aussi lui demander de les regrouper en un seul écran virtuel grâce à xinerama :

$ Xdmx +xinerama -display machine1:0 machine2:0 -input machine1:0 :1

Et maintenant, astuce ...

Xdmx supporte la déconnexion et la reconnexion d'écrans.

Il est donc possible de faire une application qui supporte la déconnexion d'un serveur X de façon volontaire. Attention, lorsque ceci fonctionne, l'opengl est désactivé :

# on lance Xdmx sur un nouveau premier serveur X
$ Xdmx -display machine1:0 -addremovescreens -norender -noglxproxy :1
# on lance une application à travers xdmx (qui nous sert de proxy)
$ xclock -display :1
# on supprime l'accès au premier écran de xdmx (qui est sur le premier serveur X)
# attention à bien lancer cette commande, une coupure violent de l'écran fait planter xdmx
$ dmxrmscreen :1 0
# et on réactive le premier écran sur un 2e serveur X
$ dmxaddscreen :1 0 machine2:0

Et voilà !