Blog de Boris HUISGEN

Coder votre projet ESP8266 avec CLion IDE

2019-10-01T20:54:59.000Z

La prochaine version du SDK RTOS - version 4 et plus - va utiliser CMake comme outil de build par défaut mais il est déjà présent dans la version 3.2. Ainsi, il est déjà possible d’utiliser l’IDE CLion pour coder votre projet. Cet article va vous expliquer comment configurer votre IDE favori dans ce but.

Créer votre project

Copiez en premier lieu le squelette de project getting-started présent dans le répertoire exemple du SDK ESP.

Ouvrez le répertoire dans CLion. Il sera détecté comme un projet CMake.

Configurer une nouvelle toolchain

Ouvrez les paramètres de l’IDE, rubrique Build, Execution, Deployment / Toolchains:

Créer la toolchain xtensa-lx106-elf et spécifiez les répertoires requis aux outils de compilation gcc et g++.

Configurer le profil CMake

Toujours dans les paramètres, rendez-vous à la rubrique Build, Execution, Deployment / CMake:

Sélectionnez la nouvelle toolchain xtensa-lx106-elf

Ajoutez l’option CMake:

-DIDF_PATH=/home/boris/.local/share/ESP8266_RTOS_SDK

Ajoutez les variables d’environnement:

IDF_PATH=/home/boris/.local/share/ESP8266_RTOS_SDK;PATH=/home/boris/.local/share/xtensa-lx106-elf/bin
BATCH_BUILD=1

Configurer le terminal de l’IDE

Rendez-vous à la rubrique Tools / Terminal:

Configurez l’environnement du terminal:

IDF_PATH=/home/boris/.local/share/ESP8266_RTOS_SDK
PATH=/home/boris/.local/share/xtensa-lx106-elf/bin:/usr/bin:/bin:/home/boris/.local/share/ESP8266_RTOS_SDK/tools

Recharger le project

Rechargez le project CMake par clic droit sur le nom du project dans la vue project et vérifiez qu’aucune erreur CMake n’est générée.

Vous pouvez à présenter générer le projet.

Flasher votre périphérique

Pour flasher le firmware à votre périphérique ESP, sélectionnez la configuration de build flash et exécutez-la.

Vous pouvez également ouvrir le terminal de l’IDE et exécutez la commande équivalente:

$ idf.py flash monitor

Il ne vous reste plus qu’à coder!

Singleton thread-safe en Python

2019-03-23T14:12:05.000Z

Le singleton est probablement le design pattern le plus utilisé pour limiter la consommation des ressources comme le nombre de connexions aux bases de données ou tout autre service. Son implémentation est relativement simple mais elle peut rapidement devenir source d’ennuis si le code doit être thread-safe.

Un code thread-safe est généralement garanti par utilisation d’un système de synchronisation comme un verrou dont Python possède grâce à sa primitive Lock du module threading, mais une autre astuce est nécessaire pour un support thread-safe.

Implémentation

 1import logging
 2import threading
 3
 4class MySingleton(object):
 5    _instance: object = None
 6    _lock: threading.Lock = threading.Lock()
 7
 8    def __new__(cls):
 9        """Create a new instance"""
10        if MySingleton._instance is None:
11            with MySingleton._lock:
12                if MySingleton._instance is None:
13                    MySingleton._instance = super(MySingleton, cls).__new__(cls)
14                    MySingleton._instance._initialized = False
15
16        return MySingleton._instance
17
18    def __init__(self):
19        """Initialize the instance"""
20        if self._initialized is False:
21            self._logger = logging.getLogger(self.__class__.__name__)
22            self._count = 0
23            self._initialized = True
24
25        self._logger.debug("using instance: %s" % self._instance)
26
27    def increment(self):
28        """Increment the counter"""
29        self._count += 1
30
31        self._logger.debug("count = %d" % self._count)

L’astuce est donc d’utiliser un verrou combiné à un autre objet qui va conserver l’instance partagée de votre classe singleton.

Test

Pour tester son fonctionnement, lancez une console Python:

>>> from code import MySingleton
>>> logging.basicConfig(level=logging.DEBUG, handlers=[logging.StreamHandler()])
>>> a = MySingleton()
DEBUG:MySingleton:using instance: <__main__.MySingleton object at 0x7f8bee80c550>
>>> b = MySingleton()
DEBUG:MySingleton:using instance: <__main__.MySingleton object at 0x7f8bee80c550>
>>> a.increment()
DEBUG:MySingleton:count = 1
>>> a.increment()
DEBUG:MySingleton:count = 2
>>> b.increment()
DEBUG:MySingleton:count = 3

Comme vous pouvez le voir, les instances a et b sont identiques.

Générer un certificat wilcard Let's Encrypt

2018-10-28T14:08:10.000Z

Un certificat wildcard est utile pour protéger plusieurs services avec des alias différents du même nom de domaine, en lieu et place d’un certificat différent par alias. Let’s Encrypt propose à présent un tel service gratuitement.

La création du certificat Let’s Encrypt est effectuée avec le client CLI certbot qu’il convient d’installer selon votre distribution:

$ sudo apt install certbot

Un répertoire de travail doit être créer pour stocker les différents fichiers :

$ mkdir -p ~/certbot/{config,work,logs}
$ cd ~/certbot

Pour générer un certificat, lancez la commande suivante en spécifiant votre nom de domaine sans aucun alias :

$ certbot certonly --config-dir config/ --work-dir work/ --logs-dir logs/ \
    --server https://acme-v02.api.letsencrypt.org/directory --manual \
    -d '*.monsite.fr'

Le processus de création vous invitera à ajouter un enregistrement à la zone DNS du domaine. Une fois effectué, le certificat sera généré dans votre répertoire. Il conviendra de réutiliser cette même commande pour le renouveler avant sa date d’expiration.

Interface réseau dummy avec NetworkManager

2018-03-12T21:57:01.000Z

La création d’une interface réseau dummy permet de simplifier la gestion des services locaux d’un hôte en leur permettant d’être attaché à une adresse IP fixe, et par extension de disposer d’un réseau virtuel.

Pour ajouter une interface dummy avec NetworkManager, une nouvelle connexion doit être créer:

$ sudo vim /etc/Network/Manager/dummy

[connection]
id=dummy
uuid=6ad57828-f873-4e4c-9ebd-ac3f49b99cbe
type=dummy
interface-name=dummy0
permissions=
timestamp=1520895027

[ipv4]
address1=169.254.1.1/24
dns-search=
method=manual

[ipv6]
addr-gen-mode=eui64
dns-search=
method=ignore

La configuration peut être appliquée à chaud :

$ sudo nmcli connection reload

L’interface réseau doit être disponible :

$ ip addr show dummy0

5: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 26:ed:f7:10:de:ba brd ff:ff:ff:ff:ff:ff
inet 169.254.1.1/24 brd 169.254.1.255 scope link noprefixroute dummy0
valid_lft forever preferred_lft forever
inet6 fe80::24ed:f7ff:fe10:deba/64 scope link
valid_lft forever preferred_lft forever

Il vous reste à attacher vos services réseaux sur cette interface.

Gestion des zones DNS Gandi avec Terraform

2018-01-01T19:03:10.000Z

La gestion des zones DNS Gandi avec Terraform est possible grâce à un module open-source.

Installation du provider

$ go get github.com/tiramiseb/terraform-provider-gandi
$ cd $GOPATH/go/src/github.com/tiramiseb/terraform-provider-gandi
$ go build -o terraform-provider-gandi

Comme indiqué dans la documentation du module, seules sont supportées les zones LiveDNS de la nouvelle infrastructure DNS. Il convient donc de migrer vos anciennes zones le cas échéant. Une clé API est également à générer pour permettre les modifications distantes depuis Terraform.

Projet Terraform

Débutons par la création du projet Terraform :

$ mkdir ~/Projects/terraform-gandi-dns
$ cd ~/Projects/terraform-gandi-dns
$ touch main.tf providers.tf variables.tf outputs.tf terraform.tfvars

Fichier provider.tf :

1provider "gandi" {
2  key = "${var.gandi_key}"
3}

Fichier variable.tf :

1variable "gandi_key" {}

Fichier main.tf :

 1resource "gandi_zone" "hbis_fr" {
 2  name = "hbis.fr"
 3}
 4
 5resource "gandi_domainattachment" "hbis_fr" {
 6  domain = "hbis.fr"
 7  zone = "${gandi_zone.hbis_fr.id}"
 8}
 9
10resource "gandi_zonerecord" "root" {
11  zone = "${gandi_zone.hbis_fr.id}"
12  name = "@"
13  type = "A"
14  ttl = 3600
15  values = [
16    "51.15.171.130"
17  ]
18}
19
20resource "gandi_zonerecord" "www" {
21  zone = "${gandi_zone.hbis_fr.id}"
22  name = "www"
23  type = "A"
24  ttl = 3600
25  values = [
26    "51.15.171.130"
27  ]
28}

En plus du code des ressources, une variable Terraform sera utilisée pour fournir la clé API.

Importation de la zone DNS

Le projet est à initialiser :

$ terraform init

Avant de débuter l’importation, l’étape essentielle est de récupérer l’identifiant de la zone en utilisant l’API Gandi:

$ curl -s -H "Content-Type: application/json" -H "X-Api-Key: ******" https://dns.api.gandi.net/api/v5/zones|jq -r

[
  {
    "retry": 3600,
    "uuid": "72e4069e-eeef-11e7-8db5-00163e6dc886",
    "zone_href": "https://dns.api.gandi.net/api/v5/zones/72e4069e-eeef-11e7-8db5-00163e6dc886",
    "minimum": 10800,
    "domains_href": "https://dns.api.gandi.net/api/v5/zones/72e4069e-eeef-11e7-8db5-00163e6dc886/domains",
    "refresh": 10800,
    "zone_records_href": "https://dns.api.gandi.net/api/v5/zones/72e4069e-eeef-11e7-8db5-00163e6dc886/records",
    "expire": 604800,
    "sharing_id": "4aace8e0-b393-11e7-bcf1-00163ec388ae",
    "serial": 1514825087,
    "email": "hostmaster.gandi.net.",
    "primary_ns": "ns1.gandi.net",
    "name": "hbis.fr"
  }
]

La valeur UUID est l’identifiant à récupérer pour lancer l’importation de la ressource gandi_zone:

$ terraform import -var 'gandi_key=******' gandi_zone.hbis_fr 72e4069e-eeef-11e7-8db5-00163e6dc886

Terraform devrait avoir confirmer l’importation de la ressource dans son fichier d’état, ce qui peut-être vérifié :

$ terraform show

gandi_zone.hbis_fr:
id = 72e4069e-eeef-11e7-8db5-00163e6dc886
name = hbis.fr

La ressource gandi_domainattachment est également à importer:

$ terraform import -var 'gandi_key=******' gandi_domainattachment.hbis_fr hbis.fr

Si des alias DNS sont déjà existants, ils seront également à importer. L’identifiant interne des ressources gandi_zonerecord a le format : <UUID>/<NAME>/<TYPE>

$ terraform import -var 'gandi_key=******' gandi_zonerecord.root 72e4069e-eeef-11e7-8db5-00163e6dc886/@/A
$ terraform import -var 'gandi_key=******' gandi_zonerecord.blog 72e4069e-eeef-11e7-8db5-00163e6dc886/www/A

Vérification du plan

Le fichier d’état étant peuplé de toutes les ressources nécessaires, vérifiez que le plan ne requiert aucune modification :

$ terraform plan -var 'gandi_key=******'

Vous pouvez à présent gérer votre zone et ses enregistrements depuis votre projet Terraform.

Plugin Maven de build Docker

2017-10-22T16:58:40.000Z

Suite à un besoin professionnel, j’ai développer un plugin Maven pour générer les images Docker de certains projets Java. Je viens de publier la version 0.2.0 qui fixe quelques problèmes.

Le plugin est disponible sur ce dépôt GitHub.

Forcer Debian apt en IPv4

2017-10-13T20:56:21.000Z

La commande Debian apt a parfois tendance à poser problème sur des hosts en configuration réseau dual-stack IPv4 et IPv6. Pour y remédier, il convient de forcer l’utilisation d’IPv4.

L’activation du mode forcé IPv4 permet d’éviter les lenteurs et échecs réseaux et au final garantir la récupération des mises à jour.

Une option est à ajouter à votre configuration :

# echo 'Acquire::ForceIPv4 "true";' > /etc/apt/apt.conf.d/99forceipv4

Supprimer un fichier sensible d'un dépôt Git

2017-07-22T21:31:49.000Z

Parfois, un fichier sensible tel une clé, un token ou encore un certificat, se retrouve ajouté par erreur dans un dépôt Git. Seule solution faire une passe complète des commits pour le supprimer.

Pour filtrer un fichier à supprimer, utilisez la commande git suivante :

# git filter-branch --force \
   --index-filter 'git rm --cached --ignore-unmatch path/to/file' \
   --prune-empty --tag-name-filter cat -- --all

Le dépôt devra par la suite être republié par force push.

Activer IPv6 sur une instance EC2 Debian

2017-05-08T11:13:04.000Z

Suite à l’assignation d’un bloc IPv6 à votre VPC et aux subnets réseaux, il reste à activer le support IPv6 sur chaque instance EC2.

Dans le cas d’une distribution Debian, l’activation de l’IPv6 s’effectue en ajoutant la ligne suivante au fichier de configuration des interfaces réseaux:

# vim /etc/network/interfaces

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

L’instance est ensuite à redémarrer.

Nettoyer les branches Git locales

2017-04-10T21:34:36.000Z

Suite à l’évolution d’un dépôt git, les branches sont supprimées au fur et à mesure sur le serveur. Cependant, les anciennes branches locales demeurent côté client et il est également nécessaire de les supprimer en veillant à ne supprimer aucune branche active.

Voici la commande git pour supprimer toutes les branches locales fusionnées et déjà supprimées sur le serveur :

$ git branch -r | \
    awk '{print $1}' | \
    egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | \
    awk '{print $1}' | \
    xargs git branch -d

Installation de Kodi 17.1 sur RaspberryPI

2017-04-02T15:56:45.000Z

Un dépôt de paquets est disponible pour installer facilement Kodi sur RaspberryPI.

La procédure d’installation se limite aux commandes suivantes:

# 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 0.2.1

2017-03-11T19:54:58.000Z

Zabbix-docker est un agent de monitoring des containers Docker pour Zabbix permettant de récupérer l’ensemble des métriques des containers d’un host particulier ou d’un cluster.

Les métriques actuellement supportées sont :

le statut des containers dont le healthcheck
les statistiques RAM, CPU, des interfaces réseau et des périphériques de stockage
l’état des processus en exécution
les évènements

La version 0.2 apporte en particulier l’exécution de commandes distantes dans les containers monitorés par Docker. Ainsi, en ajoutant vos scripts de collecte des métriques trapper à vos images Docker.

Le dépôt du projet est disponible sur GitHub.

Gérer vos certificats Let's Encrypt avec dehydrated

2017-03-11T19:06:08.000Z

Dehydrated permet de gérer vos certificats SSL/TLS Let’s Encrypt depuis la ligne de commandes.

Le package logiciel est disponible sur la plupart des distributions Linux :

# apt install dehydated

Les noms de domaines des certificats à gérer sont à lister dans le fichier domains.txt:

# vim /etc/dehydated/domains.txt

blog.hbis.fr www.hbis.fr
mail.hbis.fr

Chaque ligne correspond à un certificat. Dans le cas où des noms alternatifs sont nécessaires, ils sont à spécifier sur la même ligne suite au nom principal du certificat.

Au sujet de la configuration, éditez les paramètres de validation des certificats:

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

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

Les certificats peuvent enfin être générés :

# dehydrated -c

Afin de renouveller les certificats avant leur expiration, un script cron doit être créé:

# vim /etc/cron.monthly/dehydrated

#!/bin/bash

/usr/bin/dehydrated -c
systemctl reload nginx

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

Extraire une chaîne de certificats avec OpenSSL

2017-02-11T20:58:49.000Z

La commande openssl permet de récupérer la chaîne de certificats d’un hôte.

La commande suivante permet de récupérer la chaîne complète et la stocke dans un fichier:

$ echo | openssl s_client -connect my.host.com:443 -showcerts 2>&1 |  \
    sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > fullchain.pem

Inspecter les healthchecks Docker

2017-01-19T15:05:58.000Z

L’inspection des évènements Docker permet de détecter les containers dont les fréquences d’exécution des healthchecks est trop aggressive.

Pour analyser l’exécution des commandes healthcheck, le filtre d’évènements à appliquer est exec_start :

$ 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.hbis.fr/base/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.hbis.fr/base/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.hbis.fr/base/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.hbis.fr/base/dynamodb, name=dev_dynamodb_1)

Redémarrer un host distant avec Fabric

2016-10-23T17:38:07.000Z

Le redémarrage d’un host avec Fabric est parfois compliqué à gérer.

L’opération reboot fournie par Fabric étant dysfonctionnelle et dépréciée, il convient d’utiliser une méthode manuelle et sûre :

1from fabric.state import *
2
3def mytask:
4    sudo("shutdown -r +1")
5    time.sleep(120)
6    connections[env.host_string].get_transport().close()
7    run("uptime")

Le délai d’attente peut être adaptée au besoin, mais la déconnexion à l’hôte est requise pour que Fabric puisse ré-établir le tunnel SSH.

Corriger la keymap FR d'un clavier mac alu sous Linux

2016-09-29T20:22:02.000Z

La keymap des claviers mac FR sous Linux est erronée : les touches arobase/dièse et inférieur/supérieur sont inversées.

Voici 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 : images Alpine Linux avec intégration Consul

2016-05-22T20:29:40.000Z

Depuis quelques mois, j’utilise mes propres images Docker basées sous Alpine Linux.

En dehors d’un gain substantiel d’espace disque, ces images sont destinées à une utilisation avec Consul d’Hashicorp afin de prendre en charge la configuration/reconfiguration à chaud des services. Les processus sont gérés par s6-overlay et les fichiers de configuration dynamiques par Consul-template.

Docker : erreur Resource temporarily unavailable (11)

2016-03-25T20:04:48.000Z

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

Maven : vérifier les mises à jour disponibles

2016-03-06T18:30:29.000Z

Vérifier les mises à jour des plugins Maven :

boris@debian:~$ mvn versions:display-plugin-updates

Vérifier les mises à jour des dépendances du projet :

boris@debian:~$ mvn versions:display-dependency-updates

NetworkManager : désactiver la gestion d'une interface réseau

2016-03-06T18:26:20.000Z

Par défaut, NetworkManager s’accapare de la gestion de toutes les interfaces réseaux. Dans le cadre de l’utilisation de système de virtualisation, ceci est problématique. Il est nécessaire de désactiver cette gestion en précisant soit le nom/regex de l’interface réseau, soit son adresse MAC.

Voici un exemple couvrant ces deux cas :

boris@debian:~$ vim /etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[keyfile]
unmanaged-devices=interface-name:vboxnet*;interface-name:docker0
unmanaged-devices=mac:74:da:38:60:15:cd

boris@debian:~$ sudo systemctl restart network-manager

Firefox : supprimer la configuration HSTS d'un site

2016-03-06T18:17:49.000Z

L’effacement de l’historique Firefox ne supprime pas la configuration de HSTS. Pour y remédier, l’édition du fichier SiteSecurityServiceState.txt présent dans votre profil est obligatoire :

# cd ~/.mozilla/firefox/eue6le58.dev-edition-default/
# vim SiteSecurityServiceState.txt

Supprimez-le ou les lignes concernées.

Nginx : création d'un fichier htpasswd avec openssl

2016-03-06T18:12:43.000Z

boris@debian:~$ printf "USER:$(openssl passwd -crypt PASSWORD)\n" > vhost.htpasswd

Maven : construire une image Docker et y intégrer le JAR du projet

2016-02-24T00:24:17.000Z

Le but est de construire l’image Docker d’un projet Java par Maven. L’image est générée par le plugin Maven docker-maven-plugin mais afin de ne pas casser le versioning, le nom du JAR original n’est pas modifié; une copie est réalisée avant intégration (un nom de fichier fixe est obligatoire).

Au niveau du projet Maven, un répertoire dédié est créé pour le Dockerfile et l’ensemble des fichiers de génération de l’image :

bhuisgen@local:~/Projects/java/demo$ find src/main/docker/

src/main/docker/
src/main/docker/Dockerfile
src/main/docker/root
src/main/docker/root/etc
src/main/docker/root/etc/services.d
src/main/docker/root/etc/services.d/app
src/main/docker/root/etc/services.d/app/finish
src/main/docker/root/etc/services.d/app/run

L’image repose sur une base Alpine Linux avec gestion des services par s6-overlay auquel est ajouté le strict nécessaire :

bhuisgen@local:~/Projects/java/demo$ cat src/main/docker/Dockerfile

FROM bhuisgen/alpine-base:latest
MAINTAINER Boris HUISGEN <bhuisgen@hbis.fr>

RUN apk add --update openjdk8-jre && \
    rm -rf /var/cache/apk/*

COPY root /

ENTRYPOINT ["/init"]
CMD []

A noter que la commande de copie du JAR n’est pas présente; le plugin l’ajoutera de lui-même. Le reste est donc à ajouter au fichier POM :

bhuisgen@local:~/Projects/java/demo$ vim pom.xml

[...]
    <build>
        <plugins>
[...]
            <!-- copy and rename the JAR to a fixed filename -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-antrun-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <target>
                                <copy
                                    file="${project.build.directory}/${project.artifactId}-${project.version}.jar"
                                    tofile="${project.build.directory}/app.jar" />
                            </target>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

            <!-- build the Docker image -->
            <plugin>
                <groupId>com.spotify</groupId>
                <artifactId>docker-maven-plugin</artifactId>
                <version>0.4.0</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>build</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <imageName>${docker.image.prefix}/${project.artifactId}</imageName>
                    <imageTag>${project.version}</imageTag>
                    <imageTag>latest</imageTag>
                    <dockerDirectory>src/main/docker</dockerDirectory>
                    <resources>
                        <resource>
                            <directory>${project.build.directory}</directory>
                            <include>app.jar</include>
                            <targetPath>/</targetPath>
                        </resource>
                    </resources>
                </configuration>
            </plugin>

L’image sera générée lors de la phase package et un tag y sera appliqué pour conserver le numéro de version de l’application.

OpenSSH : accès au prompt

2016-02-23T23:14:40.000Z

Raccourci-clavier : [Entrée] + [~] + [?]

~?
Supported escape sequences:
 ~.   - terminate connection (and any multiplexed sessions)
 ~B   - send a BREAK to the remote system
 ~C   - open a command line
 ~R   - request rekey
 ~V/v - decrease/increase verbosity (LogLevel)
 ~^Z  - suspend ssh
 ~#   - list forwarded connections
 ~&   - background ssh (when waiting for connections to terminate)
 ~?   - this message
 ~~   - send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

Boto : gérer le logging

2016-02-23T23:12:47.000Z

Pour activer le log de debug :

import logging

logging.basicConfig(filename="boto.log", level=logging.DEBUG)

Pour supprimer tout le logging (par exemple avec S3) hormis les erreurs critiques :

import logging

logging.getLogger('boto').setLevel(logging.CRITICAL)

Amazon EC2 : scripts de gestion des disques éphémères

2016-01-22T00:03:52.000Z

Voici les scripts et unités systemd que j’utilise pour gérer les disques éphémères de mes instances Amazon EC2.

Dépôt git : ephemeral-scripts

Java : log syslog avec log4j

2015-12-19T13:43:03.000Z

package syslog;

import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.net.SyslogAppender;

public class test {
    private static final Logger log = Logger.getLogger(test.class);

    public static void main(String[] args) {
        Logger rootLogger = Logger.getRootLogger();

        rootLogger.setLevel(Level.DEBUG);

        PatternLayout layout = new PatternLayout("%t: %p: %m%n");
        SyslogAppender syslogAppender = new SyslogAppender(layout, "localhost",
                SyslogAppender.LOG_USER);

        Logger.getRootLogger().addAppender(syslogAppender);

        log.info("log message");
    }
}

Ne pas oublier d’activer l’écoute réseau du serveur syslog local :

# vim /etc/rsyslog.conf

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Git : annuler le dernier commit amend

2015-12-19T13:39:38.000Z

# git reset --soft HEAD@{1}

Docker : activer les restrictions RAM et swap

2015-09-20T23:28:43.000Z

# vim /etc/default/grub

GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"

# update-grub

# vim /etc/default/docker

DOCKER_OPTS="--exec-opt native.cgroupdriver=cgroupfs"

# shutdown -r now

Debian : fix startup Docker 1.7 et kernel 4.1

2015-09-20T19:44:18.000Z

sept. 20 19:34:19 muse systemd[1]: Started Docker Application Container Engine.
sept. 20 19:34:19 muse docker[18643]: time="2015-09-20T19:34:19.773439875+02:00" level=error msg="[graphdriver] prior storage driver \"aufs\" failed: driver not supported"
sept. 20 19:34:19 muse docker[18643]: time="2015-09-20T19:34:19.773487551+02:00" level=fatal msg="Error starting daemon: error initializing graphdriver: driver not supported"

# systemctl start docker

Debian : fix crash Netbeans 8

2015-09-20T19:25:58.000Z

# vim /etc/java-8-openjdk/accessibility.properties

#assistive_technologies=org.GNOME.Accessibility.AtkWrapper

Git : appliquer une stratégie de merge différente

2015-09-20T19:22:14.000Z

# git checkout master
# git merge --no-ff release -X theirs

MongoDB : déployer rapidement un replicat set local

2015-09-18T15:15:50.000Z

Linux : afficher la consommation swap par processus

2015-09-01T09:21:40.000Z

# for file in /proc/*/status ; do awk '/^(VmSwap|Pid|Name)/{printf $2 " " $3}END{ print ""}' $file; done | sort

Git : prompt bash

2015-08-31T12:16:16.000Z

Un prompt bash spécialisé pour l’utilisation de Git : https://github.com/magicmonty/bash-git-prompt

Linux : tester les performances I/O

2015-07-15T13:33:34.000Z

# hdparm -t -T /dev/sda

# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync

# bonnie++ -d /mnt -r 8000 -u toto

PostgreSQL : afficher les droits spécifiques associés à un table

2015-07-08T11:16:32.000Z

dbname=# SELECT grantee,privilege_type FROM information_schema.role_table_grants WHERE table_name='mytable';

 grantee  | privilege_type
----------+----------------
 user1    | INSERT
 user1    | SELECT
 user1    | UPDATE
 user1    | DELETE
 user1    | TRUNCATE
 user1    | REFERENCES
 user1    | TRIGGER
 user2    | INSERT
 user2    | SELECT
 user2    | UPDATE
 user2    | DELETE
(11 rows)

Talend : erreur avec le service IComponentsService

2015-07-08T10:59:40.000Z

Une petite erreur classique lors de l’utilisation du logiciel Talend :

java.lang.RuntimeException: Le service org.talend.core.model.components.IComponentsService n'a pas été enregistré.
    at org.talend.core.GlobalServiceRegister.getService(Unknown Source)
    at org.talend.repository.model.ComponentsFactoryProvider.getInstance(Unknown Source)
    at org.talend.core.CoreService.componentsReset(Unknown Source)
    at org.talend.core.repository.model.ProxyRepositoryFactory.logOnProject(Unknown Source)
    at org.talend.repository.ui.login.LoginDialog$1.run(Unknown Source)
    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Pour la corriger, le répertoire suivant est à supprimer :

# rmdir C:\Talend\workspace\.metadata\.plugins\org.eclipse.core.resources\.root\.indexes

Docker : supprimer tous les containers à l'arrêt

2015-05-13T14:46:14.000Z

# docker rm $(docker ps -a|grep "Exited"|awk "{print \$1}")