24 déc. 2017

Merci et bonnes fêtes de fin d'année !

Aujourd'hui, rien de particulièrement technique : je voulais juste profiter de ce dernier billet blogmas 2017 pour te souhaiter, chère lectrice ou cher lecteur, une excellente fin d'année. Peu importe que tu la fêtes ou non, et peu importe ce que tu fêtes, je te souhaite d'agréables moments.

C'est aussi la fin de l'année pour ce blog, et probablement l'un des derniers billets sinon le dernier de 2017. J'espère avoir pu rendre service, fait découvrir une chose ou deux à au moins une personne grâce à mes billets. J'en profite pour remercier toutes celles et ceux qui ont lu un ou plusieurs articles, voir même commenté au bas d'entre eux ou sur les réseau sociaux ! J'ai énormément apprécié vos contributions !

Rendez-vous en 2018 !

Crédit photo : Pete - Project 366 #188: 060712 Party Time...Again!.

23 déc. 2017

On the road again !

Mountain roadAujourd'hui, je suis sur la route des vacances de fin d'année, et n'ai pas eu le temps d'écrire un billet technique. Il me manque d'ailleurs encore deux billets pour ce blogmas, je n'aurai malheureusement pas le temps d'ici demain de les écrire.

Sans préciser particulièrement d'où je pars et où je vais, il y a environ 6h30 de route, sans compter les pauses. Je ne fais pas souvent des journées de route comme ça mais étrangement je les apprécie.

Bonne journée !

Crédit photo : Wall Boat - Mountain road.

22 déc. 2017

NetBSD : haute disponibilité avec CARP

Turner Twins, acrobats, 1937 / by Sam HoodNetBSD dispose depuis la version 4.0 d'une implémentation du protocole CARP. Il s'agit d'un protocole, à l'origine prévu pour les routeurs, permettant à un groupe de machines de disposer d'une adresse IP flottante. Si la machine principale venait à être indisponible, une machine secondaire peut alors prendre le relai. CARP permet donc de mettre en place de la haute disponibilité.

Je me suis amusé à mettre en place une configuration CARP sur les deux serveurs DNS de mon LAN. Pourquoi ? J'ai remarqué que bien souvent, selon les OS, quand on spécifie deux serveurs DNS dans les paramètres réseau, même si la redondance est là, on peut sentir un ralentissement :

  • le client va faire du round-robin et donc régulièrement des requêtes vont échouer ;
  • le client va d'abord s'adresser au premier serveur DNS de sa liste, et si celui-ci est indisponible, il attendra un timeout avant de passer au suivant.

Il y a probablement d'autres moyens d'adresser ces problèmes, mais cela m'a fourni une excuse de jouer avec CARP, c'est le plus important :)

CARP se présente en fait sous forme d'une carte réseau fictive dont le pilote est disponible dans le noyau. Quand je dis disponible, c'est qu'en théorie l'option est compilée dans le noyau GENERIC, mais cela n'est pas forcément le cas sur toutes les plateformes. Ainsi, j'ai dû recompiler un noyau contenant pseudo-device carp.

Une fois que CARP est bien disponible, il suffit tout simplement de créer une nouvelle interface réseau sur chaque machine. La machine principale aura un poids plus fort que la machine secondaire, et portera l'adresse IP flottante en temps normal.

Sur la machine principale :

# ifconfig carp0 create
# ifconfig carp0 vhid 101 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

Sur la machine secondaire :

# ifconfig carp0 create
# ifconfig carp0 vhid 100 pass motdepassehalakon 10.13.37.42 netmask 255.255.255.0

On peut alors vérifier que l'adresse IP flottante est joignable. A noter la présence d'un mot de passe permettant de limiter les cas de "vol d'IP flottante", ici positionné à "motdepassehalakon"

Pour que cela tienne au redémarrage, il faut bien entendu que la configuration soit enregistrée quelque part. En fait, en terme de configuration, il s'agit tout simplement de la configuration de la carte réseau carp0, ici sur la machine principale :

$ cat /etc/ifconfig.carp0
create
up
vhid 101 pass motdepassehalakon 10.13.37.42 255.255.255.0

Ensuite sur la machine secondaire :

$ cat /etc/ifconfig.carp0
create
up
vhid 100 pass motdepassehalakon 10.13.37.42 255.255.255.0

Maintenant, il ne reste plus qu'à tester... en débranchant la prise !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : State Library of New South Wales - Turner Twins, acrobats, 1937 / by Sam Hood.

21 déc. 2017

rsnpashot, le robot de sauvegarde

Suite au commentaire de Xate dans un récent billet, aujourd'hui un billet sur rsnapshot, un logiciel de sauvegarde incrémentale basé sur rsync. Si j'en fais un billet, c'est tout simplement car c'est ce que j'ai mis en place pour sauvegarder mon infrastructure.

J'avoue ne pas trop savoir quoi raconter sur ce logiciel, car de nombreuses documentations existent déjà, quasiment pour chaque distribution :

Je vais donc parler de quelques points de ma configuration en particulier. La première particularité de celle-ci est que j'ai choisi d'installer rsnapshot sur une machine (en fait une jail FreeBSD sur mon NAS FreeNAS) et de l'utiliser en mode "robot de sauvegarde", c'est-à-dire qu'il va se connecter sur toutes les machines à sauvegarder via SSH pour effectuer les sauvegardes. J'y vois l'avantage que je n'ai qu'une seule configuration à modifier, et un utilisateur à configurer sur mes serveurs (accompagné, bien entendu, de sa configuration sudo et de la clé SSH).

Par exemple, pour la sauvegarde du Raspberry Pi qui fait des bulk builds :

backup rsnapshot@netpi2:/etc/                                          netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/usr/pkg/etc/                                  netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/var/log/                                      netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'
backup rsnapshot@netpi2:/srv/sandbox/pkgsrc-current/usr/pbulk/etc/     netpi2/         +rsync_long_args=--rsync-path='/usr/pkg/bin/sudo /usr/pkg/bin/rsync'

On peut aussi noter que j'ai choisi d'ajouter des options à rsync selon mes machines, car celles-ci peuvent être de différents OS, ce qui fait que rsync et sudo ne se trouvent pas toujours au même endroit.

Du côté de la rétention et des intervalles de sauvegarde, j'ai fait très simple :

  • une sauvegarde par jour (daily);
  • 370 jours de rétention.

370 jours peut sembler un peu abusé, mais la force de rsnapshot est dans son utilisation des liens (hardlinks) combinée à celle de rsync, qui rend les sauvegardes rapides, mais aussi moins consommatrices en espace disque car dédupliquées. Par exemple pour le serveur web de ce blog :

# du -csh daily.0/vhost2/ daily.1/vhost2/                                                                                                                                                                       
 17G    daily.0/vhost2/
2.3G    daily.1/vhost2/
 19G    total

La restauration se fait très simplement aussi, puisqu'il s'agit de fichiers tout ce qu'il y a de plus classiques, ou de liens.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Ritva Pirinen - Spare Parts.

20 déc. 2017

5 fichiers texte à placer à sur son site web !

En regardant dans mes statistiques de visites pour un autre billet, j'ai remarqué que j'avais des tentatives d'accès sur un fichier /.well-known/dnt-policy.txt. Je me suis donc renseigné sur ce fichier, et de fil en aiguille, j'ai lu sur d'autres fichiers textes plus ou moins standard placés à la racine d'un site.

dnt-policy.txt

Commençons donc par ce fichier dnt-policy.txt. Le premier résultat en cherchant sur un moteur de recherche m'amène à une page du site de l'EFF. A quoi sert ce fichier ? Il sert à annoncer la politique du site Internet visité concernant l'en-tête Do Not Track.

A la lecture de tout cela, je vois que c'est quand même assez compliqué, je ne pense pas mettre en place de fichier sur mon blog dans l'immédiat.

robots.txt

Le grand classique, robots.txt permet de signaler aux moteurs de recherche quel contenu de son site indexer, et quel contenu ne pas indexer. Malgré tout, certains robots ou moteurs de recherche ne respectent pas les directives de ce fichier, puisqu'il n'y a aucune obligation.

Pour aller plus loin :

Bien entendu, mon blog dispose d'un tel fichier.

humans.txt

Dans la logique du précédent fichier, certains se sont dit : et pourquoi pas proposer un fichier à destination des "humains" et qui contient des informations sur les différentes personnes qui ont contribué à la construction du site ? Ainsi est né le fichier humans.txt ! On peut se renseigner sur cette initiative sur humanstxt.org

Je viens de mettre en place un tel fichier, mais je n'ai pas ajouté de lien vers celui-ci dans mes balise meta. J'espère que pour le moment, cela convient.

security.txt

Toujours dans l'esprit d'informations faciles à obtenir, security.txt a pour principe d'indiquer qui contacter en cas de problème de sécurité avec le site visité. Ce fichier est en particulier utile aux chercheurs en sécurité des systèmes d'information qui souhaitent informer de manière responsable l'équipe du site de la présence d'une vulnérabilité.

Le fichier est assez simple dans son implémentation, on y indique généralement une adresse e-mail ainsi qu'une URL vers une éventuelle clé GPG pour s'assurer de la confidentialité des échanges. Plus d'informations sont disponibles sur le site dédié.

J'ai profité de l'écriture de ce billet pour en mettre un ! J'espère que celui-ci est correct.

hackers.txt

Ce dernier fichier est un peu plus particulier. Kiffie Liversage a remarqué que sur le site humanstxt.org qu'une image d'illustration contenait, en plus des habituels robots.txt et humans.txt, un fichier nommé hackers.txt. A priori il n'y a aucune norme, aucun standard ou convention pour un tel fichier, alors il a décidé d'en créer une.

Je n'ai pas de fichier de ce type au moment de l'écriture de ce billet. Mais l'initiative m'amuse, alors j'ai bien envie de le faire aussi à l'occasion !

et d'autres ?

Il existe probablement d'autres conventions, plus ou moins connues. Les seules qui me viennent à l'esprit sont le répertoire /.well-known/ (utilisé pour dnt-policy.txt mais aussi pour le fichier de challenge Let's Encrypt, et décrit dans la RFC 5785), et le fichier sitemaps.xml, mais qui n'est pas juste du texte, comme son nom l'indique.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Susanlenox - Ninotchka (1939).

Propulsé par Dotclear