~/

Si on se faisait un petit certificat wildcard ? - Partie 2

2018-03-19T17:00:00+01:00

Dans l’article précédent, je vous ai expliqué comment installer la bonne version de certbot pour générer des certificats wildcard letsencrypt et je vous ai montré comment en générer un avec une édition manuelle de la zone DNS.

Dans ce second article de cette série sur la génération de certificats wildcard letsencrypt, je vais vous montrer comment générer automatiquement un certificat wildcard.

Nous allons commencer par un domaine dont le DNS est géré sur un fournisseur DNS pour lequel il exist un plugin pour certbot. Nous utiliserons AWS route53 dans cet exemple

Ensuite, nous verrons comment utiliser des scripts maison pour faire l’ajout de l’entrée DNS nécessaire au challenge ACME DNS-01 (le protocole de validation pour l’émission du certificat wildcard). Nous utiliserons cette technique pour générer des certificats lorsque la zone DNS est hébergée sur un bind local ou lorsqu’elle est hébergée sur les DNS de gandi (LiveDNS) ou d'OVH.

Génération de certificat wildcard avec DNS route53
Génération de certificat wildcard avec scripts maison d’édition de zone
Points complémentaires
Conclusion

Génération de certificat wildcard avec DNS route53

Pour pouvoir créer les entrées DNS nécessaires à la validation du domaine, il vous faudra une clé d’accès et une clé secrète pour l’API AWS. Vous devez donc commencer par créer un utilisateur dans la console IAM de la façon suivante :

Choisissez “Ajouter un utilisateur”
Appelez-le “letsencrypt_validation” par exemple et choisissez un accès par programmation (pour obtenir une clé d’API) et cliquez sur “Suivant”
Choisissez d’attacher directement les stratégies existantes et cliquez sur “Créer une stratégie” pour créer les droits de votre nouvel utilisateur
Créez une nouvelle stratégie pour le service Route53 qui autorise les actions “GetChange”, “ListHostedZones” et “ChangeRessourceRecordSets” sur tous les objets (vous pouvez sinon restreindre l’action “ChangeRessourceRecordSets” sur les seuls domaines pour lesquels vous souhaitez pouvoir effectuer une validation DNS-01)
Nommez votre stratégie (par exemple letsencrypt_validation) et validez
Revenez à votre utilisateur en cours de création, cliquez sur “Actualiser” pour recharger la liste des stratégies puis recherchez celle que vous venez de créer et cochez la case en début de ligne pour l’associer à votre utilisateur, puis cliquez sur “Suivant”
Vérifiez le résumé et cliquez sur “Créer un utilisateur” pour procéder à la création
Dans le résumé de création de l’utilisateur, notez l’ID de clé d’accès ainsi que la clé d’accès secrète qui vous serviront à vous authentifier auprès de l’API route53

Le plugin route53 de certbot utilise ces identifiants. Nous allons donc installer le paquet awscli et configurer les identifiants :

$ apt-get install awscli
$ aws configure
AWS Access Key ID [None]: AKIAXXXXXXXXXXXXXXXX
AWS Secret Access Key [None]: 74Bo!xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [None]: eu-central-1
Default output format [None]:

Nous allons ensuite installer le plugin route53 de certbot :

$ /opt/eff.org/certbot/venv/bin/pip install certbot-route53
Collecting certbot-route53
  Downloading certbot-route53-0.2.0.tar.gz
[...]
Successfully built certbot-route53
Installing collected packages: jmespath, python-dateutil, docutils, botocore, futures, s3transfer, boto3, certbot-dns-route53, certbot-route53
Successfully installed boto3-1.6.11 botocore-1.9.11 certbot-dns-route53-0.22.0 certbot-route53-0.2.0 docutils-0.14 futures-3.2.0 jmespath-0.9.3 python-dateutil-2.6.1 s3transfer-0.1.13

Et nous avons désormais tout ce qu’il nous faut pour générer un certificat wildcard letsencrypt avec un domaine géré sur route53. Nous utiliserons les options suivantes de certbot :

--server https://acme-v02.api.letsencrypt.org/directory On utilise l’API ACME v2
--dns-route53 L’entrée DNS pour le challenge sera créée via l’api route53
-d '*.domain.tld' le sujet du certificat qu’on souhaite émettre

$ cd /opt/eff.org/certbot/venv/bin
$ ./certbot certonly \
    --server https://acme-staging-v02.api.letsencrypt.org/directory \
    --dns-route53 \
    -d '*.domain.tld'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found credentials in shared credentials file: ~/.aws/credentials
Plugins selected: Authenticator dns-route53, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld
Starting new HTTPS connection (1): route53.amazonaws.com
Waiting 10 seconds for DNS changes to propagate
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/domain.tld/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/domain.tld/privkey.pem
   Your cert will expire on 2018-06-15. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Et voilà ! nous avons généré automatiquement notre certificat wildcard letsencrypt pour un domaine géré sur route53. Et comme la validation s’est faite automatiquement, sans intervention manuelle, la renouvèlement se passera de la même façon.

Génération de certificat wildcard avec scripts maison d’édition de zone

Fonctionnement

Lors d’une génération de certificat avec validation manuelle, certbot dispose des options --manual-auth-hook et --manual-cleanup-hook qui permettent de définir des scripts qui doivent être appelés pour créer l’entrée dns avant la validation puis pour la supprimer après. Voir à ce sujet la documentation officielle.

Ces scripts sont appelés avec les variables d’environnements suivantes définies (pour une validation DNS-01) :

CERTBOT_DOMAIN : le domaine à valider
CERTBOT_VALIDATION : le contenu de l’entrée TXT à créer

Le script de nettoyage post-validation reçoit également la variable d’environnement CERBOT_AUTH_OUTPUT qui contient la sortie standard du script de validation. Ceci peut servir par exemple à passer entre les 2 scripts l’ID de l’enregistrement créé.

Je vous ai mis dans github tous les scripts utilisés ci-dessous. Ces scripts sont des exemples pour vous aider à développer les vôtres. Commencez par cloner ces scripts dans /opt/le-scripts :

    $ git clone https://github.com/sblaisot/certbot-dns-01-authenticators.git /opt/le-scripts

4 ensembles de scripts sont disponibles, le premier pour tester le fonctionnement de certbot avec des scripts de validation personnels, le second si vous avez votre serveur DNS bind sur la même machine que celle avec laquelle pour générez les certificats et les deux derniers pour générer des certificats wildcard letsencrypt lorsque vos zones DNS sont gérées sur le service LiveDNS de Gandi ou chez OVH.

Chaque ensemble est composé de 2 scripts : un script auth qui permet de créer l’entrée DNS pour la validation et un script cleanup qui permet de la retirer une fois la validation effectuée.

Un script pour tester

Les scripts du répertoire test se contentent d’afficher le contenu des variables d’environnements passées par certbot, pour en étudier le fonctionnement. De ce fait, ils ne créent ni ne suppriment aucune entrée DNS et la génération de certificat échoue forcément.

Néanmoins, ils nous permettent de voir comment cela fonctionne. Appelons certbot en lui demandant d’utiliser ces scripts :

$ cd /opt/eff.org/certbot/venv/bin
$ ./certbot certonly \
    --server https://acme-staging-v02.api.letsencrypt.org/directory \
    --manual-public-ip-logging-ok \
    --manual \
    --manual-auth-hook /opt/le-scripts/test/auth.sh \
    --manual-cleanup-hook /opt/le-scripts/test/cleanup.sh \
    -d '*.domain.tld'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld
Output from auth.sh:
------ AUTH ------
CERTBOT_VALIDATION=39sbL18pMHYSusn0zZoenN3kUtJyq7DU-XnpzkFQdBA
CERTBOT_DOMAIN=domain.tld
------ AUTH ------

Waiting for verification...
Cleaning up challenges
Output from cleanup.sh:
------ CLEANUP ------
CERTBOT_VALIDATION=39sbL18pMHYSusn0zZoenN3kUtJyq7DU-XnpzkFQdBA
CERTBOT_DOMAIN=domain.tld
CERTBOT_AUTH_OUTPUT=------ AUTH ------
CERTBOT_VALIDATION=39sbL18pMHYSusn0zZoenN3kUtJyq7DU-XnpzkFQdBA
CERTBOT_DOMAIN=domain.tld
------ AUTH ------
------ CLEANUP ------

Failed authorization procedure. domain.tld (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.domain.tld

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: domain.tld
   Type:   unauthorized
   Detail: No TXT record found at _acme-challenge.domain.tld

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address.

Nous voyons ici que les scripts sont appelés avant la validation pour créer l’entrée DNS et après la validation pour la supprimer. Ces scripts reçoivent bien les variables d’environnement de certbot.

Génération de certificat wildcard avec DNS bind local

Le répertoire local-bind contient des scripts qui permettent d’ajouter l’entrée de validation dans des fichiers de zone bind accessible en local sur la machine qui émet le certificat.

Ces scripts freezent la zone dns (pour éviter une rotation de clé dnssec lors de l’ajout de l’entrée), mettent à jour le numéro de série de la zone et ajoutent l’entrée (ou la suppriment pour le script de cleanup)

Pour les utiliser, copiez le fichier config.sh.example en config.sh et adaptez le pour y indiquer l’emplacement de vos fichiers de zone, le format de leur nom (qui doit contenir le nom de domaine) ainsi que la chaine à rechercher pour trouver le serial de la zone.

Vous pourrez ensuite générer votre certificat wildcard de la façon suivante :

$ cd /opt/eff.org/certbot/venv/bin
$ ./certbot certonly \
    --server https://acme-v02.api.letsencrypt.org/directory \
    --manual-public-ip-logging-ok \
    --manual \
    --manual-auth-hook /opt/le-scripts/local-bind/auth.sh \
    --manual-cleanup-hook /opt/le-scripts/local-bind/cleanup.sh \
    -d '*.domain.tld'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld
Output from auth.sh:
Freeze zone
Update serial
Add challenge to zone file
Release zone
A zone reload and thaw was started.
Check the logs to see the result.
Wait 5 seconds for repplication to masters
Done

Waiting for verification...
Cleaning up challenges
Output from cleanup.sh:
Freeze zone
Update serial
Remove challenge from zone file
Release zone
A zone reload and thaw was started.
Check the logs to see the result.
Done


IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/domain.tld/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/domain.tld/privkey.pem
   Your cert will expire on 2018-06-16. To obtain a new or tweaked
   version of this certificate in the future, simply run
   letsencrypt-auto again. To non-interactively renew *all* of your
   certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Il serait également possible de configurer bind pour accepter les mises à jour dynamiques (rfc2136) et utiliser le plugin dns-rfc2136 de certbot. Je vous le laisse en exercice ;)

Génération de certificat wildcard avec DNS Gandi (LiveDNS)

Maintenant qu’on a bien joué avec nos scripts de test, voici un exemple plus près de la vie réelle pour la génération d’un certificat wildcard lorsque la zone DNS est hébergée chez Gandi.

Il est indispensable que votre zone DNS soit hébergée sur la solution LiveDNS de gandi (v5) qui permet une mise à jour des enregistrement DNS instantanée contrairement à l’ancienne solution (v4). Dans l’ancienne version, il fallait plusieurs minutes pour que vos enregistrements DNS soient créés et ceci n’est pas compatible avec la validation de domaine.

Ensuite, il vous suffit dans le répertoire /opt/le-scripts/gandi-livedns de copier le fichier config.py.example en config.py et d’ajuster les paramètres :

livedns_api = "https://dns.api.gandi.net/api/v5/" c’est le endpoint de l’API LiveDNS de Gandi. Il n’est habituellement pas nécessaire de modifier ce paramètre
livedns_apikey = "YOUR-KEY-HERE" Votre clé d’API LiveDNS que vous pourrez générer dans vos paramètres de compte à la rubrique “Modification de mot de passe et configuration des restrictions d’accès“
livedns_sharing_id = None Si vos domaines ne sont pas rattachés directement à votre compte mais gérés dans une organisation, il faudra indiquer ici votre sharing_id qui permet de gérer l’organisation à partir de votre compte. Vous le retrouverez dans l’URL du manager lorsque vous listez votre domaine sous la forme d'un GUID.

Une fois la configuration effectuée, il ne vous reste plus qu’à générer votre certificat :

$ cd /opt/eff.org/certbot/venv/bin
$ ./certbot certonly \
    --server https://acme-v02.api.letsencrypt.org/directory \
    --manual-public-ip-logging-ok \
    --manual \
    --manual-auth-hook /opt/le-scripts/gandi-livedns/auth.py \
    --manual-cleanup-hook /opt/le-scripts/gandi-livedns/cleanup.py \
    -d '*.domain.tld'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld
Output from auth.py:
all good, entry created

Waiting for verification...
Cleaning up challenges
Output from cleanup.py:
all good, entry deleted


IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/domain.tld/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/domain.tld/privkey.pem
   Your cert will expire on 2018-06-15. To obtain a new or tweaked
   version of this certificate in the future, simply run
   letsencrypt-auto again. To non-interactively renew *all* of your
   certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Génération de certificat wildcard avec DNS OVH

Et si vos domaines sont hébergés chez OVH, c'est la même chose.

On installe d'abord les prérequis :

$ sudo apt-get install python3-dnspython
$ sudo pip3 install ovh

Vous devez ensuite copier le fichier /opt/le-scripts/ovh/ovh.conf.example en /opt/le-scripts/ovh/ovh.conf et l'ajuster avec vos clés d'api.

Et vous pouvez ensuite génèrer le certificat :

$ cd /opt/eff.org/certbot/venv/bin/
$ ./certbot certonly \
    --server https://acme-v02.api.letsencrypt.org/directory \
    --manual-public-ip-logging-ok \
    --manual \
    --manual-auth-hook /opt/le-scripts/ovh/auth.py \
    --manual-cleanup-hook /opt/le-scripts/ovh/cleanup.py \
    -d '*.domain.tld'

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld
Output from auth.py:
All good, DNS record created
Waiting for record to be available on DNS servers
DNS record available on DNS server

Waiting for verification...
Cleaning up challenges
Output from cleanup.py:
All good, DNS record deleted


IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/domain.tld/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/domain.tld/privkey.pem
   Your cert will expire on 2018-06-17. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Points complémentaires

Emplacement des scripts et renouvèlement

Si vous devez déplacer les scripts sur votre système, le renouvèlement de certificat risque de ne pas les trouver, et donc d’échouer. Il vous faut alors mettre à jour le fichier de configuration du renouvèlement qui se trouve dans /etc/letsencrypt/renewal/<domain>.conf

Délai de création de l’entrée DNS

Il est indispensable pour la validation automatique (et donc pour le renouvèlement) que votre système DNS permette de créer immédiatement une entrée DNS. S’il vous faut plusieurs minutes/heures/jours pour que l’entrée DNS soit créée, vous ne pourrez pas générer de certificat wildcard avec cette méthode. Bien que le protocole ACME semble semble permettre la validation asynchrone, je ne sais pas quelle est la durée de vie maximale du jeton d’authentification et le client certbot ne le permet pas, il vous faudra donc trouver ou coder un autre client ACME.

Mais Hey, on est en 2018, il y a plein de super services DNS qui permettent de mettre en ligne immédiatement une entrée, avec un pilotage par api. Il est peut-être temps de changer de fournisseur DNS dans ce cas.

Et la sécurité dans tout ça ?

Dans les exemples donnés, le serveur qui génère le certificat letsencrypt a un contrôle total sur la zone DNS. Il n’est pas souhaitable, en réalité, que le serveur web qui a besoin du certificat ait la possibilité de modifier tout le contenu de la zone DNS. Dans ce cas, vous pouvez imaginer générer le certificat à partir d’une machine d’administration puis le pousser sur le serveur web qui en a besoin, ou développer une api interne accessible par le serveur web qui permette uniquement de gérer l’entrée _acme-challenge et qui fera le relai vers le fournisseur DNS.

Conclusion

Vous avez maintenant tous les éléments en main pour générer des certificats letsencrypt. Si vous vous posez encore des questions, n’hésitez pas à les laisser en commentaire, j’essaierai d’y répondre.

Si on se faisait un petit certificat wildcard ? - Partie 1

2018-03-15T22:35:00+01:00

Le 13 mars 2018, letsencrypt lançait enfin en production une fonctionnalité maintes fois réclamée : la possibilité de générer des certificats wildcard, c’est à dire des certificats valable pour tous les sous-domaines d’un domaine, de la forme *.domaine.tld.

Habituellement, de tels certificats ne sont pas nécessaires pour un site web (puisqu’un certificat peut contenir plusieurs noms via l’utilisation des SAN, Subject Alternate Name), cependant, il existe des cas où ils sont indispensable. Par exemple dans le cas d’un service pour lequel chaque utilisateur obtient une URL propre du style https://username.service.tld. Dans ce cas, la liste peut être grande et n’est pas connue à l’avance et un certificat wildcard est nécessaire.

Si letsencrypt fournit désormais des certificats wildcard, c’est pour couvrir ces cas de figure uniquement. Les certificats wildcard ne sont pas fait pour être déployés sur un ensemble de serveurs fournissant des services différents juste pour éviter de gérer des certificats différents. C’est une mauvaise pratique

Challenges

Pour émettre un certificat, letsencrypt doit s’assurer que vous avez bien la main sur les ressources à certifier. Letsencrypt propose 3 types de challenge :

HTTP-01 : challenge par requête http, le plus couramment utilisé pour les certificats simples
TLS-SNI-01 : challenge par présentation de certificat TLS. Ce challenge a été désactivé suite à des problèmes de sécurité.
DNS-01 : challenge par requête DNS sur une entrée TXT dans le domaine.

Si dans le cas d’un site web, cette validation se résume généralement à vérifier que vous avez la main sur le serveur web, dans le cas d’un certificat wildcard il faut prouver que vous avez la main sur l’ensemble du domaine. Aussi, seul le challenge DNS-01 est possible pour des certificats wildcard letsencrypt, il faudra donc pouvoir éditer votre zone DNS pour commander ce type de certificat.

Fournisseurs DNS gérés

Le client letsencrypt certbot gère nativement les fournisseurs de service DNS suivants :

AWS Route53
Cloudflare
CloudXNS
DigitalOcean
DNSimple
DNS Made Easy
Google Cloud DNS
LuaDNS
NS1

Certbot permet aussi de gérer les serveurs DNS dynamiques conformes à la RFC 2136 comme par exemple bind.

Il est également possible d’émettre un certificat wildcard en éditant manuellement la zone DNS. C’est utile pour tester, en revanche, le renouvèlement automatique du certificat ne sera pas possible et il vous faudra dans ce cas renouveler l’opération tous les 3 mois (durée de vie maximum des certificats letssencrypt).

Enfin, outre la possibilité de développer un plugin à certbot pour gérer un autre fournisseur (et cela arrivera, des gens en feront, mais il y en a peu pour l’instant principalement parce que le challenge HTTP-01 était suffisant jusqu’à présent), il est également possible de fournir à certbot un script/programme à lancer pour créer et supprimer l’entrée DNS de challenge et y faire ce qu’on veut.

Nous ne couvrirons pas ici l’ensemble des fournisseurs de DNS, mais je vais vous présenter l’émission de certificats wildcard letsencrypt avec édition manuelle de la zone DNS et dans un second article l’émission de certificat wildcard pour un domaine géré sur AWS route53 ainsi que l’utilisation de scripts maison d’édition de zone pour gérer un provider non disponible. Je prendrai l’exemple de Gandi pour cela.

Prérequis

Vous devrez disposer du client certbot en version 0.22.0 au minimum. à l’heure où j’écris ces lignes, cette version n’est pas encore présente sur les dépots debian ou ubuntu mais nous allons voir comment l’installer, éventuellement en parallèle d’une autre version que vous utilisez déjà. Pour vérifier votre version de certbot, utilisez certbot --version
La possibilité d’éditer votre zone DNS. De préférence via une API ou à défaut automatisable par scripting.
Un peu de patience et de persévérance, même si j’ai l’outrecuidance de penser que ces quelques lignes les allègeront…

Installation de certbot 0.22.0

Ces instructions permettent d’installer certbot sur la plupart des systèmes unix/linux dans /opt y compris si vous avez déjà une autre version de certbot installée par les packages de votre distribution sans y toucher. Cela vous permettra de tester la génération de certificat wildcard pour être prêt dès que cette version sera disponible dans votre repo/ppa préféré.

Créez un répertoire /opt/certbot pour le wrapper de téléchargement/mise à jour de certbot

$ mkdir /opt/certbot
$ cd /opt/certbot

Téléchargez le wrapper sur le site de certbot

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto

Lancez l’installation

$ ./certbot-auto --install-only

Et voilà, certbot 0.22.0 (ou plus récent) est installé dans /opt/eff.org/certbot comme nous le prouve la commande suivante :

$ /opt/eff.org/certbot/venv/bin/certbot --version
certbot 0.22.0

Le seul inconvénient de cette méthode si vous utilisez déjà un certbot installé par le package de votre repo/ppa préféré et que vous avez mis en place un renouvèlement automatique est que cette version antérieure à 0.22.0 sera incapable de renouveler automatiquement vos certificats. Cependant, cela laisse 3 mois pour que ce package soit mis à jour en version 0.22.0, ce qui ne devrait plus tarder désormais.

Note complémentaire : si vous souhaitez désinstaller votre package certbot ou letsencrypt (encore plus ancien), faites une sauvegarde de votre /etc/letsencrypt avant. En effet, un apt-get purge certbot a la désagréable habitude de supprimer ce répertoire et vous predriez tous vos crtificats.

Génération de certificat wildcard avec édition manuelle de zone DNS

Pour générer un certificat en éditant manuellement la zone DNS, c’est aussi simple que :

$ cd /opt/eff.org/certbot/venv/bin/
$ ./certbot certonly --server https://acme-v02.api.letsencrypt.org/directory \
                     --manual -d '*.domain.tld'
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.tld

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.domain.tld with the following value:

6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/domain.tldu/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/domain.tld/privkey.pem
   Your cert will expire on 2018-06-13. To obtain a new or tweaked
   version of this certificate in the future, simply run
   letsencrypt-auto again. To non-interactively renew *all* of your
   certificates, run "letsencrypt-auto renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Voici les options utilisées :

--server https://acme-v02.api.letsencrypt.org/directory : On utilise l’API ACME v2
--manual on va créer l’entrée DNS pour le challenge manuellement
-d '*.domain.tld' le sujet du certificat qu’on souhaite émettre

Et le détail de ce qui s’est passé et des actions a effectuer :

Tout d’abord, on aura des logs, c’est là qu’il faudra aller voir si quelque chose se passe mal

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Nous avons demandé à créer les entrées pour le challenge manuellement (--manual) et ne souhaitons pas que certbot installe le certificat pour nous dans notre serveur web (certonly)

Plugins selected: Authenticator manual, Installer None

L’adresse IP de la machine qui initie la demande de certificat est enregistrée et disponible publiquement dans le cadre de la transparence sur l’émission des certificats. Si vous refuser, vous ne pourrez pas obtenir de certificat de la part de letsencrypt. Ce message et la question peuvent être évitée en ajoutant l’option --manual-public-ip-logging-ok

-------------------------------------------------------------------------------
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
-------------------------------------------------------------------------------
(Y)es/(N)o: y

Vient ensuite la phase de challenge

-------------------------------------------------------------------------------
Please deploy a DNS TXT record under the name
_acme-challenge.domain.tld with the following value:

6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY

Before continuing, verify the record is deployed.
-------------------------------------------------------------------------------
Press Enter to Continue

Il ne vous reste plus qu’à ajouter dans votre zone DNS une entrée de type TXT de nom _acme-challenge et dont la valeur vous est fournie par letsencrypt (ici 6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY) Par exemple, pour bind :

_acme-challenge        IN    TXT        6CmoURMbv3F14hJdzR8zqXrhcYJeKWJEhT8xZcz4gUY

Si nécessaire, attendez le temps de la bonne mise en place de votre entrée DNS et de sa propagation si votre DNS n’est pas très véloce, puis appuyez sur entrée et certbot se charge de demander à letsencrypt de vérifier le challenge.

Enfin, si tout s’est bien passé, votre certificat est disponible dans /etc/letsencrypt/live/domain.tld

Conclusion

Voilà pour cette première partie qui, je l’espère, vous aura permis de générer votre premier certificat wildcard. Dans un second article je détaille la génération de certificat letsencrypt avec édition automatique de la zone pour le service DNS AWS route53 ainsi que l’utilisation de script personnels pour l’édition de la zone DNS et nous appliquerons cette dernière méthode pour des domaines hébergés sur les DNS de Gandi et d'OVH.

Multi-diffusez vos tableaux de bord, de manière centralisée, sans fil et à faible coût avec Raspberry Pi, dashkiosk et Chromecast

2017-09-20T18:00:00+02:00

Ok, le titre sonnait mieux en anglais : Low-cost centralized wireless dashboard multicasting with Raspberry Pi, dashkiosk and Chromecast. Mais la ligne éditoriale de ce blog est en Français...

Les équipes informatiques sont friandes des écrans sur les murs qui diffusent toutes sortes de tableaux de bord, que ce soit l'état de la chaine d'intégration continue, le taux de passage des tests ou les métriques de supervision de la production. Ces dernières années ont vu fleurir les écrans sur les murs des open-spaces. Généralement contrôlés par des SOC (Raspberry Pi, Odroid, ...). Cette solution peu onéreuse a toutefois quelques inconvénients. Notamment, cela fait un OS de plus à administrer pour chaque écran, la fiabilité est moyenne (combien de prise de main à distance sur le Raspberry Pi par an et par écran ?) et surtout, chaque solution d'affichage est autonome, avec ses avantages, mais aussi ses inconvénients.

La solution que je vous propose aujourd'hui a pour objectif :

De diffuser vos tableaux de bord (accessibles en HTTP/HTTPS) sur plusieurs écrans
De diffuser du contenu sans fil (via Wi-Fi)
D'être gérée de manière centralisée
D'être d'une fiabilité déconcertante
De pouvoir ajouter un écran très facilement, rapidement, sans connaissances particulière de l'administration système
De couter moins cher qu'un Raspberry Pi pour chaque écran

Elle peut également servir dans d'autres contextes, par exemple gérer les différents écrans publicitaires d'une boutique pour de la signalétique numérique

Tour d'horizon

Je vous propose donc d'utiliser un Raspberry Pi pour gérer vos affichages de manière centralisée (c'est à dire pouvoir simplement choisir quel(s) tableau(x) de bord seront affichés sur quels écrans) en utilisant le logiciel dashkiosk et d'utiliser des Chromecast pour la diffusion.

dashkiosk peut être installé sur n'importe quelle machine, mais le Raspberry est l'une des moins cher. Ce logiciel en nodejs permet de gérer chaque écran et de décider ce qui sera affiché dessus (quelles URL), de gérer l'affichage en fonction de l'heure ou du jour, de réaliser un cycle entre différentes URL, etc...

Un kit de démarrage Raspberry Pi 3 coute environ 55€ TTC (Raspberry Pi + boitier + alimentation + sdcard). On trouve des Chromecast de première génération sur ebay pour environ 10€ port compris. c'est amplement suffisant.

Cela nous fait donc un cout total d'environ 55€ + 10€ * (nombre d'écran).

Dashkiosk

Dashkiosk est une solution de gestion d'affichage multi-écrans. La video ci-dessous vous présente en détail son fonctionnement :

Installation

Nous allons commencer par installer nodejs. Comme dashkiosk s'attend à avoir nodejs accessible par la commande node, nous demandons aussi à alternatives de gérer un lien symbolique pour nous. Nous installons également les prérequis à dashkiosk.

$ aptitude install nodejs npm
$ update-alternatives --install /usr/bin/node node /usr/bin/nodejs 10
$ aptitude install git libavahi-compat-libdnssd-dev libsqlite3-dev libjpeg-progs optipng gifsicle autoconf dh-autoreconf

Téléchargez dashkiosk depuis github et configurez le tout.

$ curl -sL -o - 'https://github.com/vincentbernat/dashkiosk/archive/master.tar.gz' | tar -C /opt -zxvf -
$ mv /opt/dashkiosk-master /opt/dashkiosk
$ cd /opt/dashkiosk
$ npm install -g bower grunt-cli
$ npm install
$ grunt
$ cd dist && npm install --production

Troll mode : oui oui, on utilise un gestionnaire de paquets (aptitude) pour installer un gestionnaire de paquets (npm) qui nous permet d'installer un gestionnaire de paquets (bower). C'est trop cool, en fait, NodeJS ;)

Démarrons dashkiosk et testons avec un navigateur si cela fonctionne :

$ cd /opt/dashkiosk/dist
$ node server.js --environment production

Vous pouvez ensuite avec un navigateur vous rendre à l'URL http://<IP de votre raspberry>:9400/admin pour accéder à l'interface d'administration et avec un autre onglet à l'adresse http://<IP de votre raspberry>:9400/receiver pour en faire un écran d'affichage.

Une fois votre test effectué, vous pouvez quitter dashkiosk (CTRL-C)

Démarrage automatique

Bon, c'est chouette de pouvoir lancer à la main dashkiosk, mais ce serait mieux qu'il se lance tout seul comme tous les autres démons. systemd va gérer cela pour nous.

Créez un utilisateur dashkiosk qui sera dédié au lancement de dashkiosk:

$ adduser --home /opt/dashkiosk/ --shell /usr/sbin/nologin --no-create-home --disabled-login --gecos "" dashkiosk
$ chown -R dashkiosk: /opt/dashkiosk/dist/

Puis créez un fichier /etc/systemd/system/dashkiosk.service avec le contenu suivant :

[Unit]
Description=Dashkiosk dashboard admin

[Service]
ExecStart=/usr/bin/nodejs server.js --environment production
StandardOutput=null
StandardError=syslog
Restart=always
User=dashkiosk
Group=dashkiosk
WorkingDirectory=/opt/dashkiosk/dist/

[Install]
WantedBy=multi-user.target

Vous aurez remarqué qu'on supprime la sortie standard. En effet, dashkiosk est très verbeux et j'ai rempli un disque de 15Go en moins d'une semaine en l'envoyant dans syslog. Il est toujours possible de remplacer null par syslog temporairement pour débugguer ultérieurement.

Il ne reste plus ensuite qu'à demander à systemd de prendre en compte ce fichier et à lancer dashkiosk :

$ systemctl enable dashkiosk
$ systemctl start dashkiosk

Chromecast

Nous allons supposer ici que votre chromecast est déjà configurée et fonctionnelle, c'est un jeu d'enfant en suivant les instructions à l'écran.

Comme la Chromecast est découverte en utilisant le protocole DNS multicast (mDNS), le Raspberry Pi et la Chromecast doivent obligatoirement être dans le même réseau pour que cela fonctionne.

Nous allons configurer notre Raspberry Pi pour qu'il fasse de la résolution DNS multicast (ZeroConf/Apple Bonjour/Microsoft LLMNR).

D'abord, installez les packages nécessaires :

$ aptitude install avahi-utils libnss-mdns

puis éditez le fichier /etc/nsswitch.conf et remplacez la ligne qui commence par hosts par ce contenu :

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

Il n'y a plus qu'à tester manuellement que cela fonctionne. Nous lançons d'abord une recherche de chromecast :

$ avahi-browse -r _googlecast._tcp
+  wlan0 IPv4 Chromecast-Ultra-7f532001624a95c2f74e7b44d690c056 _googlecast._tcp     local
=  wlan0 IPv4 Chromecast-Ultra-7f532001624a95c2f74e7b44d690c056 _googlecast._tcp     local
   hostname = [7f532001-624a-95c2-f74e-7b44d690c056.local]
   address = [192.168.1.2]
   port = [8009]
   txt = ["rs=" "nf=1" "bs=FA8FCA7ED164" "st=0" "ca=4101" "fn=Chromecast" "ic=/setup/icon.png" "md=Chromecast Ultra" "ve=05" "rm=BE1C2E8914AAF2BB" "cd=D7FBF1741973D5D9085B37B99AF75FE1" "id=7f532001624a95c2f74e7b44d690c056"]

avahi-browse découvre bien une chromecast. Relevez le contenu de hostname (ici 7f532001-624a-95c2-f74e-7b44d690c056.local) puis essayez de récupérer son adresse IP :

$ getent hosts 7f532001-624a-95c2-f74e-7b44d690c056.local
192.168.1.2     7f532001-624a-95c2-f74e-7b44d690c056.local

Si vous obtenez bien l'adresse IP de votre Chromecast, c'est que tout fonctionne, votre Raspberry Pi peut découvrir votre Chromecast et communiquer avec.

Editez ensuite le fichier /opt/dashkiosk/dist/lib/config.js et modifiez la section chromecast comme ceci :

// Chromecast
chromecast: {
  enabled: true,
  receiver: 'http://<IP de votre raspberry>:9400/receiver',
  app: '5E7A2C2C'
},

en remplaçant <IP de votre raspberry> par l'IP de votre Raspberry Pi. Cela permet d'indiquer aux clients Chromecast l'URL à charger.

Il suffit ensuite de relancer dashkiosk :

$ systemctl restart dashkiosk

Vous devriez alors voir aparaitre votre Chromecast comme nouvel écran dans l'interface d'administration de dashkiosk. Il suffit de le placer dans un groupe pour qu'il charge les dashboard sélectionnés

Ajout d'un écran

Ajouter un écran à la solution est d'une simplicité enfantine. Il suffit de configurer la Chromecast et de la connecter au même réseau que le Raspberry Pi, dashkiosk la reconnait alors automatiquement et il n'y a plus qu'à l'ajouter dans le bon groupe pour que l'écran commence à diffuser son contenu.

Et la sécurité dans tout ça ?

Contrôle d'accès

à l'administration de dashkiosk

Comme on ne veut pas que n'importe qui sur le réseau puisse modifier l'affichage sur nos écrans, nous devons protéger l'accès à l'interface d'administration de dashkiosk.

Pour ajouter du contrôle d'accès à dashkiosk, il suffit d'éditer le fichier /opt/dashkiosk/dist/lib/config.js et de modifier la section auth pour ajouter un utilisateur et un mot de passe d'accès à l'administration de dashkiosk :

// Auth
auth: {
  enabled: true,
  realm: 'Dashkiosk',
  username: 'myuser',
  password: 'mypasswd'
},

Il faut ensuite relancer dashkiosk pour la prise en compte de ces nouveaux paramètres :

$ systemctl restart dashkiosk

Cependant, cette approche présente un inconvénient : l'URL de visualisation est également protégée, il faut donc modifier l'URL des clients sous la forme http://user@password:<IP de votre raspberry>:9400/receiver. C'est moche d'abord parce qu'on véhicule un mot de passe sur une session non chiffrée (HTTP) et d'autre part parce que la chromecast affiche l'url lors du chargement. bof bof.

Une meilleure solution serait d'installer un serveur web en frontal de dashkiosk qui ne protège que la partie administration de dashkiosk. Je vous laisse cette partie en exercice.

aux Chromecast

Il est préférable, pour éviter que tout le monde joue avec les chromecast de les protéger.

Dans les paramètres de votre Chromecast (contrôlable par l'application Google Home sur un téléphone android), assurez vous que le paramètre suivant est décoché :

Vous pouvez également utiliser un réseau dédié pour connecter vos Chromecast. Ainsi, personne ne pourra prendre la main dessus. Le Raspberry Pi pourra alors se connecter à ce réseau avec son interface Wi-Fi et au réseau de l'entreprise grâce à son interface RJ45 pour l'administration de la solution.

Je vous laisse aussi en exercice ce point ;)

Disponibilité

Cette solution a l'avantage de la robustesse. Si un écran plante, il suffit de relancer la Chromecast (débrancher/rebrancher). Dashkiosk la redécouvre et reconnecte les chromecast automatiquement.

On peut même avoir en stock une Chromecast supplémentaire pour effectuer un remplacement ultra rapide en cas de défaillance. c'est beaucoup plus simple à configurer que de réinstaller un Raspberry Pi pour le coller derrière un écran...

Conclusion

Voilà une solution à moindre cout, fiable, qui sera utile aussi bien pour la gestion de multiples écrans à partir d'un point central que pour la gestion d'un seul écran lorsque l'unité "intelligente" doit être déportée loin de l'affichage.

Time-series sur Raspberry Pi avec la stack TICK

2017-09-18T15:00:00+02:00

Aujourd'hui, nous allons voir comment installer la pile TICK (Telegraf, InfluxDB, Chronograf et Kapacitor) sur un Raspberry Pi 3 sous Raspbian Lite pour jouer avec les séries temporelles (time-series) à la maison.

Les séries temporelles sont une suite de valeurs numériques évoluant au cours du temps. Elles sont particulièrement adaptées pour manipuler des mesures comme la température, la charge CPU d'une machine, etc...

On s'attachera ici à déployer la pile uniquement, à injecter des données provenant du Raspberry (monitoring) et à afficher un dashboard de ces données. En revanche, nous n'aborderons pas en détail la configuration, ni la sécurisation de la pile (gestion des droits notamment), ni encore la scalabilité de la solution, je laisse ça pour un prochain article.

La pile TICK
Installation
Ajoutons une source de données

La pile TICK

La pile TICK est une pile logicielle dédiée à la manipulation des séries temporelles. Elle se compose des 4 éléments suivants :

Telegraf qui est un agent de collecte des données doté de nombreux plugins de collecte ainsi que de stockage,
InfluxDB qui est la base de données de stockage des séries temporelles,
Chronograf, l'interface graphique de visualisation des données,
Kapacitor qui traite les données et déclenche des actions ou des alertes suivant les règles que vous lui avez établies. Il peut alerter par SMTP, slack, PagerDuty, Telegram et plein d'autre moyens encore.

Installation

Dans la suite de cet article, nous supposons que vous installez sur un OS raspbian lite, mais c'est probablement identique sur l'ensemble des distributions dérivées de debian.

Ajout du dépot InfluxData.com

En premier lieu, nous allons ajouter le dépot influxdata à notre Raspberry Pi

$ sudo echo "deb https://repos.influxdata.com/debian $(grep -e '^VERSION=' /etc/os-release | sed -e 's/^.*(\(.*\)).*$/\1/') stable" > /etc/apt/sources.list.d/influxdb.list
$ sudo curl -sL https://repos.influxdata.com/influxdb.key | apt-key add -
$ sudo aptitude update

Installation d'InfluxDB

$ sudo aptitude install influxdb influxdb-client
$ sudo systemctl enable influxdb
$ sudo systemctl start influxdb

Vous pouvez ensuite tester que la base est bien démarrée avec la commande suivante :

$ curl "http://localhost:8086/query?q=show+databases"
{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"],"values":[["_internal"]]}]}]}

Le résultat vous indique qu'il existe une base nommée _internal. C'est tout bon.

Si vous obtenez au premier lancement de la commande curl le résultat suivant :

{"results":[{"statement_id":0,"series":[{"name":"databases","columns":["name"]}]}]}

Pas de panique. Cela peut arriver la première fois, quand InfluxDB n'a encore reçu aucune commande, la base interne n'existe pas. Au second appel de curl, vous devriez voie que la base d edonnées interne a été créée.

Installation de Chronograf

Chronograf est l'interface utilisateur de la pile TICK.

$ sudo aptitude install chronograf
$ sudo systemctl enable chronograf
$ sudo systemctl start chronograf

Vous pouvez ensuite vous rendre avec votre navigateur à l'adresse http://<IP de votre raspberry>:8888/. L'écran de configuration de chronograf vous est alors présenté. Il faut entrer les informations de connexion à InfluxDB. Nous n'avons pas mis en place de gestion de droit sur InfluxDB, vous pouvez donc laisser vide les champs utilisateur de mot de passe.

Et voilà, vous pouvez commencer à jouer avec l'interface de visualisation des données. Il y a déjà les données de métrologie de la base de données influxdb (nombre de requêtes exécutées, durée des requêtes, nombre d'accès http, etc...) dans la base de données "_internal.monitor"

Il reste maintenant à ajouter des données.

Installation de Telegraf

Telegraf s'installe de la même façon que Chronograf :

$ sudo aptitude install telegraf
$ sudo systemctl enable telegraf
$ sudo systemctl start telegraf

Telegraph est construit autour de plugins d'entrée (inputs) pour accéder aux données des mesures, et des plugins de sortie (outputs) pour aller stocker les données. Les plugins de Telegraf sont écrits en GO.

Il y a toutes sortes de plugins d'entrée pour obtenir des mesures sur une quantité incroyable de systèmes (Apache, Elasticsearch, Docker, etc...). La documentation de Telegraf comporte le descriptif de chacun des plugins qui viennent avec telegraf.

Il y a également toutes sortes de plugins de sortie pour stocker les données récupérées dans différents types de bases de données. Par défaut InfluxDB, mais aussi (non exhaustif) Kafka, Graylog, Elasticsearch, Datadog ou des fichiers plats.

Dans la configuration par défaut de telegraf, les plugins d'entrée suivants sont activés et collectent des métriques systèmes sur la machine sur laquelle Telegraf tourne :

cpu
disk
diskio
kernel
mem
processes
swap
system

Et les données sont stockées par défaut dans une base de données telegraf d'InfluxDB sur l'hôte local (localhost:8086) sans authentification. ça tombe bien parce que c'est notre cas, nous n'avons donc pas besoin de toucher à la configuration de Telegraf pour commencer à récolter des données et les voir dans Chronograf. La configuration de Telegraf se trouve sous /etc/telegraf.

Telegraf construit également un dashboard système par défaut de la machine locale dans Chronograf. Vous le retrouverez sous Host List.

Et maintenant que vous avez plein de données toutes fraiches, vous pouvez jouer à les explorer (Data Explorer) et à faire vos propres tableaux de bord (dashboards). Notez que la partie Data Explorer est beaucoup plus limitée, je n'ai notamment pas trouvé moyen de changer le type de graphe alors que c'est enfantin dans les dashboards.

Installation de Kapacitor

Maintenant que nous avons des données, pourquoi ne pas en profiter pour alarmer sur dépassement de seuil ? C'est le travail de Kapacitor.

$ sudo aptitude install kapacitor
$ sudo systemctl enable kapacitor
$ sudo systemctl start kapacitor

Vous devez ensuite "brancher" Kapacitor sur InfluxDB et Chronograf. Pour cela, dans l'interface de Chronograf, allez dans Configuration et dans la colonne Active Kapacitor, cliquez sur le bouton Add Config de votre source de données.

Saisissez ensuite les informations de connexion à Kapacitor (Normalement les valeurs préremplies sur suffisantes) et validez.

Enfin, scrollez en bas de l'écran et ajoutez des moyens d'alerting. Ici par exemple la configuration de l'alerting par mail :

Et voilà ! Vous pouvez maintenant définir des alertes dans Alerting->Alert Rules

Ajoutons une source de données

Bon, on a la base, mais maintenant, on veut ajouter nos données à nous. Par exemple la température du CPU du Raspberry Pi. On peut la lire facilement dans /sys/class/thermal/thermal_zone0/temp (c'est une valeur multipliée par 1000).

On va donc créer un petit programme en python qui va lire cette valeur et retourner les données en format json. On crée pour cela le fichier /etc/telegraf/pi_temp.py avec le contenu suivant :

#!/usr/bin/env python3

import json

# This gets the CPU temp
f = open('/sys/class/thermal/thermal_zone0/temp', 'r')
temp=f.readline()
temp=int(temp) / 1000
f.close


json_body = [
{
    "sensor": "cpu",
    "temperature" : temp
}
]

print(json.dumps(json_body, indent=2, sort_keys=True))

On le rend executable et on teste :

$ cd /etc/telegraf/
$ chmod +x pi_temp.py
$ ./pi_temp.py
[
  {
    "sensor": "cpu",
    "temperature": 45.084
  }
]

Il n'y a plus alors qu'à utiliser le plugin exec de Telegraf pour que les données soient automagiquement envoyées toutes les 10 secondes dans InfluxDB. Modifiez la section inputs.exec du fichier /etc/telegraf/telegraf.conf comme cela :

# # Read metrics from one or more commands that can output to stdout
[[inputs.exec]]
  ## Commands array
  commands = [
    "/etc/telegraf/pi_temp.py"
  ]

  ## Timeout for each command to complete.
  timeout = "5s"

  ## measurement name suffix (for separating different commands)
  name_prefix = "temperature_"

  ## Data format to consume.
  ## Each data format has its own unique set of configuration options, read
  ## more about them here:
  ## https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md
  data_format = "json"

  ## List of tag names to extract from top-level of JSON server response
    tag_keys = [
        "sensor"
    ]

Et voilà, vous aurez la mesure de température du CPU du Raspberry Pi dans InfluxDB.

Amusez vous bien avec votre pile TICK et les séries temporelles !

BreizhC@mp 2016

2016-03-24T22:28:00+01:00

Introduction

Lors du BreizhCamp 2016, il y avait une erreur d'impression de la banderole d'accueil.

@breizhcamp nous y sommes 👍 pic.twitter.com/uHqHWQKlaR
— CODE 42 (@CODE_42) 23 mars 2016

Cela s'est vite transformé en jeu concours lors de la keynote : trouver la fin de la banderole. Défi relevé, voici un tour d'horizon du Breizhcamp 2016 s'appuyant sur vos twits avec un clin d'oeil à la banderole à chaque fois.

BreizhC@...rtons, les conférences qui tiennent dans des boites

Bref, le mec d'UPS et moi on se fait la bise maintenant (cc @breizhcamp) pic.twitter.com/sWsKDdheI1
— Nicolas De loof (@ndeloof) 19 mars 2016

BreizhC@...méra, si tu viens pas, c'est filmé

Je suis jaloux pic.twitter.com/EH4yzyTMSA
— Nicolas De loof (@ndeloof) 23 mars 2016

BreizhC@...ses, pour y mettre le programme

Plus qu'à remplir les cases pour avoir un programme #SelectionEnVue pic.twitter.com/rzxRuhZBlP
— BreizhCamp (@breizhcamp) 16 février 2016

BreizhC@...issière, un rève de gosse

Après le choix du programme du @breizhcamp , on passe à la caisse pour scanner le programme ! #IoT pic.twitter.com/Gybdat6zg6
— Sébastien Brousse (@seb_brousse) 18 février 2016

BreizhC@...nicule, enfin presque...

Vous êtes sûr que le Breizhcamp commence bien aujourd'hui ? #bzhcmp pic.twitter.com/dtMIJBGtA9
— Sébastien PRUNIER (@sebprunier) 23 mars 2016

BreizhC@...ca dans les couches de bébé

Les couches de bébé dans le bigdata avec @vcasse au #BreizhCamp pic.twitter.com/Sgz3X4arbw
— Sebastien BLAISOT (@SebBLAISOT) 24 mars 2016

BreizhC@...sseroles, des talks et des bons petits plats

Merci le @breizhcamp ! On c'était top cette journée !! A demain #bzhcmp pic.twitter.com/gLDjPe94y4
— Nicolas Pennec (@NicoPennec) 24 mars 2016

BreizhC@...deaux, des conférences et des goodies

Trop chic au #BreizhCamp, on a des cadeaux! Merci @jfrog :) pic.twitter.com/CEjFzjfSFR
— Maxime Odye (@MaxOdye) 24 mars 2016

BreizhC@...fé, ça réveille entre deux conf

Vous l'avez adoré, il fait son come back : le café ! sinon le thé glacé et la citronnade sont excellents pic.twitter.com/COMzqrUFiV
— BreizhCamp (@breizhcamp) 24 mars 2016

BreizhC@...nard, mais un super canard !

Le @breizhcamp avec en guest @CommitStrip et #CanardMan !!! #bzhcmp pic.twitter.com/VCLCxNDCob
— Nicolas Pennec (@NicoPennec) 24 mars 2016

BreizhC@...sual, l'équipe OVH en mode beaux gosses

Décontracté, mais chic

La Team #Ovh au #BreizhCamp ! pic.twitter.com/j8G0SR4f3l
— Sou MOOKIEN (@Sou_OVH) 24 mars 2016

BreizhC@...sse gueule, sur de drôles d'engins à roulettes

Au @BreizhCamp ! Venez ns rencontrer pr parler Expertise & tentez votre chance de remporter le gros lot #BreizhCamp pic.twitter.com/fhWjY54BfE
— SOFTEAM Cadextan (@SofteamCadextan) 24 mars 2016

Breizhc@...rburant, pour décompresser de la journée

Sushi/bière, Merci #Breizhcamp ! cc @dadoonet @waxzce @snicoll @sdeleuze pic.twitter.com/rlXbxjDPoS
— Laurent Doguin (@ldoguin) 24 mars 2016

BreizhC@...ché, le problème d'impression

Un problème d'impression ? Quel problème ? @breizhcamp #BreizhCamp pic.twitter.com/V1zQYqq67g
— David Pilato (@dadoonet) 24 mars 2016

BreizhC@...amelott, la conf où c'est pas faux

je ne peux m'empêcher d'associer ces 2 twits

@SebBLAISOT @ndeloof @breizhcamp Tu as aussi BreizhC@melott la conf où c'est pas faux ou encore BreizhC@melott la conf où on en a gros !
— Frederic Alix (@fredericalix) 24 mars 2016

Quand ils sortent le café au @breizhcamp pic.twitter.com/ZtXA3iaUNX
— Guillaume A. (@GuiGuiSoft) 24 mars 2016

Un script pour superviser l'expiration des enregistrements DNSSEC

2014-06-13T13:00:00+02:00

Dans mon précédent article sur la mise en place de dnssec, je vous avais renvoyé pour la partie supervision de l'expiration des enregistrements dnssec sur un article de Stéphane Bortzmeyer expliquant comment le mettre en place sous icinga.

Comme tout le monde n'a pas icinga sous la main, voici un petit script de ma composition qui vous enverra un mail lorsqu'un enregistrement RRSIG arrive à expiration (et donc que quelque chose s'est mal passé dans la resignature automatique par bind)

#!/bin/bash

### CONFIGURATION DEFAULTS ###

# Warn if an RRSIG expires in less than this time period
WARN_TIME="4 weeks"

# print warnings to STDOUT (true or false)
WARN_STDOUT=false

# Send warnings by mail (true or false)
WARN_MAIL=true

# Where to send mail alerts (if WARN_MAIL set to true)
SEND_WARNING_MAIL_TO="hostmaster@example.tld"
SEND_WARNING_MAIL_FROM="hostmaster@example.tld"

# Command to get zone list. Adapt to your settings.
ZONE_LIST_COMMAND="ls /etc/bind/keys"

# Signed zone file path for zone ${zone}
# Use single quotes to avoid variable expansion
ZONE_FILE_PATH='/etc/bind/zones/db.${zone}.signed'



### DO NOT MODIFY ANYTHING BELOW UNLESS YOU EXACTLY KNOW WHAT YOU ARE DOING ###


# Usage function
function usage {
  echo "USAGE: $(basename $0) [-h] [-d] [-e <warning_time>] [-m] [-f <sender>] [-t <destination>] [-s] [-q]"
  echo ""
  echo "Options:"
  echo "  -h, --help    print usage message and exit"
  echo "  -d, --debug   debug mode, show expiration date of older RRSIG record for each domain even if not in"
  echo "                warning time period (only on STDOUT)"
  echo "  -e <time>,    warn if RRSIG expires in the given time period"
  echo "  --expirein <time>"
  echo "  -m, --mail    send warning by mail"
  echo "  -f <sender>,  set warning mail sender address"
  echo "  --from <sender>"
  echo "  -t <dest>,    set warning mail destination address"
  echo "  --to <dest>"
  echo "  --nomail      do NOT send warning by mail even if enabled by default"
  echo "  -s, --stdout  show warnings on stdout"
  echo "  -q, --quiet   do NOT show warnings on stdout, even if enabled by default"
  echo ""
}

DEBUG=false

# Options parsing

PARSED_OPTIONS=$(getopt -n "$0"  -o hde:msqf:t: --long "help,debug,expirein:,mail,stdout,quiet,from:,to:,nomail,nostdout"  -- "$@")

if [ $? -ne 0 ];
then
  echo "" >&2
  usage >&2
  exit 1
fi

eval set -- "$PARSED_OPTIONS"

while true; do
  case "$1" in
    -h|--help)
      usage >&2
      exit 1
      ;;
    -d|--debug)
      DEBUG=true
      shift
      ;;
    -e|--expirein)
      case "$2" in
        "") shift 2 ;;
        *) WARN_TIME=$2 ; shift 2;;
      esac
      ;;
    -m|--mail)
      WARN_MAIL=true
      shift
      ;;
    -f|--from)
      case "$2" in
        "") shift 2 ;;
        *) SEND_WARNING_MAIL_FROM=$2 ; shift 2;;
      esac
      ;;
    -t|--to)
       case "$2" in
        "") shift 2 ;;
        *) SEND_WARNING_MAIL_TO=$2 ; shift 2;;
      esac
      ;;
    --nomail)
      WARN_MAIL=false
      shift
      ;;
    -s|--stdout)
      WARN_STDOUT=true
      shift
      ;;
    -q|--quiet|--nostdout)
      WARN_STDOUT=false
      shift
      ;;
    --)
      shift
      break
      ;;
  esac
done

# Warn time limit since epoch
WARN_EPOCH=$(date --date "+${WARN_TIME}" +"%s")

# For each zone
for zone in $( $ZONE_LIST_COMMAND ); do

  # Get expiration time of next expiring RRSIG
  N=$(named-compilezone -q -D -f raw -o - ${zone} $(eval echo ${ZONE_FILE_PATH}) | grep "IN RRSIG" |awk '{ print $9 }' |sort -n |head -1)

  # Transform to epoch (usefull for date comparison)
  EXP_EPOCH=$(date --date "${N:4:2}/${N:6:2}/${N:0:4} ${N:8:2}:${N:10:2}:${N:12:2}" +"%s")
  EXP_HUMANREADABLE=$(LANG=C date --date "${N:4:2}/${N:6:2}/${N:0:4} ${N:8:2}:${N:10:2}:${N:12:2}")

  # Warn if in expiration warning time
  if [ ${EXP_EPOCH} -le ${WARN_EPOCH} ]; then
    WARN_MSG="\

DNSSEC EXPIRATION WARNING
-------------------------

Domain ${zone} has an RRSIG expiring in less than ${WARN_TIME}
Next expiration date on (${EXP_EPOCH}) ${EXP_HUMANREADABLE}
"
    $WARN_STDOUT && echo -e "${WARN_MSG}"
    if $WARN_MAIL; then
      WARN_MAIL_HEADERS="\
From: ${SEND_WARNING_MAIL_FROM}
To: <${SEND_WARNING_MAIL_TO}>
Subject: ***DNSSEC RRSIG EXPIRATION WARNING ***
Date: $(date -R)
"
      echo -e "${WARN_MAIL_HEADERS}\n${WARN_MSG}" | sendmail -t -oi -f "${SEND_WARNING_MAIL_FROM}"
    fi
  else
    $DEBUG && echo "Next Expiration of zone ${zone} (no warning) on (${EXP_EPOCH}) ${EXP_HUMANREADABLE}"
  fi
done
exit 0

Tout ce que vous avez à faire, c'est de déposer ce scripts dans /etc/cron.daily (n'oubliez pas de le rendre exécutable) et adapter les valeurs par défaut en début de script et hop, vous recevrez un mail 3 jours avant l'expiration des enregistrements RRSIG.

La variable WARN_TIME contient la période de temps dans laquelle la présence de l'expiration d'un enregistrement RRSIG provoque une alarme. C'est une "date string" compréhensible par la commande date. Par exemple, 3 days provoquera une alarme si un enregistrement RRSIG arrive a expiration dans les 3 prochains jours. On peut également utiliser "Next thursday" pour les domaines dont un enregistrement RRSIG arrive a expiration avant jeudi prochain, ou bien "next month".

Les variables WARN_STDOUT et WARN_MAIL servent respectivement à afficher les warning sur la sortie standard ou à les envoyer par mail.

Les variables SEND_WARNING_MAIL_TOet SEND_WARNING_MAIL_FROM servent à définir respectivement le(s) destinataire(s) et l'expéditeur (d'en-tête et d'enveloppe) du mail d'alarme.

La variable ZONE_LIST_COMMANDindique au script comment obtenir la liste des domaines à checker. Pour mon cas, chaque domaine a ses clés dans un sous-répertoire spécifique de /etc/bind/keys dont le nom est le nom du domaine. Ainsi, je me contente de lister le contenu de /etc/bind/keys. Toute autre commande qui fournit la liste des domaines à vérifier fera l'affaire. Au pire, le cat d'un fichier texte.

Enfin, la variable ZONE_FILE_PATH indique le chemin du fichier de zone signé pour la zone ${zone}. Pensez à utiliser des simples quotes pour éviter l'expansion de la variable ${zone}.

J'ai préféré baser ce script sur le contenu des fichiers de zone signés plutôt que sur une interrogation du DNS.

Vous pouvez aussi l'appeler manuellement avec les options qui vont bien :

USAGE: dnssec-monitor [-h] [-d] [-e <warning_time>] [-m] [-f <sender>] [-t <destination>] [-s] [-q]

Options:
  -h, --help    print usage message and exit
  -d, --debug   debug mode, show expiration date of older RRSIG record for each domain even if not in
                warning time period (only on STDOUT)
  -e <time>,    warn if RRSIG expires in the given time period
  --expirein <time>
  -m, --mail    send warning by mail
  -f <sender>,  set warning mail sender address
  --from <sender>
  -t <dest>,    set warning mail destination address
  --to <dest>
  --nomail      do NOT send warning by mail even if enabled by default
  -s, --stdout  show warnings on stdout
  -q, --quiet   do NOT show warnings on stdout, even if enabled by default

Par exemple, pour afficher le résultat sur la sortie standard, ne pas envoyer de mail, alarmer s'il y a une expiration dans les 16 prochains jours, et afficher les prochaines dates d'expiration pour chaque domaine même s'il n'y a pas d'expiration dans la période indiquée :

$ ./dnssec-monitor --nomail -s -e "16 days" -d
Next Expiration of zone example.tld (no warning) on (1404131654) Mon Jun 30 14:34:14 CEST 2014
Next Expiration of zone example2.tld (no warning) on (1404130965) Mon Jun 30 14:22:45 CEST 2014
Next Expiration of zone example3.tld (no warning) on (1404133571) Mon Jun 30 15:06:11 CEST 2014

DNSSEC EXPIRATION WARNING
-------------------------

Domain example4.tld has an RRSIG expiring in less than 16 days
Next expiration date on (1403990327) Sat Jun 28 23:18:47 CEST 2014

Introduction à DNSSEC

2014-05-30T18:00:00+02:00

Introduction

Le système DNS permet de faire l'association entre un nom humainement comprésensible et une adresse IP (et vice-versa). Le fonctionnement du DNS a été défini et implémenté dans les années 80, à une époque où la sécurité sur internet n'était pas encore une préoccupation.

De ce fait, par design, le système DNS, par son protocole de base, est vulnérable, en ce sens qu'il est basé sur la confiance. Nos ordinateurs posent des questions au serveur DNS, reçoivent des réponses, mais n'ont pas les moyens de s'assurer que la réponse qu'ils reçoivent est légitime. l'extension DNSSEC, définie dès 1999 par la RFC 2535 et complété par les RFC 4033, RFC 4034 et RFC 4035, permet de combler ce manque en introduisant une chaine de signature numérique jusqu'à la signature des enregistrements d'une zone DNS par son propriétaire, chaine de singature qui pourra être vérifiée par quiconque aura besoin de l'information.

Nous allons donc voir comment s'assurer que notre resolveur vérifie les signatures DNSSEC et si non, comment le mettre en place, puis comment signer sa zone dns et la gérer.

Cet article s'appuie sur bind 9.9.5 sous ubuntu LTS 14.04.

Introduction
S'assurer que son serveur DNS vérifie les signatures DNSSEC
Configuration d'un bind récursif pour vérifier les signatures DNS
Mise en place d'une zone signée
Maintenance d'une zone signée
Références

S'assurer que son serveur DNS vérifie les signatures DNSSEC

La première des choses consiste à vérifier que le serveur DNS que votre poste utilise vérifie bien les signatures DNSSEC.

Nous allons donc effectuer une requête positive et une requête négative pour s'assurer à la fois que les informations correctement signées sont vérifiées comme tel et que les informations mal signées conduisent à un échec (SERVFAIL), échec qui ne se présente pas quand on désactive la vérification de signature DNSSEC :

$ dig sigok.verteiltesysteme.net

; <<>> DiG 9.9.5-3-Ubuntu <<>> sigok.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57950
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

[...]

$ dig sigfail.verteiltesysteme.net

; <<>> DiG 9.9.5-3-Ubuntu <<>> sigfail.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8675
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

[...]

$ dig +cd sigfail.verteiltesysteme.net

; <<>> DiG 9.9.5-3-Ubuntu <<>> +cd sigfail.verteiltesysteme.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55863
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN  A

;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN A   134.91.78.139

[...]

Dans le premier cas de figure, avec une signature correcte, le flag AD (Authenticated Data) dans la réponse indique qu'une signature dnssec a été vérifiée correctement.

Dans le second cas, le serveur DNS a refusé de nous répondre (SERVFAIL) parce que la signature est incorrecte.

Enfin, dans le troisième cas, nous avons demandé à notre résolveur de ne pas vérifier les signatures DNSSEC (CD = Check Disabled) et nous obtenons bien une réponse, c'est donc bien une erreur DNSSEC qui provoque le SERVFAIL dans le deuxième cas de figure. La présence du flag CD dans la réponse indique que la vérification DNSSEC a été désactivée.

Mode livre dont vous êtes le héro :

Si vous obtenez le même résultat, bravo, vous utilisez un résolveur DNS qui vérifie les signatures DNSSEC, vous pouvez passer directement à la mise en place d'une zone signée.

Dans le cas contraire, vous aurez une réponse à la deuxième requête, cela signifie que votre résolveur ne vérifie pas les signatures DNSSEC. Passez au chapitre suivant qui vous expliquera comment configurer un bind récursif pour vérifier les signatures DNSSEC.

Configuration d'un bind récursif pour vérifier les signatures DNS

En supposant que vous ayez déjà un bind récursif pour la résolution de nom, activer la validation DNSSEC est trivial.

Il suffit de s'assurer que la clé de la root zone '.' est bien incluse dans votre distribution de bind (généralement dans /etc/bind/bind.keys) et d'ajouter dans le fichier named.conf (/etc/bind/named.conf.options sous ubuntu) les 2 directives suivantes :

        dnssec-enable yes;
        dnssec-validation auto;

Une relance de bind est nécessaire pour la prise en compte de ces directives :

$ service bind9 restart

Tester comme indiqué au chapitre précédent et voilà !

Il est à noter que la plupart des relais DNS des box de connexion à internet (et des serveurs DNS de nos FAI) ne permettent pas la validation dnssec c'est pourquoi il est plus sûr de disposer de son propre caching-recursive-name-server plutôt que de s'appuyer sur sa box.

Si vous n'utilisez pas bind mais Unbound ou un DNS microsoft, vous trouverez des éléments de configuration dans ce document.

Mise en place d'une zone signée

Prérequis

Pour héberger une zone DNS signée, il vous faut :

Un nom de domaine utilisant un TLD gérant DNSSEC. Cela peut se vérifier en utilisant la commande dig ds tld (par exemple dig ds com pour le TLD .com) qui rendra des enregistrements DS si tld gère dnssec.
Un serveur DNS, qui sait gérer des zones signées. Nous utiliserons ici bind. Depuis sa version 9.9, bind sait gérer seul tout le cycle de signature. C'est la méthode la plus simple et la moins risquée, c'est donc celle que nous utiliserons. Ainsi, nous n'aurons pas à nous préoccuper de l'expiration des enregistrements signés, à penser à signer la zone à chaque modification, etc...
Un registrar qui vous permet de publier les enregistrements DS. Vérifiez le avant de commencer, si votre registrar ne gère pas dnssec, vous ne pourrez pas aller jusqu'au bout de la mise en place de la chaine de confiance.

Une zone basique pour commencer

Supposons que votre dns héberge déjà une zone. Pour l'exemple de cet article, nous partirons d'une zone basique example.tld avec une entrée test.example.tld dont l'adresse IPv4 est 1.2.3.4. Evidemment, le reste ne fonctionnera que s'il s'agit d'un vrai nom de domaine enregistré et connu sur internet.

$TTL 86400
@       IN      SOA     ns1.example.tld. hostmaster.example.tld. (
                        2014052901      ; serial number of this zone file
                        8H              ; slave refresh (1 day)
                        30M             ; slave retry time in case of a problem (2 hours)
                        4W              ; slave expiration time (4 weeks)
                        1H )            ; minimum caching time in case of failed lookups (1 hour)

        IN      NS      ns1.example.tld.
test    IN  A   1.2.3.4

Définie dans la configuration de bind de la façon suivante :

zone "example.tld" {
    type master;
    file "/etc/bind/db.example.tld";
};

Nous pouvons tester que l'entrée test.example.tld fonctionne bien :

root@vm-xubuntu:/etc/bind# dig @serveur_dns test.example.tld

; <<>> DiG 9.9.5-3-Ubuntu <<>> @serveur_dns test.example.tld
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21659
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.example.tld.      IN  A

;; ANSWER SECTION:
test.example.tld.   30  IN  A   1.2.3.4

;; AUTHORITY SECTION:
example.tld.        30  IN  NS  ns1.example.tld.

;; Query time: 32 msec
;; SERVER: xxxxx
;; WHEN: Thu May 29 22:32:34 CEST 2014
;; MSG SIZE  rcvd: 98

Bien, maintenant que nous avons une zone qui fonctionne, nous allons pouvoir la signer.

Génération des clés

Il vous faudra 2 clés, l'une dite KSK (Key Signing Key), l'autre appelée ZSK (Zone Signing Key). La première sert à signer la seconde, la seconde sert à signer les enregistrements de la zone.

Si vous avez plusieurs zones, vous aurez besoin d'une KSK, et d'une ZSK par zone à minima.

Commençons par créer un répertoire où nous stockerons les clés

$ mkdir -p /etc/bind/keys
$ chgrp bind /etc/bind/keys
$ chmod u+rwx,g+srx,o-rwx /etc/bind/keys
$ cd /etc/bind/keys

Les permissions utilisées permettent de s'assurer que bind pourra bien lire les clés.

Créons la KSK :

$ dnssec-keygen -a RSASHA256 -3 -f KSK -b 4096 example.tld
Generating key pair.....................................................................................++ ...............................++ 
Kexample.tld.+008+17107

La génération de la clé peut être particulièrement longue si votre machine n'a pas assez d'entropie. Si tel est le cas, générez de l'entropie (accès disques, frappes au clavier, ou installation du démon haveged)

Ensuite, générons une ZSK :

$ dnssec-keygen -a RSASHA256 -3 -b 2048 example.tld
Generating key pair.......+++ .......+++ 
Kexample.tld.+008+25266

On utilise une taille de clé de 2048 bits minimum car en dessous, ~~nous ne pourrons pas utiliser NSEC3 et serons limité à NSEC~~ c'est moins bien. (on me signale dans l'oreillette¹ que NSEC3 fonctionne aussi avec des clés de 1024 bits).

$ ls
Kexample.tld.+008+17107.key       Kexample.tld.+008+25266.key
Kexample.tld.+008+17107.private   Kexample.tld.+008+63666.private

Nos deux clés sont créées, la KSK porte la référence (key ID) 17107 et la ZSK porte la référence 25266. Si vous ne savez plus quelle est la clé KSK de la clé ZSK, regardez le contenu du fichier .key, c'est indiqué dedans !

Configuration de Bind pour signer la zone

Ensuite, il faut configurer bind (la partie options dans /etc/bind/named.conf.options et la partie concernant la zone dans /etc/bind/named.conf.local) :

options {
    directory "/etc/bind";
    key-directory "/etc/bind/keys";
    recursion no;
    dnssec-enable yes;
};

zone "example.tld" in {
    inline-signing yes;
    auto-dnssec maintain;
    update-policy local;
    type master;
    file "dnssec.fr";
    ...
}

La configuration proposée ici est la plus simple : bind se charge de tout tout seul, nous n'avons qu'à maintenir un fichier de zone non signé.

La directive key-directory permet d'indiquer à bind où il doit aller chercher les clés. Cette directive peut être mise dans la section zone. C'est particulièrement utile si on utilise un répertoire différent pour stocker les clés de chaque domain.

Il faut recharger bind pour prise en compte de ces modifications

$ rndc reload

On teste ensuite que bind renvoit bien des enregistrements signées

$ dig +dnssec test.example.tld

; <<>> DiG 9.9.5-3-Ubuntu <<>> +dnssec test.example.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42791
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;test.example.tld.      IN  A

;; ANSWER SECTION:
test.example.tld.   30  IN  A   1.2.3.4
test.example.tld.   30  IN  RRSIG   A 8 3 30 20140628235217 20140529231424 16140 example.tld. M+tIdL9wvT3s0rmvVYk8Rpe/+mDPeow75KQ3cMWi8THuP/yD+nRj01hU HZZzzCF4asrq+VRhwGE1rjLxdR2FPs9X7qF6IeCFrVNo2opxkSSsNxoq KJTGA60dbudJOShIlqvllgu6SNaes2WiUaD7s4O71UckAnG0nbVeT8Nw mEtQ2aJ6BvUONOWVAwwMNhhI8oPfZR5fVu79conWTTn/++8Y4EFD5P0F ozfdVszrrDM2tBsvv7DtX9arGqsXt0COlOz0DU8LTWJ8OVXTjku5Aetf HPpkHzhJcjX7+3CeOPfc16bNWbn2d2fs9pGj1Y9z4jNvewnnIwimcYbn 0lBbkA==

;; AUTHORITY SECTION:
example.tld.        30  IN  NS  ns1.example.tld.
example.tld         30  IN  RRSIG   NS 8 2 30 20140628235217 20140529231424 16140 example.tld. K+Gi5ETPhM0pwmf4FyuL2ADaRJvkdteU0FWnrh+HLZl7mrynA4mxk6xQ IxiX3DGLpNatSax+3UzVL8itBuNzuASRXblo07dcZ88b/lJTN0XBSzcR Erjz57VYwh06W57LuiWi/YdvYO74COWGWfStmOvQ84x0wSs0VGDJnLgS Ly67lCBrLPf48AK2bQUUMvgDWhpHMr1kjgAYZZb+m/lLDMpHPU6xbAns xmkwySBQhLnNWxy9u6gzdFzn0zW5yQ/lzfoX1r5bbC6vMjaL0RMUE7Pa jeseofK021PmWB4xJM0c/Bx60OBher5bwceC9Zkr7xQhhqcKR60jlVJJ Q7ivRA==

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 30 02:18:36 CEST 2014
;; MSG SIZE  rcvd: 700

...

Nous voyons bien ici les enregistrements RRSIG, bind fait bien son travail de signature.

Bind a d'ailleurs créé un nouveau fichier de zone suffixé par .signed qui contient la version signée et qui peut être lu avec la commande :

$ named-compilezone -D -f raw -o - example.tld db.example.tld.signed

Utiliser NSEC3 plutôt que NSEC

Pour l'instant, notre zone est signée en utilisant NSEC (par défaut). Nous pouvons le vérifier par la présence d'engistrements de type NSEC retournés par la commande précédente

Pour utiliser NSEC3, nous devons procurer à bind le sel à utiliser. Commençons par générer le sel :

$ dd if=/dev/random bs=1 count=10 | md5sum | cut -c1-8
10+0 enregistrements lus
10+0 enregistrements écrits
10 octets (10 B) copiés, 0,00278809 s, 3,6 kB/s
49d135ce

Nous allons donc utiliser le sel 49d135ce

$ rndc signing -nsec3param 1 0 10 49d135ce example.tld
request queued

et voilà. Nous avons désormais des enregistrements NSEC3 dans le fichier de zone.

Publication dans la zone parente

Pour que la chaine de signature DNSSEC soit complète, il reste à publier l'enregistrement DS (condensat de la KSK) au niveau du TLD. Ces engegistrements seront eux-même signés par la clé du TLD.

La première des choses consiste à générer ces enregistrements DS à partir de la KSK :

$ dnssec-dsfromkey Kexample.tld.+008+17107.key
example.tld. IN DS 17107 8 1 E89E85FFD0377CBC50BBD36F3275B460FD6B5A75
example.tld. IN DS 17107 8 2 08E46F22CE866971DC41A4A770A35E6EF3FA659EBB9FEC5DA81B716BD68F7B82

Maintenant que nous avons ces 2 enregistrements, il nous faut les déclarer.

L'interface de votre registrar devrait vous permettre de déclarer ces enregistrements. Si tel n'est pas le cas, il ne vous reste plus qu'à changer de registrar.

S'il ne vous permet pas de copier/coller la ligne entière mais présente des champs à remplir, voici les informations contenues dans ces enregistrements :

17107 : Il s'agit de la Key ID (identifiant de clé)
8 : ceci est l'algorithme de chiffrement. Ici 8 = RSHSHA256. On rencontre aussi parfois 5 = RSASHA1
1 ou 2 : le type de condensat : 1 = SHA1, 2 = SHA256
la longue suite hexadécimale : il s'agit du condensat de la clé

Vérifier le bon fonctionnement

Une fois tout ceci effectué, cela devrait normalement être fonctionnel. Vous pouvez le vérifier sur le debugger DNSSEC verisign. Si vous avez des points verts partout, bravo, votre domaine est maintenant signé par DNSSEC.

L'utilitaire ZoneCheck dispose également d'une option pour tester la configuration DNSSEC d'un domaine (entre autres choses)

L'interrogation d'un autre serveur dns récursif prenant en charge la vérification DNSSEC présentera le flag AD (Authenticated Data), votre domaine est maintenant signé grâce à DNSSEC.

Maintenance d'une zone signée

Modification du contenu de la zone

Lorsque vous voulez désormais modifier une zone signée automatiquement par bind, il vous faut freezer la zone, faire vos modifications, puis libérer la zone, ce qui provoquera un rechargement et une resignature par bind. Cela ne vous dispense évidemment pas de mettre à jour le serial de la zone.

$ rndc freeze example.tld

[...Éditer le fichier de zone...]

$ rndc thaw example.tld
A zone reload and thaw was started.
Check the logs to see the result.

Supervision

Il est important de superviser que les opérations de resignature régulières des zones fonctionnent correctement, car en cas d'expiration des enregistrements RRSIG, votre domaine ne serait plus joignable.

Je vous renvoie pour cela à cet excellent article de stéphane Bortzmeyer qui détaille très clairement comment il a mis en place la supervision de l'expiration des enregistrements RRSIG à l'aide d'un script perl et d'icinga.

Rotation de clé

Les clés doivent être remplacées régulièrement. On parle de key-rollover. Plus souvent pour la ZSK, qui est plus petite et surtout qui n'est pas publiée dans les DNS de niveau supérieur (donc plus facile à remplacer).

Je vous conseille un remplacement des ZSK tous les 6 mois et un remplacement de la KSK tous les 2 ans. Ceci est bien entendu à ajuster en fonction de la criticité de votre domaine (et du temps dont vous disposez).

Une rotation de clé est toujours une opération minutieuse qu'il vaut mieux avoir répété avant sur un domaine de faible importance car les risques de se prendre les pieds dans le tapis sont grands, et cela pourrait rendre votre domaine inutilisable pendant quelques temps.

Pour la rotation de la ZSK, on commence par créer une nouvelle ZSK, puis on indique que la clé doit être retirée dans 2 jours et supprimée dans 6 jours (à ajuster en fonction des TTL) :

$ # Génération de la nouvelle ZSK
$ dnssec-keygen -a RSASHA256 -b 2048 example.tld
Generating key pair...............................................+++ ....................................................................................................................+++ 
Kexample.tld.+008+21999

$ # On indique que la clé doit être retirée dans 2 jours
$ dnssec-settime -I +2d Kexample.tld.+008+25266.key
dnssec-settime: warning: Permissions on the file ./Kexample.tld.+008+25266.private have changed from 0640 to 0600 as a result of this operation.
./Kexample.tld.+008+25266.key
./Kexample.tld.+008+25266.private

# On indique que la clé doit être supprimée dans 6 jours
$ dnssec-settime -D +6d Kexample.tld.+008+25266.key
./Kexample.tld.+008+25266.key
./Kexample.tld.+008+25266.private

$ # On ajuste les permissions pour que bind puisse toujours lire les clés
$ chmod g+r *

Bind fait normalement le nécessaire ensuite.

Pour le remplacement de la KSK, il y a 2 étapes de plus : d'une part il faut révoquer immédiatement la clé, d'autre part, il faut publier auprès de son registrar les enregistrements DS correspondant à la nouvelle KSK :

$ # Génération de la nouvelle KSK
$ dnssec-keygen -a RSASHA256 -f KSK -b 2048 example.tld
Generating key pair...+++ .............................................................................+++ 
Kexample.tld.+008+14614

$ # Révocation immédiate de la KSK
$ dnssec-settime -R +0 Kexample.tld.+008+17107.key
dnssec-settime: warning: Permissions on the file ./Kexample.tld.+008+17107.private have changed from 0640 to 0600 as a result of this operation.
./Kexample.tld.+008+17107.key
./Kexample.tld.+008+17107.private

$ # On indique que la clé doit être retirée dans 2 jours
$ dnssec-settime -I +2d Kexample.tld.+008+17107.key
./Kexample.tld.+008+17107.key
./Kexample.tld.+008+17107.private

# On indique que la clé doit être supprimée dans 6 jours
$ dnssec-settime -D +6d Kexample.tld.+008+17107.key
./Kexample.tld.+008+17107.key
./Kexample.tld.+008+17107.private

$ # On ajuste les permissions pour que bind puisse toujours lire les clés
$ chmod g+r *

$ # On génère les nouveaux enregistrement DS à publier chez notre registrar
$ dnssec-dsfromkey Kexample.tld.+008+14614.key 
example.tld. IN DS 14614 8 1 F14DCF5DA74A6A2727A5DF570C98BB2186CD241B
example.tld. IN DS 14614 8 2 B4CAF28F7BA14AA99E8C18DD87604ABBC1D18F4EE1C69D84E8BE33B7E439132F

On prendra évidemment bien soin de superviser le tout dans les jours qui suivent pour s'assurer que l'opération se passe bien.

Une fois les 6 jours passés, on pourra supprimer les enregistrements DS de l'ancienne clé, effacer les fichiers .key et .private correspondants. Faire un peu de ménage, quoi.

Références

https://twitter.com/bortzmeyer/status/473350103584231424 ↩

Réflexions sur l'idempotence et les déploiements automatisés

2014-01-24T21:00:00+01:00

L'idempotence ? Mais qu'est-ce que c'est quoi ça ?

L'idempotence est une propriété d'un traitement mathématique ou informatique qui donne le même résultat (état final) quel que soit le nombre de fois où il est appliqué à un état de départ. En mathématique, par exemple, les fonctions suivantes sont idempotentes :

f(x)=x+0
f(x)=x*1
f(x)=x*0

f(x) est donc une fonction idempotente si f(x)=f(f(x))=f(f(f(x)))=...

En informatique, un traitement appliqué à un état de départ et aboutissant à un état final donne toujours le même résultat final s'il est appliqué plusieurs fois. Ainsi, si la condition d'idempotence est respectée, un script de déploiement (d'un système, d'une configuration, d'une application) pourra être lancé plusieurs fois de suite (pour vérifier qu'il marche vraiment bien, parce qu'on a ajouté le truc oublié et qu'on ne veut pas repartir de zéro, ou simplement parce que le mec chargé de lancer le script est un boulet et a oublié qu'il vient de le faire 3 minutes avant).

Un traitement informatique peut être idempotent s'il respecte un de ces 3 principes :

il vérifie au début de son exécution si il a déjà été appliqué et ne fait rien dans ce cas
il commence par faire l'opération inverse de ce qu'il va finalement faire (par exemple supprimer les lignes de conf si elles sont présentes pour les ajouter ensuite)
il n'utilise par design que des fonctions, commandes, sous-ensembles eux-mêmes idempotents suivant les 2 principes ci-dessus

À propos des déploiements automatisés

Je n'essaierai pas de vous convaincre ici de l'utilité d'automatiser les déploiements (agilité, reproductibilité, rapidité, ...), je considère ce point comme acquis. Cela nécessiterait un article à part entière.

Nous partons donc du principe que, à minima, vous automatisez/scriptez/utilisez un système de gestion de configuration/whatever pour vos déploiements. J'utiliserai ci-dessous plusieurs fois le terme de script de déploiement. Si le système que vous utilisez n'est pas un script à proprement parler mais un framework/application/ce que vous voulez, faites le parallèle, ça marche aussi.

Oui, mais quels déploiements ?

À vrai dire, peu importe. L'idéal, bien sûr, étant que tous les déploiements, à partir de la machine physique vierge jusqu'à l'application en production soient automatisés. C'est le fantasme du "chouette, je viens d'avoir une nouvelle machine, je branche, j'appuie sur le gros bouton déploiement et hop, dans 5 minutes, mon service est en prod".

Ainsi, on peut automatiser le déploiement de l'hyperviseur sur une machine physique, la création des machines virtuelles (l'enveloppe), le déploiement des OS dans les machines virtuelles, leur configuration, le déploiement des middlewares nécessaires au fonctionnement de l'application et leur configuration, le déploiement de l'application, etc...

Et bien sûr, on souhaite le faire non pas sur un seul et unique système, mais sur un système de systèmes (oui, des équipements réseaux, des frontaux, des bases de données, des cluster nosql, des serveurs de web services, ... tout ça en même temps pour déployer non pas une application, mais un service)

Un script de déploiement, c'est avant tout du code.

Nous devons donc le considérer comme du code et le traiter comme tel. Et donc appliquer les mêmes méthodes de développement que pour une application :

Gérer nos outils de déploiement dans un système de gestion de version (cvs pour les dinosaures, svn, git, bazaar, ...)
Faire des tests unitaires
Pourquoi pas de l'intégration continue, surtout si notre outil de déploiement est modulaire et réutilisable
Et on peut aussi y appliquer les méthodes agile (oui, bon, on est pas obligé non plus de faire des planning games et des stand-up meetings, je déteste faire une réunion debout, mais on peut se poser autour d'une bière pour disserter de l'étape suivante)
Surtout, on doit décrire les exigences. Et l'idempotente fait partie de ces exigences.

Pourquoi en avons-nous besoin ?

Les outils/scripts/... de déploiement se doivent d'être idempotents.

Cette affirmation très péremptoire provient de l'observation de plusieurs problématiques rencontrées dans la vraie vie. Pas celle des bisounours, celle des vrais gens. Et dans cette vie-là, vous trouvez :

des développeurs de scripts de déploiement qui oublient les sorties/affichages pour la personne qui exécutera le déploiement et des angoissés qui pour être certains que le déploiement a bien été fait le relanceront une seconde fois même si c'est écrit en rouge, taille 48, police comic sans dans la doc qu'il ne faut pas le faire
des corrections en live/de dernière minute du dernier morceau de déploiement, au moment du passage en prod et qu'on n'a pas envie de repartir de zéro en désinstallant tout et qu'on se contente de relancer globalement le déploiement (oui, c'est crade...)
des étourdis qui ne se souviennent plus après leur café qu'ils ont déjà lancé un déploiement avant de partir en pause et qui recommencent
... complétez avec vos propres expériences ...

Note : oui, je sais, ce n'est pas forcément un humain qui doit lancer le déploiement, mais c'est pareil, l'humain peut aussi relancer le truc qui lance les déploiements, ou décider de le rejouer juste pour voir parce qu'il est... humain.

D'autre part, c'est agréable, lorsqu'on développe un programme, de pouvoir le lancer plein de fois pour le tester ou tester les nouveaux morceaux, et que comme on est excité de découvrir ce qu'on a fait de bien (ou pas), on ne veut pas perdre du temps à recréer les conditions initiales idéales pour relancer son truc.

Enfin (mais la liste n'est pas exhaustive), plus on aura eu de cas tordu, récupérés par notre fameuse idempotence, plus on aura un déploiement robuste et moins on aura de problème au moment du passage -en prod- à l'étape suivante.

Donc, les déploiements automatiques se doivent d'être idempotents dans leur ensemble, on doit pouvoir les lancer plusieurs fois de suite sans impact sur le résultat final.

Mais ils doivent aussi être idempotents dans leurs sous-parties, parfois jusqu'au niveau de la commande unitaire. Si par exemple je crée un script de déploiement d'une appli qui installe sur un OS

apache
PHP (remplacez par l'interpréteur que vous préférez)
les confs qui vont bien
l'appli

et qu'ensuite, disons dans une version N+1, j'ai besoin d'ajouter une base mysql, je veux pouvoir ajouter mon morceau de code qui déploie mysql et relancer le tout dans son ensemble. Je m'attends alors à ce que ma base de données soit déployée mais que le reste, qui était déjà installé ne soit pas cassé.

Dans la pratique

Dans la pratique, quelques opérations unitaires sur une machine ont l'air idempotentes. Par exemple l'installation d'un package :

aptitude update && aptitude install -y monpackage

Je peux lancer cette commande plusieurs fois, j'aurais toujours le même résultat final, le paquet sera installé.

Sûr ? Certain ? Y compris si entre les deux invocations il y a eu une mise à jour du package sur mon dépôt ?

Si ce n'est pas garanti, il vaudrait mieux le modifier légèrement pour le garantir quand c'est possible, ou connaitre (et communiquer) les limites de son script de déploiement.

D'autres commandes échouent simplement si le résultat attendu est déjà présent. Il suffit de gérer l'exception et le tour est joué. Pensez à useradd par exemple qui ne créera pas l'utilisateur s'il existe déjà.

Enfin, pour tout le reste, on peut coder soi-même une vérification d'existence du résultat attendu avant l'appel à la commande qui va produire ce résultat. Par exemple, je peux faire un ls avant de créer un fichier pour voir s'il n'existe pas déjà, ou chercher la ligne de conf que je veux ajouter pour savoir si c'est vraiment nécessaire, etc... et si ce test réussi, alors je n'ai plus rien à faire, je saute ce morceau.

C'est tout ? C'est aussi simple ? Ah bin oui, mais non car dans ce cas, on ne vérifie pas que le contenu est correct.

Dans mon exemple d'application LAMP, mon script de déploiement installe et configure apache. Et comme je veux garantir l'idempotence, j'ai ajouté avant l'installation d'apache une vérification, qu'il n'est pas déjà installé, sinon je saute cette partie.

Maintenant, que se passe-t-il si apache est installé, mais qu'il est tout cassé ? Par exemple, après un premier déploiement, j'ai fait un rm -rf /etc/apache2 (juste pour le fun, hein, personne ne ferait une chose pareille en vrai :-p ).

Mon script va vérifier si le paquet est installé, comme il est installé, il ne va rien faire, et mon déploiement ne va pas bien se passer du tout.

Vérifier partiellement l'existence du résultat final ne permet pas de garantir que nous avons TOUT le résultat final.

Humm, une solution pourrait être dans ce cas de prévoir dans notre script de déploiement une suppression, un retour à l'état initial "vierge" avant le déploiement.

Là encore, c'est trop simple, tout simplement parce que d'une part, défaire systématiquement pour refaire la même chose est inefficace, on ne veut pas pénaliser 99% des lancements pour gérer les 1% de cas tordus, d'autre part on risque de casser autre chose. Par exemple la modif qui a été appliquée en prod et non reportée dans le script de déploiement (qui a dit bien fait ?) ou la seconde appli installée sur le même serveur et qui n'est pas gérée par le même script de déploiement (qui a répété bien fait ?).

La vrai bonne réponse est que le développeur du script de déploiement doit s'adapter à l'environnement cible et user d'un savant mélange de ces 2 techniques (vérification d'exécution préalable ou désinstallation préalable) suivant le contexte. Il doit également poser lui-même ses conditions sur l'état initial que son script de déploiement peut accepter ou non.

Alors, maintenant que nos script de déploiements sont idempotents, c'est le bonheur... ou pas.

Pourquoi cela ne suffit pas

Repartons du besoin. Lorsqu'on crée un script de déploiement c'est pour obtenir comme résultat final un bouzin fonctionnel. Et on sait qu'il sera fonctionnel si tel et tel prérequis est respecté. Notre script de déploiement a donc pour mission de mettre en place ces prérequis. Nous cherchons donc, en plus de l'idempotence nécessaire, à obtenir un état final constant quel que soit l'état initial.

En d'autres termes, ce qu'on cherche, c'est que notre script de déploiement f, peu importe l'état initial x, donne toujours le résultat c. f(x)=c

Je ne connais pas le nom de cette propriété, malheureusement, mais s'il y a des plus matheux que moi dans le coin, n'hésitez pas à compléter en commentaire.

Cela tombe bien, parce que ce type de fonction est aussi idempotent.

Et là, je ne vois que 2 solutions pour le garantir :

Soit l'état initial est le vide absolu. Dans ce cas, comme on construit tout, on est certain de ce qu'on obtient. il faut donc partir de l'installation de l'OS (on supposera pour l'exercice qu'en dessous de l'OS, c'est le vide absolu. C'est un peu réducteur mais on est certain que l'OS vierge d'installation est reproductible aisément)
Soit nous sommes obligés d'imposer des prérequis, de poser des exigences sur l'état initial.

En conclusion

L'art noble et délicat du développement d'un script de déploiement doit respecter quelques principes :

Edicter et documenter les exigences ou prérequis à l'exécution de ce script (il est d'ailleurs mieux de les vérifier au lancement)
Être idempotent dans son ensemble
Être idempotent dans ses sous-parties

Enfin, et surtout, la qualité du déploiement utilisé dépend principalement de l'humain qui l'a codé, de sa maitrise technique, et de sa capacité à anticiper les cas problématiques plutôt qu'à les découvrir à l'utilisation.

Feuilletés au foie-gras et à la mangue

2013-12-31T16:00:00+01:00

Aujourd'hui, j'ai réalisé des feuilletés au foie-gras et à la mangue pour l'apéro du nouvel an et je me suis dit que je partagerai bien la recette avec vous. La voici donc :

Ingrédients

Pour la confiture de mangue :

Une mangue bien mûre
Du sucre (même poids que la mangue épluchée)
Un peu d’eau (5 à 10 cl)

Pour les feuilletés

Pâte feuilletée (achetée toute prête ou faite maison, mais à conserver au réfrigérateur pour la travailler froide)
Des tranches de foie-gras entier (pas de bloc, cela fond à la cuisson)
Un jaune d’œuf
Fleur de sel, poivre

Réalisation

La confiture de mangue

Éplucher la mangue, retirer le noyau central et couper la pulpe en dés. Réaliser une confiture en faisant cuire 20 minutes dans une casserole à feu moyen la mangue avec un peu d’eau, puis ajoutez le sucre et laissez cuire 10 minutes supplémentaires en remuant régulièrement afin d’éviter que cela ne colle au fond de la casserole. Laissez refroidir, puis mettre au réfrigérateur 2h.

Les feuilletés

Lorsque la confiture de mangue est bien froide : Préchauffez votre four à 180°C

Étalez la pâte feuilletée et découpez à l’emporte-pièce de jolies formes. Suivant la taille, vous obtiendrez des amuse-bouche pour l’apéritif ou une entrée.

Disposez-les sur une tôle de four recouverte d’un papier cuisson.

Ajouter un morceau de foie-gras en veillant à ce qu’il reste au moins 3mm de pâte autour

Afin d’obtenir une belle dorure à la cuisson, badigeonnez de jaune d’œuf au pinceau autour du foie-gras

Ajoutez une petite touche de confiture de mangue. Celle-ci peut être remplacée par un morceau de figue fraiche, ou même un morceau de mangue mais elle doit dans ce cas être très sucrée et ne pas apporter d’acidité qui ne se marie pas très bien avec le foie-gras. Ajoutez un peu de poivre du moulin et un grain de fleur de sel.

Mettez la tôle au four 10 minutes à 180°C. Ne pas ouvrir la porte du four pendant la cuisson, vous risqueriez de voir le feuilletage retomber.

Disposez dans une assiette de présentation et régalez-vous. Ils se mangent tiède, ou à température ambiante.

Et voilà, bon réveillon à tous !

Migration d'apache 2.2 + mod_auth_mysql vers 2.4 + mod_authn_dbd

2013-12-06T21:00:00+01:00

Depuis longtemps, une partie de mon serveur web, servi par un apache 2.2, était protégée par une authentification de type basique dont la base d'utilisateurs se trouvent dans une table mysql. Lors de l'upgrade du serveur en Ubuntu 13.10, apache est passé de la version 2.2 à la version 2.4.

Et soudain, c'est le drame. De grands changements on eu lieu du côté des modules d'authentification en général et celui gérant les bases mysql comme base d'utilisateurs en particulier.

Création de la table d'utilisateur

Avant toute chose, il faut une table d'utilisateurs. Pour l'exercice, nous allons créer une base apache_auth, créer un utilisateur mysql username et son mot de passe password pouvant lire le contenu des tables de cette base. Puis créer la table utilisateurs.

mysql> CREATE DATABASE apache_auth CHARACTER SET UTF8;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT SELECT ON apache_auth.* TO 'username'@'localhost' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0.00 sec)

mysql> use apache_auth;
Database changed
mysql> CREATE TABLE IF NOT EXISTS `utilisateurs` (
    ->       `login` varchar(255) NOT NULL,
    ->       `pass` varchar(255) NOT NULL,
    ->       UNIQUE KEY `login` (`login`))
    ->       ENGINE=MyISAM DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.00 sec)

mysql> desc utilisateurs;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| login | varchar(255) | NO   | PRI | NULL    |       |
| pass  | varchar(255) | NO   |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+
2 rows in set (0.00 sec)


mysql>

On peut ensuite y mettre un utilisateur pour apache dont le login est joe et le mot de passe est jwja.¹ Les commandes de hachage mysql n'étant pas forcément bien compatible avec apache, on utilise htpasswd pour hacher le mot de passe.

$ mysql -u root -p -e "INSERT INTO utilisateurs (login, pass) VALUES (\"joe\",\"$(htpasswd -nb joe jwja |cut -d ':' -f 2)\")" apache_auth
Enter password:
$

et même vérifier le tout

$ mysql -u root -p -e "SELECT * FROM apache_auth.utilisateurs;"
Enter password:
+-------+---------------------------------------+
| login | pass                                  |
+-------+---------------------------------------+
| joe   | $apr1$7jO4MTja$pd2pAH6WkYfcyrzPhgLcX/ |
+-------+---------------------------------------+
$

et voilà, nous sommes prêts

Configuration avec apache 2.2 et le mod_auth_mysql

Sous Ubuntu 13.04 (en apache 2.2 donc), voici quelle était ma configuration : Dans la directive <Directory> d'apache, simplement un

AllowOverride AuthConfig

Puis dans le .htaccess du répertoire, ceci :

AuthType Basic
AuthName "mon super espace protégé"
AuthBasicAuthoritative off
AuthMySQLAuthoritative on
AuthMYSQLEnable on
AuthMySQLHost localhost
AuthMySQLUser username
AuthMySQLPassword password
AuthMySQLDB apache_auth
AuthMySQLUserTable utilisateurs
AuthMySQLNameField login
AuthMySQLPasswordField pass
AuthMySQLPwEncryption md5

Require valid-user

<LIMIT GET POST PUT>
  require valid-user
</LIMIT>

Bien sûr, un petit coup de a2enmod auth_mysql était nécessaire.

That's all.

Configuration avec apache 2.4 et le mod_authn_dbd

Là, ça se corse. Dans le <VirtualHost> il faut définir les paramètres du driver sql :

        DBDriver mysql
        DBDParams "socket=/var/run/mysqld/mysqld.sock dbname=apache_auth user=username pass=password"
        DBDMin  4
        DBDKeep 8
        DBDMax  20
        DBDExptime 300

Puis dans le <Directory> ajouter :

                AuthName "mon super espace protégé"
                AuthType Basic
                AuthBasicProvider dbd
                # Requete SQL pour l'authentification
                AuthDBDUserPWQuery "SELECT pass FROM utilisateurs WHERE login = %s"
                Require valid-user

Je n'ai pas creusé davantage pour déporter les directives dans le .htaccess, mais la définition du driver mysql ne me semble pas pouvoir se déporter facilement de cette manière (disons que je n'ai pas trouvé du premier coup et que je n'avais pas le temps de débugguer).

Joe utilise un mot de passe faible créé à partir de l'initiale du prénom des 4 frères, les 3 autres étant William, Jack et Averell. Dans la vraie vie, le mot de passe ressemblerait plus à ceci :d3F@j5(éF(c54)+F'Dfc23 ↩

SSL/TLS hardening for apache 2.4

2013-11-30T11:30:00+01:00

Je suis tombé au détour du web sur un super outil de test de votre serveur httpS qui vous dit tous les protocoles et "cipher suites" que votre serveur autorise, ainsi que les cipher suites utilisée par chaque navigateur. Vous pouvez tester votre site httpS ici : https://www.ssllabs.com/ssltest/

Evidemment, en ce qui me concerne, avec la configuration par défaut, le résultat n'a pas été très glorieux :

Donc, la question, c'est quelle est "la bonne" configuration à appliquer à son serveur apache pour faire du SSL qui soit un minimum mieux sécurisé que la configuration par défaut.

Et la réponse, bien évidemment, c'est "ça dépend". En particulier, cela dépend des visiteurs que vous adressez, de votre capacité à leur imposer un nbavigateur plutôt qu'un autre (et même un OS plutôt qu'un autre), en fonction des protocoles implémentés par les différents navigateurs.

Déjà, vous pourrez retrouver les "best practice" décrites dans ce document : https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf

Pour la mise en oeuvre, je vous conseille d'appliquer la configuration suivante dans votre apache :

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

et là, TADAAAA, magie du spectacle, le résultat est bien meilleur :

Le revers de la médaille, c'est que vous vous privez des clients sous IE6 sur windows XP. Cela me semble acceptable comme compromis, ce navigateur n'étant déjà plus supporté par la plupart des sites, mais si vous devez continuer à garantir le fonctionnement de votre site pour ce navigateur, il suffit de laisser le protocole sslv3 comme ceci :

SSLProtocol all -SSLv2

[Astuce] Eviter de mettre une commande dans l'historique du shell

2013-10-12T18:00:00+02:00

Parfois, parce qu'on a pas le choix, on doit passer un mot de passe en argument d'une commande. Et bien sûr, en bon parano, on ne souhaite pas que ce mot de passe finisse enregistré dans l'historique du shell.

Par exemple, la dernière fois que cela m'est arrivé, c'était pour définir le proxy :

export HTTP_PROXY='http://user:PASSWORD@proxy:port/'

Jusqu'à présent, je prenais soin d'empêcher tout bonnement l'enregistrement de l'historique sur disque à la fin de la session avec un

unset HISTFILE

Redoutablement efficace, mais cela a tout de même l'inconvénient d'être un peu violent : aucun historique de la session n'est gardé. En plus, tant qu'on ne s'est pas déconnecté, c'est quand même toujours dans l'historique (en mémoire).

La solution plus propre, pour éviter qu'une commande ne soit enregistrée dans l'historique, c'est simplement de la faire précéder par... une espace

user@localhost:~# █export HTTP_PROXY='http://user:PASSWORD@proxy:port/'

Ainsi, la commande n'est pas enregistrée dans l'historique, ni en mémoire, ni sur disque à la fin de la session, mais toutes les autres commandes y seront.

Cela fonctionne avec zsh nativement, et avec bash en fonction de la configuration. Par défaut, c'est activé sur ubuntu 13.04, si ce n'est pas le cas dans votre bash, cela s'active en ajoutant ignorespace à la variable HISTCONTROL

HISTCONTROL=ignorespace

Je vous recommande par ailleurs la découverte de cette variable HISTCONTROL en lisant http://voidandany.free.fr/index.php/astuce-bash-la-variable-histcontrol/

dedibox IPv6 reloaded

2013-09-14T21:00:00+02:00

Cet article fait suite à l'article précédent sur la configuration IPv6 d'une dédibox suite à la disponibilité de nouvelles options

Comme vous l'avez peut-etre vu, depuis jeudi, deux nouvelles fonctionnalités IPv6 sont disponibles sur les serveurs dédiés dedibox chez online.

Une nouvelle plage d'adresses IPv6 2001:xxxx:xxxx été mise en production chez online (précedemment 2a01:xxx:xxx). Ainsi, les nouveaux clients IPv6 auront des adresses dans cette plage.

Vous pouvez désormais découper votre bloc d'adresses IPv6 pour le répartir sur plusieurs serveurs et vous pouvez mettre en place une résolution de nom inverse (reverse DNS) sur vos IPv6. Ces nouvelles fonctionnalités ne sont toutefois disponible que sur la nouvelle plage d'adresses IPv6. Si vous avez un bloc d'adresses dans l'ancienne plage, vous devrez migrer vos adresses dans la nouvelle plage pour en bénéficier.

Migrer vers la nouvelle plage
Accéder à la configuration IPv6 dans votre console de gestion
Reverse DNS IPv6
- J'ai mon serveur DNS bind
- Les services en ligne
Découpage du bloc pour différents serveurs

Migrer vers la nouvelle plage

Il n'y a pas (encore ?) de procédure simple de migration. Pour les "early adopters" qui voudraient migrer d'un bloc d'IP dans l'ancienne plage vers un bloc d'IP dans la nouvelle plage, la procédure consiste à :

résilier votre bloc actuel
commander un nouveau bloc

Pas de crainte de perte de service néanmoins, online y a pensé et la résiliation d'une plage d'IP s'arrêtera durant la période de migration à l'aspect administratif, la partie technique continuant à fonctionner après la résiliation le temps que vous mettiez en place votre nouvelle configuration (pas de nettoyage des conf de résiliation des anciens blocs IPv6 sur les routeurs).

Afin de résilier, il faut se rendre dans votre console de gestion online, rubrique compte->Mes services et cliquer sur la croix rouge de résiliation au bout de la ligne "Bloc IPv6". Et voilà, il suffit d'attendre la fin du mois que la résiliation prenne effet pour commander un nouveau bloc d'IPv6.

Ah, vous êtes pressé ? Dans ce cas, pour accélérer la résiliation, créez un ticket au support pour demander la résiliation anticipée.

Ah, vous êtes encore plus pressé que ça ? Vous pouvez alors essayer de contacter le support par IRC. Avec un peu de chance, il y aura quelqu'un de disponible pour valider immédiatement la résiliation.

Une fois votre résiliation validée, il faut attendre que le lapin-cron¹ vienne nettoyer toute référence à votre ancienn bloc d'IPv6 pour que vous puissiez en commander un autre. Il passe 2 fois par heure, à 00 et 30.

Enfin, quand vous n'avez plus de bloc d'IPv6, vous pouvez en commander un nouveau qui sera dans la nouvelle plage d'IPv6 d'online et bénéficier ainsi des nouvelles fonctionnalités. Une fois votre nouvelle plage commandée, il faut attendre un nouveau passage du lapin-cron avant qu'elle ne soit utilisable sur votre serveur, ne supprimez pas votre ancienne configuration trop vite ou vous risquez de perdre votre connectivité IPv6.

Accéder à la configuration IPv6 dans votre console de gestion

Pour accéder aux nouvelles fonctionnalités dans votre console de gestion, rendez-vous dans le menu serveur->configuration réseau.

Votre bloc d'IPv6 y est indiqué et un petit menu déroulant à droite vous permet de déléger à vos serveurs la résolution dns inverse et de découper votre bloc pour l'affecter à différents serveurs.

Reverse DNS IPv6

Contrairement à l'IPv4, les serveurs DNS d'online ne réalisent pas la résolution inverse pour vos IPv6. Néanmoins, ils peuvent déléguer à vos serveurs cette résolution afin qu'elle soit effective. Cela nécessite d'avoir 2 serveurs DNS (probablement un master et un slave) qui réalisent cette résolution. Si vous n'avez qu'un serveur, vous pouvez faire un échange de dns secondaire avec quelqu'un ou simplement utiliser des services DNS en ligne qui pourront être slave de votre serveur.

J'ai mon serveur DNS bind

Voici un exemple de configuration pour le serveur DNS bind sur votre serveur.

Créez un fichier de zone /etc/bind/db.2001 contenant

;
; BIND reverse data file for IPv6 2001:xxxx:xxxx::/48
;
$TTL    3600
@       IN      SOA     monserveur.mondomaine.tld. hostmaster.mondomaine.tld. (
                        2013091202
                        8H
                        30M
                        4W
                        1H )

;
@       IN      NS      monserveur.mondomaine.tld.
@       IN      NS      secondaire.mondomaine.tld.

; IPv6 PTR entries
x.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa.    IN    PTR    monserveur.mondomaine.tld.

à adapter à votre domaine bien sûr. La dernière ligne correspond à une entrée reverse. L'adresse IPv6 du serveur est notée de droite à gauche avec un point séparant chaque caractère, le tout fini par ip6.arpa.

Pour le reste du contenu d'un fichier de zone bind, je vous renvoie vers le DNS Howto et cet assistant de création de fichier de zone. Vraisemblablement, si vous ne savez pas comment ça marche, il vaut mieux vous tourner vers un service de DNS en ligne (voir ci-dessous).

Ensuite, vous devez déclarer la zone dans votre fichier de configuration /etc/bind/named.conf.local sur votre DNS master

zone "x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa" {
        type master;
        notify yes;
        allow-transfer { x.x.x.x; 2001:xxxx:xxxx:xxxx::x; };
        file "/etc/bind/db.2001";
};

"x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa correspond à la zone reverse de votre bloc (il s'agit de votre bloc écrit de droit à gauche en séparant chaque caractère par un point et fini par ip6.arpa). La ligne allow-transfer permet aux slave de venir chercher le contenu de la zone sur le master La ligne notify yes permet à chaque changement de notifier les slaves qu'ils doivent recharger le contenu de la zone Enfin, la ligne file référence le fichier de zone créé précédemment.

Il faut également déclarer la zone sur le serveur slave :

zone "x.x.x.x.x.x.x.x.1.0.0.2.ip6.arpa" {
        type slave;
        notify yes;
        file "/etc/bind/zones/db.2001";
        masters { x.x.x.x; 2001:xxxx:xxxx::x; };
};

Relancez le tout, et testez.

Les services en ligne

Les services dns.he.net ou xname.org par exemple permettent de gérer des zones DNS sans posséder de serveur DNS soi-même et d'être slave de vos serveurs DNS. Je ne les ai pas encore testés personnellement pour l'instant, si j'ai le temps un jour, j'essaierai et je vous ferai un billet là-dessus.

Découpage du bloc pour différents serveurs

Dans votre console de gestion, sous serveur->configuration réseau->IPv6 sélectionnez "Créer un sous-réseau". Choisissez alors parmis les sous-réseau proposés /56 de votre bloc /48. Un nouveau DUID est alors créé pour ce sous-réseau utilisable sur l'un de vos serveurs. Il s'utilise comme le DUID de votre bloc principal.

Ces sous-réseaux /56 peuvent à nouveau être découpés en sous-sous-réseaux /64.

Amusez-vous bien avec ces nouvelles fonctionnalités.

private-joke avec les techniciens d'online avec lesquels j'ai échangé où on comparait leur cron au lapin blanc d'Alice au pays des merveilles, celui avec sa grosse montre, toujours pressé. ↩

Timeout infini de grub après un boot avorté

2013-09-10T13:00:00+02:00

Le problème

Si vous avez un serveur sans console hébergé un peu loin, non accessible, et sans KVM, vous pourriez avoir un problème. Si un boot se passe mal (disons pour l'exercice que votre hébergeur, farceur, a eu une coupure de courant pendant un boot), alors grub le détecte et passe dans un mode RECORDFAIL.

Cela peut également survenir sur vous cliquez sur le bouton reboot de votre console de gestion alors que le serveur est déjà en cours de reboot.

Le plus drôle (façon de parler), c'est qu'à cet effet les solution dites de "monitoring proactif" peuvent avoir un effet désastreux suite à une coupure de courant, en provoquant un reboot de votre serveur pendant qu'il est justement en train de booter, et conduisant donc à un boot avorté.

Et il se trouve que par défaut, sous ubuntu, lorsque cela arrive, les boot suivants ont un timeout de grub infini. Cela veut dire que votre machine ne boote pas et que grub attend une interraction sur la console... que vous n'avez pas.

C'est très bien pour une machine de bureau, parce que si un boot s'est mal passé, il est important d'éviter la spirale infernale de reboot en boucle, mais pour un serveur distant sans console, c'est plus embêtant.

Bref, si ça vous arrive, c'est bien la m..., votre machine ne démarre plus.

Les solutions

La préventive

Pour ne pas que cela se produise, c'est assez simple, il suffit d'ajouter dans le fichier /etc/default/grub la ligne suivante :

GRUB_RECORDFAIL_TIMEOUT=3

Puis, pour mettre à jour la configuration de grub avec ce nouveau paramètre, il suffit de faire un

root@localhost:~$ sudo update-grub

Ainsi, même après un boot infructueux, grub conservera un timeout de 3 secondes. Et Hop, plus de plantage. Cela devrait être standard sur les distributions installées par les hébergeurs (online, OVH, ...) sur les serveurs sans KVM (entrée de gamme).

La curative

Si cela vous est déjà arrivé et que votre serveur ne boote plus, vous pouvez booter en mode rescue, monter les partitions de votre machine et supprimer de l'environnement de grub l'information recordfail de la façon suivante :

root@rescue:/# mount /dev/sdaX /mnt
root@rescue:/# mount /dev/sdaY /mnt/boot
root@rescue:/# grub-editenv /mnt/boot/grub/grubenv unset recordfail
root@rescue:/# umount /mnt/boot
root@rescue:/# umount /mnt
root@rescue:/# reboot

Il vous restera a appliquer la solution préventive ci-dessus pour ne pas que cela recommence.

Configuration IPv6 sur une dedibox sous ubuntu 13.04

2013-09-07T14:30:00+02:00

Principe

Pour que l'IPv6 fonctionne sur votre dédibox, il est indispensable, au préalable, de demander une plage d'IPv6. Ceci se fait dans la console de gestion.

Il faut ensuite mettre en œuvre la délégation de préfix (PD pour Prefix Delegation), c'est à dire vous authentifier auprès du routeur et lui demander de router votre préfix IPv6 vers votre dédibox.

ATTENTION : Si vous possédez plusieurs dedibox, seule l'une d'entre elle pourra se connecter en IPv6. Ceci est dû à l’implémentation choisie par online qui route toute votre classe d'IPv6 sur une seule machine.

Enfin, comme pour de l'IPv4 il faut configurer une adresse IPv6 sur votre dedibox et lui indiquer le routeur par défaut (default gateway)

Principe
Commander son bloc d'IPv6
Délégation de préfixe
Configuration de l'interface
Et pour ma default Gateway ?
- Automatiquement - Les paquets RA
- Manuellement parce que ça ne marche pas
Y'a plus qu'à

Commander son bloc d'IPv6

Une fois votre bloc IPv6 commandé, vous devez trouver dans votre console de gestion :

Votre bloc IPv6 sous la forme 2a01:0e0b:xxxx::/48
Votre DUID, c'est à dire votre identifiant unique sur le réseau sous la forme 00:xx:xx:xx:xx:xx:xx:xx:xx:xx

Ces 2 informations vous seront indispensables

Délégation de préfixe

Afin de demander au routeur de router les paquets IPv6 de votre bloc vers votre serveur, il faut, en utilisant le protocole DHCPv6 vous authentifier auprès de lui.

Installation de dibbler

Pour cela, commençons par installer dibbler (implémentaiton DHCPv6)

root@localhost:~# apt-get install dibbler
[...]
root@localhost:~# service dibbler-client stop

Configuration de dibbler

Editer / créer le fichier /var/lib/dibbler/client-duid et y mettre le DUID fourni par la console dedibox (garder ce DUID "secret" c'est votre identifiant pour récupérer votre /48)

   Votre bloc IPv6  0a00:0e00:0000::/48
   Duid             00:00:00:00:00:00:00:00:00:00

root@localhost:~# cat /var/lib/dibbler/client-duid
00:00:00:00:00:00:00:00:00:00

Configurez ensuite le fichier de conf /etc/dibbler/client.conf :

# Defaults for dibbler-client.
# installed at /etc/dibbler/client.conf by the maintainer scripts

duid-type duid-ll

# 8 (Debug) is most verbose. 7 (Info) is usually the best option
log-level 8

# To perform stateless (i.e. options only) configuration, uncomment
# this line below and remove any "ia" keywords from interface definitions
# stateless

iface eth0 {
# prefix delegation
    pd

# ask for options
# option dns-server
# option domain
#    option ntp-server
#    option time-zone
#    option sip-server
#    option sip-domain
#    option nis-server
#    option nis-domain
#    option nis+-server
#    option nis+-domain
}

Configuration du firewall

Si vous avez un firewall sur votre dedibox, assurez vous que les paquets UDP sur le port 546 sont bien autorisés

ATTENTION, il s'agit ici du firewall IPv6, donc ip6table si c'est celui que vous utilisez, à ne pas confondre avec son cousin iptables qui ne travaille qu'en IPv4

Par exemple :

root@localhost:~# ip6tables -A INPUT -p udp --dport 546 -j ACCEPT

Lancement de dibbler (et lecture des logs)

Lancer dibbler

root@localhost:~# service dibller-client start

Puis jetez un oeil dans le fichier de log /var/log/dibbler/dibbler-client.log qui devrait ressembler à ceci :

2013.09.06 22:18:26 Client Notice    | Dibbler - a portable DHCPv6, version 0.8.2 (CLIENT, Linux port)
2013.09.06 22:18:26 Client Notice    My pid (28896) is stored in /var/lib/dibbler/client.pid
2013.09.06 22:18:26 Client Notice    Detected iface eth1/3, MAC=aa:bb:cc:dd:ee:ff.
2013.09.06 22:18:26 Client Notice    Detected iface eth0/2, MAC=aa:bb:cc:dd:ee:ff.
2013.09.06 22:18:26 Client Notice    Detected iface lo/1, MAC=00:00:00:00:00:00.
2013.09.06 22:18:26 Client Notice    Parsing /etc/dibbler/client.conf config file...
2013.09.06 22:18:26 Client Debug     Prefix delegation option found.
2013.09.06 22:18:26 Client Debug     Parsing /etc/dibbler/client.conf done, result=0
2013.09.06 22:18:26 Client Debug     1 interface(s) specified in /etc/dibbler/client.conf
2013.09.06 22:18:26 Client Info      Interface eth0/2 configuation has been loaded.
2013.09.06 22:18:26 Client Debug     DUID's value = 00:00:00:00:00:00:00:00:00:00 was loaded from client-duid file.
2013.09.06 22:18:26 Client Info      My DUID is 00:00:00:00:00:00:00:00:00:00.
2013.09.06 22:18:26 Client Info      Loading old address database (client-AddrMgr.xml), using built-in routines.
2013.09.06 22:18:26 Client Info      DB timestamp:1378498106, now()=1378498706, db is 600 second(s) old.
2013.09.06 22:18:26 Client Debug     Loaded PD from a file: t1=1800, t2=3600, iaid=1, iface=2
2013.09.06 22:18:26 Client Debug     Parsed prefix 2a01:xxxx:xxxx::/48, pref=3800, valid=3800,ts=1378498106
2013.09.06 22:18:26 Client Debug     Parsed PD, pdid=1, t1=1800, t2=3600
2013.09.06 22:18:26 Client Debug     Client 00:00:00:00:00:00:00:00:00:00:00:00:00:00 loaded from disk successfuly (0/1/0 ia/pd/ta).
2013.09.06 22:18:26 Client Debug     Bind reuse enabled (multiple instances allowed).
2013.09.06 22:18:26 Client Notice    Creating control (::) socket on the lo/1 interface.
2013.09.06 22:18:26 Client Notice    Creating socket (addr=fe80::0000:0000:0000:8a4f) on eth0/2 interface.
2013.09.06 22:18:26 Client Debug     Initialising link-state detection for interfaces: eth0/2 
2013.09.06 22:18:26 Client Notice    CONFIRM support compiled in.
2013.09.06 22:18:26 Client Info      Creating SOLICIT message with 0 IA(s), no TA and 1 PD(s) on eth0/2 interface.
2013.09.06 22:18:26 Client Debug     Sending SOLICIT(opts:1 25 8 ) on eth0/2 to multicast.
2013.09.06 22:18:26 Client Debug     Sleeping for 1 second(s).
2013.09.06 22:18:26 Client Debug     Received 133 bytes on interface eth0/2 (socket=4, addr=fe80::6e41:6aff:fec7:72ff.).
2013.09.06 22:18:26 Client Info      Received ADVERTISE on eth0/2,TransID=0xecc4ba, 4 opts: 25 2 1 7
2013.09.06 22:18:26 Client Info      ADVERTISE message with prefrence set to 255 received, so wait time for other possible ADVERTISE messages is skipped.
2013.09.06 22:18:26 Client Info      Creating REQUEST. Backup server list contains 1 server(s).
2013.09.06 22:18:26 Client Debug     Advertise from Server ID=00:00:00:00:00:00:00:00:00:00:00:00:00:00, preference=255, no auth info.[using this]
2013.09.06 22:18:26 Client Debug     Authentication is disabled, not including auth options in message.
2013.09.06 22:18:26 Client Debug     Sending REQUEST(opts:1 25 2 8 ) on eth0/2 to multicast.
2013.09.06 22:18:26 Client Debug     Not executing external script (Notify script disabled).
2013.09.06 22:18:26 Client Debug     Sleeping for 1 second(s).
2013.09.06 22:18:26 Client Debug     Received 127 bytes on interface eth0/2 (socket=4, addr=fe80::6e41:6aff:fec7:xxxx.).
2013.09.06 22:18:26 Client Info      Received REPLY on eth0/2,TransID=0xdcc722, 4 opts: 25 2 1 7
2013.09.06 22:18:26 Client Warning   PD: Prefix 2a01:0000:0000::/48 is already assigned to this PD.
2013.09.06 22:18:26 Client Notice    PD: Adding prefix 2a01:0000:0000::/48 to all interfaces (prefix will be split to /56 prefixes if necessary).
2013.09.06 22:18:26 Client Debug     PD: Interface eth1/3 is down, ignoring.
2013.09.06 22:18:26 Client Debug     PD: Interface eth0/2 is the interface, where prefix has been obtained, skipping.
2013.09.06 22:18:26 Client Debug     PD: Interface lo/1 is not multicast capable, ignoring.
2013.09.06 22:18:26 Client Info      PD: Using 0 suitable interface(s):
2013.09.06 22:18:26 Client Warning   Suitable interfaces not found. Delegated prefix not split.
2013.09.06 22:18:26 Client Debug     RENEW will be sent (T1) after 1800, REBIND (T2) after 3600 seconds.
2013.09.06 22:18:26 Client Debug     Not executing external script (Notify script disabled).
2013.09.06 22:18:26 Client Debug     Sleeping for 1800 second(s).

Assurez vous avant toute chose que l'échange s'est bien passé et que votre bloc IPv6 a bien été attribué à votre dedibox.

  2013.09.06 22:18:26 Client Notice    PD: Adding prefix 2a01:0000:0000::/48 to all interfaces (prefix will be split to /56 prefixes if necessary).

Ensuite, vous remarquerez que le log contient l'IP du routeur qui vous a répondu. Notez là, vous en aurez besoin plus tard (ce sera votre default gateway).

2013.09.06 22:18:26 Client Debug     Received 127 bytes on interface eth0/2 (socket=4, addr=fe80::6e41:6aff:fec7:xxxx.).

Configuration de l'interface

Il vous reste ensuite simplement à configurer une IP de votre bloc sur l'interface de votre dedibox. Le plus simple est de prendre la première¹, c'est à dire 2a01:0e0b:0000::1 si votre prefix est 2a01:0e0b:0000::/48

Ajoutez (i.e. APRES la config IPv4) les lignes suivantes à votre fichier /etc/network/interfaces

iface eth0 inet6 static
    address 2a01:0e0b:0000::1
    netmask 48

Veuillez à bien adapter l'adresse à votre cas. L'adresse est une adresse que vous choisissez dans votre bloc.

Et pour ma default Gateway ?

Automatiquement - Les paquets RA

Les routeurs d'online passent leur temps à arroser le réseau avec l'adresse IPv6 du routeur par lequel votre dedibox doit passer. Il s'agit de paquet RA. pour une explication détaillée du fonctionnement : http://blog.bashy.eu/2011/03/paquet-router-advertisement/

Normalement, donc, votre default gateway se met toute seule en place et vous n'avez rien à faire. Néanmoins, les vérifications suivantes peuvent s'avérer nécessaires :

Les paquets ICMPv6 doivent arriver à votre machine, donc ne pas être droppés par le firewall
Les paquets multicast ne doivent pas être droppés.
La machine doit accepter les paquets RA. Ces variables kernel doivent être à 1 :

root@localhost:~# sysctl -a | grep 'accept_ra ='
net.ipv6.conf.all.accept_ra = 1
net.ipv6.conf.default.accept_ra = 1
net.ipv6.conf.eth0.accept_ra = 1
net.ipv6.conf.eth1.accept_ra = 1
net.ipv6.conf.lo.accept_ra = 1

Le forwarding doit être désactivé, sinon le noyau est en mode routeur et n'accepte pas les paquest RA. à moins de forcer l'acceptation des paquets RA même avec le forwarding activé en positionnant les variables accept_ra à 2 plutôt qu' à 1.² C'est probablement le cas si vous avez installé openvpn ou un logiciel de firewalling qui a activé le forward.

Lorsque ces conditions sont réunies, cétotomatix

Manuellement parce que ça ne marche pas

Si le paragraphe précédent ne vous a pas permis de bénéficier de la configuration automatique, dites vous :

Que vous êtes un boulet, comme moi
Qu'il y a toujours possibilité de définir manuellement sa défault gateway

Pour se faire, comme on a l'adresse du routeur (souvenez vous, elle est dans les logs de dibbler), il suffit d'ajouter au fichier /etc/network/interfaces dans la section inet6 une ligne

gateway fe80::6e41:6aff:fec7:xxxx

Y'a plus qu'à

relancez le tout et testez :

root@localhost:~# service networking restart
networking stop/waiting
networking start/running
root@localhost:~# ping6 ipv6.google.com
PING ipv6.google.com(we-in-x67.1e100.net) 56 data bytes
64 bytes from we-in-x67.1e100.net: icmp_seq=1 ttl=55 time=9.80 ms
64 bytes from we-in-x67.1e100.net: icmp_seq=2 ttl=55 time=9.83 ms
64 bytes from we-in-x67.1e100.net: icmp_seq=3 ttl=55 time=9.74 ms
^C
--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 9.741/9.793/9.835/0.039 ms
root@localhost:~#

En fait, c'est la seconde, puisque la première est l'adresse 0. Contrairement à l'IPv4, l'IPv6 permet d'utiliser toutes les adresses, de la première (0) à la dernière (ffff) ↩
Voir à ce sujet http://www.mattb.net.nz/blog/2011/05/12/linux-ignores-ipv6-router-advertisements-when-forwarding-is-enabled/ ↩

Enfin, un blog !

2013-09-07T14:25:00+02:00

Ca y est, me voici l'heureux propriétaire d'un blog. J'ai une maison sur internet.

Je ne sais pas encore bien ce que je vais y mettre, surement de tout et de rien, de l'informatique, bien sûr, des humeurs, de l'info aussi.

La fréquence de post sera forcément irrégulière, suivant les envies.

Mais au moins, j'aurai un lieu où publier ce que j'aurai envie de partager.

EDIT : Commentaire de madame : "Tu va raconter ta vie ? Tu va mettre des recettes de cuisine ? Des photos de chat ? Non ? alors ça sert à rien..."

S.B.