Emile "iMil" Heitor 's home

Parce que cela sera plus pratique, parce que ça fait un bail que j’y ai pas retouché, parce qu’il y a certaines technos que j’ai envie de vraiment manipuler et parce que j’aime bien varier les plaisirs, j’ai installé un desktop sous OpenSolaris 2009.06.

L’installation étant devenue aussi triviale qu’une bête Ubuntu, je ne m’étendrai pas ici sur cet aspect.

Il y a cependant un élément qui m’a donné du fil à retordre, un truc qui m’agace toujours autant, quel que soit l’UNIX, les locales et prises de tête connexes.

Pour plein de raisons toutes aussi subjectives qu’historiques, aucune de mes machines n’utilise UTF-8, et d’habitude, je place simplement LANG=en_US.ISO8859-15 ainsi que LC_CTYPE=fr_FR.ISO8859-15. Première astuce, sous OpenSolaris, il est nécessaire de renseigner la variable LANG dans /etc/default/init. LC_CTYPE trouvera sa place dans un ${HOME}/.bashrc ou équivalent.

À ce stade, alpine et irssi affichent correctement les caractères accentués.

Arrive alors la configuration du clavier, que j’ai pour habitude de mapper en qwerty, laissant à la touche Compose (AltGr chez moi) le soin d’accentuer les caractères. Généralement, je fais cela à l’aide de ces lignes dans mon fichier /etc/X11/xorg.conf :

	Option "XkbRules"   "xorg"
	Option "XkbModel"   "pc105"
	Option "XkbLayout"  "us"
	Option "XkbOptions" "compose:ralt"

Ce qui a pour effet de permettre le fonctionnement suivant :

Frappe simultanée de AltGr + ‘ puis e donne é

Sauf que cette fois, sur le X11/gnome fourni par Sun, cette combinaison donne ‘é (avec l’apostrophe devant). Très enervant.
J’écume une liste infinie de forums, documents, wikis et j’en passe, sans réellement trouver de solution, et finalement, en désespoir de cause, modifie dans gnome-terminal la valeur de Input Method, me rendant compte qu’avec la valeur Simple, le comportement que je souhaite se produit.

N’étant pas exactement à l’aise avec ce nouveau desktop, je ne me lancerai pas en conjectures infondées, mais à la lecture de plusieurs posts, je crois comprendre qu’il faut démarrer scim (Smart Common Input Method) sans la session gnome, et placer les valeurs suivantes dans le fichier ${HOME}/.profile qui sera lu par gdm :

export GTK_IM_MODULE=scim
export QT_IM_MODULE=scim

Moyennant quoi: àéüí

phew, ça marche.

J’aborde le problème de manière tout à fait empirique et je n’aime pas ça, mais je crois comprendre qu’un autre Input Method manager est installé par defaut, iiim. J’ai préféré le desinstaller ($ pfexec pkg uninstall SUNWiiim*) afin de ne pas générer de conflits.

Probablement ai-je mal cherché, mais si un lecteur averti possède quelques pointeurs sur la question, je serai ravi de comprendre réellement comment fonctionne tout ce petit monde.

update

ah, oui, le screenshot.

On peut lire sur GCU que nous avons passé une partie du week end, après un bafr bien arrosé, à mettre à jour Zone0.GCU-Squad.org, machine qui héberge le site, et moult services du groupe.

Il faut l’avouer, cette mise à jour fut une promenade de santé en comparaison de sa cauchemardesque installation voila deux ans. Je me propose tout de même de vous raconter les quelques manipulations qui furent nécessaires à sa migration vers 2009.

Rappelez-vous, Zone0 c’était :

• Un quad-core VT-capable
• Une debian etch
• Un noyau Linux 2.6.18 patché en raison d’un bug du driver du controlleur RAID 3ware
• En conséquence du point précedent, un Xen 3.1 roulé sous les aisselles en provenance de Xen.org

Contre toute attente, un simple :%s/etch/lenny/g suivi d’un apt-get update && apt-get dist-upgrade a rectifié la situation bancale d’un Xen et d’un noyau non-issus de debian, ce qui rendait tout upgrade très périlleux.

Il est à noter qu’en raison du passage de lvm1 à lvm2, il a été nécessaire de se refendre d’un apt-get dist-upgrade, alors seulement l’installation d’un nouveau noyau utilisera les nouveaux hooks de lvm2 pour générer un initrd correct. Le noyau installé est en l’occurrence linux-image-2.6.26-2-xen-amd64.

Un reboot plus tard, le dom0 2.6.26 était controllé par Xen 3.2.

Pour être tout à fait honnête, nous avons planché quelques minutes sur un problème lié à l’ancienne installation. En effet, les domUs hvm ne démarraient pas, et nous constations que qemu-dm, l’executable en charge de virtualiser les péripheriques, était en état defunct. La raison était en réalité simplissime, les configurations de nos domUs faisaient appel aux fichiers /usr/lib/xen/boot/hvmloader et /usr/lib/xen/bin/qemu-dm, or c’étaient les anciens binaires qui se trouvaient là, ceux installés par la version 3.2 issue du package debian se trouvent dans /usr/lib/xen-default (qui est un lien logique vers /usr/lib/xen-3.2-1). Rien de bien méchant.

Une fois rebootée, c’en était fini pour notre session au datacenter, et il me revenait de mettre à jour les deux domUs NetBSD. Double (quadruple donc) mise à jour, puisqu’en plus de migrer les deux systèmes vers NetBSD 5.0.1, en raison de l’incroyable gain de performance que j’avais constaté entre le mode HVM et Paravirtualisé de Xen, j’avais prévu de profiter de cet upgrade massif pour basculer les domUs NetBSD en mode paravirtualisé.

Là encore, rien de terrifiant, dans la configuration des domUs, j’ai simplement remplacé :

kernel = '/usr/lib/xen-3.2-1/boot/hvmloader'
builder = 'hvm'
device_model = '/usr/lib/xen-3.2-1/bin/qemu-dm'

par

kernel = '/home/xen/NetBSD/5.0.1/netbsd-XEN3PAE_DOMU.gz'

Après avoir booté les domUs sur ce kernel domU modifié, il n’a s’agit que d’une procédure d’upgrade des plus classiques, suivie de la mise à jour des packages à l’aide de pkg_comp (recréé pour correspondre au système réel) puis pkg_chk.

Les machines, virtuelles et réelles, semblent bien se comporter, et je suis désormais complètement convaincu par la supériorité du mode paravirtualisé, les temps de réponse sont simplement sidérants.