Emile “iMil” Heitor ’s home

Au boulot, j’ai élu une solution de déploiement à haute teneur en convivialité qui m’a été suggérée par nico, j’ai nommé fabric.

Ce soft à l’utilisation simplissime permet en un tournemain de réaliser des opérations complexes en masse sur une architecture distante en utilisant le protocole SSH.

Si la documentation de la plupart des fonctions est clarissime, l’une d’entre elles, qui pourtant me semblait avoir un fort potentiel loutresque, n’était pas très clairement exposée: upload_template.
Cette fonction, comme son nom semble l’indiquer, permet d’envoyer sur un serveur distant un fichier “template” en ayant préalablement remplacé des variables par le contenu souhaité. Après un peu de lecture du code source de fabric, la subtilité de son utilisation m’est apparue.

Voici à quoi doit ressembler un fichier template, j’utilise ici l’exemple classique d’un /etc/network/interfaces à remplir avec les valeurs adéquates :

auto lo
iface lo inet loopback

auto %(iface)s
iface %(iface)s inet static
	address %(ipaddress)s
	netmask %(netmask)s
	gateway %(gateway)s

Ces variables utilisent les string interpolation formatting de python, que l’on renseigne à l’aide d’un dict de cette façon :

netinfo  = {
                'iface': 'eth0',
                'ipaddress': '10.20.30.40',
                'netmask': '255.255.255.0',
                'gateway': '10.20.30.254'
}

Et que l’on inclut finalement dans la fameuse fonction upload_template de cette façon :

        upload_template('etc/network/interfaces', '/etc/network/interfaces', context=netinfo, use_sudo=True)

Moyennant quoi, fabric enverra le fichier template sur sa destination puis remplacera les variables par leur valeurs définies dans le dict passé en paramètre.

Sysop, ne révèle pas à tes employeurs que tu construis aujourd’hui ta glande de demain.

Il y a quelques jours, un collègue m’apprenait l’existence d’un soft basé sur gnome-terminal, terminator, permettant de diviser un terminal horizontalement et verticalement. J’en parle sur #gcu, et on me signifie que screen est capable de splitter verticalement (le split horizontal était implémenté depuis longtemps) dans sa version current, présente dans debian/unstable. Étant d’une nature loutresque, je décidais donc d’ecrire un screenrc spécifique qui démarrerait screen en mode splitté avec 4 fenetres (deux en haut, deux en bas). Je m’aperçois alors que le man de screen ne mentionne nulle part comment spécifier ce comportement dans une conf. C’est en fouillant dans le repository git de screen que je lis :

+  {
+    char *args[2];
+    args[0] = "-v";
+    args[1] = 0;
+    SaveAction(ktab + '|', RC_SPLIT, args, 0);
+  }

Et effectivement, la directive split -v réalise exactement ce que je souhaitais. Finalement, pour obtenir ceci :

Il faut utiliser la syntaxe suivante dans votre screenrc :

split
split -v
focus bottom
split -v

Et tant qu’on est dans les ssheries, connaissez-vous sshmenu applet ? J’ai découvert ce petit outil à insérer dans une barre gnome voila un an et j’en suis devenu fan. Ce dernier vient enfin d’arriver dans debian/lenny, et via un ajout dans l’apt source-list, c’est également installable sur une ubuntu.

Petit screenshot :

Sur zone0, j’ai des domUs dont le ssh n’est pas accessible depuis Internet. Habituellement, je ssh sur le dom0 puis rebondis. Et puis je me suis souvenu de cette news de Reefab qui pointait une astuce à base de nc. Voici une version compactée et un peu modifiée de la doc en question :

Sur le client :

imil@tatooine:~$ cat bin/netcat-proxy-command
#!/bin/sh
bouncehost=$1
target=$2
port=$3

ssh $bouncehost nc -w 1 $target $port

nc devra evidemment etre installé sur le serveur de rebond (ici, le dom0).
Voici enfin un exemple de .ssh/config :

host cible.gcu.info
Hostname 192.168.0.1
HostKeyAlias cible.gcu.info
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
ProxyCommand bin/netcat-proxy-command rebond.gcu.info %h 2222

Moyennant quoi :

$ ssh cible.gcu.info
Warning: Permanently added 'cible.gcu.info' (RSA) to the list of known hosts.
Enter passphrase for key '/home/imil/.ssh/id_dsa':
NetBSD 4.0 (GENERIC.NOACPI) #0: Sun Dec 16 00:56:55 PST 2007

Welcome to NetBSD!

imil@cible:~$ ifconfig ne2|grep inet\\
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255

Ptite magouille.

Pour bruler mes CDs audio, j’utilise gnomebaker. Il est pratique, rapide, intuitif, et il fonctionne. Ce dernier est capable d’enregistrer des “projets”, qui correspondent en l’occurrence à un fichier XML contenant les informations sur la playlist que vous allez graver.

J’avais pas envie de coder un truc, j’ai donc opté pour du scripting de feignant. La première brique s’appelle xmlstarlet, un outil command line qui permet de manipuler du XML. Un petit coup de sed | nl permettra de mettre un peu d’ordre.
Enfin, Nous ferons appel à ImageMagick et plus particulièrement convert pour générer une image avec cette sortie. Ce qui nous donne :

#!/bin/sh

SIZE="800x600"
FONTSIZE="14"

COVER=`xmlstarlet sel -t -m "//file" -v "@path" -n $1 | sed -r 's,.*/(.+)\\.mp3,\\1\\n,'|nl -n ln -w 3 -s'- '`

convert -size ${SIZE} -stroke black -pointsize ${FONTSIZE} -draw "text 5,20 \\"$COVER\\"" xc:white output.png

Y’a plus qu’à tuner un peu.

Sur mon serveur perso, par définition, y’a des trucs perso. De plus, à l’approche d’une société nouvelle, il n’est pas superflu de prendre quelques mesures afin de préserver un semblant d’intimité.
Pour cela, les bons génies de l’Internet on créé, il y a bien longtemps, SSL.
Mais voila, il y a d’autres trucs et bidules que je souhaite pouvoir exposer en place publique. J’entreprend donc de jouer avec les directives de lighttpd pour créer des exclusions et autres redirections.
Le lien qui eclaire tout, c’est celui là. En substance, nous allons rediriger tout ce qui matche mon.host.magique et faire passer ce traffic en SSL.
Voici la conf :

On déclare le serveur TLS :

$SERVER["socket"] == "mon.host.magique:443" {
  ssl.engine = "enable"
  ssl.pemfile = "/etc/ssl/certs/lighttpd.pem"
  server.document-root = "/vers/www/magique"
  server.name = "mon.host.magique"
  auth.backend.htpasswd.userfile = "/path/vers/lighttpd-htpasswd.user"
  auth.require = ( "/" =>
    (
       "method" => "basic",
       "realm" => "ce ne sont pas ces droïdes que vous recherchez.",
       "require" => "valid-user"
    )
  )
}

Puis la redirection, tout ce qui arrive sur le port 80 du host “mon.host.magique” sera redirigé vers son équivalent en HTTPS. On note les regexps compatibles Perl qui nous permettent de récupérer l’URL complète.

$SERVER["socket"] == "mon.host.magique:80" {
  $HTTP["host"] == "mon.host.magique" {
    url.redirect = ( "^/(.*)" => "https://mon.host.magique/$1" )
    server.name = "mon.host.magique"
  }
}

Et enfin les restrictions gentilles, on n’applique pas de restrictions à host1.host.magique, unautre.host.magique et blip.host.magique car ils ont leur propre déclaration dans le fichier lighttpd.conf. Pour le reste, seuls la racine, le repertoire public ainsi que les fichiers .php et .jpg sont autorisés.

$HTTP["host"] !~ "(host1|unautre|blip).host.magique" {
  server.document-root = "/var/ou/c/est/mignon"
  $HTTP["url"] !~ "(^/$|^/public|php$|jpg$)" { url.access-deny = ( "" ) }
}

C’est quand même un peu bien.