Univers Libre

Carte des pistes de ski des Laurentides

2019-04-23T00:00:00+00:00

Après 4 hiver à skier et cartographier les pistes de ski nordique des Laurentides, je me devais de produire une carte de tout ça. C’est maintenant chose faite avec ces 2 cartes des Laurentides :

secteur sud (format A4)
secteur nord (format A4)

Ce sont les premières cartes à couvrir tout le secteur des Laurentides, et à être plus complètes que les cartes locales des différents organismes, qui ne montrent pas certaines des pistes historiques.

Pour générer ces cartes, j’ai utilisé QGIS, puissant outil libre de SIG mais qui reste assez complexe à maitriser pour quelqu’un comme moi qui manque clairement de connaissance dans ce domaine.

Voici les sources du projet QGIS.

J’explique ci-après les étapes en gros que j’ai suivi pour construire la carte dans QGIS.

Fond de carte

Pour les données topographiques, j’adore le rendu de OpenTopoMap pour leur précision et leur qualité graphique. J’ai donc connecté leur serveur WMS dans QGIS pour avoir leurs tuiles en fond de carte.

Récupération des données relatives aux pistes de ski nordique

Le but ici est de récupérer les données brutes de OpenStreetMap relatives aux pistes de ski nordique afin d’avoir des données vectorielles sur lesquelles travailler.

QGIS, via le plugin QuickOSM, peut interroger directement l’API Overpass pour récupérer ce qui nous intéresse. On va donc récupérer plusieurs choses à l’aide de requêtes Overpass API :

tous les sentiers. Ils sont déjà rendus sur les tuiles OpenTopoMap mais ça permet de les mettre un peu plus en valeur :
```
way["highway"="path"]({{bbox}});
out geom;
```

les relations ayant pour tag piste:type=nordic :

relation["piste:type"="nordic"]({{bbox}});
out geom;

les chemins (dans le vocabulaire de OpenStreetMap) ayant pour tag piste:type=nordic :
```
way["piste:type"="nordic"]({{bbox}});
out geom;
```

et enfin les chemins qui ont pour tag piste:type=nordic mais n’étant dans aucune relation ayant pour tag piste:type=nordic. C’est une astuce qui va être importante pour la suite. Plus compliqué (merci les nombreux exemples de requêtes Overpass API) :

// On récupère les chemins avec piste:type=nordic et on stocke ça dans
// le set .all
way({{bbox}})["piste:type"="nordic"]->.all;

// On récupère les relations pour lequelles au moins un de leur chemin
// membre est présent dans le set .all
rel["piste:type"="nordic"](bw.all);
// et pour ces relations, on récupère tout leurs chemins membres dans
// .members
way(r)->.members;

// Il ne reste plus qu'à faire la différence des 2 sets
( .all; - .members; );

out geom;

QuickOSM stocke le résultat de chaque requête dans des calques séparés. On voit déjà que des mêmes données se retrouvent dans plusieurs calques (la 3ème requête inclue forcement les données de la 4ème et beaucoup de chemins avec piste:type=nordic ont aussi le tag highway=path. Idéalement j’aurai rajouté des exclusions dans les requêtes, mais je suis allé au plus simple, pourquoi s’embêter avec des requêtes Overpass quand il suffit de changer l’ordre d’affichage des calques.

J’ai donc dans l’ordre (du plus bas au plus haut) :

le calque de fond de carte OpenTopoMap
le calque avec les chemins avec highway=path
le calque avec les relations avec piste:type=nordic
le calque avec les chemins avec piste:type=nordic qui ne font parti d’aucune relation (mais dont le tracé est masqué, voir la suite)
le calque avec les chemins avec piste:type=nordic

Maintenant il s’agit d’ajouter des styles à tout ça

Pour reprendre ce qui se fait de plus commun au Québec, les pistes de ski de fond tracées seront en trait plein et avec le code de couleur représentant leur niveau de difficulté (vert/bleu/noir). Les pistes de ski nordique (communément appelé « hors-piste ») seront en rouge et en tirets. Les autres sentiers seront noir en tirets avec une épaisseur légèrement moindre que les autres (ils sont moins importants). Les relations quant a elles ont une couleur rouge pale. Ça ne se verra pas dans la plupart des cas car par dessus il y a la couleur de la piste de ski (appliquée sur les calques des chemins, sauf dans le cas où la piste que représente la relation traverse un lac ou suit une route : dans ce cas il n’y a pas de chemin avec piste:type=nordic. Ça permet de bien différencier là où il y a une vraie piste des parties qui ne sont pas forcement skiables (routes) ou qu’il n’y a pas de tracé définit (lacs).

Pour les 2 premiers calques (de l’ordre évoqué précédemment), c’est simple on joue avec les options de style de QGIS. Pour le 3ème, on ne veut pas les afficher donc on les mets en transparence totale ou largeur de 0 px (c’est toujours à cause de la fameuse astuce, j’y reviens, j’y reviens !).

Et enfin pour le 4ème calque, pour définir le style en fonction du type de piste et du niveau de difficulté (pour les pistes tracées), on va dire à QGIS de gérer le style suivant 5 règles, que voici :

"piste:grooming" =  'backcountry'
("piste:grooming" like '%classic%' or "piste:grooming" like '%skating%') and "piste:difficulty" = 'easy'
("piste:grooming" like '%classic%' or "piste:grooming" like '%skating%') and "piste:difficulty" = 'intermediate'
("piste:grooming" like '%classic%' or "piste:grooming" like '%skating%') and ("piste:difficulty" = 'advanced' or "piste:difficulty" = 'expert')
"piste:grooming" = 'scooter'

Puisqu’on a accès à tous les attributs OSM dans les données vectorielles importées, c’est relativement simple.

Nom et référence des pistes

Ensuite vient la partie où il faut placer le nom et/ou la référence (en fonction de qu’est ce qui est présent dans les attributs OpenStreetMap) sur les pistes. C’est là que j’ai bloqué pendant longtemps car, au niveau de OpenStreetMap, c’est un peu le bordel : une piste peut être créée par une relation qui assemble plusieurs chemins. Dans ce cas le nom et la référence (numéro ou lettre identifiant la piste en pratique) de la piste sont portés par les attributs name et ref de la relation. Une piste peut aussi ne pas avoir de relation, et être constituée d’un ou plusieurs chemin indépendants. Dans ce cas le nom et la référence peuvent être portés par les attributs name et ref des chemins où, si ces attributs existent déjà et qu’ils ne reflètent pas les bonnes valeurs, par les attributs piste:name et piste:ref (c’est le cas par exemple si la piste de ski emprunte un sentier de vélo ou de marche qui est nommé différemment).

Mon problème sur lequel j’ai luté pendant un moment était pour savoir si un chemin faisait parti d’une relation ou nom via le langage de requête de QGIS. En effet, une fois les données OSM importées, on perd leur structuration. La solution qu’on m’avait proposée sur StackOverflow consistait à utiliser des fonctions géométriques pour voir si le chemin donné se superposait à la relation donnée, mais je ne pouvais pas faire ça simplement pour chacune des relations à tester. D’où l’idée que j’ai eu de récupérer ce fameux calque supplémentaire : les chemins qui ne font partie d’aucune relation. Ainsi au niveau de QGIS c’est bien plus simple : j’affiche les noms pour le calque des relations ainsi que pour le calque des chemins n’ayant pas de relations. Le calque qui contient tous les chemins, lui, je ne lui fait afficher aucun nom.

Pour chacun des 2 calques, Il reste quand même à savoir quels attributs afficher parmi name, ref, piste:name et piste:ref mais ça se fait simplement avec le langage de QGIS.

Pour les relations :

case
    when name <> '' and ref <> '' then
        name || ' (' || ref || ')' 

    when ref <> '' then
        ref

    when name <> '' then
        name

end

Pour les chemins :

case
    when ("name" <> '' or "piste:name" <> '') and ("ref" <> '' or "piste:ref" <> '') then
        if("piste:name" <> '', "piste:name", "name") || ' (' || if("piste:ref" <> '', "piste:ref", "ref") || ')' 
    
    when "ref" <> '' or "piste:ref" <> ''then
        if("piste:ref" <> '', "piste:ref", "ref")
    
    when "name" <> '' or "piste:name" <> '' then
        if("piste:name" <> '', "piste:name","name")

end

On a maintenant les noms et/ou les référence des pistes qui s’affichent, et sans conflit. J’ai du jouer beaucoup sur les options d’affichage de QGIS car par défaut si la ligne est trop courbe dans tous les sens ou qu’il y a déjà trop d’information à un endroit, le moteur de QGIS n’affiche pas le nom. Pour plus de lisibilité, mais du coup je me retrouvais avec beaucoup de piste qui n’étaient pas identifiées.

Composition des cartes

Enfin c’est le moment de générer l’aperçu de la carte, via le module de composition de QGIS. Je définis la zone géographique que je veux imprimer, fixe une échelle, y ajoute des objets de texte pour le titre, les sources de données utilisées, une barre d’échelle, etc… QGIS permet de générer automatiquement une légende en fonction des règles de style qu’on a définit précédemment, ce qui est très pratique !

J’ai décidé de générer 2 cartes (secteur nord et secteur sud) pour économiser de la place sur le papier, car il n’y a pas beaucoup de pistes entre les 2.

J’aurai aimé pouvoir imprimer cette carte sur du grand papier pour pouvoir la donner à des collègues de ski. Pour avoir une échelle de 1:50 000, ça m’aurait pris environ une surface de papier de 1 m × 1 m. Mais après quelques devis, les prix sont vraiment chers et je ne suis pas non plus 100 % satisfait du rendu graphique (ni certain du résultat une fois imprimé !) donc j’ai plutôt décidé de découper ça en feuille A4 avec posterazor.

Améliorations

Il y en a beaucoup !

Déjà construire cette carte a permis de détecter pas mal de petites erreurs dans OpenStreetMap sur les données utilisées, je n’ai clairement pas tout corrigé, au delà du fait qu’il y a toujours des pistes incomplètes à aller explorer.

Je ne suis pas non plus très satisfait du placement automatique des noms des pistes par QGIS, bien que j’ai pas mal bidouillé ses réglages. La solution serait probablement de placer le nom des pistes à la main pour chacune d’elles, pour ainsi les mettre à l’endroit qui me semble le plus naturel.

Mais surtout je ne peux malheureusement pas considérer mes cartes générées comme de réelles cartes topographiques car j’ai du faire plusieurs approximations :

la projection utilisée est la pseudo-mercator, projection utilisée par OpenTopoMap sur lequel je me base et typiquement utilisé pour le rendu des cartes sur le web. Cette projection fait que l’échelle varie en fonction de la latitude et donc pas adaptée pour une carte topographique. Je devrais plutôt utilisé la projection UTM (zone 18 N pour la région qui m’intéresse ici), qui n’introduit pas de distorsion d’échelle et est utilisé comme projection officielle au Canada. Cependant ça aurait voulu dire regénérer toutes les tuiles avec le style OpenTopoMap avec la bonne projection, donc beaucoup de travail
la deuxième approximation est beaucoup plus classique et est au niveau de la sortie en PDF st du fait que je découpe le gros fichier en plusieurs A4, je n’arrive pas à garantir que l’échelle est correctement conservée entre le moment où je produits le PDF dans QGIS et où j’imprime les feuilles A4.

Mis à part ces problématiques, j’espère que cette carte pourra servir aux autres skieurs pour découvrir des nouvelles pistes dans les Laurentides !

Using molecule with GitLab CI

2019-04-21T00:00:00+00:00

This article follows this one where I talk about verifying and testing your Ansible roles with molecule.

As I wrote in this first article, I also configured GitLab CI to automatically run molecule tests after each push to the repository. A good documentation to start with is the official GitLab CI/CD documentation.

Here is our .gitlab-ci.yml (latest version) used on our ansible repository hosting all our roles:

---
image: quay.io/ansible/molecule:latest
services:
  - docker:dind

stages:
  - tests

before_script:
  - docker -v
  - python -V
  - ansible --version
  - molecule --version

molecule-role-common:
  stage: tests
  tags:
    - docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    PY_COLORS: 1
  script:
    - cd roles/common/
    - molecule test
  only:
    changes:
      - roles/common/**/*

molecule-role-monitoring-tools:
  stage: tests
  tags:
    - docker
  variables:
    DOCKER_HOST: "tcp://docker:2375"
    PY_COLORS: 1
  script:
    - cd roles/monitoring-tools/
    - molecule test
  only:
    changes:
      - roles/monitoring-tools/**/*
[…]

Our repository is hosted on gitlab.com and even if we can connect our own GitLab Runners to gitlab.com instance, we decided to use the provided gitlab.com’s shared runners to get started quickly.

Those use Docker to run the jobs. So we instantiate the official molecule image (from Red Hat’s registry):

image: quay.io/ansible/molecule:latest

And since molecule also needs to spawn Docker containers, we need to start another container: docker:dind (Docker in Docker). This is done with:

services:
  - docker:dind

And by exporting the DOCKER_HOST variable to the jobs, so that molecule will be able to connect to the Docker daemon to manage its containers:

variables:
  DOCKER_HOST: "tcp://docker:2375"

Then we define one stage, called tests:

stages:
  - tests

Each jobs related to this stage will have the stage: tests key in their definition.

The before_script block is here for debugging purpose (if the molecule tests succeed locally bt fail on the runners, it may be because the tests are run with a different version of molecule).

Last, we define as many jobs as we have roles to test with molecule. Here, tags is important since it is used by GitLab CI to select the runner the job will be executed on. We need a runner with Docker, thus:

tags:
  - docker

With script keyword we specify each command the runner should run. Pretty self-explanatory:

script:
  - cd roles/monitoring-tools/
  - molecule test

And only adds kind of a condition to the job. We don’t want to run all jobs if, for instance, someone updates the README file. The job should run only if a commit introduces a change to a file in the role itself. So we restrict the execution to a change under the role’s hierarchy only with:

only:
  changes:
    - roles/monitoring-tools/**/*

For instance, this pipeline, triggered by the commit afe5929c, has spawned only one job, the molecule-role-firewall test, since only the firewall role was modified. Whereas this commit (which impacted multiple roles) triggered 7 jobs (and yes, one has failed).

If a job fails, the commiter will receive a notification by e-mail with the commit and job ID. We can check the job’s output on GitLab, to see why it has failed.

As an ending note, to test your .gitlab-ci.yml without pushing, you can install the gitlab-runner package and run it on your repository (you still need to commit your changes since `gitlab-runner will checkout the repository):

$ gitlab-runner exec docker <your job name>

Containerize ZNC with systemd-nspawn

2019-04-20T00:00:00+00:00

On my previous server, I had an IRC client (weechat) running in a screen session. I recently migrated this setup to a ZNC bouncer running on my server + weechat running on my laptop, mainly to avoid network lags through SSH and to have a better desktop integration (notifications, etc.).

My server hosts my e-mails, important and confidential documents (among other things) and I always thought that running an always connected IRC client on the same machine was a bad idea.

So in the same time I got rid of my weechat+screen to migrate to ZNC, I had a look at systemd-nspawn, also known as systemd containers. It’s actually pretty much like LXC containers, but managed with the systemd logic in mind.

Here is a quick tutorial of how I containerized ZNC into a systemd container on a Debian stretch system:

First, install systemd-container and debootstrap packages:
```
# apt install systemd-container debootstrap
```
Create directories used by systemd-container (which aren’t create on install):
```
# mkdir /var/lib/machines/ /etc/systemd/nspawn/
```
/var/lib/machines/ will host the containers’ hierarchy and containers unit files will be stored into /etc/systemd/nspawn/.
Install a Debian system + znc package using debootstrap into /var/lib/machines/znc/:
```
# cd /var/lib/machines/
# debootstrap --include znc stretch znc
```
To make the container start on boot, you have to enable the corresponding systemd-nspawn instance and the machines target (which will start all enabled instances of systemd-nspawn unit:
```
# systemctl enable systemd-nspawn@znc machines.target
```
At this stage, your container is ready. You can start your container (run its init process) with:
```
# systemd-nspawn -D /var/lib/machines/znc/
```
Or execute a command in the container:
```
# systemd-nspawn -D /var/lib/machines/znc/ hostname
```
systemd-nspawn comes with the machinectl command which allows you to easily manage your containers:
```
# machinectl [list|list-images|start|stop|status|…]
```
See its man page for all supported sub-commands and options.
Now, let’s configure some few extra stuff to run ZNC. Create a dedicated user in the container:
```
# systemd-nspawn -D /var/lib/machines/znc/ useradd -u 1002 -g 1002 -m znc
```

And customize the container’s options by putting a config file into /etc/systemd/nspawn/:

[Exec]
# Don't start the init process inside the container, instead execute
# `znc`
Boot=off
Parameters=/usr/bin/znc --foreground

# Drop all default capabilities: the container will run with no
# capabilities, ZNC doesn't need any
DropCapability=CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_IPC_OWNER CAP_KILL CAP_LEASE CAP_LINUX_IMMUTABLE CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SETGID CAP_SETFCAP CAP_SETPCAP CAP_SETUID CAP_SYS_ADMIN CAP_SYS_CHROOT CAP_SYS_NICE CAP_SYS_PTRACE CAP_SYS_TTY_CONFIG CAP_SYS_RESOURCE CAP_SYS_BOOT CAP_AUDIT_WRITE CAP_AUDIT_CONTROL

# Start `znc` as znc
User=znc

# Those 2 options aren't supported by the version of systemd shiped
with Debian stretch. Ephemeral=on makes the container discard on
shutdown any modification made during its runtime (Docker style) and
NoNewPrivileges ensures that the code executed inside the container
won't be able to gain greater privileges (with setuid bit for instance)
#Ephemeral=on
#NoNewPrivileges=on

# Use private user namespace (equivalent to LXC's unprivilegied mode)
PrivateUsers=on
    
[Files] 
# Mount my .znc configuration directory onto the container (with write
access) and the znc.pem containing the private key, certificates chain
and DH param (read-only)
Bind=/home/romain/.znc/:/home/znc/.znc/
BindReadOnly=/var/lib/acme/live/irc.univers-libre.net/combined:/home/znc/.znc/znc.pem
    
[Network]
# Use the same network stack as the host
VirtualEthernet=no

This file will automatically be read by systemd-nspawn before starting the container. All these options can be specified as commandline parameters to systemd-nspawn as well.

Resources:

Ancien réseau de ski à Saint-Donat

2019-04-16T00:00:00+00:00

Bien qu’assez éloigné des autres pistes nordiques de la vallée de la Rivière du Nord, on peut retrouver aussi des vielles pistes abandonnées aussi loin que Saint-Donat. Le massif de montagne entre le lac Ouareau, Saint-Donat et l’Interval hébergeait visiblement beaucoup de pistes de ski. La plus connue et celle qui a le mieux survécue à l’épreuve du temps est la Kaaikop qui monte au Mont Kaaikop depuis la 329 en passant par l’auberge de l’Interval. Un petit réseau de pistes toujours entretenues existe aussi autour de cette auberge mais je ne le connais pas vraiment.

Mais plus au nord-est, j’avais découvert en y allant l’été plusieurs sentiers bien envahis mais assez larges pour être des pistes de ski (lui, lui et lui notamment. Sur certains, il restait même quelques panneaux avec le numéro de la piste, des « attention pente raide » et des « sens unique », preuve que ça devait même être un réseau damé et tracé. Certaines balises portaient le nom La Réserve, station de ski alpin des environs, c’est donc possible qu’à une époque ce centre avait un réseau de ski nordique qu’il a ensuite complètement abandonné au profil du ski alpin…

Aujourd’hui, seules quelques pistes sont encore entretenues officiellement par le club de plein air de Saint-Donat qu’on peut voir sur leur carte.

J’y suis retourné la semaine passée, après la dernière neige de la saison avec 2 autres collègues de ski, dans le but de rejoindre le Mont Kaaikop depuis Le Grand R via une des pistes abandonnées. Je la connaissais en partie pour l’avoir faite l’été, mais je l’avais perdue à un moment donnée. En début d’hiver, j’avais repéré une intersection sur un autre sentier où c’était très probable qu’elle arrive là, je voulais donc confirmer ça. Finalement on a manqué une intersection et pas pris le sentier que je voulais… mais on en a découvert un autre ! À peu près parallèle à celui que je voulais retrouvé. J’ai aussi remarqué le départ d’un autre sentier (encore un) qui partait plein est.

Bref il reste beaucoup à explorer dans ce secteur encore, j’ai rajouté plus de fixme que complété des sentiers dans OpenStreetMap…

Par contre j’ai pu mettre la main sur un vieux plan des piste de Saint-Donat datant de 1981, édité à l’époque par le club de ski de fond des Panaches (qui n’existe plus). Le secteur dont je parle ici est celui du Lac Bouillon. Mais on voit qu’il y avait des pistes pas mal partout autour de Saint-Donat.

Certains des pistes que j’ai trouvé apparaissent effectivement sur le plan, mais d’autres non, probablement plus récentes.

Mémo pour fartage de skis de classique

2019-04-12T00:00:00+00:00

À chaque début de saison, j’ai toujours du mal à me rappeler de certains petits détails et astuces pour préparer mes skis de fond de classique. Je mets donc ici mes notes en public, chacun a ses techniques et astuces mais ça m’a bien servi au début de lire les méthodes des autres skieurs.

Zone de glisse

Commencer toujours par la zone de glisse pour éviter de mettre de la poussière de cire sur le nouveau fart de retenu.

Brosser 2 ou 3 fois la zone de glisse à la brosse de laiton pour enlever la saleté et la vieille cire ;
Crayonner la cire du jour sur la zone de glisse. Pour les cires pour températures chaudes, très facile, pour les cires plus dures c’est bien de les poser quelques minutes avant sur un radiateur pour les ramollir un peu (sinon les réchauffer au fer). En mettre vraiment très peu, juste un passage suffit ;
Prendre une chaussette de laine autour d’un liège et polir énergiquement la base ;
Finir avec quelques passages à la brosse de nylon.

De temps en temps, et si la base est vraiment salle, il peut être bien de couler de la cire (n’importe laquelle) dessus et de gratter + brosser, soit la méthode classique (à l’ancienne).

Zone de retenue

Scraper l’ancien fart avec une raclette de métal s’il en reste. La lame de la raclette doit être en biseau et bien aiguisée pour éviter que le fart ne roule sur lui même. Toujours gratter des extrémités de la zone vers l’intérieur ;
S’il y a du klister, faire fondre un peu de cire dessus pour faciliter le retrait et éviter de s’en mettre de partout ;
Nettoyer éventuellement au fiberlene + défartant, surtout s’il y avait du fart plus chaud avant. Ne pas oublier les côtés du ski ;
Sabler la zone de retenue au papier de verre (80-100) dans le sens inverse de la glisse pour redresser les fibres. 2 passages suffisent ;
Crayonner une couche de binder (garder le binder au congélateur pour que ce soit plus facile à appliquer) ;
Étaler le binder au fer (~120 °C) pour améliorer sa prise. Nettoyer rapidement la rainure avant que le fart ne refroidisse s’il y en a dedans ;
Laisser refroidir quelques minutes et polir au liège ;
Appliquer le fart ou klister de jour. Prendre garde a bien nettoyer la rainure entre chaque nouvelle couche. Je mets toujours 5 couches, quelque soit la longueur de la sortie. Mieux vaut faire beaucoup de fines couches que quelques couches épaises.

On peut éventuellement se passer de remettre du fart de base si neige fraiche et pour une courte sortie.

Divers trucs

Attention, la neige artificielle est plus proche des micro-cristaux de glace que des vrais flocons, donc très abrasive. Du fart (un peu plus chaud que la normale) marche bien (pas besoin de klister), mais prévoir un bon fart de base, voir une couche intermédiaire de klister entre le binder et le fart de jour si longue sortie.

Si besoin de réajuster le fartage durant la sortie, quelques trucs pour faciliter la réapplication de fart et éviter de faire des gros motons :

Sécher le mieux possible la zone de retenue ;
Si il fait grand soleil, exposer la base du ski fasse au soleil et attendre un peu pour la réchauffer. Sinon la réchauffer en faisant quelques passages énergique de liège ;
Réappliquer le fart. Si il est trop chaud pour être crayonné, le presser légèrement sur la semelle et faire un petit twist du poignet.

Pour les conditions printanières :

cas de neige mouillée et chaude : klister seul ;
cas de neige glacée et froide : ajouter une couche ou 2 de fart (typiquement bleu ou bleu spécial) par dessus, le klister a tendance à geler sinon.

La cire pour ski est tout aussi efficace sur le plancher, si vous préparez vos skis à l’intérieur, mettre une bâche sous le banc de fartage pour récupérer la poussière de cire, au risque de transformer votre plancher en patinoire !

Yoghourt maison

2019-04-12T00:00:00+00:00

Des fois il y a des trucs tellement simple à faire qu’on peut se demander pourquoi le monde ne les font plus eux-mêmes. Les yoghourts par exemple.

Un couple qui m’avait hébergé en Colombie-Britannique faisait son propre yaourt et m’avait montré comment faire. Du coup maintenant j’ai pris l’habitude de faire le mien (et d’en remanger aussi, parce que ça faisait longtemps que je n’en achetais plus).

Les avantages que je vois à faire son propre yaourt :

moins de déchet, surtout s’il est possible de trouver du lait en bouteille consignée (même si au Canada c’est moins pire, on ne trouve pas des pots de yoghourt individuels, seulement des pots de 0,5 ou 1 L)
plus économique (1 L de lait est généralement moins cher que 1 L de yoghourt)
le plaisir de faire son propre yoghourt
permet de conserver du lait plus longtemps si votre bouteille est due pour bientôt

La marche à suivre est assez simple, en fait il n’y a quasiment rien à faire. Je peux résumer ça à :

vider une bouteille de lait dans une casserole et le faire bouillir
le laisser tiédir et mélanger avec le fond de votre yoghourt précédent
transvaser dans des pots et les conserver au chaud le plus longtemps possible, puis mettre au frigo

Mais ça mérite quand même quelques explications de plus :

Au départ il faut trouver des bactéries lactiques actives, soit en pharmacie soit en supermarché, sous forme de « Yogourt Starter ». D’après des tests, utiliser des yaourts existants du commerce ne marche pas, même des yaourt dit contenant des ferments actifs, un bon test pour valider (ou pas) ce qui est écrit sur les pots de yaourt…

Ensuite il faut du lait (entier tant qu’à faire, mais allégé marche aussi).

Commencez par faire bouillir le lait pour le stériliser (en le surveillant car ça monte vite, prévoyez une grande casserole) et laissez le refroidir tranquillement jusqu’à ce qu’il soit tiède (trempez un doigt dedans, ça doit être chaud mais pas brulant).

À ce moment là ajoutez les bactéries actives et mélangez bien puis transvaser dans des pots type Mason (ou n’importe quels pots de récup en fait).

Le but maintenant est de garder les pots tièdes (normalement autour de 40 °C mais on est pas à 5 °C près) pendant 4 ou 5h minimum, le temps que les bactéries travaillent. C’est à ce moment là qu’il faut faire preuve d’un peu de créativité. Personnellement je les mets chacun systématiquement dans un gros bas de laine pour mieux garder leur chaleur. Ensuite, l’hiver je les pose sur un radiateur puis je les recouvre d’une polaire. Sinon ils vont dans le four encore chaud, derrière une vitre au soleil, sous la couverture et je dors avec (oui oui !)… Vous pouvez aussi récupérer des petites résistances chauffantes et les mettre dans un vêtement, puis les pots dedans. Bref plein de possibilités.

Je les laisse comme ça une nuit puis je les mets au frigo ensuite pour stopper le processus (plus les bactéries travailleront, plus le yaourt sera ferme mais acide).

Sinon il y a bien sûr des… trucs qui s’appellent des yaourtières (qui devraient être efficaces), spécialement conçus pour encombrer vos placards de cuisine, puis vos (nos) poubelles quand, tôt ou tard, ils ne marcheront plus.

Le yaourt dans les pots se conservent un ou deux mois au frigo sans problème. Un fois un pot ouvert, je peux le conserver plusieurs semaines. Probablement plus en fait, mais ça m’ait jamais arrivé d’avoir un yoghourt qui a viré mauvais.

Miam !

Et enfin, pour refaire une autre batch, au lieu des bactéries sèches du départ, il suffit de prendre le fond du pot qui vous reste et le mélanger au nouveau lait tiédi (genre l’équivalent de 3 ou 4 cuillères à soupe, au pif). Au bout d’un moment, si le yoghourt a du mal à prendre, c’est que votre culture de bactéries s’épuise et il suffit de repartir avec de nouvelles.

Automatically generate a diagram of your infrastructure from Ansible inventory

2019-04-05T00:00:00+00:00

Another post about Ansible. This time I will talk about generating a representation of your infrastructure, for documentation purpose, using your Ansible inventory and gathered facts.

I had to update the infrastructure diagram of the Services FACiLes project, it was deprecated and, inevitably, will still be in a few months because we keep adding new containers and services. That’s a common issue in tech documentation.

Moreover, manually editing a graph isn’t a thing I usually like to do, especially when elements, relations and additional text can more easily be declared in a text file using a definition language. I found for instance this tool (not tested) which allows you to describe what you want to graph using a YAML file and then use graphviz to draw the resulting diagram. But, wait, I already have this kind of structured data, it’s in my Ansible inventory file.

I then thought about writing an equivalent tool to draw a diagram representing Ansible hosts and groups declared in the inventory and their facts and variables. Of course, someone else already had this idea, and this is called ansible-inventory-grapher. This python tool produces graphviz code that you can directly pipe to graphviz to generate a png or svg file.

As an example, here is how the graph of our infrastructure looks like:

ansible-inventory-grapher doesn’t show value of variables but you can use [this fork]((https://github.com/eking-go/ansible-inventory-grapher/tree/variables_with_value) merge request pending) to have them on your graph. You should also enable fact caching in your ansible.cfg and gather your server’s facts before running ansible-inventory-grapher. Else you will only have variables declared in host_vars/ and group_vars/.

The default jinja2 template used to generate the code suitable for graphviz prints all variables and facts, but I was only interested by some of them (those passed to the --visible-vars actually) so I slighty modified the template as follow:

--- doc/ansible-inventory-graph.default.j2
+++ doc/ansible-inventory-graph.j2
@@ -8,7 +8,7 @@
   <tr><td><b>
   <font face="Times New Roman, Bold" point-size="16">{{ node.name}}</font>
   </b></td></tr>
-{% if node.vars and showvars %}<hr/><tr><td><font face="Times New Roman, Bold" point-size="14">{% for var in node.vars|sort %}{{var}}{% if var in visible_vars %} = {{node.vars[var]}}{% endif %}<br/>{%endfor %}</font></td></tr>{% endif %}
+{% if node.vars and showvars %}<hr/><tr><td><font face="Times New Roman, Bold" point-size="14">{% for var in node.vars|sort %}{% if var in visible_vars %}{{var}} = {% if node.vars[var] is iterable and node.vars[var] is not string %}{{ node.vars[var]|map(attribute='name')|join(', ') }}{% else %}{{node.vars[var]}}{% endif %}<br/>{% endif %}{% else %}<br />{%endfor %}</font></td></tr>{% endif %}
 </table>
 >]
 {% else %}
@@ -17,7 +17,7 @@
   <tr><td><b>
   <font face="Times New Roman, Bold" point-size="16">{{ node.name}}</font>
   </b></td></tr>
-{% if node.vars and showvars %}<hr/><tr><td><font face="Times New Roman, Bold" point-size="14">{% for var in node.vars|sort %}{{var}}{% if var in visible_vars %} = {{node.vars[var]}}{% endif %}<br/>{%endfor %}</font></td></tr>{% endif %}
+{% if node.vars and showvars %}<hr/><tr><td><font face="Times New Roman, Bold" point-size="14">{% for var in node.vars|sort %}{% if var in visible_vars %}{{var}} = {% if node.vars[var] is iterable %}{{ node.vars[var]|map(attribute='name')|join(', ') }}{% else %}{{node.vars[var]}}{% endif %}<br/>{% endif %}{% else %}<br />{% endfor %}</font></td></tr>{% endif %}
 </table>
 >]
 {% endif %}{% endfor %}
@@ -26,3 +26,5 @@
   {{ edge.source|labelescape }} -> {{ edge.target|labelescape }};
 {% endfor %}
 }

Finally, I wrote a simple Makefile to easily update the graph when inventory is updated:

# Clear out default implicit rules and variables.
MAKEFLAGS += --no-builtin-rules --no-builtin-variables

.PHONY: inventory-graph

inventory-graph: doc/ansible-inventory-graph.png

doc/ansible-inventory-graph.png: inventory/hosts $(wildcard inventory/group_vars/*.yml) $(wildcard inventory/host_vars/*.yml)
	ansible -i inventory/ -m setup all >/dev/null
	~/src/ansible-inventory-grapher/bin/ansible-inventory-grapher -i inventory/ -t doc/ansible-inventory-graph.j2 -a "rankdir=LR;" \
	--visible-vars knot_zones \
	--visible-vars backup_server \
	--visible-vars munin_master \
	--visible-vars icinga2_master \
	--visible-vars icinga2_parent \
	--visible-vars backup_hosts \
	--visible-vars icinga2_monitored_sites \
	--visible-vars db_type \
	--visible-vars hosted_by \
	--visible-vars libvirt_domains \
	--visible-vars lxc_containers \
	--visible-vars ansible_architecture \
	--visible-vars ansible_default_ipv4.address \
	--visible-vars ansible_default_ipv6.address \
	--visible-vars ansible_distribution \
	--visible-vars ansible_distribution_version \
	--visible-vars ansible_memtotal_mb \
	--visible-vars ansible_processor_vcpus \
	--visible-vars ansible_virtualization_role \
	--visible-vars ansible_virtualization_type \
	all | dot -T png >$@

That way, when we add a new machine or make any change in our infra, all we need to do is make inventory-graph and commit the resulting graph. The image file is linked in our documentation in our private wiki, thus we are ensured that it is always up to date!

Ansible QA and testing with molecule

2019-03-31T00:00:00+00:00

Winter is already over in the Laurentians, and for a few weeks now ski conditions are so horribles that it’s not fun anymore and I’m sick of applying and cleaning klister on my skis. We will soon have rain and mud and flooding everywhere. April is definitely the worst month in Quebec despite sunny and longer days. But the good thing is that I suddenly have a huge amount of time left for other things. Like system administration and coding.

Thus I picked up a task from my todo list that I always wanted to do: trying molecule over our Ansible roles and playbook at FACiL. The infrastructure running behind the Services FACiLes project is setup and maintained 100% with Ansible. All our roles and playbooks are public and hosted on Gitlab.

molecule is a Python tool developed by the same team as Ansible and aims running different kind of tests over your ansible roles: linting, role execution on multiple targets and scenarios, ensure idempotence over multiple executions and running unit tests on the target.

I am not going to write a full tutorial on molecule, a lot of them already exist on Internet, though not always up to date since molecule is still a young project and in heavy development. The official documentation is a bit rough to get started and to understand the scope of molecule. A good tutorial I found for being the most up to date and accurate.

Instead, in this post I’m going to explain how I use it to test our roles, with some tips I didn’t find in the official documentation. I also played with Gitlab CI so molecule tests are run on each git push, but it will be for another post.

molecule’s files

We start by creating a molecule directory in our role:

$ molecule init scenario --verifier-name goss --driver-name docker --role-name <role>

It will create a directory named molecule/ in your role’s directory. You can have multiple scenarios for your role, stored under molecule/ directory. By default, molecule init will create the scenario default:

$ tree molecule/
molecule/
└── default
    ├── Dockerfile.j2
    ├── INSTALL.rst
    ├── molecule.yml
    ├── playbook.yml
    ├── tests
    │   └── test_default.yml
    └── verify.yml

Each file above are just here to help you to get started and can be edited as you want. Options we passed to the molecule init command are just here to alter these files. I usually prefer copying the molecule/ directory from an existing role (which is totally acceptable) since I have done some extra customization on it.

molecule.yml

molecule.yml is the only molecule configuration file. Here is the molecule.yml we use in our roles :

---
dependency:
  name: galaxy
driver:
  name: docker
lint:
  name: yamllint
platforms:
  - name: molecule-monitoring-tools
    image: geerlingguy/docker-debian9-ansible:latest
    command: ${MOLECULE_DOCKER_COMMAND:-""}
    volumes:
      - /sys/fs/cgroup:/sys/fs/cgroup:ro
    privileged: true
    pre_build_image: true
provisioner:
  name: ansible
  lint:
    name: ansible-lint
  options:
    skip-tags: molecule-converge-notest
  log: true
scenario:
  name: default

molecule is designed to be very extensible. For instance, it uses the galaxy dependency resolver (dependencies are defined in the meta/main.yml file of your role) and ansible as a provisioner (this is the only one supported for now but we can imagine molecule will be able to use other configuration management tools).

We use yamllint as the linter for all YAML file of the role (including molecule’s own files!) and ansible-lint for ansible files.

For some reasons, we don’t want to run some Ansible tasks when testing the role. molecule let us pass any ansible-playbook option with the dict provisioner:options. Here we excluded tasks which have the molecule-converge-notest tag on them.

And finally we tell molecule to run the role in a Docker container. molecule supports a large range of drivers, including LXC containers, Vagrant VMs and common public cloud providers. Even if we use LXC containers on production, I choose to use the Docker driver with molecule because, first it’s more easy to setup on a personal machine, and second because this is the only supported option if we want to run molecule tests on Gitlab’s shared runners (using Docker in Docker), I will talk about it later in a second post.

Most of our roles don’t work inside a minimal Docker container, so we use geerlingguy/docker-debian9-ansible Docker image. The image provides a more complete Debian system (with systemd and common tools). It is maintained by Jeff Geerling, who wrote a lot of Ansible roles and uses it to test his own roles.

By default, molecule spawns a container named instance. It’s a bad idea since I ended up with conflicts when I tried to launch tests on multiple roles at the same time, each of them was executed in the same container. Thus I edited platforms:name key so that it bears the role’s name.

Dockerfile.j2

This file is only here if you want to build your Docker container on each test. You can use any Docker image (defined in platforms:image) and this Dockerfile will install requirements such as python, sudo, bash and ca-certificates package to run Ansible.

Since the image we use already contains those dependencies, we instruct molecule not to build another Docker image (platforms:pre_build_image). this way, we also speed up tests.

INSTALL.rst

INSTALL.rst is an informal file containing instructions to others contributors and requirements to run molecule tests. For instance, we need to have the Docker engine and docker-py installed on our machine.

playbook.yml

After molecule.yml, this is the second most important file. Once molecule has spawned the container, it will run this playbook.

Here is its content:

---
- name: Converge
  hosts: all
  roles:
    - role: <role>

Pretty simple, it applies <role> onto the spun up container. But if your role requires some variables to be set, or dependencies that aren’t declared in your role’s meta/main.yml file, you can add them here. For instance:

---
- name: Converge
  hosts: all
  roles:
    - role: <other role>
    - role: <role>
  vars:
    foo: "bar"

verify.yml and tests/test_default.yml

Finally, those two files are for unit tests. verify.yml installs Goss (the verifier tool) in the container and run tests it finds in the tests/ directory. Although it’s a very interesting subject, I didn’t dig too much into unit tests for now.

Running molecule

First, to enable bash completion:

$ eval "$(_MOLECULE_COMPLETE=source molecule)"

Running molecule without argument will show you the list of available sub-commands. I’m not going to explain all of them, and I don’t even sure what all these sub-commands do, I still learning about molecule.

Run linting tools on your role:

$ molecule lint

Test your role into a freshly created container (by executing playbook.yml on it):

$ molecule converge

molecule converge will automatically lint your code prior to run it.

At this time you can either login to the container to manually check what has been done:

$ molecule login

Or replay molecule converge if you obtained errors and have fixed them in your role.

molecule converge allows us to pass almost any ansible-playbook option. For instance, you may want to debug tasks with a specific tag:

$ molecule converge -- -vvv --tags <tag>

To destroy the running container so you can start with a new one:

$ molecule destroy

If you just want to start a container but don’t execute anything in it (for instance if you want to known the state of a file in a brand new install):

$ molecule prepare

To run idempotence check (molecule will simply run the playbook.yml a second time and check that no tasks report a changed state):

$ molecule idempotence

All these previous commands are useful while you are developing a role. Once you have done or did only minors edits (you are pretty confident that you didn’t break anything), it’s handy to run all the test suite at once:

$ molecule test

It will lint your code, start a new container, apply playbook.yml, verify idempotence, run unit tests and finally destroy the container.

[Ansible] sudo password from your password manager or agent

2019-03-29T00:00:00+00:00

Make Ansible retrieve the sudo password from my password manager. For a long time, I was wondering how to solve this issue. Ansible is my main tool to manage my own servers. All the infrastructure of the Services FACiLes project I contribute to (a future CHATONS is built with Ansible automation in mind, and even at my previous work, Ansible is used on a daily basis.

A thing that really annoyed me was that each time I run a playbook, I have to give Ansible my sudo password. Besides that, Ansible prompts for the password at an early stage of execution, even before trying to include all files or running a syntax check on them. Thus it isn’t uncommon that Ansible fails immediately after because of a mistake I made in a playbook, and I have fix it, rerun the command, reenter my password… and so on. Which is very frustrated.

I know some workarounds exist to avoid dealing with the interactive sudo password prompt: allowing Ansible to be executed without password on the servers (almost equivalent to allowing any command to be executed without password…, which is not an acceptable answer), storing your password into ansible_sudo_pass variable in a cleartext file somewhere (yes you can encrypt it with ansible-vault but then you have to give the vault password each time you run your playbook), trying to mess with except…

The simple and elegant way of doing it for me would be that Ansible gets the password from an agent, like gpg-agent, or execute an arbitrary command to get it. After a lot of research and experimentation, I found a pretty nice and clever solution on Stackoverflow (far at the bottom, it should be upvoted more than that IMHO). The idea is to combine --extra-var ansible option (to which a file descriptor can be passed, while prefixing it with @) and <() bash operator to convert a command’s stdout to a file virtual file descriptor. We end up with the following command:

$ ansible-playbook -e@<(echo "ansible_sudo_pass: $(pass Sysadmin/xxxx)") playbook.yml

This way my sudo password is retrieved from my pass’s password manager (which uses gpg-agent) and I’m not bothered anymore with Ansible’s interactive prompt \o/.

The only drawback is that I didn’t find a way to set this into the ansible.cfg or somewhere else, except writing a bash alias or a small wrapper.

Les pistes de Saint-Hippolyte

2019-03-14T00:00:00+00:00

Qui aurait penser qu’il y avait des anciennes pistes de ski nordique vers Saint-Hippolyte ? C’est un coin semble-t-il assez peu connu à part par les locaux qui fréquentent ces pistes là. En effet aucune ressource sur Internet n’en parle et aucune carte de ce secteur qu’on peut se procurer (à ma connaissance). Mais il y avait bel et bien un dense réseau tout autour de Prévost (Shawbridge), puisque c’est là où habitait Herman S. Johannsen. Le secteur de Prévost, Piedmont et Saint-Hippolyte est protégé par la Réserve Naturelle du Parc des Falaises contre (notamment) le développement immobilier, ce qui est une très bonne chose. Mais c’est aussi un secteur littéralement envahi par les raquetteurs, ce qui ne donne jamais trop envie d’aller l’explorer à ski. Pourtant au delà d’une certaine distance des points d’accès, les sentiers deviennent moins tapés par les raquettes et on peut retrouver de la belle neige.

Je m’y suis rendu pour la première fois avec des membres du CMC qui connaissaient un peu le coin, puis à quelques jours près, Barclay s’y était aussi aventuré (en deux fois). J’y suis donc retourné seul avec pour mission de cartographier le plus de pistes possible.

J’ai ainsi pu ajouter un bon bout de la Fd (Flight Delight), la plupart de la 6X, qui continuait même plus au nord en contournant le lac Desjardins, la partie centrale de la Johannsen (que j’aimerai vraiment pouvoir relier au complet, j’ai en tête de partir de Mont-Rolland et d’aller jusqu’à Prévost en la suivant), et enrichie un peu la WN, Wizzard, la 8 et quelques autres.

Cela n’a pas été une tâche facile, surtout dans le secteur de Prévost, non pas que les pistes ne sont plus visibles, mais au contraire, certaines pistes ont été reroutées, donc on peut tomber sur les anciens tracés avec quelques vieilles balises rouillées qui ont bravées l’épreuve du temps, les nouveaux sentiers qui reprennent les mêmes noms mais qui ne correspondent plus du tout au tracé original et les sentiers informels créés par les randonneurs eux-mêmes, sans compter que plusieurs pistes fusionnent ensemble sur une certaine distance avant de se reséparer. Bref, quoi cartographier dans OpenStreetMap n’a pas été chose facile et je ne suis pas certain que chaque sentier y est correctement nommé, mais c’est déjà beaucoup mieux qu’avant.

J’ai aussi suivi la MOC (McGill Outing Club) aussi loin que possible avant d’arriver dans un terrain privé. Elle n’a pas beaucoup d’intérêt (peu de défis et pas très jolie, elle à l’air d’un vieux chemin de coupe) et est pas mal envahie aussi, mais elle sert d’artère centrale aux autres pistes du secteur. Et j’ai trouvé une piste mystère (elle aussi pas mal envahie) qui remonte de la MOC vers le Mont Olympia, juste balisée avec des disques de plastiques jaune.

C’est dans le secteur de Saint-Hippolyte que j’ai trouvé une précieuse aide dans ma tâche : 2 cartes différentes, présentes à 2 intersections :

La première n’est pas très intéressante car elle ne montre que quelques sentiers, l’autre est déjà plus complète et m’a bien servie pour m’aider à y voir plus clair dans ce réseau, même si elle n’est pas tout à fait complète non plus. Ces 2 cartes ne semblent pas être trouvable sur Internet, donc à conserver précieusement !

J’en profite aussi pour laisser un lien vers une carte éditée par Plein-Air-Saint-Hippolyte, organisme qui ne semble plus exister depuis une dizaine d’année, qui montre encore d’autres sentiers de ski, cette fois au nord de Saint-Hippolyte (merci Archive.org !). Je ne suis pas du tout allé explorer ce coin là par contre.

Un autre article de Barclay tout récent à propos de ce secteur, après qu’il a vu les nouveaux sentiers cartographiés dans OpenStreetMap (j’ai l’impression qu’on joue au chat et à la souris à chaque fois !).

Le nord de la Western

2019-03-13T00:00:00+00:00

La Western est une autre ancienne piste de ski dans les Laurentides qui, comme son nom de laisse penser, se trouve dans la partie ouest de la région, à l’ouest de la vallée de la rivière du Nord et l’ancienne voie du CP Railway. La partie probablement la plus connue se trouve dans le réseau de Morin-Heights et apparait sur la carte de leur réseau pour une dizaine de kilomètres, partant des pistes de fond tracées jusqu’au lac Théodore au Nord. C’est la seule partie présente sur une carte. Mais la Western va en fait bien au delà !

Au sud, je l’ai trouvée aussi bas qu’à Sainte-Anne-des-Lacs, au niveau de la Loken, où j’ai été surpris d’y trouver une vieille balise de la Western. Je suppose qu’elle monte plein nord vers Morin-Heights, mais au vu du développement résidentiel de Saint-Sauveur qui se trouve entre les 2, je doute malheureusement qu’il en reste grand chose et, si c’est encore possible de passer, ça risque d’être beaucoup sur la route. Je ne suis pas allé explorer ce secteur.

Section du lac Théodore à la Fleur-de-Lys

Par contre beaucoup plus au nord, je l’avais encore croisée l’année passée en remontant la Fleur-de-Lys de Sainte-Adèle à Sainte-Agathe-des-Monts, peu avant que la Fleur-de-Lys connecte la Canadienne. Dernièrement je suis donc retourné à cette intersection pour suivre la Western le plus loin possible. D’abord vers le sud, jusqu’au lac Théodore. À l’endroit de l’intersection avec la Fleur-de-Lys, la Western qui part vers le sud n’est pas forcement évidente à retrouver, il faut en fait suivre un chemin privé vers le sud sur une cinquantaine de mètres. Ensuite de ça le tracé est très bien visible et balisé jusqu’au Lac Théodore, aucune difficulté particulière à le suivre. Il y a peu de dénivelé mais j’ai trouvé le sentier très joli, notamment le long du lac Normand, à travers une belle forêt de cèdre.

Balises de la Western

On arrive au Lac Théodore en marchant/skiant un bout sur l’avenue des Pivouanes, qui débouche sur une mini-baie privée sur le lac. Pour rejoindre la Western du réseau de Morin-Heights, il suffit de mettre cap plein sud sur lac pour retomber dessus sur l’autre rive.

Après avoir reviré de bord une fois rendu au lac Théodore, j’ai tenté d’explorer la section au nord de l’intersection à la Fleur-de-Lys. La piste était un peu plus envahie par les branches et moins évidente à suivre. J’ai pu la skier jusqu’à un lac sans nom au nord de la Colline Beauvais. Mais j’ai perdu son tracé après. J’ai appris par contre jusqu’où elle va : elle doit traverser le lac Paquin, traverser le chemin du 7ème Rang et arriver tout au bout du Chemin des Pins à Sainte-Agathe.

On peut deviner un « Direction Sainte-Agathe »

Section de la Fleur-de-Lys à Sainte-Agathe

Bon, je n’ai pas eu le temps de publier cet article que je suis déjà retourné sur les traces de la Western ! Je rajoute ici ce qui devait être un second article.

Comme j’ai su que la Western pouvait se prendre tout au bout du Chemin des Pins à Sainte-Agathe, je me suis rendu là lundi dernier. Le Chemin des Pins se termine dans un camp de vacances, complètement abandonné pour la saison hivernale. Après avoir tourné un peu rond dans le camp, j’ai fini par trouver la piste ; elle file assez proche de la route avant de partir plein est. Son extrémité nord se trouve en fait 500 m plus loin puisqu’elle joint directement la Fournelle, piste tracée du centre de ski de fond du Camping Sainte-Agathe.

Après ça, la piste contourne la Colline aux Framboises par le sud puis file vers le sud-est en coupant les 8ème et 7ème rangs, jusqu’à arriver au lac Paquin. Un peu avant de croiser le 8ème rang, on se retrouve face à une descente toute droite assez impressionnante, digne d’une pente de ski alpin (je n’en ai jamais vu des aussi raides et longues ailleurs) ! Heureusement elle n’est pas trop étroite et comme j’ouvrais dans 40 cm de neige lourde, j’ai pu faire quelques beaux virages de telemark assez facilement (en fait un des rares moments durant cette journée où j’ai pu profiter de la glisse). Avec des conditions de neiges plus difficile par contre, je ne pense pas être capable de la descendre…

La photo ne rend pas du tout de la pente.

On arrive au chemin du 7ème rang par la Rue du Continental, puis il faut marcher 50 m sur le rang vers l’est avant de pouvoir embarquer sur le lac (avant de traverser la décharge du lac). Sur le lac, je n’avais pas la moindre idée d’où aller, donc j’ai longé la rive est qui offre de belle falaises et cascades de glace. Mais il faut en réalité mettre le cap plutôt vers le sud-sud-ouest pour retomber sur le chemin Gascon Est. En réalité on peut tout aussi bien marcher/skier sur le chemin du 7ème rang pour arriver sur le chemin Gascon Est, ce sera certainement plus rapide si il n’y a aucune trace sur le lac et que les chemins ne sont pas totalement déneigés pour permettre de ski dessus.

La piste reprend depuis le chemin (facile à trouver, il y a une balise) et continu plein sud en passant à l’ouest d’une petite colline, jusqu’aux lignes électrique qu’il faut traverser. La piste traverse de bout-en-bout un lac sans nom, celui-là où je m’étais rendu la fois précédente. Après ça, la Western continue sud-ouest jusqu’à la Fleur-de-Lys.

Globalement, cette section de la Western reste assez bien balisée même si, sans connaitre son tracé approximatif, elle reste difficile à suivre à certains endroits où le balisage est un peu plus aléatoire (érablières clairsemées, traversées de lacs et intersections avec des chemins et rangs).

J’ai continué jusqu’à Sainte-Adèle en suivant la Fleur-de-Lys jusqu’au bout, très belle piste que j’aime beaucoup aussi, mais celle là je l’avais déjà cartographiée l’année passée.

Ancienne balise de la Fleur-de-Lys.

La Western est maintenant complète pour sa portion au nord de Morin-Heights dans OpenStreetMap.

Automatically backup your Android phone with udev

2019-03-01T00:00:00+00:00

I wrote a simple script and udev rule a few years ago to automatically backup my phone (running Replicant OS, a free, FSF-approved Android distribution) to my computer when I plug it to a USB port. I just published those scripts after some clean-up on a git repository and wrote instructions on how to set it up.

I know there are plenty of Android applications to backup my data and upload them somewhere via Internet. But my phone is rarely connected, the Wi-Fi is usually turned off and I have no data plan. Instead I do plug my phone to my computer on a regular basis to recharge it, so it seemed obvious to automatically trigger a backup of my phone via USB.

udev can be use to detect events, like plugging-in a device, and trigger actions based on these events. In my case, the udev rule looks like this:

ACTION=="add", SUBSYSTEMS=="usb", ENV{ID_SERIAL_SHORT}=="XXXXXXXXXXXXXXXX", TAG+="systemd", ENV{SYSTEMD_USER_WANTS}+="android-backup@$env{ID_SERIAL_SHORT}.service"

Where ID_SERIAL_SHORT is used to uniquely identify my phone. The rule triggers the android-backup@.service systemd unit (in user mode, no need to run it as root).

The systemd unit is very simple, there is no need to specify an [Install] section, targets or anything like that since it is triggered directly by udev:

[Service]
Type=oneshot
ExecStart=%h/.local/bin/android-backup.sh %I

So the unit simply calls the following shell script:

#!/bin/sh

export DISPLAY=0:0
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
BACKUP_DIR=~/replicant-backup/
RSYNC_EXCLUDE=~/.config/android-backup.exclude

notify-send "Android Backup" "Starting Android backup"

(
set -e

mkdir -p "$BACKUP_DIR"
adb wait-for-device 2>&1 |(grep -Ev "^(\* daemon not running; starting now at|* daemon started successfully$)" || true)
adb root
adb wait-for-device
adb shell rsync --daemon --no-detach --config=/system/etc/rsyncd.conf &
adb forward tcp:6010 tcp:873
sleep 2
rsync -av --chmod u+rwX --delete --delete-excluded --exclude-from "$RSYNC_EXCLUDE" rsync://localhost:6010/root/ $BACKUP_DIR
adb forward --remove tcp:6010
adb shell pkill rsync
)

if [ $? -ne 0 ]; then
    notify-send "Android Backup" "Backup terminated with errors. See journalctl --user -eu android-backup for details"
else
    notify-send "Android Backup" "Backup terminated successfully"

In this script, I first start adb (as root so it can have access to the whole system) and start a rsync daemon on the OS running on the phone and forward its TCP port through adb. I can then start a normal rsync from my computer to fetch all the files and directories. The destination directory (on my computer) is included in my daily backup, thus I automatically have incremental copies of my phone’s data.

Marathon Canadien de Ski

2019-02-12T00:00:00+00:00

Le Marathon Canadien de Ski (MCS) est la plus longue épreuve de ski de fond en Amérique du Nord, 160 km (163,7 km exactement), qui se répartissent en 2 jours soit à peu près 80 km par jour. C’est aussi la plus ancienne épreuve en Amérique, il a été tenu pour la première fois en 1967, lors des 100 ans du Canada. Il s’agit plus d’un évènement populaire que d’une compétition, les skieurs ne sont pas chronométrés et sont là plus pour le plaisir de skier et le défi personnel que la performance. L’évènement attire en moyenne 2000 personnes, venant principalement du Québec, de l’Ontario et du nord-est des États-Unis.

La piste reliait à l’origine les villes de Gatineau et La Chute en longeant plus ou moins la rivière des Outaouais. Montebello était le point central et l’étape intermédiaire. À cause de l’enneigement de plus en plus incertain ces dernières années, il part maintenant d’un peu au sud de Saint-Jovitte (Mont-Tremblant) pour se rendre à La Chute, en faisant un crochet par Montebello, qui reste l’étape intermédiaire. La piste est tracée une seule fois par année pour l’évènement et passe en majorité sur des terres privées.

Pourquoi j’en parle ici ? Ça me titillait depuis que j’en ai entendu parlé en arrivant au Québec, mais cette année je m’y suis inscrit et suis très fier d’avoir skier l’intégralité des 160 km en 2 jours ! Je fais un petit retour sur mon expérience.

Il y plusieurs catégories lors de l’inscription, on peut soit faire le demi-marathon, le marathon entier (Coureur des Bois) ou les sections que l’on veux (Randonneur) (le parcours est divisés en 10 sections de 16 km chacune en moyenne). Jusqu’au dernier moment avant mon inscription, j’ai beaucoup hésité dans quelle catégorie m’inscrire. J’étais plus partant pour faire le marathon entier au début, puis à un moment j’ai douté beaucoup, je n’arrivais pas à m’entrainer autant que je voulais (on a eu un décembre sans neige) et j’ai fini par m’inscrire dans la catégorie Randonneur. Comme ça je me suis dit que si je ne skiais pas les 10 étapes, je ne perdais pas le défi. Le prix a joué aussi, car les frais de participation sont assez cher : 300 $ pour les Coureurs des Bois contre 200 $ pour les Randonneurs. Puisque les Randonneurs peuvent quand même skier l’intégralité du marathon, les 100 $ ne se retrouvent que dans la médaille à la fin, ça ne justifiait pas la différence pour moi. Surtout qu’à cela, il fallait ajouter les frais d’hébergement pour vendredi et samedi (150 $ pour dormir par terre dans les salles de classe de l’école de Papineauville et manger à la cantine de l’école) + plus la navette depuis Montréal (100 $), plus toutes les taxes… Bref ça faisait un sacré budget et faisait cher le kilomètre skié. Mais je dois admettre que c’était toute une organisation sur place vu le nombre de participant et c’était assez bien rodé.

La veille du marathon, j’avais encore changé d’avis et je voulais à tout pris skier les 80 km par jour. Sauf qu’une chose que j’ai appris au dernier moment est que les Randonneurs qui veulent skier les 10 sections sont clairement pénalisés par rapport aux Coureurs des Bois : les Coureurs des Bois partent à 5h, le départ des Randonneurs est à 7h30 et il y a un cutoff à 15h30 pour tout le monde au départ de la dernière section de la journée. Ça laisse beaucoup moins de temps aux Randonneurs ! Donc au final, je me retrouve avec un défi supplémentaire, skier les 4 premières sections de chaque jour plus vite que les Coureurs des Bois pour arriver avant le cutoff de 15h30.

Dans ma tête, c’était donc un défi de 66 km à skier en 8h, pauses comprises, puis les 15 km de la dernière section du jour que je pouvais skier à la vitesse d’un piéton si je serai à bout, ça n’aura plus d’importance. J’ai calculé précisément mes heures de passages aux différents checkpoints. Je devais skier à une vitesse minimum de 9 km/h et pouvais m’arrêter maximum 15 minutes à chaque checkpoint pour refaire le plein d’eau, manger et refarter mes skis si besoin. La veille, j’ai appris par cœur mes heures de passage et j’ai mémorisé le plus de détails possible des cartes des sections (traverses de routes, de lacs, grandes côtes, passages dans les champs) de façon à me donner des points de repères une fois sur la piste pour situer mon avancement ; 80 km c’est long et il est facile de se « perdre » dans les chiffres et d’avoir l’impression de ne pas avancer si dès le départ au matin l’objectif est le 80 ème kilomètre. Voir que j’arrive effectivement à telle place alors que j’en suis qu’au 38 km est très motivant et rassurant à la fois. Et je me prépare ensuite à atteindre le prochain repère, peut-être juste 10 km plus loin. En fait, je me fous complètement du tout dernier kilomètre.

De manière générale, je suis (assez involontairement mais maintenant que j’en ai conscience ça devient moins involontaire) pessimiste concernant mes objectifs, ce qui fait que je les surpasse bien au delà et ça devient une source de motivation plus grande. Dans ce cas si concrètement, mes heures de passage étaient vraiment le minimum, le cas vraiment limite (je skie plus vite que 9 km/h), donc à chaque fois j’arrivais toujours avec 5 ou 10 minutes d’avance sur ce que j’avais en tête. Là encore, ça me rassurait et me motivait pour la section suivante, où je me mettais au défi de maintenir mon avance ou faire encore mieux.

Le premier jour, je suis arrivé à 1h05 avant le cutoff, 1h05 d’avance sur ce que j’avais prévu, et 40 minutes d’avance pour le deuxième jour. J’ai fini la première journée à 16h30 et 16h37 le lendemain, en skiant à peu près 8h à 10,5 km/h de moyenne plus 1h de pause au total. Je skie habituellement entre 10 et 11 km/h et avant le marathon, je doutais être capable de maintenir ma vitesse habituelle sur une aussi grande distance. Mais en faisant des stats par section, je ne constate aucune baisse de vitesse en fin d’épreuve (sauf la dernière section du premier jour où je me ralentissais volontairement pour ne pas me bruler inutilement pour le lendemain). Même, je me sentais bizarrement encore plein d’énergie, en tout cas d’un point de vue mental et cardiaque, mes muscles eux commençaient à fatiguer sérieusement.

Autant j’ai skié plus vite que prévu, autant la durée des pauses passait très rapidement. Le fait est que contrairement à la course à pied, c’est bien moins facile de boire et manger en skiant, avec les bâtons, gants et dragonnes ergonomiques, alors que mon eau est coincée quelque part contre mon ventre pour éviter le gel au lieu d’une simple poche d’eau avec un tuyau comme en trail. Donc je me ravitaillais essentiellement aux checkpoints qui étaient d’ailleurs pas mal bien fourni (eau chaude miellée, soupe, chili, bananes, barres de céréales…).

L’autre chose étaient les conditions de ski assez difficiles : il y a eu plusieurs épisodes de pluie puis du regel la semaine précédent l’évènement et la neige était très transformée. Les 2 jours on a eu un grand beau soleil, bien agréable mais n’améliorant pas les conditions, la température oscillait entre -15 à -3 °C suivant l’avancement de la journée. Bref, des conditions très printanières, la glisse était rapide mais le fartage n’était pas évidant. Malgré une base de liant que j’avais appliqué à chaque fois la veille, le fart de jour ne durait pas longtemps avec les conditions abrasive et je refartais tous les 15 à 20 km en moyenne, et dépendamment de l’évolution de la température (après coup, à des moments j’aurai vraiment du m’arrêter et prendre 5 minutes pour ajuster le fartage au lieu de me fatiguer à skier sans plus aucun kick et me disant que sa attendra le prochain checkpoint). Par contre une chose de vraiment bien, des exposants étaient là à chaque checkpoints pour farter les skis ; j’arrivais, je leur laissais mes skis, je mangeais et buvais un bout puis dès qu’ils avait fini avec mes skis je repartais. Ça me faisait gagner pas mal de temps.

Par rapport à la course à pied, c’est bien plus facile, je ne me verrai pas du tout courir pendant 8h par exemple. Déjà il n’y a pas toute la fatigue du aux chocs à chaque impact, c’est que de la glisse, je peux me reposer en descente (si elles sont pas trop raides) et je peux changer de technique pour reposer plus le haut ou le bas du corps quand l’un ou l’autre fatigue. Je faisais même du pas de patin sur les pistes de motoneige pour varier un peu, preuve que ce n’était pas le cardio mais plus les muscles qui fatiguaient.

Au niveau des paysages traversés, c’était très varié, certaines sections étaient très belles, d’autres moins. On a traversé des pinèdes, des érablières et des forêts de cèdres, des terrains de golf, des champs, passé au travers de fermes, skié le long de routes et dans des vallées, traversé des lacs et des rivières, on a skié dans un tunnel sous l’autoroute… Par moment on était sur des sentiers étroits dans le bois, d’autres fois sur des larges pistes de motoneige.

Finalement je ne regrette pas de m’être inscrit en tant que Randonneur, ça a été un défi supplémentaire par rapport au temps, j’ai pu dormir plus longtemps que les Coureurs des Bois qui se levaient à 3h pour partir à la nuit, et aussi, comme peu de Randonneurs faisaient la première section de la journée, on était qu’un petit groupe de 20/30 personnes à partir au lieu des centaines de Coureurs des Bois qui, eux, partaient tous en même temps et créaient des gros bouchons (de ce qu’on m’a raconté).

D’ailleurs dans la catégorie Coureurs des Bois, il y a une catégorie spéciale pour ceux qui dorment dehors. C’est en fait le défi ultime, skier avec tout son matériel de camping d’hiver et dormir au camp aménagé (avec feu de camp et balles de foin) le samedi soir. Moi personnellement, je ne regrette pas du tout de trouver une douche et un endroit chaud et sec après 80 km de ski. Je m’étais dis à un moment que j’essayerai le camping d’hiver au Québec, mais finalement… ça me tente plus trop !

Bref, le Marathon Canadien de Ski aura été pour moi une superbe expérience, j’en garde plein de bon souvenir et je suis pas mal plus confiant et fier de mes capacités en ski de fond. Presque je m’en veux un peu d’avoir douté de mes capacités au moment de l’inscription !

List changed configuration files and restore the maintainer's version

2019-01-24T00:00:00+00:00

Recently I had to clean one of my server (a virtual machine hosted by Tetaneutral) to make it as close to a fresh install as possible, but without reinstalling it or migrate it somewhere else. It is an old server and it has been installed by hand. Since I now use Ansible to manage my other servers, I wanted to include it to the inventory and apply the same configuration on it.

On Archlinux, I used to use this command which list me all configuration files (in /etc) which have diverged from the version shipped by the package:

$ pacman -Qii | awk '/^MODIFIED/ {print $2}'

I didn’t find a simple equivalent way to do it in Debian with dpkg tools, however I found debsums, an extra package that does the job pretty well:

$ debsums -se

I then can restore the package’s version by reinstalling the corresponding package with --force-confask option:

# apt install --reinstall -o Dpkg::Options::="--force-confask"

Here is an oneliner to automate the process (careful, it doesn’t ask for any confirmation!):

# debsums -se 2>&1 |awk '{print $4}' |xargs -n 1 dpkg -S |awk -F: '{print $1}' |sort -u |xargs apt install --reinstall -o Dpkg::Options::="--force-confask" -o Dpkg::Options::="--force-confnew"

Since xargs doesn’t work well with interactive commands, I force the choice by passing both --force-confask and --force-confnew options.

As a conclusion, keep in mind the configuration files added in *.d/ directories won’t be listed nor removed, so you still have to clean these directories manually.

Safe paste in terminal

2018-12-22T00:00:00+00:00

In my daily life of sysadmin, I copy-paste many chunk of text (commands, IP addresses, URLs, file paths, whole scripts or file contents sometimes because it’s easier to copy-paste them rather than to scp them). I usually copy them from other servers or from my company’s internal documentation (trusted sources). However, I may sometimes follow howtos or read Stackoverflow answers and copy text and commands from those less trusted websites.

I want to talk about how easy one could trick you by replacing copied text in your clipboard or inserting terminal escape sequences so that your shell will run additional and potentially malicious commands. And how I protecting myself against these tricks.

Tricks I have identified

Here is a list of tricks an attacker can use to fool you and make you paste a malicious command in your terminal.

Replacing copied text with Javascript

Dylan Ayrey demonstrates that with a few lines of Javascript, a malicious website can alter your clipboard content. The code runs on key release event (keyboard shortcut or right click) and override clipboard content with the malicious code the attacker wants you to execute.

Obviously this attack doesn’t work if you disable Javascript on unstrusted websites, which is by the way always a good idea.

Hiding malicious code with CSS

But even with Javascript disabled it’s easy for an attacker to put hidden text in your clipboard. The idea is to put the malicious code in the middle of the displayed command in a <span /> element and apply different CSS properties on it, so that the malicious code isn’t visible for the user. For instance make it float and move it away from the viewport, make it transparent, with no height or width…

Here is an interesting article about this attack. It also show how to hide the malicious code once pasted in the victim’s terminal so that the victim can’t even known he has been p0wned.

What about disabling CSS then?

Inserting non-printable characters

That’s no enough since you could have non-printable characters (like backspaces) in raw text. Here is an example (the whole thread is an interesting reading by the way). Basically, the idea is to insert extra characters and a backspace character after each of them to make the code appear inoffensive.

How I protect myself

So what next? What solutions I use to protect myself against those attacks?

Pasting into a text editor: the bad idea

In most shell, I can easily start $EDITOR with ^X^E to edit the current command. But that’s totally ineffective since the pasted text can contain ^ESC:!<malicious code> which will work in vim, or simply send the right shortcut to close the editor and get back to the shell.

Shell’s bracketed paste mode

This is an elegant solution. Bash (actually readline) can configure the terminal to enclose the pasted text between paste sequences (hence the bracketed paste mode):

enable-bracketed-paste (Off) When set to On, readline will configure the terminal in a way that will enable it to insert each paste into the editing buffer as a single string of charac‐ ters, instead of treating each character as if it had been read from the key‐ board. This can prevent pasted characters from being interpreted as editing commands.

To enable it:

$ echo "set enable-bracketed-paste on" >>~/.inputrc

If you then try to paste multi-lines commands in your terminal, the commands won’t be executed unless you press enter. You have a chance to review and edit them before their execution.

But it has two main drawbacks:

obviously enabling bracketed paste mode will work on your own computer only, unless you enable it on all your remote servers as well.
you may still be vulnerable to code injection if the pasted text contains the bracketed-paste-mode end sequence, whether your terminal automatically filter this sequence or not.

You can test this here.

confirm-paste plugin in URxvt

URxvt has a nice plugin called paste-confirm. It is shipped with URxvt and can be found in its plugin directory (/usr/lib/urxvt/perl/). Once loaded, the plugin will detect multi-lines pastes and will ask you whether to really paste it to the shell or not.

To enable it, simply add it to the plugin list in your ~/.Xdefaults:

URxvt.perl-ext-common: […],confirm-paste

Print your clipboard content before you paste

It’s always a good idea to double-check your clipboard content before pasting it somewhere. I sometimes don’t remember or I’m not sure about what was my previous selection, and I remember pasting whole file content into my terminal a couple of times…

I now use clipster for my cliboard manager with roficlip. Thus with a simple shortcut I can quickly double-check and select the previous entries in my clipboard.

Convert SSH keys from a format to another

2017-09-06T21:46:24+00:00

An SSH key can be stored in multiple format. ssh-keygen from OpenSSH generates keys in its own format, but other SSH implementations can use other formats. PuTTY for example generates keys in RFC4716 format, which looks like this:

You can’t simply copy-paste this in an authorized_keys file. Hopefully you can easily convert the public key from a format to another. This is done by I-do-about-anything-and-everything command, aka ssh-keygen:

$ ssh-keygen -i -m <format> -f input_key.pub > output_key.pub

-m specify the input key format among RFC4716 (the format used by PuTTY, this is the default if -m isn’t specified), PKCS8 and PEM.

Get a list of opened Firefox tabs

2017-09-06T21:20:49+00:00

Since I usually work with 2 Firefox on 2 different computers (a personal one and a professional one), I often need to get back some of my opened tabs from the Firefox instance running on my second computer.

Firefox store all opened tabs and windows and their history in the sessionstore-backups/recovery.js in your profile’s directory. So as long as this file is synchronized in some way to a remotely accessible machine (backups), you can parse the file and get the list of all your opened tabs and windows. I wrote a simple Python script to print tab’s title and URL of each tabs from the recovery.js file:

#!/usr/bin/env python3

# Print title and URL for each tab of each window of the specified
# Firefox profile.

import json

with open("<path to your Firefox profile's directory>/sessionstore-backups/recovery.js", "r") as f:
    jdata = json.load(f)
    for w in jdata['windows']:
        for t in w['tabs']:
            i = t['index'] - 1
            print("%s (%s)" % (
                t['entries'][i]['title'],
                t['entries'][i]['url']
                ))

You will get a list like this:

$ show-ff-tabs.py
[…]
GitHub - devimust/easy-bookmark-manager: Easy and simple self-hosted bookmark / snippet management tool. (https://github.com/devimust/easy-bookmark-manager)
GitHub - Kickball/awesome-selfhosted: This is a list of Free Software network services and web applications which can be hosted locally. Selfhosting is the process of locally hosting and managing applications instead of renting from SaaS providers. (https://github.com/Kickball/awesome-selfhosted#personal-dashboards)
GitHub - cdevroe/unmark: An open source to do app for bookmarks. (https://github.com/cdevroe/unmark)

(you can see that I currently looking for a simple self-hosted bookmark manager :-) )

More information for the structure of recovery.js file on the Mozilla wiki.

Rando-voyage dans les provinces maritimes du Canada

2017-07-18T21:53:42+00:00

Je reviens d’un voyage-rando dans les provinces maritimes du Canada, principalement à Terre-Neuve. Comme d’habitude, les photos sont ici mais j’ai aussi pour l’occasion fait un récit de mon séjour là-bas.

Ça m’a pris quelques modifications dans gallepy (mon générateur de galeries photos statique), pour pouvoir ajouter un onglet Récit si un story.mdwn est présent dans le répertoire de la galerie, mais je suis plutôt content du résultat.

La suite du récit arrivera dans les prochains jours.

Upgrade to Debian Jessie, introducing relay_access_restrictions in Postfix

2016-06-10T10:51:42+00:00

Abstract for TL;DR readers: since debconf append a relay_access_restrictions at the end of your main.cf file with same values of recipient_access_restriction, you have to do the same on all your services listed in master.cf. relay_access_restrictions intends to replace recipient_access_restriction on next Postfix releases.

After upgrading my mail server to Debian Jessie, I faced a weird problem with Postfix: emails sent from authenticated clients were rejected with a “Relay access denied” error.

I have a particular setup, though not-so-uncommon I think, since it should be the standard: port 25 is for server-to-server communications, no authentication is supported here. Instead, clients which want to send emails have to submit them on submission port (obviously). Concretely on my master.cf file, I override recipient_access_restriction for submission service to allow sending of emails with minimum restrictions if clients got authenticated.

So in my case, it seemed that the recipient_access_restriction option passed to submission process was ignored, or the one setup on my main.cf file won. Enabling debugging didn’t tell me anything. It even confirmed me that the recipient_access_restriction option for submission process was ignored since I saw Postfix testing all conditions specified on my main.cf

Then after some time, I have seen a new line at the end of my main.cf file : relay_access_restrictions, with all the tests of recipient_access_restrictions. Searching this on postconf(5) manual confirmed me that it replace recipient_access_restriction, although this one is always supported and not planed to be removed on the next coming versions. So debconf has added this new directive on my main.cf file, without any debconf advertisment as far as I remember, and without reason (Postfix don’t even raised a depreciation warning about that), and that breaks other services setted up on master.cf.

No ones seem to mention that on the Internet.

Québec − janvier 2016 : gastronomie québécoise

2016-01-31T17:28:50+00:00

Gastronomie québécoise

En amateur de bonne bouffe, parlons un peu de la gastronomie d’ici.
Si on s’intéresse à la gastronomie du Québec, on devrait plutôt parler d’archéogastronomie, car aujourd’hui il n’en reste que quelques traces, à part les produits dérivés du sirop d’érable et la poutine (si on considère ça comme un plat) qui restent courant. La culture américaine a largement pris le dessus. Je trouve que comparativement à la France, il n’est pas rare de manger dans des resto (hors fast-food) des trucs sans goût, aseptisés, fades… En fait, après 5 mois ici, j’ai remarqué que les québécois, et je pense que c’est généralisable à tout le Canada et l’Amérique du Nord, accordent beaucoup moins d’importance aux repas, à la qualité de la nourriture et au plaisir de manger. Les « repas » sont souvent expédiés et pris sur le pouce d’ailleurs, pas question de s’éterniser à table comme on a l’habitude en France. Ils mangent presque par contrainte, juste pour satisfaire leur faim. Ou plutôt leur envie de manger, car d’un autre coté je vois régulièrement des gens obèses, dans le sens vraiment maladif.

Mais Montréal abrite pourtant des milliers de restaurants qui représentent à peu près toutes les cuisines du monde (Montréal est une ville extrêmement cosmopolite). J’ai lu souvent dans les guides touristiques que Montréal est une destination de choix pour quelqu’un qui veut gouter à la gastronomie de différent pays. Mais même si les plats sont cuisinés effectivement avec le savoir faire du pays d’origine, les ingrédients eux sont (au moins en partie) ce qu’on trouve sur le continent américains, et j’ai du mal à croire qu’une choucroute ou une pizza ici soit aussi bonne qu’en Allemagne ou qu’en Italie.

Mais bref, on trouve donc à Montréal une très grande quantité de restaurants qui reprennent la gastronomie de différents pays, sauf… celle du Canada, en particulier du Québec ! Et forcement, si elle est déjà peu cuisinée ici, en dehors du Canada elle est quasiment méconnue. Donc pour y gouter, il faut souvent cuisiner les plats soit-même.

Le blog d’À Boire et À Manger en parle à peine malheureusement (voir pas du tout malgré les 4 épisodes), donc je vais vous en parler moi, mais sans dessins…

Malgré qu’elle soit très peu connue, je trouve que la gastronomie québécoise vaut quand même le détour. Elle est assez particulière dans le sens où les associations sont souvent surprenantes et inhabituelles. C’est à l’opposé de la fine cuisine, les plats sont généralement simples, sans raffinements, copieux et bien caloriques. Tout tourne autour de la viande ou de la charcuterie.
La raison est que, premièrement, les pionniers de la Nouvelle France (je ferrai peut-être un article sur l’histoire de la Nouvelle France, c’est assez intéressant, et encore une fois complètement méconnu, je ne me souviens même pas ne serait-ce que l’avoir entrevue en cours d’histoire à l’école) étaient généralement assez pauvres (paysans ou ouvriers) et n’avaient pas une très grande variété d’aliments à leur portée. Mais ils bénéficiez quand même de beaucoup de produits importés grâce au commerce maritime entre la Nouvelle France, les Antilles et la France, ou encore entre la Nouvelle France et la Martinique. D’où la présence de sucre, de mélasse (résidu de raffinage de la canne ou betterave à sucre, bien moins cher que le sucre à l’époque), de rhum depuis les Antilles ou de vin et de sel depuis la France, dans leur cuisine.
L’omniprésence de viande s’explique par l’abondance de gibier et la liberté de chasse (dans le sens pas contrôlée par un seigneur comme en France). Le climat et le travail était difficile, donc il fallait quelque chose de très calorique.

Parmi les plus connues, et le top du top pour moi, on trouve donc les fèves au lard, appelées aussi bines, de l’anglais bean (haricot/fève) qui ne sont donc pas des fèves mais des haricots blanc (même si à l’époque c’était des gourganes appelées aussi fèves des marais, si vous suivez toujours), qu’il faut faire cuire au four pendant une dizaine d’heures à basse température, avec beaucoup de lard, de la mélasse, du coulis de tomate et des épices comme du gingembre et de la moutarde. Ça donne des haricots fondant et bien imprégné du gras du lard, vraiment très bon mais à manger avec des pommes de terre ou du pain, sinon seul c’est vraiment très gras.

Connu surtout pour les controverses quand à son origine et sa facilité de préparation, il y a le pâté chinois, qui consiste en un gratin composé d’une couche de viande hachée, une couche de maïs en grains ou en crème (aussi appelé blé d’Inde) et une couche de purée de pomme de terre. Certains affirment que ce nom a été donné car le plat était consommé quotidiennement par les ouvriers chinois lors de la construction de la ligne ferroviaire pancanadienne, d’autres pensent que ça n’a rien à voir avec les chinois, et que son origine viendrait de la traduction de china pie, une spécialité locale de la ville de South China, dans l’état du Maine. Il y a d’autres théories, mais en résumé on a perdu son origine.

Autre plat typique, pour lequel presque chaque région a sa variante, la tourtière à la viande. Au Sagenay-Lac-Saint-Jean, il s’agit de la tourtière du Lac-Saint-Jean, en Gaspésie de la cipaille, etc… chacune est à priori différente, mais le plat consiste en une couche de pâte, de la viande, hachée ou en petits cubes, de gibier, de bœuf ou de porc, éventuellement marinée, des épices, éventuellement des pommes de terre en cubes, et une seconde couche de pâte pour fermer hermétiquement. Le tout cuit au four à basse température. On peut aussi rajouter des légumes (carottes, navets…) ou remplacer la viande par de la morue, ou encore du saumon. Bref, plein de variantes existent. C’est pas très compliquer à faire, mais on en trouve assez facilement des toutes prêtes dans des boucheries ou boulangeries.

Et puis plein d’autres encore à base de viande toujours : ragout de boulettes de viande, pain de viande, bouillons et ragoût en tout genre etc…

En charcuterie, ils ont moins de chose qu’en France, mais on trouve le fameux cretons, qui peut se comparer avec de la rillettes (d’ailleurs tous les 2 ne s’écrivent qu’au pluriel !) mais fait généralement avec de la viande de porc grasse, plus éventuellement du beurre (pour faire encore plus gras). C’est un plat qui était surtout mangé au petit-déjeuner sur du pain, comme les fèves au lard. On retrouve sinon plein de pâtés (de gibier, de tête, à la bière, etc…), du jambon fumé effiloché, qui est en fait un jambon cuit (blanc) puis fumé dans lequel on prélève non pas des tranches mais des lanières de viande, etc…

Outre tout ce gras, les colons faisaient quand même une très grande consommation de soupe à base de légumes d’hiver qu’ils cultivaient (genre carottes, pommes de terre, navets, courges, betterave etc…). Soupe dans laquelle ils pouvaient rajouter, aller pour changer… un peu de viande ! C’est peut-être la seule chose qui reste autant consommée aujourd’hui, quasiment n’importe quel fastfood, boulangerie etc… qui propose des plats à emporter propose des soupes (mais il ne faut pas s’attendre à un truc exceptionnel niveau goût).

Au niveau sucré, on trouve bien sûr toute sorte de produits de l’érable, allant de l’eau d’érable (aucune transformation) jusqu’au beurre et sucre d’érable, avec la fameuse tire d’érable dans les cabanes à sucre au printemps. Idem pour ce qui est des canneberges et des bleuets (variété de grosses myrtilles), disponible sous pleins de formes différentes : fraiches, en jus, dans des tartes, etc…

En dessert, le plus consommé encore aujourd’hui est le pouding-chômeur fait, encore une fois, avec des ingrédients bon marché : farine, beurre, œuf, lait et sirop de cassonade.

D’origine bien plus plus récente, les populaires beavertails (ou queues de castor) vendues dans des camions ambulants, lors des fêtes foraines et autres animations, sont des pâtisseries faites d’une sorte de pâte à gaufre mise en forme de queue de castor, puis frittes dans l’huile et recouvertes de diverses garnitures. J’imaginais ça bien bourratif, mais en fait pas du tout.

Le Québec fait une très grande production de pomme, principalement au début de l’automne, et est donc un gros producteur de cidre et cidre de glace. Le cidre de glace est fait à partir de jus de pomme concentré par l’action du froid (le jus est stocké dehors à une température largement négative, l’eau qui a formé des cristaux de glace est ainsi retirée au fur et à mesure. Ça permet d’obtenir un cidre plus sucré et alcoolisé, plus ou moins équivalent au vin.

D’origine plus récente, On trouve aussi plusieurs spécificités plus régionales, comme la viande fumée ou les bagels à Montréal, les microbrasseries artisanales un peu partout, les produits de la mer en Gaspésie, etc…

Les trucs chiants (cette fois-ci)

Les unités de mesure… un sujet classique mais je ne me serais jamais douté que c’était autant une prise de tête !
Tout d’abord il y a ceux qui parlent en pouces. Ça c’est simple. Ensuite ceux qui parlent en pieds, mais comme ça ne tombe pas rond, soit parlent ensuite en pouces, soit en fraction de pied. Tout en sachant qu’un pied n’équivaux évidemment pas à un nombre entier de pouces.
Pour illustrer la situation, pour une rallonge électrique de même taille on peut voir noter sur l’étiquette : 3 m, 9’ 10“, 118“, 9,84’ ou encore 9’ 4/5’.

Et ils aime ça les fractions de pouce pour remplacer les millimètres, ils les utilisent partout. J’ai acheté par exemple une boite de tournevis de précision, dans lequel j’ai des tournevis de 3/32“, 5/64“ et 1/16“. Exercice : classez les du plus petit au plus grand[1]. Bon oui, après avoir réfléchit un peu et avec l’habitude ça vient plus facilement, n’empêche que c’est bien moins simple que si ils avaient utilisé des millipouces (ou des poils de jambe pour continuer dans le délire). Je n’avais lu nul part qu’il fallait réviser ses cours de math avant de venir au Québec ! Car si je veux savoir combien fait 4mm en pouce, diviser 4mm par 2,54 ne m’avancera pas beaucoup avec une bête calculette, je n’aurai pas la fraction la plus proche… Un de mes meilleurs investissements est donc un mètre ruban, gradué à la fois en mètres, pouces et pieds, en un coup d’œil je trouve la bonne fraction.

Et puis, ces histoires de pouces, ça peut devenir dangereux. Un dialogue qui aurait pu arriver chez le coiffeur :

− Et pis, combien tu veux-tu que je t’enlève de pouces?
− Euh, ne touche pas a mes pouces, coupe moi juste mes cheveux, ce sera suffisant!

[1] Réponse : et bien ils sont déjà classés, ils ne sont pas sadiques au point de ranger les tournevis dans le désordre !

Getting Galaxy S2 GPS to work on Replicant

2016-01-21T20:24:34+00:00

Last week I gave a talk about Replicant with a live (re)installation of it on my phone at Club Linux Atomic. You can download the slides (in french) here (and LaTeX sources here). There are available under the Creative Common BY-SA 3.0 license.

But let’s come back to the topic of this post, the GPS chip of the Samsung Galaxy S2. After my talk, someone asked me how I got the GPS module to work on my phone. There is indeed no support of it on Replicant as the chip (a SiRF star IV GSD4t) is not recognized by standard free software tools like gpsd. Someones already worked on it, but without success at this time. All the work is on this Replicant’s wiki page. So if you really need it, you have to use the proprietary code.

I realize that there is no documentation explaining how to install this proprietary code, so here is what I did on my phone. Bear in mind that, unlike proprietary firmwares you need for WiFi/Bluetooth chipset, the proprietary code needed for the GPS is a “real” software which run on your main SoC, and could potentially have access to all your data.

First, let’s download the CyanogenMod archive corresponding to the Galaxy S2. Replicant is based on CyanogenMod and we are sure that the code we need is chipped with the CyanogenMod distribution.

Then you need to extract and upload to your phone this 2 files: gps.exynos4.so and libsecril-client.so:

adb push system/lib/hw/gps.exynos4.so /system/lib/hw/
adb shell chmod 644 /system/lib/hw/gps.exynos4.so
adb push system/lib/libsecril-client.so /system/lib/
adb shell chmod 644 /system/lib/libsecril-client.so

And that’s it! Pretty simple, just 2 files but we should have to know the good ones.

Québec − novembre/décembre 2015 : le vélo et le ski à Montréal

2016-01-05T19:52:44+00:00

Il n’a pas manqué du tout d’article pour novembre, c’est juste que cet article en contient 2 pour le prix d’un !

En fait ce n’est pas que les sujets à aborder manquent, mais plutôt que je préfère attendre afin d’avoir un avis plus précis et de ne pas passer à coté de choses que je n’aurai pas vu au premier abord. C’est le cas par exemple de randonnées et des réputés (à tord) grands espaces, de la gastronomie québécoise, complètement méconnue et pas mise en valeur à mon sens (à tord encore une fois), de la démocratisation du logiciel libre ici…

Mais tout ça ce sera pour après. Je vais plutôt parler de vélo et un peu de ski.

Le vélo à Montréal

Couramment appelé bicycle d’ailleurs, même si le terme vélo reste majoritairement utilisé.

Il y a énormément de vélo à Montréal. En fait, Montréal fait parti des villes d’Amérique du Nord les plus développées pour la pratique du vélo, et en conséquence (ou à cause) qui possède le plus grand nombre de personnes se déplaçant à vélo. Il est vraiment courant de faire une bonne partie de son trajet sur une bande ou carrément une piste cyclable.
Surtout quand il fait beau, il y a en fait tellement de monde sur les bandes cyclables que l’on ne peut pas doubler sans au moins regarder derrière soi, au cas où il y aurait déjà un autre vélo en train de doubler. Ça me semble naturel maintenant, mais à Marseille c’était tellement peu probable qu’un accident entre 2 vélos arrivent…

Concernant le comportement des automobilistes face aux vélos, et en comparaison avec Marseille toujours, c’est à peu près équivalent : ils ont moins tendance à forcer le passage aux priorités (mais ça ça semble être le cas de manière générale vis-à-vis des automobilistes entre eux, ils sont moins pressés, par contre ils respectent moins les distances de sécurités (les mêmes qu’en France), alors que les routes sont globalement plus larges. Je me suis déjà fait doubler en plusieurs fois à quelques dizaines de centimètres, en même pas quatre mois, alors qu’après plusieurs années à Marseille, ça ne m’était arrivé que très rarement (bon ils ne respectaient pas le 1 mètre non plus, mais ça restait raisonnable). Du coup j’ai quand même cette impression de ne pas être totalement en sécurité sur la route à Montréal, et de chercher à faire des détours pour prendre des bandes et pistes cyclables.

Il y a d’ailleurs beaucoup de pistes cyclables, les vraies, celles complètement séparées de la route, voir qui n’en suit pas. Elles se trouvent en général le long des berges et quand on s’éloigne du centre-ville. Ainsi on peut faire le tour complet de l’île de Montréal (attention, il faut être en forme, plus de 200 km !) uniquement sur des pistes cyclables qui longent le fleuve, traversent des parcs etc…
C’est vraiment cool pour avoir l’impression de sortir de la ville tout en commençant à pédaler de chez soi, sans avoir à prendre de voiture. Même au delà de l’île, le réseaux de pistes cyclables continu et traverse des endroits moins peuplés et avec bien plus de verdure.

Un bémol par contre, plusieurs bandes cyclables ne sont plus réservées aux cyclistes à partir de mi-novembre et deviennent des emplacements de stationnement. Mais parfois uniquement sur certaines portions, ce qui fait qu’on peut se retrouver d’un coup sans bande cyclable et à contre sens de la circulation ! Légèrement dangereux…

Il faut savoir aussi que globalement le Québec, mais Montréal particulièrement, se situe sur une forte zone sismique. Bon ce n’est pas vrai :-), mais à voir l’état des routes, c’est comme si ! Plein de fissures, d’affaissements et des nids de poules de partout, alors la ville les rebouche de temps en temps (ça devient des bosses, car c’est mal fait), puis d’autres nids de poule apparaissent sur la réparation, et ils en rajoutent encore une couche par dessus, etc… Ça donne des chaussés horribles. Je n’ai jamais vu ça en France, même sur des petites départementales dans les Alpes pas entretenues depuis une dizaine d’années.
Et pourtant, une grosse partie des gens roulent en vélo de course/route mais honnêtement je me demande comment ils font. Avoir un vélo un minimum costaud et des pneus pas trop fin pour absorber les chocs est pour moi à privilégier pour espérer qu’il dure longtemps. Ça s’appelle des hybrides ici, ce qui est à peu près l’équivalent des VTC en France.

Pour le vélo l’hiver, ça se fait très bien avec des pneus hiver, jusqu’à quelques centimètres de neige. Au delà ça se fait toujours mais c’est plus… sportif disons, mais je trouve ça amusant personnellement.
De toute façon, les bandes cyclables finissent par être déneigées au bout de quelques jours.

Le ski au Québec

Le Québec étant une région très plate, il se prête assez bien à la pratique du ski de fond ou de randonnée nordique. Malheureusement cette année la neige a mis du temps à arriver et je n’ai eu jusqu’à présent l’occasion de skier qu’une seule fois, mais ça n’empêche pas de commencer à en parler.

Vocabulaire

Déjà au Québec, les différents sports de ski ne s’appellent pas de la même façon qu’en France, donc voici un magnifique tableau pour s’y retrouver :

Dénomination française	Dénomination québécoise	Dénomination anglaise
ski de fond (alternatif)	ski de fond (alternatif)	cross-country skiing
skating	ski de patin	skate skiing
ski de randonnée nordique (SRN)	ski hors-piste, ski de randonnée, ski de randonnée hors-piste	pas de terme vraiment adapté
ski de piste, ski alpin	ski alpin	alpine skiing
ski de randonnée	ski de haute-route, ski hors-piste	ski touring

En résumé, ça va à peu près sauf pour le SRN où tout le monde l’appelle un peu comme il veut, et on ne peut même pas utiliser le terme anglophone car c’est pas mieux chez eux. Certains nomment le ski de randonnée également ski hors-piste, donc ça porte encore plus à confusion pour le SRN…
Comme le texte vise plutôt les français nouvellement arriver au Québec, j’emploierai les termes français.

Location/achat de ski

Suivant votre utilisation, vous pouvez soit :

en louer sur place à la journée, suivant les endroits où vous allez ;
en louer pour un weekend ou la saison entière ;
en acheter neuf ou d’occasion.

Pour en acheter neuf, les boutiques principales sont MEC et La Cordée, sortes de Décathlon en plus petit et plus cher. Mais il y a à voir également D’un Sport à l’Autre (majoritairement d’occasion, et peu de choix quand j’y suis allé) et Sports aux Puces (de l’occasion aussi). Les 2 premières font de la location à la journée/weekend, mais ça revient très vite cher si vous comptez skier plus de quelques fois dans la saison (environ 20$/j).

Mais l’option clairement intéressante est d’aller à La Poubelle du Ski, magasin visiblement très connu à Montréal : ils proposent de louer des skis d’occasions pour la saison entière, ou des skis neufs avec possibilité de les acheter ensuite en fin de saison. C’est donc assez intéressant si vous comptez en faire beaucoup, et que vous n’êtes pas prêt à investir directement dans l’achat de skis neufs. Surtout que les tarifs sont plus qu’intéressants, les skis neufs étant des modèles des années passées ou d’exposition. À titre d’exemple, pour des skis de fond neufs à farter, fixations (pose comprise), bâtons et chaussures, j’en ai eu pour légèrement plus de 100 $ pour la saison. En fin de saison, je peux les acheter pour 100 $ de plus. Le personnel est visiblement assez compétant (beaucoup de jeunes), par contre vu la réputation de la boutique, il vaut mieux y aller tôt le matin à l’ouverture, en soirée c’est la cohue…

Pistes de ski de fond à Montréal

Le truc vraiment bien, c’est que la ville trace des pistes de ski de fond dans les grands parcs de la ville et en périphérie dans les parcs nature. Et L’accès y est gratuit ! Les parcs skiables et les conditions de neige sont consultables sur le site de la ville.

Par contre le skating étant moins populaire ici, les pistes ne sont faites que pour le pas alternatif, et des pistes distinctes (plus rares) sont damées pour la pratique du skating.

Les trucs marrants

Dans l’éternel et passionnant débat sur l’appellation pain au chocolat versus chocolatine, les québécois viennent soutenir l’effectif des sud-ouestien de France en appelant les pains au chocolat des chocolatines. Heureusement ici un sac plastique reste un sac plastique. Mais là où ils sont bons, c’est qu’ils ont enfin résolu le problème du choix entre croissant et pain au chocolat en inventant… le croissant au chocolat (et non la croissantine, preuve que c’était une bonne idée) !
Moi qui faisait toujours très attention à mettre une espace insécable avant la plupart des points de ponctuation, j’ai appris qu’au Québec personne ne s’embête avec ça, la règle est de ne rien mettre du tout (comme en anglais donc). Donc maintenant, je fais attention suivant à qui j’écris.

Québec − octobre 2015 : accès à Internet, meubles et un peu de tourisme

2015-11-07T17:42:43+00:00

Petit d’état des lieux des FAI au Canada

Après l’achat d’un frigo et d’un matelas, dans l’ordre des priorités, vient celui d’un abonnement à un fournisseur d’accès à Internet (protip : en prenant d’abord un abonnement Internet, vous pouvez vous passer d’un matelas puisque vous pourrez ne plus dormir. Et en suivant un régime spécial vous pourrez en fait également vous passez aussi de frigo :-) ).

Attention, je ne vais parler que de l’offre résidentielle, il y en ai bien sûr autrement pour l’offre à destination des entreprises.

Au niveau offres disponibles sur le marché des FAI, c’est pas terrible : en fait il y a de nombreux FAI, certains sont uniquement présents sur certains secteurs (Grand Montréal, Ottawa-Gatineau, etc…), la majorité sur tout une province, et les quelques gros sur plusieurs, mais aucun ne couvrent la totalité du pays. Mais la concurrence ne semblent pas être très avantageuse pour les consommateurs, les tarifs sont finalement assez identiques d’un FAI à l’autre, de l’ordre de la quarantaine de dollars pour un accès ADSL en ligne sèche (équivalent d’une ligne dégroupée en France). Ça, c’est à condition d’accepter d’avoir une limite de ~150 Go téléchargés par mois. Pour avoir plus ou, soyons fou, aucune limite (genre… comme en France en fait), c’est plus cher. Et pour du VDSL ou de la fibre, pour votre santé mentale, ne rêvez pas :-). Les offres Internet/téléphonie VoIP/TV existent aussi, pour environ $100/mois…

D’un point de vu plus technique… ce n’est pas mieux. Commençons quand même par deux points positifs : plusieurs fournisseurs donnent la possibilité d’avoir une adresse IP fixe (moyennant quelques dollars de plus sur l’abonnement). Parmi eux, certains offrent aussi la possibilité d’avoir un /30, /29 voir /28 (!) moyennant un peu plus que quelques dollars par mois, mais c’est toujours intéressant d’avoir cette possibilité en tant que particulier).

Au niveau IPv6, à ma connaissance, seul TekSavvy fournit un accès en IPv6 natif (officiellement en beta, dans le sens où il ne font pas de support, mais relativement stable, et en place depuis plusieurs années). Quelques autres ont une beta en cours de mise en place, ou bien offrent un tunnel via Hurricane Electric. TekSavvy fournit une IPv6 pour l’interco via DHCP-PD et un /56, on peut donc se créer plusieurs réseaux locaux avec.

À priori, tous laissent la possibilité d’utiliser son propre modem[1], et d’héberger son serveur. TekSavvy bloque par défaut le port SMTP en sortie au niveau de leur réseau, désactivable sur demande.

Venons en là où ça fait mal : la gestion du réseau fonctionne un peu comme en France, dans le sens où les quelques très gros opérateurs (Bell et Telus au Québec) louent leurs infra aux opérateurs intermédiaires (équivalent de l’offre de collecte en France). La différence est que la partie réseau qui est louée passe d’abord par des équipements actifs des opérateurs de collecte, qui ont pris la mauvaise habitude de faire de la limitation de trafic à base de DPI. Donc au final, quelque soit l’opérateur qu’on choisisse, nos communications seront analysés par Bell ou Telus !
Quelques opérateurs intermédiaires et unions de consommateurs ont porté plainte contre Bell, sans trop de succès pour le moment. Du coup, quelques opérateurs offrent des solutions de contournement : de manière radicale, Acanac fournit un service de VPN, de l’abonné jusqu’à leur réseau par exemple. D’autres tel que TekSavvy donnent la possibilité de faire du SLPPP (Single Link PPP, donc du MLPPP à un seul lien PPP), ce qui permet (à l’heure actuelle) de passer au travers des limitations imposées.

Au sujet de la neutralité du net, y a-t-il des FAI associatifs qui visent à fournir une connexion la plus neutre possible, comme tous les petits FAI associatifs et FDN en France ?
Pas vraiment. Le seul qui s’en rapproche est NCF (National Capital Freenet), surtout présent comme son nom l’indique sur la région de la Capitale Nationale (Ottawa-Gatineau). C’est un OBNL (Organisme à But Non Lucratif, à peu près équivalent aux associations Loi 1901 en France) nait dans une université, dont le but affiché est plus de fournir un accès au plus pas prix possible au plus grand nombre qu’un accès le plus neutre possible. Bien qu’ils disent le contraire, je n’ai pas trouvé qu’ils étaient moins cher que les FAI commerciaux, et certains trucs m’ont un peu rebuté : ils donnent par défaut une IPv4 non fixe et font payer le fait d’avoir une IPv4 fixe, et comme ils passent par Bell, ils sont également impacté par le DPI. Ils n’offrent rien contre ça, mais pire (ce n’est pas officiel), j’ai compris qu’ils faisaient eux aussi de la limitation de débit sur certains ports. Sur Montréal, les différentes personnes impliquées dans le logiciel libre auxquelles j’ai pu parlé n’avait jamais entendu parlé de NCF…

Pour retrouver le sourire, un projet plus sympa existe sur Montréal : reseau-libre.ca, c’est un OBNL qui maintien un réseau mesh en WiFi. Il ne vise pas de fournir un accès à Internet, mais plutôt d’avoir un réseau local (surtout dans le sens agriculture locale, pas LAN) pour permettre au montréalais de communiquer entre eux, et éviter de passer par les gros points de concentration sur Internet. Ce qui est cool, c’est que rien ne semble très sérieux et ça fait un peu grand aire de jeux/bac à sable pour adminsys/admin réseau : chacun peut ajouter sa petit machine sur le réseau en fournissant les services qu’il veut (XMPP, serveur web d’une station météo, webcam d’un lieu public…), en testant des nouveaux protocoles avec ses voisins, etc… Je ne les ai pas encore rencontré, mais c’est clairement dans mes todo !

Au final, j’ai donc opté pour TekSavvy, pour leur support d’IPv6, la possibilité de passer au travers du DPI de Bell, la possibilité d’avoir une IPv4 fixe et si besoin des IPv4 additionnelles, et leur support technique assez compétant (genre ils comprennent de quoi je parle si je leur demande d’ajouter un reverse DNS sur mon IPv4) d’après les différents retour d’utilisateurs. Je ferai probablement un retour plus poussé plus tard, et avec la bonne conf du démon pppd de FreeBSD qui supporte SLPPP.

Quelques liens pour aider à choisir son FAI :

Canadian ISP, pour avoir une liste quasi exhaustive ;
DSL Report, surtout pour les retours d’utilisateur et le forum très actif, concerne tous les FAI nord-américains.

[1]: À titre d’info les modem français/européens fonctionnent bien, j’utilise un D-link DSL 320B, n’apportez pas votre câble gigogne <-> RJ11 par contre, ils ne connaissent pas, c’est du RJ11 des 2 côtés.

Où trouver des meubles

Parce que vivre dans un appart vide, ça devient vite peu agréable. Voici quelques endroits où trouver de quoi remplir un peu votre nouvel appart :

Kijiji, équivalent de leboncoin en France, c’est la référence numéro 1. Avec un peu/beaucoup de patiente on peut tomber sur des superbes affaires. J’ai pu par exemple avoir un grand canapé 3 places comme neuf pour $170 livraison comprise, et une table et 2 chaises en état pas top mais pour $20 livraison comprise aussi ! La grande difficulté est de tomber sur des personnes qui acceptent/peuvent faire la livraison pour les gros meubles, et c’est pas forcement évident. Avoir la possibilité de louer une voiture aide pas mal, encore faut-il arriver à la rentabiliser ;
les autres sites de petites annonces comme Craigslist ou Lespacs sont nettement moins fournit, mais ça peut être intéressant de jeter un œil de temps en temps ;
plus pour ce qui est décoration intérieure et vaisselle, Renaissance, Le Village des Valeurs (traduction à la québécoise de Value Village, donc dans le sens économique plutôt qu’éthique, j’ai mis du temps à comprendre), l’Armée du Salut et les bazars dans les Églises. On trouve pas mal de choses pour quelques dollars, c’est des dons à la base, donc il faut pas s’attendre à des trucs super mais ça peut dépanner, ou si vous êtes vraiment juste au niveau budget ;
les magasins de revente d’occasion : le gros plus c’est qu’ils font la livraison, parfois gratuitement, et il est facile de négocier le prix. J’y ai acheté matelas, frigo et cuisinière car ça permet d’avoir une petite garantie de quelques mois sur l’électroménager. Au niveau meubles, c’est quand même nettement plus cher que ce que vous pourrez trouver auprès de particuliers. Ils y en a un peu partout dans Montréal, notamment sur l’avenue Papineau, à partir de la rue Rachel et en remontant assez loin vers le nord ;
les magasins de destockage, là c’est du neuf, mais même avec des rabais important, c’est un autre budget ;
et enfin Ikea, du neuf de qualité moyenne pour un prix moyen. Le gros inconvénient et qu’il est loin de tout et qu’il faut une voiture pour y aller (surtout si vous compter revenir avec plein de trucs).

Un peu de tourisme

J’ai commencé à avoir un peu plus de temps libre, ce qui m’a permis de visiter enfinla ville. J’ai commencé tout près de chez moi, par le jardin botanique et son insectarium. Le jardin botanique de Montréal est le plus grand du Canada et vraiment super bien aménagé, avec des jardins à thème et un très grand arboretum, je n’ai pas encore tout vu. Au printemps, ça doit vraiment valoir le coup ! Pour les photos, c’est ici.

Et une petite balade autour de St-Jérôme, petite ville accessible en bus la plus loin au nord de Montréal, car j’avais envie de sortir enfin de l’île.

Les trucs marrants

En vrac, quelques trucs amusants :

aucun commerce ne ferment entre midi et 2, et ça c’est vraiment bien, car outre le fait que c’est… ouvert, pas besoin de se rappeler pour chaque commerce de quelle heure à quelle heure il ferme. Il est ouvert de 9h à 18h la journée, point. Dans le même genre, tous les commerces sont ouverts le dimanche, et la plupart ferme bien plus tard le jeudi/vendredi, vers 21h en général.
En automne, ce n’est pas la neige qui recouvre les routes, mais les feuilles mortes, car il y a des arbres vraiment partout. À tel point que les feuilles mortes se ramassent… au tractopèle ! Pas de photos pour illustrer, mais c’était assez marrant.
J’aurai l’occasion d’en reparler, mais en France j’avais l’habitude de voir dans les supermarchés des amandes provenant de Californie. Ici, au Québec, elles proviennent d’Italie. Magnifique.

Québec − septembre 2015 : paperasse et recherche de logement

2015-10-05T21:04:01+00:00

Après un mois passé au Québec, voici un petit article dans lequel je tiens surtout à laisser de l’information utile/que j’aurai bien aimé savoir avant de partir pour d’autres immigrants.

Passage de l’immigration au Canada

Petit contexte avant tout, je travaille au Canada dans le cadre du V.I.E, pour une durée de 2 ans (durée maximum possible). Ce qui nécessite donc entre autre d’avoir déjà un contrat de travail conclu avec un employeur canadien.

Le statut de V.I.E étant purement français, au Canada je suis donc là dans le cadre d’EIC Jeunes professionnels. La procédure pour obtenir la lettre officielle (Lettre d’Introduction) de demande de permis de travail est un peu longue et fastidieuse, mais assez simple car très bien documentée sur le site de Citoyenneté et Immigration Canada.

Par contre, la liste des documents à avoir pour le passage de l’immigration à l’aéroport est restée assez floue. J’ai fini par trouver dans la FAQ de CIC, cette liste, mais ce n’étais pas très clair, notamment comment faire si on a pas de billet de retour (à priori il faut prouver qu’on a suffisamment d’argent pour l’acheter sur place, mais comment ?), et leur définition de la « preuve de fonds disponibles » n’est pas très claire, d’ailleurs ils ne précisent pas le montant.

Au service d’immigration, l’agent m’a finalement demandé uniquement la lettre d’introduction (forcement) et la lettre de mon employeur confirmant le contrat de travail, document absolument pas mentionné dans la liste mais que j’avais imprimé et avec moi, (ainsi que d’autres) au cas où. Et j’ai pu avoir mon beau permis de travail !

Pour la preuve de fond, je ne saurai donc pas ce qu’il fallait…

Démarches une fois arrivé

On retrouve assez facilement les démarches à faire une fois sur place un peu partout sur le net, beaucoup moins la notion de dépendance entre elles. Du coup pour éviter un casse-tête à expliquer son cas à chaque fois et de perdre trop de temps et de sous, voici les démarches à faire, dans l’ordre :

commencez par apprendre votre code postal par cœur (ou pensez à le noter quelque part), c’est une suite de 3 chiffres et 3 lettres immémorisable et qui dépend de la rue dans laquelle vous résidez (et non de la ville comme en France). Ce n’est utile que pour la poste, pas pour trouver une adresse sur une carte/un GPS ;
demande du NAS (Numéro d’Assurance Sociale, pas d’équivalent en France) dans un bureau de Service Canada : c’est une affaire d’une dizaine de minutes, sauf entre midi et 2 où vous n’avez généralement pas beaucoup de temps et où tout le monde à la bonne idée de venir au même moment. Sinon ça ouvre tard le matin et ferme tôt l’après-midi.
Il ne vous faut que votre passeport et votre permis de travail, et il faudra donner votre adresse (même temporaire) à laquelle vous résidez ;
ouvrez un compte en banque, de préférence dans une banque ayant des offres pour les immigrants comme la TD ou Desjardins). Il vous faudra toujours votre passeport et votre permis de travail, toujours donner votre adresse de résidence (avec son horrible code postal), et votre NAS récemment reçu.
Si vous avez pensez à amener des euros en espèces de France, faites-les changer et déposez-les sur votre compte canadien. Sinon, là commence les ennuis : si vous comptiez faire un virement international depuis votre compte français pour avoir de l’argent rapidement, grave erreur. Sauf à être dans une banque implantée à la fois en France et au Canada, leurs procédures pour les virements hors zone SEPA impliquent de faire une demande via un formulaire papier à leur renvoyer signé, puis le temps qu’il le prennent en compte, vous appelle pour vérifier les info et envoi l’ordre de virement, ça peut prendre une dizaine de jours. Si il y a une information incomplète, vous repartez à la case départ pour 10 jours supplémentaires.
Bref, il vaut mieux prévoir d’arriver avec déjà de l’argent en espèces à mettre sur votre compte canadien ;
ensuite, dans le but de trouver un appartement, il vous faut un numéro de téléphone canadien, déjà pour éviter de trop payer en hors-forfais avec votre forfait français, et surtout si un proprio doit vous rappelez c’est mieux de lui donnez un numéro local qu’un numéro étranger.
Ça va dépendre des opérateurs, mais juste une adresse et une carte de débit canadienne (avec des sous sur le compte) suffit ;
Montréal étant grand, pour être efficace et pouvoir enchainer les visites, il vaut mieux avoir un moyen de transport plus rapide et moi contraignant que ses pieds et les transports en commun. Le vélo est à mon avis la meilleure solution, et puis ça vous permet de visiter par la même occasion les quartiers. À Montréal il y a les BiXi (équivalent des Vélib), mais personnellement j’ai dessuite acheté un vélo d’occasion, vu mon utilisation pour la suite ;
après ça, vous êtes normalement parez pour rechercher efficacement un appart.

Dès que vous aurez votre adresse permanente, il restera des démarches moins urgentes et facultatives, notamment l’inscription au registre des français établis hors de France auprès du consulat, la demande de la carte Soleil auprès de la RamQ (équivalent de la carte Vitale) qui permet juste de ne pas avoir à avancer des frais de santé et la souscription d’une assurance habitation (qui n’est pas obligatoire ici). Et bien sûr, un service vital, une connexion Internet suffisamment fiable et neutre, mais j’y reviendrai probablement par la suite, car c’est moins évident qu’en France.

Comme vous vous en doutez, ce scénario idéal n’était pas mon cas. En fait, j’ai à peu près fait les démarches dans le bon ordre, mais sans attendre des sous sur mon compte canadien, donc je n’ai pas pu acheter dessuite de forfait mobile, et je n’ai pas attendu non plus d’avoir de forfait mobile pour chercher un appart, ce qui m’a fait une sacrée facture de hors forfait. Et quand j’ai signé mon bail, je n’avais toujours pas de sous sur mon compte canadien pour faire de chèque… Donc beaucoup de stress que j’aurai pu éviter.

La recherche de logement

Montréal a les logements les plus cher de tout le Québec. Mais le Québec a les logements les moins cher de tout le Canada. Et dans toute l’Amérique du Nord, j’en sais rien :).
Comparativement à la France, ça reste bien moins cher que Paris et le sud-est de la France, hormis certains quartiers comme le centre-ville, le Plateau, et les quartiers riches résidentiels d’Outreront et Westmount.

Rapidement, car l’info se trouve assez facilement ailleurs :

les annonces de location se trouvent sur les sites comme Kijiji, Craigslist et Les Pacs équivalent de leboncoin français. On peut aussi en trouver sur d’autres sites, dans les journaux etc… mais rien qu’avec ces 3 là il y a de quoi faire ;
le truc particulièrement sympa par rapport à la France, c’est que les propriétaires n’hésitent pas à mettre l’adresse exacte du logement dans l’annonce, ce qui permet d’avoir les résultats sur un carte (fond de carte OSM + LeafletJS en plus !). Il manque plus que de pouvoir filtrer la recherche en traçant des polygones sur la carte, avec un peu plus de Leaflet, PostgreSQL + PostGIS \o/ ;
beaucoup de propriétaire demandent soit des références d’anciens propriétaires soit un historique de crédit. En arrivant bien sûr on a rien de tout ça, donc il faut passer son chemin… ;
les québécois commence à compter à partir de 1, donc le rez-de-chaussé est le premier étage, le premier le deuxième etc… Sauf qu’il y a beaucoup de français immigrés qui continus à appeler le rez-de-chaussé le rez-de-chaussé, le premier le premier etc… donc en clair il n’est pas possible d’être sûr de l’étage de l’appartement tant que vous ne l’avez pas vu. Et les appart en demi sous-sol sont plutôt des 3/4 sous-sol ;
au niveau vocabulaire, le tapis est la moquette, le bois franc le parquet, la céramique le carrelage, le poêle la cuisinière, la laveuse le lave-linge…
le propriétaire connait rarement la superficie de ce qu’il loue et préfère parler en nombre de pièces.

Les trucs marrants

En vrac, quelques trucs amusants et particulièrements différents de la France :

l’état semble plus laïque que la France : à l’aéroport, une femme employée au service d’immigration portait un voile (assortie à son uniforme d’ailleurs) ;
parfois c’est difficile de se croire à l’étranger : beaucoup de produits alimentaires (notamment les huiles, du sel, des conserves préparées, confitures…) viennent de France, sans compter des marques classiques de France qu’on retrouve ici aussi, puis les nombreuses rue aux noms de villes française (rue de Marseille, de Bordeaux, avenue d’Orléans…, rue Mistral, Charlemagne…), les nombreux vélos Peugeot…
il y a globalement beaucoup de vélos dans Montréal, il y en a même tellement dans certains quartiers qu’il y a parfois des bouchons sur les pistes cyclables !

How to enlarge your raw disk image

2015-09-10T17:04:19+00:00

Extending a disk image file (of a KVM guest for example) is a tricky operation, especially if we haven’t enough disk space to keep a backup of the image we will working on. So I write a little howto for the next time we have to do this operation.

Prerequisites

First, you need to have the following packages installed: qemu-utils kpartx parted.

Make sure your VM is halted and no processes have opened the file:

# lsof $img

Note: for following commands, I assume $img contains the path to your image file.

Extend the image file

Pretty easy step, you can simply use qemu-img tool:

# qemu-img resize $img +50G
Image resized.

You can mount the image and check that it has the correct size:

# kpartx -v -a $img
add map loop0p1 (254:13): 0 195318207 linear /dev/loop0 63
# fdisk -l /dev/loop0 

Disk /dev/loop0: 214.7 GB, 214748364800 bytes
[...]

Extend the partition

Then, you have to extend the partition. That supposes of course either the disk image contains only one partition (which could be a LVM PV) or the partition you want to extend is at the end of the image.

Before all, backup your partition table:

# sfdisk -d /dev/loop0 >~/loop0.parts

(It could be restored with sfdisk /dev/loop0 <~/loop0.parts).

And remove and recreate the partition using all free space with parted:

# parted /dev/loop0 print
Model:  (file)
Disk /dev/loop0: 215GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  100GB  100GB  primary  ext3
..
# parted /dev/loop0 rm 1
# parted /dev/loop0 mkpart primary ext3 32.3kB 215GB
# parted /dev/loop0 print

Remount the image to see her new size:

# kpartx -d $img
loop deleted : /dev/loop0
# kpartx -v -a $img
add map loop0p1 (254:13): 0 419430337 linear /dev/loop0 63

Extend the filesystem

We are almost there, remaining the filesystem. First, this is a good thing to run a fsck before all:

# e2fsck -f /dev/mapper/loop0p1 
e2fsck 1.42.5 (29-Jul-2012)
/dev/mapper/loop0p1: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/mapper/loop0p1: 41753/6111232 files (9.1% non-contiguous), 23479003/24414775 blocks

Then, resize the filesystem:

# resize2fs /dev/mapper/loop0p1 
resize2fs 1.42.5 (29-Jul-2012)
Resizing the filesystem on /dev/mapper/loop0p1 to 52428792 (4k) blocks.
The filesystem on /dev/mapper/loop0p1 is now 52428792 blocks long.

It’s done! We can check if we see the correct size after mounting the partition:

# mount /dev/mapper/loop0p1 /mnt
# df -h /mnt
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/loop0p1  197G   89G  109G  45% /mnt
# umount /mnt

Finally, unmount the image:

# kpartx -d $img
loop deleted : /dev/loop0

Départ pour le Québec

2015-09-01T19:36:08+00:00

Dans quelques jours, j’aurai mes pieds au Canada pour 2 ans au moins, probablement plus. Avec toute ma vie que j’ai réussi à faire tenir dans 3 sacs.

C’est le résultat d’un très dur choix que j’avais eu à faire en début d’année : depuis 1 an, je préparais une grande rando/voyage à l’étranger (je n’avais jusqu’alors jamais mis les pieds hors de France métropolitaine) au départ de France pour remonter jusqu’en Norvège en train/ferry/stop… et de là, avancer jusqu’au Cap Nord en marchant à travers les fjords, les Alpes scandinaves, et la Laponie. Le but était vraiment de prendre mon temps et de profiter. Je pensais partir pour 2 ou 3 mois, et ça impliquait beaucoup de choses, notamment de quitter mon emploi à Evolix, et de me débarrasser de la plupart de ce que je possédais.

Mais alors que j’ai donné ma démission, j’ai eu une proposition qui a tout remis en cause : partir ouvrir une filiale d’Evolix au Canada, à Montréal. Alors que ma préparation pour mon projet initial avançait, que je m’étais préparé psychologiquement à ce départ, le choix a été très dur, mais j’ai finalement accepter de remettre mon projet dans un coin et de saisir cette opportunité. C’était une opportunité qui ne se représenterait peut-être jamais, quant à mon projet, je le garde bien au chaud dans un coin, avec tous mes autres rêves à réaliser.

Parmi tout ce que j’ai eu à faire dans les préparatifs, une chose a été bien plus compliquée que ce que je pensais : faire tenir tout ce dont j’aurai besoin dans quelques sac, sachant que je ne sais même pas pour combien de temps je pars (2 ans au minimum, mais peut-être 5, vois plus…). Je pensais que je ferai ça assez facilement car je suis relativement peu attaché à des biens matériels en général, et j’achète très rarement des trucs (quand je regarde mes connaissances autour de moi qui amassent des quantités faramineuses de fatras chez eux dont ils ne se sont probablement jamais servi pour la plupart, ou qu’ils commandent sans cesse un tas de gadgets dont j’ai du mal à comprendre l’intérêt parfois, ça m’impressionne toujours…). Mais le peu que je possède, ce sont des trucs qui me servent plus ou moins régulièrement, et en tout cas qui me manqueront forcement sur une période aussi grande.

À l’inverse, je pensais que vendre dans les temps tout ce que je n’emporterai pas serait un peu utopique (du moins j’avais peur de me retrouver avec des meubles invendus dont je n’aurais su que faire), mais non, la demande est en fait très forte en ce qui concerne l’ameublement et l’électroménager. Bon faut pas espérer en tirer grand chose par contre, mais on ne peut pas tout avoir…

À l’heure actuelle, je n’ai plus qu’une seule clé à mon trousseau, celle du bureau, et ça fait vraiment bizarre ! Je n’ai plus ma petite zone de confort qu’était mon appart, c’est assez excitant et stimulant.
J’ai arrêté la vie que je commençais à trouver bien trop monotone, le fameux boulot-métro^Wvélo-dodo, et je re-vie enfin ! (c’est un peu ce que je recherchais à l’origine en voulant partir en Norvège).

Play a Vim macro on all opened buffers

2015-05-28T19:16:40+00:00

Here is a small useful tip, which I use in my daily sysadmin work, when I have a lot of similar configuration files to alter, but my modification is to complex to be scripted with sed/awk.

The perfect example is Apache’s vhost configurations in site-enabled/.

Open all files in Vim and start recording your macro (with q) on the first buffer.
Until now I opened the next buffer, replay my macro, then opened the next buffer, replay my macro again, etc…
Pretty boring.

But I discovered recently that you can execute a command on all opened buffers, and particularly a macro. Here is the magic line:

:bufdo execute "normal @a"

Replace a with the name of your macro of course, and don’t miss to :write at the end of your macro (or add a | write at the end of the command).

Get verbose output from an already launched cp/mv/rsync process

2015-05-27T19:26:18+00:00

This could be a bit obvious for others sysadmins, but I use this trick quite often and it’s really helpfull.

Imagine you connect on a server and see a running process (a cronjob for example) doing some file copy operations, running for a while and launched without -v option (or you can’t see his stdout).

Or imagine you launched a big cp/mv (from a partition to another)/rsync or whatever, you know it will probably run for a while, but you missed to add the -v option.

No problem, here is how we could get an equivalent with strace:

strace -p $(pidof cp) 2>&1 |grep open

Or for a rm:

strace -p $(pidof rm) 2>&1 |grep unlink

If you want just to see the current file your command is currently on:

lsof -p $(pidof cp)

Ghostscript − Concatenate pages with different orientations

2014-08-10T08:35:15+00:00

Concatenate multiple PDF documents while preserving orientation (portrait/landscape) of each page:

$ gs -q -sPAPERSIZE=a4 -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dAutoRotatePages=/PageByPage -sOutputFile=concatenated.pdf $(ls -v doc*.pdf)

Reverse proxy avec re-chiffrement du flux vers le backend

2014-07-11T20:50:27+00:00

Dans un environnement web critique/à fort trafic, il est courant d’avoir de multiples serveurs web, et un ou deux load-balancer devant permettant de répartir la charge et d’avoir une tolérance de panne sur les serveurs web.
Dans le cas d’un site en HTTPS, le flux est en général déchiffré par les load-balancer, puis transite en clair vers les frontaux. Cela permet de décharger les frontaux du traitement cryptographique et au load-balancer d’interpréter le HTTP, donc d’avoir certaines fonctionnalités intéressantes (répartition du trafic en fonction du virtualhost ou de l’URL, gestion des cookies de session, interprétation des codes d’erreurs HTTP renvoyés par les frontaux pour anticiper un problème, etc…).
Cependant le fait que le flux HTTP transite en clair entre les load-balancers et les frontaux peut poser problème dans certains cas :

les données qui y transitent nécessitent un haut degré de confidentialité (numéros de cartes bancaires par exemple) ;
le réseau entre le load-balancer et les frontaux n’est pas sûr (le flux repasse sur Internet par exemple).

Dans ces cas, la solution est de re-chiffrer le trafic après traitement par le load-balancer, puis chaque frontal le déchiffre à nouveau. Il faut bien noter que cette charge supplémentaire en traitement cryptographique (déchiffrement, re-chiffrement, re-déchiffrement), n’est pas anodine et la quantité de requêtes par seconde que peut encaisser la plateforme sera bien moindre que dans le cas d’un simple déchiffrement du flux par le load-balancer.

Pour en venir au cœur de l’article, j’ai dû mettre en place récemment une architecture de ce type, et j’ai été confronté à un problème dont je ne m’attendais pas vraiment : peu de reverse proxies HTTP savent re-chiffrer le flux HTTP vers les backends !

Parmi les logiciels existants :

HAProxy : dans sa version stable actuelle (1.4), il ne sait pas déchiffrer le trafic entrant, et donc encore moins re-chiffer derrière. Sa version encore en dév (1.5) supporte le déchiffrement du HTTPS néanmoins ;
Nginx : il sait bien sûr déchiffrer le HTTPS mais pas le re-chiffrer vers les backends ensuite ;
Pound : pareil que Nginx, ne sais que déchiffrer ;
Apache : le seul après recherche à savoir faire les 2 !

Voici la conf (en somme très simple) d’Apache pour lui dire de re-chiffrer le flux vers les backends. Elle nécessite bien évidemment d’avoir mod_proxy_http et mod_ssl :

<VirtualHost *:443>

    # Activation de SSL pour le trafic entrant, cas dans le cas d'un
    # serveur web classique.
    SSLEngine On
    SSLCertificateFile    /etc/ssl/certs/example.com.crt
    SSLCACertificateFile  /etc/ssl/certs/example.com-intermediate.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    # Activation de SSL pour la communication avec les backends.
    # On vérifie au passage que le certificat fourni par le backend est
    # bien valide.
    SSLProxyEngine          On
    SSLProxyCheckPeerExpire On
    SSLProxyVerifyDepth     10

    # Configuration classique du mod_proxy, mis à part qu'on spécifie bien
    # https dans l'URL du backend.
    ProxyRequests     Off
    ProxyPreserveHost On
    ProxyPass         / https://192.0.2.42:443/ keepalive=On retry=5
    ProxyPassReverse  / https://192.0.2.42:443/

    ErrorLog  /var/log/apache2/example.com_error.log
    CustomLog /var/log/apache2/example.com_access.log combined
</VirtualHost>

Ajout d'une carte son à chaud dans un conteneur LXC

2014-01-21T21:02:08+00:00

Voici un article express pour rajouter une carte son dans un conteneur LXC, plus un aide-mémoire en fait, car c’est pas le genre de chose que je fais tous les 4 matins.

Brancher la carte son à la machine hôte. Dans mon cas une carte USB, si c’est en PCI, la procédure n’a que peu d’intérêt puisqu’il faudra dans tout les cas redémarrer.
le kernel doit la détecter et créer des fichiers spéciaux de type caractère dans /dev/snd :

```
# ls -l /dev/snd/
total 0
drwxr-xr-x 2 root root       60 Jan 21 19:44 by-id
drwxr-xr-x 2 root root       60 Jan 21 19:44 by-path
crw-rw---T 1 root audio 116,  4 Jan 21 19:44 controlC0
crw-rw---T 1 root audio 116,  3 Jan 21 19:44 pcmC0D0c
crw-rw---T 1 root audio 116,  2 Jan 21 19:44 pcmC0D0p
crw------T 1 root root  116,  1 Dec 17 09:24 seq
crw-rw---T 1 root audio 116, 33 Dec 17 09:24 timer
```

Notez le numéro majeur et mineur de chaque pseudo fichier (dans mon cas 116
et de 1 à 4 et 33).

Ajoutez les autorisations nécessaires dans votre conf LXC pour le conteneur en question :

```
# /dev/snd/*
lxc.cgroup.devices.allow                = c 116:4 rwm
lxc.cgroup.devices.allow                = c 116:3 rwm
lxc.cgroup.devices.allow                = c 116:2 rwm
lxc.cgroup.devices.allow                = c 116:1 rwm
lxc.cgroup.devices.allow                = c 116:33 rwm
```

Adaptez bien sûr avec les bons numéro majeurs et mineurs.

À ce stade, il faut redémarrer le conteneur pour que les nouveaux cgroups s’appliquent. Comme j’avais pas envie de faire ça et que les cgroups cesttropbien, On va appliquer les nouvelles règles à chaud via son pseudo système de fichier :

```
# cat >/sys/fs/cgroup/lxc/<nom du conteneur>/devices.allow
c 116:4 rwm
c 116:3 rwm
c 116:2 rwm
c 116:1 rwm
c 116:33 rwm
^D
```

Maintenant, on peut créer manuellement les pseudo fichiers dans le conteneur :

# mkdir /dev/snd; cd /dev/snd
# mknod controlC0 c 116 4
# mknod pcmC0D0c c 116 3
# mknod pcmC0D0p c 116 2
# mknod seq c 116 1
# mknod timer c 116 33
# chgrp audio controlC0 pcm* timer
# chmod 1660 controlC0 pcm* timer
# chmod 600 seq

Et ajoutez vous dans le groupe audio si besoin.

Installer alsa-utils puis :
```
$ alsactl init
```

Votre carte devrait à présent être détectée, vous pouvez vérifier que tout
fonctionne avec un `speaker-test`.

Et voila.

Bon c’est pas tout ça, allons mettre à jour le kernel et rebooter :-).

Changer simplement la couleur du curseur dans rxvt

2013-11-01T17:53:37+00:00

Où comment identifier facilement le serveur de prod de celui de preprod (ou le master du slave, ou celui de prod et son futur remplaçant…).
Bref, comment différencier facilement votre terminal avec une connexion SSH sur un serveur critique, et celui vers un serveur où vous pouvez tout casser^W^W^W^W^W moins critique.
C’est surtout valable quand les hostnames ne diffèrent que d’une lettre ou d’un chiffre, où la confusion est plus facile.

Si il s’agit d’un serveur perso, le plus simple reste de modifier le prompt de votre shell. Mais ce n’est pas envisageable sur un serveur sur lequel vous vous contentez d’intervenir, ou où plusieurs admin sont susceptibles d’utiliser le compte root.

La solution est d’agir au niveau de votre terminal, ici urxvt. Les options de rxvt peuvent être quasiment toutes changées à chaud grâce à des commandes envoyées dans des séquences d’échappement du shell. Par exemple, pour avoir un curseur rouge, la commande à envoyer est \033]12;red\007. Vous pouvez tester avec un simple echo :

$ echo '\033]12;red\007'

C’est magique, mais ça reste compliquer à écrire, et encore plus à retenir. On va donc affecter la commande à une séquence de touche, par exemple Alt+! (et Alt+Shift+!). Dans votre .Xdefaults/.Xressources :

URxvt.keysym.M-S-exclam: command:\033]12;red\007
URxvt.keysym.M-exclam: command:\033]12;#657b83\007  # #657b83 à remplacer par la couleur de votre police par défaut.

À noter qu’ainsi, même en étant dans un éditeur de texte, vous identifierez rapidement le serveur de prod car le curseur restera rouge, ce qui n’est pas le cas avec un prompt coloré.

L’inconvénient est que le changement de couleur du curseur n’est pas automatique, même si il est bien simplifié. Si vous avez une liste précise de serveurs en prod, une idée peut être, à l’aide d’une extension Perl à rxvt, de comparer le titre de la fenêtre X11 (qui contient le hostname du serveur) à cette liste, pour pouvoir changer la couleur du curseur en conséquence.

Référence :

Article de Ulhume très intéressant et plus complet à propos des styles de curseur, avec une utilisation différente.

Limiter le nombre de connexions SSH avec pf

2013-09-05T22:19:19+00:00

Le port SSH doit probablement être parmi les plus testés par les scripts kiddies. Même si le mieux reste de restreindre l’accès par IP et de n’autoriser l’authentification que par clé, ce n’est des fois pas possible. Dans ce cas, on se retrouve avec une avalanche de tentative de connexion et le auth.log qui explose en taille. Ça devient lourd (dans les 2 sens du terme :-) ).

Afin de bannir une IP au bout d’un trop grand nombre de connexions par unité de temps, il existe différents outils qui analysent les logs et ajoutent des règles dynamiquement comme fail2ban, mais je préfère agir directement au niveau pare-feu quand c’est possible. Avec iptables sous Linux, il existe le module limit. Avec Packet Filter, voici comment procéder :

Créer une table, qui contiendra les IP bannies :
```
table <badguys> persist
```
on drope donc tous ce qui provient des IP présentes dans la table :
```
block in quick on $wan_if from <badguys>
```
et enfin la règle intéressante :
```
pass in on $wan_if proto tcp to self port ssh flags S/SA keep state (max-src-conn 3, max-src-conn-rate 5/30, overload <badguys> flush global)
```
La règle permet de limiter l’établissement d’une connexion sur le port SSH à 3 connexion simultanée (max-src-conn 3) et avec une limite de 5 connexion par tranche de 30 secondes (max-src-conn-rate 5/30). Si une IP dépasse cette limite, elle est ajoutée à la table badguys (overload <badguys>) et tous les états que l’IP aurait déjà pu avoir sont supprimés (flush global).

Ensuite, on peut faire expirer les IP présentes dans la table avec un simple cron :

33 3 * * *  /sbin/pfctl -t badguys -T expire 86400 2>&1 |grep -v "0/0 addresses expired."

Archlinux dans un conteneur LXC et paquet filesystem

2013-06-03T21:04:00+00:00

Parmis mes conteneurs LXC, il y en a un qui tourne sous Archlinux. Comme j’avais un peu joué avec les capabilities (7) du noyau, qu’on peut retirer avec lxc.cap.drop dans le fichier de conf du conteneur, mon /sys/ (entre autre) est en lecture seule pour le système chrooté.
Par jouer il faut comprendre rajouter des lxc.cap.drop sur des capabilities choisies au feeling, jusqu’à ce que ça ne marche plus. J’exagère mais c’était un peu ça l’idée au final :-).

Donc, comme mon /sys/ est en lecture seule, la mise à jour du paquet filesystem chie lamentablement dans la colle :

error: cannot remove file '/sys/': Read-only file system
error: could not commit transaction
error: failed to commit transaction (transaction aborted)

Par flème, lorsque une mise à jour du paquet était disponible, je l’excluais manuellement avec :

# pacman --ignore filesystem -Syu

Puis vint le jour où la mise à jour d’un paquet demandait une version à jour du paquet filesystem. Forcement, ça devait arriver un jour…

Et c’est là qu’en cherchant un peu, j’ai découvert que dans la configuration de pacman, on peut lui dire d’empêcher un paquet de toucher à un fichier. Ça se rapproche un peu du dpkg-divert de Debian.

Dans /etc/pacman.conf :

NoUpgrade    = sys/
NoExtract    = sys/

le répertoire /sys/ sera ignoré, et la mise à jour de filesystem se fait sans soucis !

Pour plus de détails, voir pacman.conf(5).

Viande séchée maison

2013-05-20T15:18:45+00:00

La charcuterie c’est bon ! Le problème c’est que, à part les produits artisanaux (et encore), il y a toujours en prime un tas de cochonneries ajoutées avec.
Je me suis donc lancé dans la fabrication de ma propre viande séchée. C’est relativement simple, plus marrant que de l’acheter à la supérette du coin, et très probablement moins cher au kilo.

Au niveau des ingrédients, il faut :

une belle pièce de viande de bœuf maigre de 1kg à peu près ;
1kg de gros sel, voir plus ;
des herbes et épices selon vos gouts et votre imagination (thym, poivre concassé, cumin, clous de girofle, voir piment, ail…).

Plus beaucoup de patience (environ 1 à 2 mois) et ne pas avoir de gerçures aux mains (nécessaire juste pour la première étape).

Première étape : salage de la viande

Le but du salage est d’accélérer le séchage de la viande. Au fil des jours, elle va rendre une bonne partie de son eau et se racrapoter sur elle même en durcissant.

Prenez la pièce de viande, une poignée de gros sel, et frotter la bien avec sur chacun des coté. La viande ne doit plus sembler humide.
Une fois ceci fait (et après avoir, au passage, foutu du sel dans toute la cuisine), prenez un plat/tupperware/ce-que-vous-avez d’assez grand pour mettre la pièce de bœuf, déposer un fond de gros sel, la pièce de bœuf dessus, et la recouvrir entièrement de gros sel.

Vous pouvez à présent l’oublier 5 jours au réfrigérateur (un peu plus ou un peu moins en fonction du poids et de l’épaisseur de la viande).

Deuxième étape : dessalage

Passé les cinq jours, votre viande baigne dans un mélange d’eau à la couleur douteuse et de gros sel, pas appétissant du tout. Mais c’est normal.

Sortez la et frottez la bien sous l’eau claire pour faire partir tout le sel. Remplissez ensuite un gros récipient dans lequel vous mettrez le morceau de viande à tremper, pendant 12h environ.
Pensez à changer l’eau 2 ou 3 fois, d’abord assez souvent, toutes les 2 ou 3h, puis moins fréquemment ensuite.

Troisième étape : séchage et épiçage

Sortez la pièce de viande du bain et séchez la bien avec des feuilles de papier absorbant. Ne pas hésiter à la presser pour faire partir l’eau, puis laissez la à l’air libre quelques temps.

Pendant ce temps, partez à la recherche d’un torchon propre et sans odeurs (de lessive notamment) de préférence (faites le sécher au grand air par exemple).

Déposer la viande sur le torchon, rassemblez les épices et herbes que vous voulez, et frottez la viande avec, comme pour le sel lors de la première étape. D’abord avec les épices, puis les herbes, et plantez éventuellement quelques clous de girofle dans le morceau.

Vous pouvez à présent l’emballer dans le tissu et la ligoter avec de la ficelle en serrant bien, comme un rôti. Le but est de comprimer le torchon contre la viande pour qu’il absorbe l’humidité.

C’est terminé, vous pouvez aller l’abandonner au moins 1 mois, soit suspendu dans un endroit frai, genre une cave si vous avez la chance d’en avoir une, soit au réfrigérateur, posé sur une grille (pour qu’elle puisse respirer par le dessous).

Sortez la de temps en temps pour la pressez, voir ouvrez le paquet et refermez le d’une autre façon pour répartir l’humidité et les épices.

Quatrième étape : mangeage dégustation

Au bout d’un mois, la viande commence a être assez sèche pour être mangée, mais reste assez molle. Vous pouvez attendre quelques semaines de plus, pour l’avoir plus ferme.

Pour la déguster, coupez des tranches les plus fines possible (1 mm maximum).

Vu qu’il n’y a pas de conservateurs, la viande va continuer de sécher. Si vous voulez la conserver sur plusieurs mois, le mieux est de la congeler ou la mettre dans un sac sous vide, si vous avez les moyens de le faire.

Pour conclure, je suis très satisfait de mon premier essai, sauf pour les épices ; hormis en surface, la viande n’en a pas vraiment pris le goût et l’odeur. Je ne vois pas vraiment de solution mise à part en mettre une plus grande quantité la prochaine fois. Pour la v2, je vais d’ailleurs tenter le dessalage dans du rouge, ou de l’eau de vie style cognac, calva… Ça ne devrait être que meilleur :-).

Je me suis inspiré pas mal de l’article de Rhaaa, avec quelques modifications, notamment un salage un peu plus court, et l’ajout des épices après le dessalage, pour ne pas les perdre dans l’eau.

Tracer un processus sur un système BSD

2013-05-09T21:01:04+00:00

Récemment sur un système OpenBSD, j’ai voulu suivre les appel système que faisait un process :

# strace isakmpd -vd
ksh: strace: not found
# pkg_add strace
Can't find strace

OMG, comment faire ?!

En fait, strace est spécifique à Linux, et un équivalent existe sur les systèmes BSD. Il s’agit du couple ktrace/kdump. En gros, ktrace permet de contrôler l’enregistrement ou non des appels que fait un process, et kdump permet de lire le fichier binaire que son cousin a généré (nommé ktrace.out par défaut).

Petit exemple d’utilisation :

ktrace <PID>

Équivalent de l’option -f de strace (pour tracer également les processus fils) :

ktrace -id <PID d'une processe qui fait plein de petits>

Équivalent de l’option -p de strace (pour tracer un process existant, sans devoir le relancer). Bon là ça ne change pas trop :

ktrace -p <PID d'un process applicatif super critique, lancé depuis une éternité, que plus personne ne sait comment le relancer et que si il crash c'est la fin du monde>

Quand vous avez récupéré suffisamment de traces à lire (ou quand vous vous apercevez que votre ktrace.out a pris 100 % de l’espace libre restant sur la partition), pour arrêter l’enregistrement :

ktrace -C

Maintenant que vous avez votre bon gros fichier binaire avec plein de traces dedans :

kdump |less

Si l’enregistrement des traces est toujours en cours, vous pouvez avoir l’équivalent d’un tail -f :

kdump -l

Pour plus de détail, voir bien sûr les man de ktrace (1) et kdump (1).

Contact

2013-04-01T15:12:41+00:00

You can reach me at the following e-mail address: <romain \_o< @univers-libre.net>
(although ducks are really cool animals, you should remove the duck from the address link to get the real one).

Please follow these simple rules before sending me an e-mail:

only plaintext e-mails, no HTML
no AI-generated messages. I will not read nor respond to your e-mail and I will mark it as spam. I’m not interested in interacting with a dumb chatbot.

You can send me PGP encrypted e-mails. If you wish to do so, my GPG key fingerprint is C59B 9EAF 6CA8 B9AE 0EAC 21D0 876B 9AB4 8BB6 2212 and my GPG public key is available on key servers.

I am not on any social networks. If you find someone there claiming to be me, he/she is most likely not me.

Passer root sans terminal

2012-01-26T00:00:00+00:00

Dans certains rares cas, on peut vouloir exécuter des commandes en tant que root sans avoir la possibilité d’allouer un terminal sur la machine en question.

Pour ceux qui aiment bien lire la fin en premier, je mets la fin au début :-) :

echo "mypassword" |sudo -S id

Pour illustrer le problème, prenons un cas concret qui m’est arrivé.
Un serveur s’est soudainement mis dans un état bizarre, à savoir que tout marchait, les processus déjà en cours continuaient de s’exécuter, d’autres processus pouvaient se créer, mais certaines choses ne marchaient pas, notamment l’allocation de pseudo-terminaux (les /dev/pts/*) ; si je tente une connexion SSH au serveur, le serveur répond bien, l’authentification se fait, et au moment d’avoir mon prompt, la connexion se freeze.
Après divers tests, je m’aperçois qu’en passant directement une commande à ssh, ça marche :

ssh serveur-foireux dmesg

La différence vient du fait que dans le deuxième cas, ssh n’ouvre pas de pseudo-terminal sur le serveur distant, puisqu’il se contente de récupérer directement stderr et stdout.
On peut faire en sorte de se connecter sans allouer de terminal sur le serveur avec l’option -T de la commande ssh :

-T Disable pseudo-tty allocation.

On a ainsi un shell qui s’exécute sur la machine, et on récupère la sortie brute de stderr et stdout (pas de prompt, d’édition de la commande en cours, etc…). Pareil pour stdin, ce qui fait que les commandes sudo ou su retournent une erreur, étant donné qu’elles font une manipulation spécifique sur stdin (pas d’echo pour la saisie du mot de passe). De ce fait, on est un peu coincé pour passer root.

Il existe une solution (que j’ai bien sûr trouvé après avoir brutalement redémarrer le serveur), une simple option à sudo qui permet de lire le mot de passe depuis stdin. Et là, pas besoin d’exécuter la commande dans un terminal donc !

echo "mypassword" |sudo -S id
[sudo] password for rdessort: uid=0(root) gid=0(root) groupes=0(root)

Et comme cela affiche votre mot de passe en clair sur l’écran, voici un petit script pour améliorer la chose :

#!/bin/bash

echo -n "Enter password: "
read -s passwd

ssh serveur-foireux "echo $passwd |sudo -S id"

Une autre application probablement beaucoup plus courante pourrait être de pouvoir scripter des commandes nécessitant d’être root sur le serveur. Notamment exécuter la même commande sur plusieurs dizaines de serveurs d’affilée.

Utiliser AWStats sans CGI

2011-01-09T00:00:00+00:00

AWStats est un générateur de statistiques, le plus souvent utilisé pour générer des stats sur des serveurs web (il peut aussi être utilisé pour des serveurs mail, ftp…). C’est une appli en Perl, qui peut donc être appelé par le serveur web via CGI pour générer les pages HTML.

Sur Apache ou Lighttpd ça marche sans problème, mais sur un serveur web qui ne supporte pas CGI (NginX par exemple, à moins de passer par des hacks assez tordus) ça ne marche plus.

La solution est donc de dire à AWStats de générer les page HTML automatiquement après chaque mise à jour de sa base de données. Voici la procédure :

Créez tout d’abord le répertoire qui contiendra les pages HTML, avec les bons droits :
```
mkdir /var/www/awstats/
chown www-data:www-data /var/www/awstats/
```

Modifiez ensuite le fichier /etc/cron.d/awstats pour appelez le script awstats_buildstaticpages.pl au lieu de awstats.pl :

[ -x /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl \
-a -f /etc/awstats/awstats.yoursite.conf -a -r /var/log/nginx/yoursite.access.log ] \
&& perl /usr/share/doc/awstats/examples/awstats_buildstaticpages.pl -update \
-config=yoursite -dir=/var/www/awstats -awstatsprog=/usr/lib/cgi-bin/awstats.pl >/dev/null

À adapter bien sûr avec les bons noms de fichiers de conf et de log.

N’oubliez pas d’ajouter un alias dans la conf de votre serveur web pour les icônes. Sous NginX, ça donne ça :
```
  location /awstats-icon/ {
      alias /usr/share/awstats/icon/;
  }
```

Utiliser la fonction PHP imagerotate() sous Debian

2010-09-18T00:00:00+00:00

imagerotate est une fonction PHP qui, comme son nom l’indique, permet de tourner une image selon un angle. Cependant elle n’est disponible que si PHP a été compilé avec la version embarqué de la bibliothèque GD.

Sous Debian ce n’est pas le cas, car cette version est difficilement maintenable au niveau sécurité (cf le bug report Debian)

Pour contourner le problème, en cherchant un peu sur le net (ici par exemple), beaucoup de monde recompile PHP avec la version embarqué de GD. Ce n’est à mon avis pas la meilleure solution au niveau “maintenabilité”.

Voici donc 2 autres possibilités.

Utiliser les dépôts dotdeb

Les dépôts dotdeb contiennent des versions plus récentes et/ou modifiés de paquets Debian pour serveurs LAMP. Le paquet php5 présent dans dotdeb est justement compilé avec la version embarqué de la bibliothèque.

Réécrire la fonction imagerotate()

Si vous n’avez besoin que de cette fonction et que vous n’avez pas envi d’utiliser la version embarqué de GD, il est tout à fait envisageable de réécrire la fonction en question :

readImage($temp_src);
      $imagick->rotateImage(new ImagickPixel($bgd_color?$bgd_color:'black'), $angle);
      $imagick->writeImage($temp_dst);
      //trigger_error( 'imagerotate(): could not write to ' . $file1 . ', original image returned', E_USER_WARNING );
      $result = imagecreatefromjpeg($temp_dst);
      unlink($temp_dst);
      unlink($temp_src);
      return $result;
  }
}
?>

trier numériquement la sortie d’un du -h

2010-09-11T00:00:00+00:00

Afficher la taille que prend un répertoire ainsi que ses sous répertoires est une tache assez courante, du moins pour un administrateur système. Cela se fait simplement avec la commande :

du -sh foo/*

Ou bien, si on veut avoir aussi les sous sous répertoires :

du -h --max-depth 2 foo/*

L’option -h permettant d’avoir la taille exprimé en kilo, méga, giga, etc…

Là où les choses se compliquent, c’est lorsqu’on veut trier numériquement le résultat par ordre décroissant. Si on fait un :

du -sh foo/* |sort -rn

le tri sera faussé du fait de la présence des lettres qui suivent la taille.

D’où l’astuce du jour : comment trier numériquement la sortie d’un du tout en ayant la taille exprimé en “human readable” ?

Si vous avez le paquet coreutils en version ≥ 7.5, vous êtes sauvé, sort implémente l’option -h qui répond exactement au problème :

du -sh foo/* |sort -rh

Dans le cas contraire (si vous êtes sur une Debian Lenny par exemple), c’est un peu moins simple.
En cherchant un peu sur le net, il existe un tas d’astuces différentes utilisant perl ou awk. Voici celle que j’utilise, qui me semble la moins tordue (mais un peu quand même) :

du -s foo/* |sort -rn |cut -f2 |xargs -d '\n' du -sh

Le principe est d’obtenir d’abord la liste des répertoires avec leur taille “brute”, de trier cette liste, puis de refaire un du (avec -h cette fois) sur chaque répertoire de la liste).
Le fait d’exécuter 2 fois un du n’est pas super élégant point de performance, mais en pratique, comme le résultat du premier du est caché en mémoire, le second est très rapide.

Gérer efficacement et rapidement ses todos avec devtodo

2010-09-10T00:00:00+00:00

Pour changer un peu de l’administration système, je vais vous présenter aujourd’hui… devtodo.

devtodo est un petit (mais puissant) utilitaire qui s’utilise en ligne de commande et qui va vous permettre de gérer votre (ou vos) todo list. Avant de vous le présenter, sachez qu’il m’a fallu pas mal de temps avant de trouver un todo list manager qui me convienne. Mon premier critère de sélection était une application en ligne de commande (éventuellement avec une interface ncurses). L’utilisation d’une interface graphique pour ce genre de tâche n’est vraiment pas adapté, je perdais trop de temps à clicouiller par-ci par-là pour saisir 3 mots que, finalement, je ne tenais plus à jour ma todo list et elle partait aux oubliettes.

À partir de là j’ai testé différents utilitaires (doneyet, task, devtodo, w2do, todo.txt, et j’en passe). Mais seuls 2 répondaient à mon second critère : savoir gérer les sous taches : doneyet et devtodo. doneyet est une interface semi-graphique utilisant ncurses, mais ne me paraissait pas assez ergonomique (sans compter un segfault à chaque caractère UTF-8 de tapé, que je n’ai pas vraiment cherché à résoudre). J’ai donc choisi devtodo.

Présentation rapide des fonctionnalités de devtodo

gestion des taches sur plusieurs niveaux ;
gestion de 5 niveaux de priorité ;
stockage de la todo list dans un fichier xml, très facile à exploiter par la suite (une fonction d’export est quand même bien sûr prévue) ;
gestion d’une todo list par répertoire (très pratique pour gérer plusieurs projets à la fois). Exemple : vous allez dans le répertoire mon-projet/, vous visualisez la todo list de ce projet :
```
cd mon-projet
todo
# affichage des todos de "mon-projet"
```
Vous voulez tout d’un coup travailler sur un autre projet :
```
cd ../autre-projet
todo
# affichage des todo de "autre-projet"
```
En fait, par défaut, devtodo lira le fichier xml .todo présent dans le répertoire courant, d’où ce fonctionnement. On peut bien sur forcer l’utilisation d’une todolist différente avec l’option -G ;
filtrage et tri avancé de l’affichage des todos (suivant des critères comme terminé, priorité, date de création…) ;
possibilité de redéfinir entièrement le formatage et la coloration de l’affichage de la todo list (en accédant au variables via %p, %d, etc…) ;
je pense que ce sera tout, tout ça prenant un peu moins de 300Ko installé !

Utilisation basique

Voici comment utiliser devtodo de manière “simple” :

Ajout d’un todo avec une priorité faible (la plus haute est 1) :
```
tda -p 4 un premier todo
```
Voir sa liste de todo :
```
todo
```
Ajout d’une sous tache à la précédente :
```
tda -g 1 une sous tache du premier todo
```
Marquer la sous tache comme faite :
```
tdd 1.1
```
Édition d’une tache :
```
tde 1
```

Bref, je vous laisse lire le man pour plus de détails (qui est d’ailleurs très clair, contrairement au site du projet).

Utilisation avancée

Filtrage

devtodo permet de filtrer l’affichage des todos suivant plusieurs critères. Quelques exemples pratiques :

N’afficher que les todos finissant par la chaîne toto (on commence simple) :
```
todo -f "/toto$"
```
Afficher les todos non fait et avec une priorité supérieure ou égale à high :
```
todo -f "-done,+high"
```
Afficher les todos contenant foo ou Foo, en recherchant aussi dans les sous tâches :
```
todo -f "/[fF]oo,+children"
```

En bonus, vous pouvez définir un filtre par défaut, qui s’appliquera lorsque vous taperez simplement la commande todo. Cela ce fait dans le fichier .todorc :

filter -done,children

Tri

De la même manière que vous pouvez filtrer la sortie, vous pouvez aussi la trier. Le principe est un peu le même que pour les filtres :

Trier par date de création :
```
todo --sort created
```
Trier d’abord par priorité, puis par ordre alphabétique :
```
todo --sort priority,text
```

Le tri à appliquer par défaut est définit par la directive sort dans le fichier de conf.

Formatage

Le formatage de la sortie de todo ne vous convient pas ? eh bien vous pouvez la réécrire complètement. Avant tout sachez aussi que vous pouvez utiliser l’option -v pour un affichage plus complet.

La définition des formats se passent (de préférence) dans le fichier de conf. Vous retrouvez les formats par défaut qui y sont décrits, puis vous pouvez écrire les votre en dessous, en utilisant la forme :

format nomDuFormat=templateString

templateString est la chaîne qui affichera le todo. Vous pouvez donc insérer des variables sur le même principe que la fonction C printf(). Un petit exemple :

format display=%4>%i%[info]%f%2n.%[priority]%+1T

Pour avoir plus d’information sur l’écriture de la chaîne (notamment la liste des variables),… cf. le man.

Après avoir écrit votre nouveau format, 2 solutions : soit il déchire tout et vous voulez l’utiliser à la place de celui par défaut, soit il déchire aussi mais vous voulez l’utilisez que dans certains cas plus spécifiques. Dans le premier cas, rajoutez la ligne suivante dans votre conf :

use-format display=nomDuFormat

Remplacez display par verbose-display si le format doit être utilisé dans le cas de l’utilisation de l’option -v. Dans le second cas, vous pouvez bien sur spécifier le thème dans les options de la ligne de commande directement, via –use-format, en utilisant la même syntaxe que ci-dessus.

Je pense avoir fait un tour global sur cet outil vraiment sympa, cependant il reste encore quelques astuces dont je n’ai pas parlé, mais bien décrite dans le man.

Hard reboot à distance

2010-08-09T00:00:00+00:00

Voici une astuce bien utile si votre serveur est complètement planté. Il faut néanmoins pouvoir se connecter en SSH sur la machine et avoir un shell en root.

Dans mon cas, il s’agissait d’un problème d’accès disque, la plupart des commandes exécutées renvoyaient des erreurs d’entrée/sortie, y compris la commande reboot, qui a besoin d’exécuter les scripts d’init de niveau 6.

Mais tout n’est pas perdu, si vous n’avez pas d’accès physique à la machine ! On va passer par le pseudo système de fichier /proc pour parler directement au noyau et lui dire de redémarrer la machine. Avant tout (et si il ne s’agit pas d’un problème disque), on tente de forcer la synchronisation du cache vers le disque :

sync

On active ensuite les magic sysrq key si elles ne le sont pas déjà :

echo 1 > /proc/sys/kernel/sysrq

Puis on modifie l’état de la machine :

echo b > /proc/sysrq-trigger

Cette dernière action a exactement le même effet que la combinaison Alt + Syst + b.

Après cela, priez pour que la machine redémarre correctement :-).

Compter le nombre de connections par IP

2010-06-18T00:00:00+00:00

Aujourd’hui au boulot, j’ai été confronté à un petit problème : sur un serveur victime d’une attaque DDoS (visiblement), je voulais savoir quelles IP ouvraient le plus de connections. Ne trouvant rien de bien intéressant dans les commandes Unix, j’ai écris un petit script en Perl.

Il se charge de récupérer la sortie de netstat (la commande est à adapter à votre besoin) et compte le nombre de lignes identiques (donc d’IP), qu’il se charge ensuite de trier par ordre décroissant et d’afficher.

Voici le script en question :

#!/usr/bin/perl

use strict;
use warnings;

my %addrs = ();
my @netstatOut = split( /\n/, `netstat -taupen | grep SYN | tr -s " " | cut -d" " -f 5 | cut -d: -f1` );
for (@netstatOut) {

    chomp $_;
    $addrs{$_} += 1;
}

for my $key ( sort {$addrs{$b} <=> $addrs{$a}} keys %addrs ) {
    print $addrs{$key}."\t$key\n";
}

Le script retourne alors son résultat sous la forme :

nbConnection    IP1
nbConnection    IP2
...

Il ne vous reste plus qu’à blacklister les IP les plus actives avec la commande

iptables -I INPUT -s IP -j DROP

Connexion ssh derrière un proxy

2009-11-17T00:00:00+00:00

Peut-être avez vous déjà rencontré ce problème, il n’est pas possible de se connecter en SSH sur un serveur lorsqu’on se trouve derrière un proxy.

Je m’en suis aperçu quelques jours après le début des cours à l’IUT de Nancy lorsque j’ai voulu créer un tunnel SSH (on verra comment par la suite) pour pouvoir accéder à mes mails, les messageries instantanées, etc… Le réseau de l’université se trouve en effet derrière un proxy qui bloque tout et n’importe quoi (en fait seul les ports http et https sont autorisés).
Souvenir du réseau wifi de l’IUT de Marseille où on pouvait télécharger en P2P les ~~films~~ ISO Linux en quelques minutes… :(.

Pour résoudre le problème (du ssh, pas du P2P), il y a deux choses à faire.

Coté serveur

Bien entendu, comme le proxy bloque tout sauf http et https, il n’y a pas de miracles, il faut faire écouter le serveur SSH sur le port https (les transfert sont chiffrés pour https et SSH, le proxy ne peut pas voir la différence). Pour ça, modifiez votre /etc/ssh/sshd_config pour changer la valeur de Port :

Port 443

Redémarrez OpenSSH et assurez vous de changer les ports également dans votre pare feu et votre routeur.

Coté client

À priori, on peut croire que le problème est maintenant résolu, le serveur écoute sur le port https, le proxy laisse passer les données sur le port https, et le client indique de ce connecter par le port https. Et bien non, ce n’est pas aussi simple, et je n’ai eu la réponse qu’aujourd’hui, pendant un cours sur les serveurs web.

En fait, le fait de passer par un proxy interdit de faire une connection direct entre le client et le serveur (un proxy étant fait pour s’intercaler entre les échanges). Il faut donc dire explicitement au proxy d’établir une connection direct entre les deux machines, et de ne plus s’en mêler ensuite. C’est grâce à la commande HTTP CONNECT que c’est possible (vous voyez mieux le rapport avec les serveurs web à présent ;) ).

Pour réaliser ça en pratique, on va utiliser corkscrew. Installez le puis modifiez votre fichier client /etc/ssh/ssh_config comme ceci :

Host univers-libre.net-proxy
        Hostname univers-libre.net
        Port 443
        ProxyCommand /usr/bin/corkscrew vivianen.iuta.univ-nancy2.fr 3128 %h %p

Host univers-libre.net
        Port 443

Explications :
on a définit 2 configurations (host, dans le fichier) : une dans le cas normal (univers-libre.net) et une autre avec un proxy (univers-libre.net-proxy).
Ainsi, si vous êtes derrière le proxy, vous devrez taper :

ssh univers-libre.net-proxy

Dans le cas contraire :

ssh univers-libre.net

Dans la configuration avec proxy, on indique que, en fait le vrai nom n’est pas univers-libre.net-proxy mais univers-libre.net (avec la directive hostname). Le port est bien sûr fixé à 443 (https) dans les 2 cas.
Viens la ligne ProxyCommand : on dit à OpenSSH de faire appel à corkscrew en lui passant en paramètre l’adresse du proxy (ici vivianen.iuta.univ-nancy2.fr), le port du proxy (3128 qui est le port par défaut des proxies). %h et %p indiquent respectivement l’hôte à atteindre et son port (univers-libre.net et 443).

Maintenant que vous avez un accès SSH sur votre serveur à vous la liberté :) . Vous pouvez alors créer un tunnel SSH pour certaines applications, en rajoutant une ligne de ce type dans le fichier /etc/ssh/ssh_config de votre client :

LocalForward 143 localhost:143

Dans cet exemple je dis de rediriger toutes les demandes de connections qui sont envoyées sur le port 143 (imap), vers le même port et sur le même serveur que le serveur SSH (localhost). Ainsi mon client mail pourra accéder à mon serveur imap, le tout de façon transparente, mais crypté dans le tunnel :-).

Passer une partition de ext2 à ext3 sans la reformater

2009-01-19T00:00:00+00:00

Même si plus beaucoup de monde utilise encore le système de fichier ext2, il se peut qu’il vous reste de vielles partitions ext2 qui traine dans un coin de votre disque dur.

Si c’est votre cas, et que vous avez toujours eu la flemme de sauvegarder les données de la partition, la formater, puis restaurer les données, voici la commande magique, à appliquer tel quel, sans sauvegarde des données :

tune2fs -j votre_partition

Petite explication (et la commande semblera moins magique :-) ) :
Il faut savoir que la différence entre ext2 et ext3 vient uniquement du fait que ext3 est journalisé, c’est à dire (en gros) que toutes les écritures réalisées sur le disque (appelées transactions) sont inscrites (journalisées) dans un journal stocké sur la partition. Cela permet, si un crash du disque survient (coupure de courant, freeze, …), de garder une cohérence dans les données écrites sur le disque (en analysant uniquement le journal, pas besoin d’aller scanner tout le disque).
Pour revenir à notre commande, celle ci ne fait que créer ce fameux journal sur la partition, rien de plus. Au prochain montage de la partition, celle ci sera monté en tant qu’ext3.