Mon puppetmaster au boulot a toujours été le bon vieux webrick fourni avec puppet. J’ai récemment atteint un nombre de machines qui ne permet plus de l’utiliser, il ne scale pas. Qu’à cela ne tienne, après avoir parcouru le wiki de puppet je me suis lancé : petit résumé et condensé orienté debian.

J’ai adopté il y a quelques temps gedit comme éditeur graphique de tous les jours (et vim en ssh). je l’aime bien parce qu’il est simple, se lance rapidement, n’est pas bloated de fonctionnalités et il est extensible… On a le choix entre les plugins, ou les “commandes externes”. Voici un petit tips pour commiter vos changements dans un dépot subversion depuis gedit par une simple pression sur un raccourci clavier.

Petit tips en provenance du comte twisla. Pour matcher dans Xterm les URLs et surtout les ouvrir convivialement :

J’utilise capistrano pour éxécuter des commandes en parallèle sur mes différents serveurs. C’est un usage un peu détourné de sa destination d’origine (le déploiement d’applis) et mon problème c’est que je n’ai pas de mémoire… j’ai donc écrit une petite fonction de complétion de la commande “cap” dans mon zsh, qui parse ~/.caprc pour convivialiser tout ça.

Je suis un adepte de remember the milk, je m’en sers de todo list pour le boulot. C’est bien pratique, joli et tout. Mais ajouter une tache est un chouia long, surtout quand on veut le faire vite fait lorsque la personne est en face de vous. Je me suis donc fait un petit script ruby qui m’ajoute directement les taches dans ma liste “Travail”.

Et voila, mon premier plugin pour munin ! C’est un plugin solaris only (utilisation du module Kstat oblige) qui permet de monitorer les I/O sur les pools ZFS. Je n’ai pas trouvé comment faire des stats par pool (comprendre à la “zpool iostat”) et si quelqu’un a une astuce à ce niveau là, je suis preneur. En attendant voici le fichier.

Petit post rapide en forme de pense bête : pour extraire des infos sur les I/O des pools ZFS en perl (sous solaris) :

Tips rapide : pour accélerer la collecte des données avec munin-update, ajoutez dans /etc/munin/munin.conf du master :

Au boulot j’ai remplacé cacti par munin. Munin c’est choupi, la conf est en flat file mais ça a deux défauts, ou un selon le point de vue : le munin-cgi-graph est tout simplement moisi car d’une lenteur sans nom, et générer les images lors du poll c’est long. Sauf quand on tombe sur ce petit hack convivial qui permet de lancer en parallèle la génération pour X nodes. Malheureusement, l’exemple donné en lien n’est valable que pour la version du trunk (au moment ou j’écris ceci) et pas pour la version 1.2.6 livrée avec lenny. J’ai donc modifié mon munin-graph en “portant” le hack disponible. Résultat : 2min30s au lieu de 9min pour la génération de 80 machines (dont certaines avec beaucoup d’infos)

J’ai eu à changer récemment des paramètres sur de nombreux switches cisco. Plutot que d’y  passer ma matinée, j’ai utilisé crisco et ça ne m’a pris que 30 minutes. Petite astuce : pour enchainer facilement des commandes mettez tout dans une seule variable / ligne et parsemez de “\n”, la lib aura moins de mal.

Au boulot je déploie des fichiers authorized_keys pour différents utilisateurs, basé sur un modèle “fixe” par utilisateur. C’est un fichier qui est utilisé comme source, rangé sous files/users/[username]/authorized_keys. Le soucis c’est quand un utilisateur veut sur une seule machine un authorized_keys différent du modèle. J’ai cherché dans tous les sens, de façon bien compliquée souvent, alors qu’il existe un moyen très simple de mettre en place une “exception” par machine. En effet, le type file autorise à spécifier plusieurs sources (un array de sources) et va “fallback” sur les différents fichiers en s’arrêtant sur le premier trouvé. Ce qui nous donne en langage puppet :

Ce post fait suite à mon précédent billet concernant puppet, les backports toussa. Le paquet a été supprimmé des backports parce que les mainteneurs ont estimé que comme il est présent dans testing, et que son installation se passe sans problème, il n’était pas nécessaire qu’il soit disponible à 2 endroits.

Si vous avez lu l’article sur puppet dans le GLMF n°112 de janvier 2008, une petite erreur s’est glissée dedans. Je préconise l’utilisation de backports pour puppet en version stable si on désire avoir une version récente. Or, entre l’écriture de l’article (et les tests que j’avais fait) et sa publication, le package puppet a été supprimé des backports… Donc il vous reste soit à upgrader, soit à installer la version venue de testing…

Je cherchais depuis un petit moment un NAS sympa, qui réponde à mes besoins : silencieux, pas moche, facilement manageable au niveau volumes, opensource friendly et extensible au niveau des fonctionnalités. Mon choix s’est porté sur le Drobo, de chez Data Robotics et son DroboShare. Petit partage de mon expérience.

Il y a quelques temps j’ai essayé de monter des disques iSCSI exportés depuis mes filers opensolaris sur des machines linux. Le problème c’est que lors de la connexion à la target, l’initiator se plantait lamentablement dans un kernel panic de derrière les fagots. Maintenant que lenny est presque là, avec des kernels récents (2.6.26) on peut jouer avec tout ça. Petit résumé & regroupement des informations éparpillées à travers le web. La target sera une machine solaris, et l’initiator une debian dotée d’un kernel 2.6.26-1-amd64.