Debian : activer l’IPv6 sur une instance EC2

# vim /etc/network/interfaces

auto eth0
iface eth0 inet dhcp
   post-up sleep 2
iface eth0 inet6 dhcp

RaspberryPI : installation de Kodi 17.1

  • dimanche 2 avril 2017
  • Ecrire
# echo 'deb http://pipplware.pplware.pt/pipplware/dists/jessie/main/binary /' | sudo tee --append /etc/apt/sources.list.d/pipplware_jessie.list
# wget -O - http://pipplware.pplware.pt/pipplware/key.asc | apt-key add -
# apt update
# apt install kodi

zabbix-docker : version 0.2.1

Zabbix-docker est un agent de monitoring Docker pour Zabbix, permettant de récupérer l’ensemble des métriques des containers Docker pour un host voire un cluster (aggrégation des métriques côté serveur Zabbix). Les métriques actuellement supportées sont les suivantes :

  • statut des containers (dont le health check de Docker 1.12)
  • statistiques des containers (RAM, CPU, interfaces réseau et périphériques de stockage)
  • processus en exécution dans les containers
  • évenèments des containers

La version 0.2 apporte en particulier l’exécution par l’API Docker de commandes distantes dans les containers monitorés. Ainsi, en ajoutant vos scripts de collecte des métriques trapper à vos images Docker, les métriques applicatives peuvent être détectées (parsing de la sortie console) et envoyées au serveur Zabbix.

Let’s Encrypt : gestion des certificats avec le client dehydrated

Ayant un peu de temps, je me suis décidé – moi et ma flemme sacrée – à virer mon certificat StartSSL. Pour les désinformés, il y a une bien triste histoire à connaître sur les pratiques de StartSSL/WoSign.

Pour gérer les certificats de Let’s Encrypt, l’installation du client CLI dehydrated permet d’automatiser leur génération et leur renouvellement étant donné leur validité de trois mois :

# apt install dehydated

Premier étape, lister les certificats et les domaines associés (1 certificat par ligne) :

# vim /etc/dehydated/domains.txt

blog.hbis.fr www.hbis.fr

Enfin, le fichier de configuration :

# vim /etc/dehydratd/conf.d/letsencrypt.sh

BASEDIR="/var/lib/letsencrypt/"
WELLKNOWN="/var/www/hbis.fr/blog/html/.well-known/acme-challenge"
CONTACT_EMAIL="postmaster@hbis.fr"

Reste à lancer la génération :

# mkdir -p /var/lib/letsencrypt /var/www/hbis.fr/blog/html/.well-known/acme-challenge
# dehydrated -c --force

Les différents services sécurisés sont à réconfigurer:

# vim /etc/nginx/ssl-enabled/hbis

ssl on;
ssl_certificate /var/lib/letsencrypt/certs/blog.hbis.fr/fullchain.pem;
ssl_certificate_key /var/lib/letsencrypt/certs/blog.hbis.fr/privkey.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /var/lib/letsencrypt/certs/blog.hbis.fr/chain.pem;

# vim /etc/postfix/main.cf

smtpd_tls_CAfile = /var/lib/letsencrypt/certs/blog.hbis.fr/chain.pem
smtpd_tls_cert_file = /var/lib/letsencrypt/certs/blog.hbis.fr/cert.pem
smtpd_tls_key_file = /var/lib/letsencrypt/certs/blog.hbis.fr/privkey.pem

# vim /etc/dovecot/conf.d/10-ssl

ssl_cert = </var/lib/letsencrypt/certs/blog.hbis.fr/fullchain.pem
ssl_key = </var/lib/letsencrypt/certs/blog.hbis.fr/privkey.pem

Dernière étape, il est nécessaire de mettre en place un cron pour les renouveller automatiquement et relancer les services nécessaires:

# vim /etc/cron.montly/dehydrated

#!/bin/bash

/usr/bin/dehydrated -c &amp;amp;&amp;amp; systemctl restart nginx postfix dovecot

# chmod +x /etc/cron.montly/dehydrated

OpenSSL: récupérer la chaîne de certificats SSL d’un host

  • samedi 11 février 2017
  • Ecrire
$ echo | openssl s_client -connect my.host.com:443 -showcerts 2>&1 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > mycert.pem

Docker : inspecter les commandes healthcheck

  • jeudi 19 janvier 2017
  • Ecrire

Pour voir en temps réel les commandes healthcheck effectuées sur chacun des containers :

$ docker system events --filter event=exec_start

2017-01-19T14:53:32.979634882+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 fa7c8221a53e2a76e61f290c4008f67ea2548b923cc42a11e9234ee0db4cab54 (com.docker.compose.config-hash=b4b13e5e0066bd757aa944cc01869736eb1d150ac04516e19028d070ef5f502c, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=zabbix-agent, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/zabbix-agent, name=dev_zabbix-agent_1)
2017-01-19T14:53:33.985556968+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 a009ecbbb3cdce6da2bdf6ae073b9d323bcc2921eafc82206f7e4719e37a617a (com.docker.compose.config-hash=2e83302dfa763cf4185883bed56a64cd8e9207d3a78f06fd250bc158aafedde6, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=rabbitmq, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/rabbitmq, name=dev_rabbitmq_1)
2017-01-19T14:53:35.252389013+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 a7398fd76d95544ac6cd8d02fbacb9608d5fd3443c1afb4fa0b4606dc032476c (com.docker.compose.config-hash=3c3cae569ff98e6a7e91b8e6734bfed22e9c5df90c8bd593539ef4876e2bda25, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=mariadb, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/mariadb, name=dev_mariadb_1)
2017-01-19T14:53:39.875116453+01:00 container exec_start: /bin/sh -c /etc/cont-consul/check || exit 1 1f41e9a3b5b63601042dbf5dcd758342e217f0f5d5685d76e9f61b2a2c155a5a (com.docker.compose.config-hash=733b83db2c39e867d08158e3101decdc5e3d70fa0653fea7f44139e29b47d2fa, com.docker.compose.container-number=1, com.docker.compose.oneoff=False, com.docker.compose.project=dev, com.docker.compose.service=dynamodb, com.docker.compose.version=1.9.0, image=registry.foobot.io/foobot/dynamodb, name=dev_dynamodb_1)

Fabric : redémarrer un host distant

  • dimanche 23 octobre 2016
  • Ecrire

Voici la méthode que j’utilise pour redémarrer convenablement un hôte avec Fabric en lieu et place de la méthode reboot fournie par l’API :

from fabric.state import *

def mytask:
    sudo("shutdown -r +1")
    time.sleep(120)
    connections[env.host_string].get_transport().close()
    run("uptime")

Cette méthode est fonctionnelle sur une instance EC2 sous systemd. Le délai d’attente peut être adaptée si besoin, mais la déconnexion à l’hôte est forcée pour que Fabric réétablisse le tunnel SSH dans tous les cas.

Linux : fixer la keymap d’un clavier mac alu FR

  • jeudi 29 septembre 2016
  • Ecrire

Le genre de truc qui m’agace depuis de nombreuses années avec mon clavier mac alu sous Linux, c’est l’inversion des touches #/@ et </>. Donc voici « enfin » le fix :

# echo 0 > /sys/module/hid_apple/parameters/iso_layout

Et pour rendre la configuration permanente:

# vim /etc/modprobe.d/hid_apple.conf

options hid_apple iso_layout=0

Docker : collection d’images Alpine Linux pour intégration avec Consul

Depuis quelques mois, j’utilise mes propres images Docker basées sous Alpine Linux. En dehors d’un gain substantiel de volume (une instance Tomcat passe de 420 Mo avec une base Ubuntu à 170 Mo sous Alpine Linux application incluse), ces images sont destinées à une utilisation avec Consul afin de configurer et reconfigurer à chaud les services – initialisés par s6-overlay – grâce à consul-template.

Docker : erreur au build « Failed to create thread: Resource temporarily unavailable (11) »

  • vendredi 25 mars 2016
  • Ecrire

Si vous obtenez l’erreur suivante lors du build d’une image Docker :

Failed to create thread: Resource temporarily unavailable (11)
Aborted (core dumped)

Il s’agit d’une limitation de ressources appliquée par systemd :

# systemctl status docker

● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/docker.service.d
           └─custom.conf
   Active: active (running) since Fri 2016-03-25 10:04:16 CET; 4h 27min ago
     Docs: https://docs.docker.com
 Main PID: 927 (docker)
    Tasks: 436 (limit: 512)
   CGroup: /system.slice/docker.service
           ├─  927 /usr/bin/docker daemon -H fd:// --iptables=false --dns 8.8.8.8 --dns 8.8.4.4
           ├─10390 docker-proxy -proto tcp -host-ip 172.18.0.1 -host-port 8500 -container-ip 172.18.0.2 -container-port 8500
           ├─10411 docker-proxy -proto tcp -host-ip 172.18.0.1 -host-port 8301 -container-ip 172.18.0.2 -container-port 8301
           ├─10907 docker-proxy -proto tcp -host-ip 172.19.0.1 -host-port 61613 -container-ip 172.19.0.3 -container-port 61613
           ├─10949 docker-proxy -proto tcp -host-ip 172.19.0.1 -host-port 15672 -container-ip 172.19.0.3 -container-port 15672
           ├─10957 docker-proxy -proto tcp -host-ip 172.19.0.1 -host-port 5672 -container-ip 172.19.0.3 -container-port 5672
           ├─10965 docker-proxy -proto tcp -host-ip 172.19.0.1 -host-port 1883 -container-ip 172.19.0.3 -container-port 1883
           └─11188 docker-proxy -proto tcp -host-ip 172.19.0.1 -host-port 80 -container-ip 172.19.0.4 -container-port 80

Il convient d’augmenter le nombre de tâches autorisées, ou tout simplement désactiver cette limitation, dans le fichier service du démon docker :

# cat /etc/systemd/system/docker.service.d/custom.conf

[Service]
ExecStart=
ExecStart=/usr/bin/docker daemon -H fd:// --iptables=false --dns 8.8.8.8 --dns 8.8.4.4
TasksMax=infinity

# systemctl daemon-reload
# systemctl restart docker.service
Haut de page