dotfiles, git et rcm

Dans un billet récent sur le thème des dotfiles, j’évoquais ma migration prochaine de stow vers rcm comme programme de gestion de mes fichiers de configuration. C’est désormais chose faite et j’utilise à présent rcm à la place de stow.

Parmi les améliorations notables apportées par rcm, la principale est la possibilité de déployer l’ensemble de mes dotfiles en une commande, et non plus en exécutant une commande stow par dossier, ou programme. Je l’avais évoqué, l’organisation de mon dépôt git a également gagné en clarté, la seule différence étant l’absence de point devant les fichiers ou dossiers à la racine du dépôt.

La migration d’un système vers l’autre s’est déroulé sans grande difficulté. Comme souvent, la première étape consiste à installer le programme. Pour une fois, celui-ci n’est pas disponible par défaut dans les paquets d’Arch Linux. Je passe donc par yaourt pour récupérer le paquet dans le dépôt AUR.

yaourt -S rcm

L’installation du paquet rcm mets à disposition quatre utilitaires: rcup, rcdn, mkrc et lsrc. Je ne rentre pas dans les détails de chacun des programmes; le programme principal à utiliser est rcup, programme responsable de l’installation et de la mise à jour des dotfiles. Avant d’exécuter la commande de déploiement, j’ai commencé par changer la structure de mon dépôt git dans une branche dédiée. Une fois la structure satisfaisante, j’ai fusionné l’ensemble dans la branche master. Avant d’effectuer la fusion, il faut s’assurer de garder un terminal ouvert, car en ouvrir un avant d’avoir effectuer le redéploiement va conduire à l’ouverture d’un terminal non configuré, dans mon cas, ouverture sur l’interface de première configuration de oh my zsh.

Revenons à nos dotfiles. Après fusion de mes branches, tous mes fichiers dotfiles existants sont désormais des liens cassés vers l’ancien emplacement des fichiers. Il est donc plus que temps de rétablir les liens pour coller à la nouvelle structure du dépôt. Pour cela, j’utilise donc rcup avec les paramètres :

x pour exclure un fichier
d pour spécifier l’emplacement du dossier dotfiles
f pour forcer l’installation (supprime le fichier existant et le remplace par un lien vers le fichier dans notre dossier dotfiles).

Ce qui donne donc quelque chose comme cela :

rcup -x README.md -x LICENSE -d /chemin/vers/dossier/dotfiles -f

J’ai eu quelques erreurs à l’exécution, étant donné que stow avait mis en place des liens symboliques directement sur certains répertoires. Les répertoires ayant changé d’emplacement, rcup n’arrive pas à y accéder pour créer le lien symbolique du fichier de configuration dans le dossier.

mkdir: ~/.config/terminator: Input/output error
ln: ~/.config/terminator/config: No such file or directory
mkdir: ~/.zsh: Input/output error
ln: ~/.zsh/keychain.zsh: No such file or directory
mkdir: ~/.zsh: Input/output error
ln: ~/.zsh/security.zsh: No such file or directory

Pour corriger ces erreurs, j’utilise donc unlink pour supprimer les liens symboliques existants et j’exécute une nouvelle fois mon déploiement via rcup.

unlink ~/.config/terminator

Au final, la migration de stow vers rcm m’aura demandé une petite heure environ et n’aura pas présenté de difficulté particulière. Compter également plusieurs dizaines de minutes, quelques heures peut-être, réparties sur plusieurs jours afin de me documenter, de comprendre le fonctionnement des outils et d’arrêter ma décision. La nouvelle structure de mon dépôt dotfiles me convient davantage et je trouve le fonctionnement de rcm plus simple dans son utilisation basique, mais proposant néanmoins des fonctionnalités avancées qu’il me faudra étudier pour éventuellement décider d’en faire usage. Ma préférence va donc à rcm et l’avenir nous dira si mon choix était pertinent. Enfin, il serait malvenu de tirer un trait définitif sur stow, qui doit rester un outil à ma disposition, si un cas d’utilisation adéquat se présente.

dotfiles, git et GNU stow

En septembre 2016, j’avais commencé à écrire l’introduction de cet article. J’expliquais donc que je venais de réinstaller le système d’exploitation de mon ordinateur portable, pour passer de Debian 8 à Arch Linux. À ce moment-là, c’était donc posé la question de la synchronisation de la configuration de l’environnement entre machines. Par configuration de l’environnement, je désigne ici les fichiers de configuration des différents logiciels que j’utilise, plus généralement appelés « dotfiles », car commençant par un point, ou étant stocké dans le dossier .config du répertoire utilisateur.

Pour gérer mes configurations entre machines, j’ai donc utilisé le duo Git et GNU stow depuis lors. Git bien sûr pour la synchronisation entre machines et l’historisation, et GNU stow, pour le déploiement des fichiers à leur emplacement dédié.

Fonctionnement

Par défaut, stow créé un lien symbolique dans le répertoire parent de celui à partir duquel on exécute la commande, pour tous les fichiers concernés par la commande. Ma configuration part du principe que mon dépôt git dotfiles est stocké à la racine de mon répertoire utilisateur, à savoir donc ~/dotfiles, et que toutes les commandes stow sont exécutées depuis ce dossier. L’installation de la configuration s’effectue alors en appelant la commande stow avec pour paramètre le nom du logiciel dont on souhaite déployer la configuration. Au niveau de la structure, mon dépôt git se présente donc sous la forme d’une liste de répertoire contenant chacun le chemin vers la configuration du logiciel concerné, c’est-à-dire :

soit directement le fichier si celui-ci est stocké directement à la racine du répertoire utilisateur: c’est le cas par exemple du fichier .gitconfig.
soit dans une arborescence de répertoire correspondant à son emplacement: par exemple pour i3, la configuration est stockée dans ~/.config/i3, j’ai donc dans mon dépôt un dossier i3 contenant l’arborescence .config/i3.

Voici un extrait de mon dépôt en image pour expliciter la situation.

Ainsi, pour déployer le fichier de configuration de Git, j’exécute la commande suivante, depuis mon dossier dotfiles:

stow git

Ce qui aura pour effet de créer un lien symbolique .gitconfig vers le fichier .gitconfig de mon dépôt git. Si on souhaite modifier le répertoire de destination, on peut utiliser l’option -t. Dans l’image ci-dessus, pour déployer la configuration ansible, j’utiliserai alors:

stow -t / ansible

A noter que stow effectue la création du lien symbolique à la condition que le fichier n’existe pas. Si un fichier de configuration par défaut existe déjà, il sera nécessaire de le supprimer d’abord avant de pouvoir procéder à l’exécution de la commande stow.

Dernier point, si je souhaite re-déployer la configuration git, j’utiliserai alors l’option -R, soit la commande :

stow -R git

Conclusion

Le duo git + GNU stow est plutôt efficace pour ce qui est de la gestion des fichiers de configuration, les fameux fichiers dotfiles, et pour la synchronisation entre machines. Je m’en étais également servi pour stocker et déployer facilement certains fichiers de configuration sur mes serveurs, avant de commencer à automatiser avec ansible. Si je rédige aujourd’hui, cet article sur le sujet, c’est pour garder une trace d’une méthode robuste qui m’a été utile pendant plus de deux ans. Néanmoins, la structure actuelle du dépôt git ne me convient plus autant qu’avant et je souhaiterais passer à une organisation plus proche, ou même identique à l’arborescence présente sur le disque. J’étudie donc les autres solutions de gestion des dotfiles, et m’intéresse en particulier à rcm; mais ceci est une autre histoire, pour un autre article.

Proxy

Lorsqu’on travaille derrière un proxy, on se retrouve vite à devoir configurer nos outils pour être certain que leur trafic passera bien par celui-ci. Voici donc quelques paramètres de configuration pour répondre à ce problème.

GNU/Linux

Les variables d’environnement qui nous intéresse sont les suivantes:

http_proxy
https_proxy
ftp_proxy
no_proxy

On peut également les retrouver en majuscule: HTTP_PROXY par exemple.

La configuration s’effectue de la manière suivante dans un terminal:

export http_proxy=http://yourproxyaddress:proxyport
export no_proxy='127.0.0.1, *.local'

Pour visualiser le contenu d’une variable:

echo $http_proxy

GNOME

gsettings set org.gnome.system.proxy ignore-hosts "['127.0.0.1','*.local' ]"

APT-GET/APTITUDE

Si aptitude n’utilise pas le proxy défini au niveau système pour une raison ou une autre, on peut modifier le fichier /etc/apt/apt.conf pour y ajouter la ligne suivante:

Acquire::http::Proxy "http://yourproxyaddress:proxyport";

GIT

git config --global http.proxy http://yourproxyadress:port
git config --global https.proxy http://yourproxyaddress:port

Si le proxy bloque le protocole git://, on force l’utilisation de http:// :

git config --global url."http://".insteadOf git://

Et en cas de problème avec le protocole https://, on peut envisager :

git config --global http.sslVerify false

WINDOWS

NPM

Dans le fichier .npmrc, ajouter les lignes:

proxy=http://yourproxyadress:port
strict-ssl = false

BOWER

Dans le fichier .bowerrc, ajouter les lignes:

{
  "proxy":"http://yourproxyadress:port",
  "https-proxy":"http://yourproxyadress:port"
}

Magical Graphite

Or, « What I’ve learned about Graphite configuration ».

Last week, I worked on configuring Graphite and had to understand how it stores and aggregates data. So here are a few facts.

Graphite Retention

The way our data will be stored is described in /opt/graphite/conf/storage-schemas.conf. As an example:

[default]
 pattern = .*
 retentions = 1s:30m,1m:1d,5m:2y

This worked great when I was looking at data from the last 30 minutes.
If I was trying to display last hour metrics: nothing.
Drawing null as zero was giving me a horizontal line at the bottom of the graph.

The magic of aggregation

This behaviour comes from the file /opt/graphite/conf/storage-aggregation.conf where we find the following lines:

[99_default_avg]
 pattern = .*
 xFilesFactor = 0.5
 aggregationMethod = average

Our problem comes from xFilesFactor. It means that by default, we need at least 50% of the data to be non-null to store an average value. Think about it.

So here, I’m having a metric every second during 30 minutes. If Graphite doesn’t have something for a given second, the value is set to null. Fine, let’s move forward.
For interval higher than 30 minutes (and lower than a day), Graphite will gather data based on the aggregation configured. So it will average data and set the value null if it has less than 50% usable values (not null).

In our case, Graphite tries to average one minute of data (1m:1d) with the precision of 1s from the first retention rule (1s:30m). To understand why nothing is displayed, consider I’m Collectd is sending data to Graphite. On average, metrics are arriving every 3s. On a one minute interval, we gather 20 values but Graphite is considering 60 values, 40 being null. We only have 33% (0.33) metrics usable which is lower than 50% Graphite is waiting for so the averaged value is set to null.

The art of confusion

Now that we updated our configuration, set xFilesFactor to 0 to be sure, restart carbon-cache, everything should work fine…

But that’s not the case; no change.

In fact, previous configuration is still being used in wsp storage files. We can check it with whisper-info.py.

whisper-info.py /opt/graphite/storage/whisper/collectd/test-java01/cpu-0/cpu-user.wsp
 
 maxRetention: 63072000
 xFilesFactor: 0.5
 aggregationMethod: average
 fileSize: 2561812

Archive 0
 retention: 1800
 secondsPerPoint: 1
 points: 1800
 size: 21600
 offset: 52
Archive 1
 retention: 86400
 secondsPerPoint: 60
 points: 1440
 size: 17280
 offset: 21652
Archive 2
 retention: 63072000
 secondsPerPoint: 300
 points: 210240
 size: 2522880
 offset: 38932

See, we still have xFilesFactor: 0.5.
If you don’t care about previous data, a good solution is to delete files so that the new parameters will be used (rm -rf /opt/graphite/storage/whisper/collectd/). Maybe it’s a little bit overkill, (but easy and fast).

The other solution consists in using whisper-resize.py to enforce the new configuration.
whisper-resize.py /opt/graphite/storage/whisper/collectd/test-java01/cpu-0/cpu-user.wsp 3s:30m,1m:1d,5m:2y –xFilesFactor=0.1

The above works fine, but this is the other way to configure how many metrics Graphite can keep. It has the format n:i, which means we store a measure every n seconds and we want i points to be stored (computed with interval / n).

Example: 3s:30m
30m = 1800s
1800 / 3 = 600

3:600

So 3s:30m,1m:1d,5m:2y gives us 3:600 60:1440 300:210380.

« An average Gregorian year is 365.2425 days = 52.1775 weeks = 8765.82 hours = 525949.2 minutes = 31556952 seconds (mean solar, not SI). » Wikipedia

Note

Thing to remember concerning storage-schemas.conf (taken from Graphite doc):

« Changing this file will not affect already-created .wsp files. Use whisper-resize.py to change those. »

[ArchLinux] Configurer le réseau

Directement tirées du wiki officiel, voici les commandes qui me sont très utiles pour configurer le réseau.

Filaire:

sudo ifconfig eth0 up
sudo ifconfig eth0 netmask 255.255.255.0 broadcast 192.168.255.255 192.168.102.1
sudo route add default gw 192.168.102.254

Wifi:

wifi-menu

NetworkManager:

sudo systemctl enable NetworkManager

Permet de lancer NetworkManager pour qu’il soit présent après le login.