jbbarth's corner

Il est minuit et demi, elle s’est endormie doucement, je l’écoute respirer, je la regarde se débattre avec ses rêves quelques secondes, puis je la vois changer d’ennemi, se battre contre cette stupide couette qui ne veut pas la suivre pendant son demi-tour. Heureusement qu’il fait chaud, ce soir encore je n’aurai pas un cm² de tissu !

Pendant qu’elle s’enfonçait dans son doux sommeil, j’ai décidé de redémarrer un serveur du boulot à distance, j’ai sursauté, j’ai ensuite angoissé, puis j’ai commencé à me voir demain matin y aller à 7 heures, histoire que les collègues ne sachent rien de ma bête tentative de mise à jour. J’ai repris du poil de la bête, j’ai imaginé des moyens de m’approprier la console à distance, mais ça ne fonctionnait pas, de nouveau l’angoisse, et puis son visage m’a rassuré. Tout est reparti. Ce visage, si calme, à croquer, il me fascine, ça fait des mois que ça dure, plus d’un an même, et impossible de s’en lasser.

Le calme avant la tempête, demain ce sera plus tendu, grand oral de l’année, une soeurette qui fait coucou avant de partir outre Manche, une visite au consulat, une jolie course de métro en perspective quoi :)

Il est vraiment temps que je dorme.

Passé récemment sous zsh comme shell par défaut (merci Laurent), je trouve la complétion automatique de mes commandes wajig très lente. Pour mémoire, wajig est une surcouche plutôt sympa des apt* écrite en Python, et il me sert de gestionnaire de package principal sur mes Debian et Ubuntu depuis plus d’un an. La complétion automatique étant relativement rapide avec les commandes apt-get et compagnie, j’ai décidé de jeter un oeil aux scripts de complétion zsh pour wajig en particulier. J’en ai profité pour rajouter le switch -y/—yes qui manque à la complétion bien qu’étant une option parfaitement valide et documentée.

Les scripts de complétion se trouvent dans /usr/share/zsh/functions/Completion/Debian. J’ai repris le script _apt pour adapter la section install dans le script _wajig. Les deux se servent d’un 3e script commun nommé _deb_packages au cas où ça vous intéresse. Le bonheur c’est que sans connaître vraiment le langage ou les structures utilisées, comme c’est du script relativement lisible on peut tenter par des essais/erreurs de modifier ça… et on y arrive !

Voici le résultat sous forme de patch :

% diff _wajig.orig _wajig
11a12
>   '(-y —yes)'{-y,—yes}'[assume yes for any questions asked]' \
44,45c45,46
<         _alternative \
<           'packages:package:_deb_packages uninstalled' \
—-
>         _wanted \
>           'packages:package:_deb_packages "$expl_packages[@]" avail' \

Et les complétions sont redevenues rapides ; le fait de changer _alternative par _wanted m’indique d’abord une liste quand j’appuie sur TAB, plutôt qu’enchainer directement sur les options possibles.

EDIT: une simple recherche Google montre que certains poussent pour que le “framework” de complétion apt pour zsh soit aussi utilisé pour wajig ; à creuser, j’éditerai ce billet si je trouve quelque chose d’intéressant…

J’apprendrai la prochaine fois à tourner 7 fois ma langue dans ma bouche avant de dire une bêtise ; non, le nombre de /dev/ram* ce n’est pas le nombre de barettes de RAM sur un Linux. Pour connaitre ce genre d’info, lshw ou dmidecode sont plus adaptés. En reformattant la sortie avec ruby, on obtient quelque chose de ce genre :

sudo dmidecode | ruby -ne '( a=[]; 12.times{a << gets.scan(/(?:Size|Speed|Type):\s*(.*)/).first }; puts a.compact.join("/") ) if $_.match /Memory Device$/' | uniq -c

Par charité, je vous fais la même en lisible :

sudo dmidecode | \
  ruby -ne '\
    ( a=[]; \
      12.times {
        a << gets.scan(/(?:Size|Speed|Type):\s*(.*)/).first \
      }; \
      puts a.compact.join("/") \
    ) if $_.match /Memory Device$/\
  ' | uniq -c

Sur mon NC10:

      1 2048 MB/DDR2/533 MHz (1.9 ns)
      1 No Module Installed/DDR2/533 MHz (1.9 ns)

Et sur un serveur du boulot:

      8 4096 MB/<OUT OF SPEC>/667 MHz (1.5 ns)
     24 No Module Installed/<OUT OF SPEC>/Unknown

(3615 Jmelapète)

Hope this helps..

Alors ça ça ronfle comme titre ! Un SAN c’est super, c’est efficace, performant, tu peux étendre tes disques à chaud, gérer ton RAID au clic, faire de la haute dispo, te la raconter à la cafét’, bref c’est merveilleux. LVM aussi, c’est super : ça apporte pas mal de souplesse dans un environnement mouvant, et quand on fait de l’informatique professionnelle, c’est bien souvent le cas.

En gros, voici le topo : on a un volume logique (que certains appelleront abusivement “un(e) LUN”) ld_disk, mappé à un serveur server. Côté serveur, ce disque s’appellera directement (par comodité) ld_disk, donc via multipathd son nom sera /dev/mpath/ld_appli. Derrière on a monté directement l’artillerie LVM, sans partitionner (ce qui aurait été plus souple/facile/intelligent) : ce disque a été déclaré comme volume physique (PV), on a fait dessus un groupe de volumes (VG) vg_appli, sur lequel on a bêtement fait un seul volume logique (LV) sobrement appelé lv_appli. Ce volume fait initialement 300Go. Les besoins changent, et on vous demande de passer le tout à 500Go. L’OS est une RHEL 5, mais ça n’a pas d’importance a priori. Bon, on commence logiquement par étendre le disque logique côté SAN. Et on espère qu’on va pouvoir prendre en compte l’extension au niveau système sans perdre de données.

Mais comme trop de choses en ce bas monde, il est difficile de trouver des infos récentes sur le web. 99% des liens trouvés via Google vont dire que c’est impossible, ou que LVM ne le permet pas encore, qu’on n’a qu’à formatter ou recopier sur un autre disque. Quelques posts assez anciens (2004?) sur des forums dont j’ai perdu la référence hélas vont expliquer qu’il faut d’abord étendre la partition via fdisk. Seulement moi, je n’ai pas de partition, aïe.

Voici donc la marche à suivre :

# on cherche et on note le(s) chemin(s) vers notre disque au sens SCSI (exemple: 3:0:0:0 et 4:0:0:0)
multipath -ll
# on met le volume offline
vgchange -a n vg_appli
# on rescanne le périphérique au niveau SCSI
echo "1" > /sys/class/scsi_device/3\:0\:0\:0/device/rescan
echo "1" > /sys/class/scsi_device/4\:0\:0\:0/device/rescan
# on relance la découverte coté multipathd
multipath -F
multipath -v2
# puis on étend au niveau de LVM ; exemple :
pvscan
#=> PV /dev/mpath/ld_appli   VG vg_appli   lvm2 [300,00 GB / 0    free]
pvresize /dev/mpath/ld_appli
pvscan
#=> PV /dev/mpath/ld_appli   VG vg_appli   lvm2 [500,00 GB / 200,00 GB free]
# on réactive le VG
vgchange -a y vg_appli
# et on étend le LV via la taille :
lvextend -L +200G /dev/vg_appli/lv_appli
#ou via le nombre d'extents :
lvextend -l +123456 /dev/vg_appli/lv_appli
# il reste à faire l'extension au niveau EXT3 (attention, ces deux étapes sont très longues)
e2fsck -f /dev/vg_appli/lv_appli
resize2fs /dev/vg_appli/lv_appli

Hope this helps!

Depuis que j’ai mon NC10, ça doit donc faire deux mois, je cherche comment faire pour que mes bookmarks ne passent pas à la trappe à chaque resizing de Firefox. Ou aléatoirement d’ailleurs. Parce que parfois ce renard imbécile étend la barre d’url on ne sait pourquoi, et réduit les dossiers personnels à une misérable double flèche, les rendant beaucoup moins accessibles.

En gros, je voulais que ça arrête de faire ça :

Mais que ça fasse ça (et tout le temps !) :

Après avoir essayé pas mal de trucs sans succès, j’ai trouvé l’inspiration ici ; et voici donc mon UserChrome.css qui fonctionne :

#bookmarksBarContent .bookmark-item {
  min-width: 70px !important;
  visibility: visible !important;
}