15/04/2010

Lancer une application graphique par SSH

Chose assez inhabituelle pour moi, j'ai deux machines qui tournent bien à disposition. Donc je peux m'amuser un peu avec... Question du jour : comment lancer une application graphique au travers de SSH, sans VNC ou autre outils de ce genre... Le but étant... euh... bon, y a pas vraiment de but. Mais je suis sur que ça peut servir.

Première chose : je pars du principe que vous savez activer sshd correctement sur la machine serveur, et ce avec ouverture du pare-feu. Pour les utilisateurs d'openSUSE, c'est assez simple : dans YaST, Pare-Feu, Services autorisés, ajouter SSH dans la zone externe. Et configurer votre interface réseau pour qu'elle soit dans la zone externe (ce qui est bien plus sûr, en passant... ;-) )

Une fois la chose faite, sshd et X11 démarrés sur le serveur, placez vous sur la machine cliente, ouvrez un terminal, et lancez la connection ssh :
ssh -X user@machine

Je pars du principe que user a les sur X11... Notez le "-X" dans la commande qui va permettre d'importer les variables relatives à l'environnement graphique.

Jusque là, ça va... Nous allons maintenant devoir autoriser les directives allant vers le serveur X à être prises en copte depuis notre machine. Supposons que notre machine s'appelle patate . À travers la connexion SSH, nous autorisons patate à lancer des commandes faisant intervenir X11 :
xhost +patate
Nous supposons ici que le serveur connaît le nom de notre machine. Si ce n'est pas le cas, utilisez une adresse IP, par exemple :
xhost +192.168.0.10
Ce n'est pas fini, cependant... les variables X11 actuelles sont relatives à la machine cliente... il va donc falloir changer un peu les choses  en corrigeant la variable DISPLAY :
export DISPLAY=:0.0
Et normalement, c'est bon... :-) pour tester, lancez xterm depuis la machine cliente :
xterm
Mieux, xdg -open marche tout à fait convenablement de cette façon :-)

Amusez vous !

09/04/2010

Installation d'awesome pour openSUSE 11.2

En traînant sur des blogs, je suis tombé sur la page d'awesome, un bureau qui se présente comme étant un gestionnaire de fenêtres hautement configurable hautement novateur, et particulièrement adapté pour les développeurs. Comme j'aime bien me faire chi** à configurer ce genre de choses, je décide de l'installer. Coup de chance, il est dans mes dépôts, donc un
zypper in awesome
a suffi. Pour ceux qui n'ont pas cette veine, passez par ce site pour la recherche de paquets. Ou ajoutez le dépôt X11, et faites l'install avec zypper.

Et là, problème : utilisateur de KDE, je ferme ma session, me retrouve dans KDM, et pas de traces d'awesome... erf. Du coup, je fouine un peu, et je me retrouve à rajouter un fichier dans
/usr/share/kde4/apps/kdm/sessions/
C'est le répertoire où KDE va regarder, pour savoir quels sont les environnements de bureaux installés. Pour chaque bureau, un fichier .desktop. Donc on rajoute un fichier
awesome.desktop
et on met les choses suivantes dedans :
[Desktop Entry]
Encoding=UTF-8
Name=awesome
Comment=awesome
Exec=awesome
Type=XSession
TryExec=awesome

Et o ntrouve enfin awesome dans la liste des bureaux disponibles. Pour la suite (l'utilisation) reportez vous aux manuels divers. Mais je confirme : ça a l'air hautement cool :)

Amusez-vous!

Interactions de communautés.

Petite mise en contexte

De nombreux remous ont agité la communauté Alionet à la fin de l'année 2009. À l'époque, la communauté Kaméléon-Facile (KF) s'est dissoute. KF hébergeait une documentation très importante, qui servait officiellement de documentation à Alionet. Du jour au lendemain, la communauté Alionet s'est donc retrouvée sans site pour sa documentation.  Nous avons donc envisagé plusieurs solutions, et sommes tombés d'accord avec l'équipe qui assure l'organisation du projet Linuxpedia . Et nous avons alors commencé la migration, dont la description des étapes n'est pas le but de ce billet.

Cet état de fait a provoqué l'apparition d'un problème original. Nous partons de deux communautés a priori distinctes : on a des utilisateurs d'openSUSE réunis au sein d'un forum, et des utilisateurs de systèmes libres qui alimentent un wiki très vaste (plus de 2500 pages... ). Bien sur, on compte quelques personnes qui jouent sur les deux tableaux, qui contribuent à la fois au forum et au wiki... mais elles sont assez peu nombreuses, en fait. La problématique suivante est donc apparue. Les membres des deux communautés cherchent à répondre à leur besoin d'informations auprès de l'outil de leur choix, ici un forum d'une part, et un wiki d'autre part. Les attentes sotn donc propres, même si elles peuvent avoir des points commun.

De plus, Linuxpedia a un statut un peu particulier : il s'agit d'une documentation traitant de problèmes très différents. Il faut donc réussir à inclure une documentation pour une distribution spécifique, ici openSUSE, dans un cadre très général. Point positif, l'expérience n'est pas la première du genre pour Linuxpedia, qui abrite par exemple la documentation de la distribution Nutyx. Point négatif : il est nécessaire de repenser la structure de la documentation qui était proposée par Kaméléon-Facile...

Une situation à démêler...

Que ce soit pour Linuxpedia ou pour Alionet, les projets à mener sont toujours le fruit de l'attente, puis de la mise en oeuvre, de la communauté. Malheureusement, dans notre cas, la situation est extrêmement complexe. En effet, les pages à étudier sur l'ancienne documentation sont nombreuses, et doivent être mises en ligne au sein de Linuxpedia. Malheureusement, aucune architecture n'est prévue pour ce genre d'entreprise, il est donc nécessaire de tout reconstruire. De plus, Linuxpedia possède ses propres règles, qu'il serait impensable pour la communauté Alionet de ne pas suivre. L'association entre les deux  communautés doit être pérennes, sans quoi le projet mourra. Et si le projet est intéressant pour Alionet, puisqu'il permet une remise en ligne et un renouveau de la documentation, il l'est également pour Linuxpedia. En effet, cette intégration permet l'apport de nouvelles connaissances, et un partage de ressources entre les commaunutés. Il est tout à fait naturel d'envisager un transfert de compétences d'une communauté à l'autre, de façon tout à fait transparente.

Dans le cadre ainsi présenté, comment réaliser la migration? Bien entendu, les communautés sont maîtresses de la chose. Cependant, il est plus qu'indispensable de réussir à transmettre les informations clairement, surtout lors des premières phases de reconstruction : la construction de l'architecture, et le transfert des documentations les plus importantes vers la nouvelle ossature. À ce niveau d'interactions, je pense qu'il est plus habile de faire communiquer des représentants de la communauté en cercle restreint, plutôt que la communauté dans son ensemble. Cela permet de limiter les problèmes de communication, et de simplifier les processus de décision.

Attention cependant, il faut toujours garder à l'esprit la règle suivante : une décision ne peut jamais être prise par une seul personne, sans consentement des autres, et de préférence avec un large soutient. Dans notre cas, la communication a connu deux niveaux distincts, peut être trois. D'une part, l'équipe d'administration d'Alionet a construit peu à peu une architecture d'accueil, qui a longtemps été débattue avant d'arriver à un résultat satisfaisant tout le monde. D'autre part, nous avons été, et sommes toujours, engagé dans un dialogue étroit avec le staff de Linuxpedia. Ceux-ci ont ainsi pu émettre des critiques vis-à-vis du résultat que nous proposions, et améliorions peu à peu.

En choisissant cette approche, nous avons effectué l'hypothèse suivante : nous pensons être capable d'effectuer un travail qui sera satisfaisant pour la communauté. Cette hypothèse est dangereuse, car elle nous impose une très grande prudence. En effet, on peut très rapidement s'éloigner de ses objectifs, oublier quel est l'intérêt du travail que nous accomplissons, et imposer finalement un résultat décevant, sans être plus capable de comprendre pourquoi les membres sont déçus.

Et les membres de la communauté dans tout ça...

Le pari était risqué. Nous serons bientôt fixé sur la qualité de notre travail, il est très proche de la mise en ligne, la plupart des phases de migration subissent des finitions  ces jours-ci. Nous avons fait le choix discutable de parler au nom de la communauté, tout en sachant que nous ne pouvons pas la représenter pleinement.

Car après tout, ces différents projets appartiennent tous aux diverses commautés. De même que Linuxpedia ne pourrait continuer son aventure sans la contribution de ses rédacteurs, Alionet mourrait sans les interventions prolifiques de certains de ses membres, toujours prompts à défendre la carte graphique veuve et le chipset wifi orphelin.

Le travail des équipe d'administration n'est qu'une simplification pour les utilisateurs. Il permet de résoudre de façon à peu près transparente les interférences qui secouent naturellement les mouvements de ce genre de projets. Transparente pour les utilisateurs. Suite à une discussion avec un membre de l'équipe technique de Linuxpedia, ce soir (enfin, hier soir, mais bon... ), il est ressorti qu'après tout, nous ne sommes que des membres de ces communautés. Même en étant administrateurs, nous sommes aussi de simples contributeurs. Avec une contrainte supplémentaire : ce que nous faisons peut rendre la vie de la communauté plus simple. Mais ça peut aussi la détruire.

07/04/2010

Retrouver les paquets orphelins sur openSUSE

Certaines questions reviennent régulièrement. Et on n'a pas forcément de réponse, en plus. Genre "comment je connais les paquets, sur mon système, qui ont été installés comme dépendances d'autres paquets, mais pas enlevés lors de la désinstallation ? ". Je crois que j'ai trouvé une réponse, autre que "en vérifiant tous les paquets à la main"...


Pour pouvoir faire cette vérification, il va falloir... installer un paquet. Ben oui, c'est pas un tour de magie que je vais proposer. Et comme il semble que la fonctionnalité ne soit pas part intégrante de zypper ou de rpm... Donc on installe rpmorphan. Comme ça :
zypper in rpmorphan

Déjà on est content, y a un nouveau logiciel sur la machine, c'est cool :) . Au delà de ça... on va aussi pouvoir l'utiliser. Rien de plus simple :
rpmorphan
va vous sortir une liste de paquets orphelins. Plus précisément, rpmorphan va lister tous les paquets qui ne sont pas dépendance d'un autre paquet.

Attention toutefois : savoir qu'un paquet n'est pas dépendance d'un autre paquet, ça veut pas dire qu'il faut le supprimer... Il peut être une dépendance "aveugle", dans le sens où un paquet aura été mal construit. Donc les dépendances mal renseignées, en l'occurrence. Et un paquet peut ne pas être une dépendance, mais être "fortement conseillé" pour un logiciel. Genre libdvdcss, pour plein de monde. Il apparaît dans ma sortie de liborphan. Et j'ai pas l'intention de le dégager, j'aime pouvoir lire des DVD sous Linux ;)

À utiliser avec prudence et intelligence, donc ;)

Amusez vous!

Il faut toujours se méfier des utilisateurs...

Les utilisateurs sont capables de tout. Du meilleur. Mais pas souvent. Alors que pour faire le pire, ils sont toujours fichus de déployer des trésors d'ingéniosité. Et quand je dis des trésors, je pèse mes mots...
Dernier exemple en date, un collector.  Légèrement désoeuvré en fin de soirée, je décide de m'occuper en faisant du openSUSE-SAV sur un chan IRC officiel. Plutôt de bonne humeur, j'ai trouvé de la bonne musique dans ma médiathèque préférée. Ça part donc plutôt bien...
Arrive un utilisateur, avec une question magique. Problème classique, il se bat un peu avec ses pilotes vidéos. Jusque là, rien de mal. Il a une carte ATi, ça part mal. Et il a réussi à installer les pilotes pour cartes nVidia sur sa machine. 
En toute franchise, j'ai cru à un canular. Vraiment. Un gars qui vient là pour tester la réaction des intervenants du canal. Un autre désoeuvré, mais dans un esprit légèrement moins coopératif que le mien. Sauf que non, vu les réponses du gars, ça a l'air sérieux. Il l'a vraiment fait.

C'est dans des moments comme ça que je me souviens pourquoi j'interviens dans ce genre de situations... Eh oui... c'est débile, hein. Souvent je me dis de toutes façons, si les gens lisaient le manuel, ils s'en sortiraient seuls. Ils ont qu'à se démerder, zut... Si seulement c'était si simple...

Il y a des gens, dont j'espère faire partie dans une mesure raisonnable, qui s'en sorte bien face à un ordinateur. Avec un système correct, un manuel à eu près clair, et un peu de temps, ils s'en sortent pas trop mal. Y a aussi des gens qui prennent le temps, après d'expliquer.

Mais à côté de ça... y a leur équivalents, leur pendant, ces gens qui sont là pour assurer l'équilibre naturel de notre univers. Qui ne comprennent rien à l'univers de l'informatique. Mais ils en ont besoin, que ce soient pour des raisons de productivité (les gens au travail, nda) ou pour des raisons de philosophie (les libristes non-geeks, nda). Et il faut bien les aider, y a pas de raisons.

C'est pour ça que j'essaie d'intervenir. Je trouve que c'est une bonne raison. Mais parfois, faut s'accrocher pour pas le balancer le clavier.... :p

PS : je me bats encore avec l'utilisateur. Ce serait plus simple s'il était pas obligé de rebooter toutes les minutes pour passer de son live cd à son système en dur. Le pire c'est qu'il a l'air d'avoir vraiment cassé son système, ce con... :D

05/04/2010

Quand on n'a pas de tête....

...on se sert de ses logiciels pour remplacer. Par exemple, je fais une mise à jour, elle casse un bout de mon installation (ça part mal). Je veux revenir en arrière, mais j'ai pas été rigoureux... erf. Je peux démarrer, me logguer en root, rpm et zypper marchent. Le contraire serait étonnant. Pas de panique, on va pouvoir récupérer les derniers paquets installés sur le système. La formule magique est la suivante :

rpm -q -a --last|head -20

rpm alimente une base de données, que nous alimentons chaque fois que nous l'utilisons, directement ou par le biais de zypper, pour installer un paquet. Cette base de données contient, entre autres, la date de dernière installation des paquets présents dans le système. Donc on interroge rpm (c'est le -q) sur toute l'installation (c'est le -a), on classe en mettant le dernier installé en premier (c'est le --last), et on filtre avec une redirection de flux.

Ici je filtre avec un head, arbitrairement, on peut faire mieux avec un grep en précisant la date d'installation.

Amusez-vous!

04/04/2010

Imposer la version d'un logiciel avec zypper

Hé oui, encore un post pour les utilisateurs d'openSUSE (ou d'ark linux, il me semble qu'ils utilisent zypper ;) ). Et aussi pour me servir de pense bête. J'aime bien faire d'une pierre deux coups :p
Problème du jour : imposer la version d'un logiciel depuis la ligne de commande. Je me suis légèrement battu pour faire marcher baskets, aujourd'hui. C'est passé, non sans une petite lecture du manuel de zypper ;)

Donc permière chose, je fais une recherche avec zypper, sur baskets :

zypper se -s baskets
Chargement des données du dépôt...
Lecture des paquets installés...


S | Nom                | Type          | Version             | Arch   | Dépot              
--+--------------------+---------------+---------------------+--------+--------------------
v | basket             | paquet        | 1.80-4.5            | x86_64 | KDE4.4Community    
v | basket             | paquet        | 1.0svn20091126-1.81 | x86_64 | KDE4.4Playground   
v | basket             | paquet        | 1.80-4.5            | i586   | KDE4.4Community    
v | basket             | paquet        | 1.0svn20091126-1.81 | i586   | KDE4.4Playground   
i | basket             | paquet        | 1.0.3.1-9.5         | x86_64 | openSUSE-11.2-Oss  
v | basket             | paquet        | 1.0.3.1-9.5         | i586   | openSUSE-11.2-Oss  
  | basket             | paquet source | 1.80-4.5            | noarch | KDE4.4Community    
  | basket             | paquet source | 1.0svn20091126-1.81 | noarch | KDE4.4Playground
(je vous épargne une partie de la sortie, c'est pas forcément toujours utile)

Moi je veux le paquet qui est en haut de la ligne. Pour que ça marche. Parceque je suis sous KDE4.4 .

Du coup, on va forcer la version, sur l'appel de zypper, en respectant la syntaxe

zypper in paquet=version

Du coup pour moi ça donne ça :

zypper in basket=1.80-4.5

et à la fin, on a bien :

Chargement des données du dépôt...
Lecture des paquets installés...


S | Nom                | Type          | Version             | Arch   | Dépot              
--+--------------------+---------------+---------------------+--------+--------------------
i | basket             | paquet        | 1.80-4.5            | x86_64 | KDE4.4Community    
v | basket             | paquet        | 1.0svn20091126-1.81 | x86_64 | KDE4.4Playground   
v | basket             | paquet        | 1.80-4.5            | i586   | KDE4.4Community    
v | basket             | paquet        | 1.0svn20091126-1.81 | i586   | KDE4.4Playground   
v | basket             | paquet        | 1.0.3.1-9.5         | x86_64 | openSUSE-11.2-Oss  
v | basket             | paquet        | 1.0.3.1-9.5         | i586   | openSUSE-11.2-Oss  
  | basket             | paquet source | 1.80-4.5            | noarch | KDE4.4Community    
  | basket             | paquet source | 1.0svn20091126-1.81 | noarch | KDE4.4Playground

Et basket marche. Donc je suis content :)