PAB's blog

Nous allons expliquer ici comment fabriquer un photomètre avec la plateforme Arduino et le composant BH1750 (encore appelé GY-30, fiche technique ici) que l'on trouve pour quelques euros chez les bons revendeurs électroniques.

Un photomètre qui parle en série

Une première version du photomètre sera simple : nous utiliserons les facultés d'Arduino à communiquer via un port série pour afficher le niveau de luminosité mesuré. Le circuit est alors assez simple (cf. représentation ci-dessous) :

• le pin VCC du capteur se connecte au pin 5V de l'Arduino
• le pin GND du capteur se connecte au pin GND de l'Arduino
• le pin SDA du capteur se connecte au pin A4 (Analogique 4) de l'Arduino
• le pin SDL du capteur se connecte au pin A5 (Analogique 5) de l'Arduino

On compile alors le code suivant et on le charge sur l'Arduino (par exemple avec l'IDE Arduino) :

#include <Wire.h>
 
int BH1750_address = 0x23; // i2c Addresse
byte buff[2];
 
void setup() {
  
  Wire.begin();
  BH1750_Init(BH1750_address);
  
  delay(200);
  Serial.begin(9600);
  Serial.println("Démarrage du système... patientez svp !");
}
 
void loop() {
  
  float valf=0;
 
  if(BH1750_Read(BH1750_address)==2){
    valf=((buff[0]<<8)|buff[1])/1.2;
  
    if(valf<0) {
      Serial.print("> 65535");
    }
    else {
      Serial.print((int)valf,DEC);
    }
    Serial.println(" lx"); 
  }
  delay(1000);
}
 
void BH1750_Init(int address) {
  Wire.beginTransmission(address);
  Wire.write(0x10); // 1 [lux] aufloesung
  Wire.endTransmission();
}
 
byte BH1750_Read(int address) {
  byte i=0;
  Wire.beginTransmission(address);
  Wire.requestFrom(address, 2);
  while(Wire.available()) {
    buff[i] = Wire.read(); 
    i++;
  }
  Wire.endTransmission();  
  return i;
}

Et hop, sur le port série, on peut voir :

Démarrage du système... patientez svp !
92 lx
92 lx
92 lx
75 lx
47 lx
342 lx
43 lx

Un photomètre avec son propre écran LCD

Rajoutons un écran LCD pour afficher le résultat sans avoir à ouvrir un port série ! Nous allons donc brancher un LCD Keypad Shield (tel qu'ici) sur l'Arduino, et nous allons modifier le code comme suit :

#include <Wire.h>
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);

int BH1750_address = 0x23; // i2c Addresse
byte buff[2];

void setup() {

  // set up the LCD's number of columns and rows:
  lcd.begin(16, 2);
  // Print a message to the LCD.
  lcd.print("Look the world");

  Wire.begin();
  BH1750_Init(BH1750_address);

  delay(200);
  Serial.begin(9600);
}

void loop(){
  float valf=0;
  if(BH1750_Read(BH1750_address)==2) {
    valf=((buff[0]<<8)|buff[1])/1.2;
    if(valf<0) {lcd.setCursor(0,0); lcd.print("> 65535 lx");}
    else {lcd.setCursor(0,0); lcd.print((int)valf,DEC); lcd.print(" lx                    ");}
  }
  else {
    lcd.setCursor(0,0); lcd.print("Error...             "+BH1750_Read(BH1750_address));
  }
  delay(1000);
}

void BH1750_Init(int address) {
  Wire.beginTransmission(address);
  Wire.write(0x10); // 1 [lux] aufloesung
  Wire.endTransmission();
}

byte BH1750_Read(int address){
  byte i=0;
  Wire.beginTransmission(address);
  Wire.requestFrom(address, 2);
  while(Wire.available()){
    buff[i] = Wire.read();
    i++;
  }
  Wire.endTransmission();
  return i;
}

On compile et on charge sur l'Arduino, et hop le tour est joué !

Depuis Mai 2016, le service Let's Encrypt n'est plus en bêta et les limitations de la bêta évoquées ici ne sont plus mordantes !

Depuis Mai 2016, le client letsencrypt est devenu certbot (https://certbot.eff.org/) ! les commandes évoquées plus bas sont sans doute valables en remplaçant letsencrypt-auto par certbot ! Il faut aussi noter que le client certbot dispose désormais de fonctions de renouvellement plus élaborées qu'auparavant ! Cet article est conservé pour archive et inspiration.

Letsencrypt se présente comme le futur du chiffrement sur internet. Bien que déjà fonctionnel, le service offert est encore en phase de test (bêta) et par conséquent certaines contraintes s'appliquent aux usagers testeurs. Parmi ces contraintes, les 2 les plus bloquantes sont :

• pas de système de renouvellement automatique pour le moment (c'est prévu, vivement !)
• limite imposée de 5 certificats par domaine par semaine (i.e. qu'il faut attendre une semaine pour pouvoir créer des certificats pour un nouveau sous-domaine d'un domaine qui possède déjà 5 certificats de sous-domaine)

Pour Letsencrypt qui émet des certificats à la validité courte de 3 mois, le renouvellement doit être fait régulièrement et il correspond ni plus ni moins à l'édition d'un nouveau certificat.

La contrainte évoquée plus haut est bloquante pour le renouvellement : en effet il n'est pas possible de renouveler plus de 5 certificats par semaine pour un même domaine...

Principe du renouvellement à terme

A terme, un système de renouvellement automatique sera intégré à Letsencrypt et il suffira de lancer tous les 2 mois (par exemple via cron) la commande demandant le renouvellement de tous les certificats en approche de péremption. Vivement cela !

Une méthode fonctionnelle aujourd'hui

Aujourd'hui, à nous de créer l'automatisme qui va bien et qui permettra aussi de contourner la limite des 5 renouvellements par semaine (en réalisant un roulement). Nous allons détailler ici un script qui, appelé chaque semaine, :

• détecte les certificats qui ont moins de 30 jours de validité (2592000 secondes)
• demande le renouvellement de chaque certificat dans ce cas

Voici le code du script :

#!/bin/bash
declare -a list=(
"/etc/letsencrypt/live/domaine1.tld;certbot certonly --renew-by-default -a webroot --webroot-path /path/to/domaine1/website -d domaine1.tld -d www.domaine1.tld"
"/etc/letsencrypt/live/sous.domaine1.tld;certbot certonly --renew-by-default -a webroot --webroot-path /path/to/sous/domaine1/website -d sous.domaine1.tld -d www.sous.domaine1.tld"
"/etc/letsencrypt/live/domaine2.tld;certbot certonly --renew-by-default -a webroot --webroot-path /path/to/domaine2/website -d domaine2.tld -d www.domaine2.tld"
)

for line in "${list[@]}"
do
	IFS=";" read -ra stuff <<< $line
	folder=${stuff[0]}
	command=${stuff[1]}
        if openssl x509 -checkend 2592000 -noout -in $folder/fullchain.pem
        then
                echo "Nothing to do for $folder"
        else
                $command
                rm -f $folder/total.pem
                cat $folder/fullchain.pem $folder/privkey.pem > $folder/total.pem
                echo "Done for $folder"
        fi
done

Rapidement :

• on commence par lister dans un tableau chaque domaine dont il faut s'occuper (en indiquant le chemin correspondant à ce domaine dans le dossier /etc/letsencrypt/live/) et, séparée par ";", la commande Letsencrypt utilisée pour le renouvellement. Il s'agit de la même commande que pour la création initiale du certificat sauf que l'on ajoute l'option "--renew-by-default"
• on parcourt ensuite le tableau élément par élément :
  • en vérifiant l'âge du certificat (avec openssl)
  • en lançant la commande de renouvellement s'il est trop proche de la péremption

Si l'on utilise Letsencrypt avec Pound, on ajoutera 2 actions :

• remplacer le fichier .pem utilisé par Pound par la nouvelle version obtenue
• redémarrer Pound

Le script devient alors :

#!/bin/bash
declare -a list=(
"/etc/letsencrypt/live/domaine1.tld;certbot certonly --renew-by-default -a webroot --webroot-path /path/to/domaine1/website -d domaine1.tld -d www.domaine1.tld"
"/etc/letsencrypt/live/sous.domaine1.tld;certbot --renew-by-default -a webroot --webroot-path /path/to/sous/domaine1/website -d sous.domaine1.tld -d www.sous.domaine1.tld"
"/etc/letsencrypt/live/domaine2.tld;certbot certonly --renew-by-default -a webroot --webroot-path /path/to/domaine2/website -d domaine2.tld -d www.domaine2.tld"
)

for line in "${list[@]}"
do
	IFS=";" read -ra stuff <<< $line
	folder=${stuff[0]}
	command=${stuff[1]}
        if openssl x509 -checkend 2592000 -noout -in $folder/fullchain.pem
        then
                echo "Nothing to do for $folder"
        else
                $command
                rm -f $folder/total.pem
                cat $folder/fullchain.pem $folder/privkey.pem > $folder/total.pem
                echo "Done for $folder"
        fi
done
service pound restart

Archive

Dans une ancienne version de ce billet, on utilisait le morceau de script suivant se basant sur la date de dernière modification du fichier de certificat plutôt que d'utiliser openssl, mais c'est moins propre. Pour archivage, voici le test qui était alors utilisé (renouvellement des certificats plus vieux que 60 jours) :

	timesincelastchange=$(expr $(expr $(date +%s) - $(date +%s -r $folder/fullchain.pem )) / 86400)
	if [ $timesincelastchange -gt 60 ]
	then
		$command
		echo "Done for $folder"
	else
		echo "Nothing to do for $folder"
	fi

Depuis le début du mois, il est possible d'utiliser "Let's Encrypt" pour obtenir des certificats TLS/SSL pour sécuriser ses sites et services en ligne (bien que le système soit toujours annoncé en bêta). Ce matin, je décidais donc de m'y mettre et de remplacer mes certificats StartSSL.

Depuis Mai 2016, le service Let's Encrypt n'est plus en bêta et les limitations de la bêta évoquées ici ne sont plus mordantes !

Depuis Mai 2016, le client letsencrypt est devenu certbot (https://certbot.eff.org/) ! les commandes évoquées plus bas sont sans doute valables en remplaçant letsencrypt-auto par certbot !

Première étape : comprendre le fonctionnement

Le principe est assez simple et n'est pas très différent de celui déjà rencontré pour l'obtention de certificats auprès des opérateurs "classiques" (les StartSSL et consors). Classiquement, (i) on démontre la possession réelle du nom de domaine, (ii) on génère une clé privée et une clé publique et on transmet la clé publique à l'opérateur de certification qui (iii) fournit en retour un certificat attestant le lien entre le nom de domaine et la paire de clés crypto utilisées pour l'établissement de communications sécurisées. Avec Letsencrypt, ces étapes ont lieu mais automatiquement. Dans l'utilisation commune, Letsencrypt vient avec un script Python (letsencrypt-auto) qui va faire tout le travail :

• le script va créer un fichier mondomaine.tld/.well-known/acme-challenge/chaîne-choisie-au-hasard et le serveur distant cherchera à accéder à ce fichier pour authentifier la possession/maîtrise du domaine mondomaine.tld
• puis le script génère et échange les clés cryptographiques avec l'autorité de certification Letsencrypt
• et le certificat est rapatrié
• enfin, dans certains cas, le script se charge même de l'installer !

Par rapport à ce qui est fourni habituellement par les acteurs privés :

• la chaîne de bout en bout est plus transparente et libre
• le certificat est gratuit
• le certificat n'a une validité que de 90 jours (mais le renouvellement est gratuit et peut être géré automatiquement par le script tous les 2 mois par exemple)
• les certificats n'autorisent pas les wildcards (e.g. *.mondomaine.tld) ce qui a déjà été fort amplement débattu partout sur le web mais ne semble pas devoir changer.

Deuxième étape : installer Let’s Encrypt

Nous allons commencer par le cas simple d'un site statique. Le script letsencrypt se télécharge sur la machine d'hébergement à l'aide de git :

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

puis on peut lancer le script (qui va effectuer les installations supplémentaires nécessaires) par :

./letsencrypt-auto

Cela fonctionne très bien sur Debian Jessie et sans doute les autres systèmes récents (c'est la version de Python qui semble être un des facteurs limitants pour les "vieilles" distributions). On reviendra sur ce point plus loin.

Troisième étape : utiliser Let’s Encrypt pour un site statique

Commençons par le cas simple d'un site statique hébergé dans /var/www/mon-site/ et servi par Apache.

./letsencrypt-auto certonly -a webroot --webroot-path /var/www/mon-site/ -d mondomaine.tld

certonly car nous demandons à Let’s Encrypt de générer le certificat et de s'arrêter là (donc de ne pas l'installer lui-même). -a webroot car nous indiquons à Let’s Encrypt où se trouve la racine du site afin qu'il puisse y placer le fichier de "challenge" (.well-known/acme-challenge/chaîne-choisie-au-hasard). Et -d mondomaine.tld pour indiquer le domaine. Il est possible d'indiquer plusieurs domaines s'ils partagent le même webroot par exemple :

./letsencrypt-auto certonly -a webroot --webroot-path /var/www/mon-site/ -d mondomaine.tld -d www.mondomaine.tld

Dans ce cas le certificat contiendra les 2 domaines en SAN (Subject Alternative Names).

Au premier lancement, le script demande de saisir l'adresse courriel qui sera rattachée au compte (et qui recevra les éventuelles notifications de péremption des domaines non renouvelés).

Et hop, le script travaille et un certificat tout neuf (et valide !) est déposé dans /etc/letsencrypt/live/mondomaine.tld/fullchain.pem. La clé privée correspondante se trouve dans /etc/letsencrypt/live/mondomaine.tld/privkey.pem. Ce certificat peut alors être utilisé comme il l'a toujours été (par ex. appelé dans la configuration d'Apache ou de votre load balancer) - je détaille ici comment l'utiliser avec le load balancer Pound.

Let’s Encrypt et un blog dotclear

Aucune surprise ni difficulté avec dotclear :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/blog/dotclear -d blog.bandinelli.net

et hop, /etc/letsencrypt/live/blog.bandinelli.net/fullchain.pem est créé ! Une commande pour un certificat, c'est classe et pratique !

Let’s Encrypt et Piwik

Aucune surprise ni difficulté avec Piwik :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/racine/piwik -d piwik.mondomaine.tld

et hop, /etc/letsencrypt/live/piwik.mondomaine.tld/fullchain.pem est créé !

Let’s Encrypt et Wordpress

Aucune surprise ni difficulté avec Wordpress :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/racine/wordpress -d mondomaine.tld

et hop, /etc/letsencrypt/live/mondomaine.tld/fullchain.pem est créé !

Let’s Encrypt et Drupal 7

Une petite astuce est nécessaire ici : par défaut le moteur de Drupal demande au serveur web de réécrire toutes les adresses et empêche l'accès à certaines adresses. Ainsi, le fichier .htaccess se trouvant à la racine d'un site Drupal contient la ligne suivante :

RewriteRule "(^|/)\." - [F]

Cette ligne ordonne à Apache de renvoyer vers la page "Accès interdit" toute requête qui débuterait par ".". Il faut bien évidemment désactiver cette sécurité pour Letsencrypt :

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule "(^|/)\." - [F]

La condition RewriteCond désactive la redirection qui suit pour le challenge de letsencrypt seulement.

Une fois cela effectué, on peut utiliser la commande classique pour obtenir le certificat valide dans /etc/letsencrypt/live/mondomaine.tld/fullchain.pem :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/site/drupal/ -d mondomaine.tld

Let’s Encrypt et ownCloud/Nextcloud

Une petite astuce est nécessaire ici : par défaut le moteur d'ownCloud demande au serveur web de réécrire toutes les adresses et empêche l'accès à certaines adresses. Ainsi, le fichier .htaccess se trouvant à la racine d'une instance ownCloud/Nextcloud contient la ligne suivante :

RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

elle renvoie vers 404 tous les appels à un chemin démarrant par ".". Il est bien sûr nécessaire de désactiver cette ligne conditionnellement :

RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

Ensuite, sans surprise, pour obtenir le certificat valide dans /etc/letsencrypt/live/mondomainecloud.tld/fullchain.pem :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/owncloud/ -d mondomainecloud.tld

Let’s Encrypt et une application Ruby on Rails

Aucune surprise ni difficulté avec une application Ruby on Rails servie en production par Unicorn, à condition de bien choisir le dossier public comme webroot :

./letsencrypt-auto certonly -a webroot --webroot-path /chemin/vers/application/public -d domaine.tld

et hop, /etc/letsencrypt/live/domaine.tld/fullchain.pem est créé !

Let’s Encrypt sur une vieille distribution ?

Si Let's Encrypt ne peut être lancé sur votre machine de production car elle dispose de versions trop anciennes des fichiers, rien n'est perdu ! Il est en effet possible de fournir au script un webroot qui serait par exemple partagé via SSH ! Par exemple :

apt install sshfs
mkdir /mnt/webroot-distant
sshfs user@machine:/path/to/webroot /mnt/webroot-distant
./letsencrypt-auto certonly -a webroot --webroot-path /mnt/webroot-distant -d mondomaine.tld

Conclusion

Très efficace et rapide, comment ne pas tomber sous le charme de Letsencrypt ? Il reste à valider : la procédure de renouvellement et la pérennité dans le temps de la structure. Pour y aider, on peut toujours faire un petit don sur la page d'accueil de Let’s Encrypt !

Si, comme moi, vous avez longuement cherché le moyen de modifier le message d'absence dans l'interface de Xivo, ne cherchez plus ! Il se paramètre très facilement sans passer par l'interface graphique en plaçant le fichier .wav adapté à cet emplacement :

/var/spool/asterisk/voicemail/contexte_du_client/numéro_boite_vocale/unavail.wav

Il suffit de le savoir !

Avec les outils inclus dans la suite ImageMagick, il est assez facile de modifier en lot les images d'un répertoire.

Par exemple, pour redimensionner tout un lot d'images (la plus grande dimension à 800 pixels), on pourra faire :

mogrify -resize 800x800 *.jpg

Pour effectuer des rotations de 180° sur plusieurs images, on fera :

mogrify -rotate 180 *.jpg

Plus compliqué, pour ajouter un texte (par exemple le nom du photographe) sur chaque photo, on pourra faire :

for file in *.jpg; do  convert $file -pointsize 20 -draw "gravity SouthEast fill white text 1,11 'Voici mon texte ' " $file; done

Cela transforme alors l'image comme suit :

Cette article fait suite aux précédents sur l'installation et le paramétrage de Xivo (ici, ici et ici) : nous allons décrire ici l'installation des téléphones Snom D715.

Les téléphones Snom D715

La société Snom est une société allemande (il est sympathique de faire travailler nos voisins européens), elle a conçu et distribue le Snom D715 : un appareil de très bonne facture avec un excellent rapport qualité prix.

Brièvement, la qualité du son est excellente, les finitions sont bonnes et le téléphone dégage dans l'ensemble une apparence de robustesse et de professionnalisme. Il accepte bien sûr une alimentation POE et dispose d'un switch intégré Gigabit qui permet de relier à des réseaux rapides mais également d'étendre le réseau à un ordinateur proche. Enfin, il dispose d'une prise pour casque, d'un port USB (pour les éventuelles extensions, mais qui délivre aussi suffisamment de courant pour recharger un téléphone portable) et est fourni avec un câble RJ45 de catégorie 6 et un support solide en plastique.

Comme il est nativement supporté par Xivo, c'est un excellent choix pour déployer un réseau VOIP à un coût acceptable : environ 90€ HT par poste.

L'installation chez Xivo

Installer le plugin Xivo pour Snom

La première étape est d'installer le plugin 'provisionning' pour les téléphones Snom. Cela se fait aisément dans Configuration > Provisioning > Plugins, puis on clique sur la petite icône 'planète terre' pour mettre à jour la liste des plugins depuis internet et, une fois les plugins visibles, on choisit "xivo-snom" puis 715-fw (correspondants aux Snom 715 & D715). Dès lors, Xivo saura communiquer avec les téléphones Snom.

Préparer un modèle de configuration qui sera déployé sur tout téléphone qui se connectera au système de provisioning Snom

Dans Configuration > Provisioning > Template device, on peut paramétrer les options qui seront données par défaut aux téléphones Snom : langue, fuseau horaire, protocole, adresse du serveur NTP et, important, les noms d'utilisateurs et mot de passe qui seront déployés sur chaque téléphone. Dans l'onglet 'Advanced', on peut alors encore un peu plus loin dans le paramétrage des téléphones.

Si vous comptez effectuer le provisioning avec le module DHCP de Xivo, vous pouvez sans doute vous arrêter là. En revanche, si vous escomptez ne pas utiliser le DHCP de Xivo (par exemple car vos téléphones sont sur votre réseau principal et vous ne souhaitez pas remplacer le DHCP par celui de Xivo) et préférez le provisioning http (i.e. que les téléphones interrogent le serveur de paramétrage), alors il est nécessaire de faire une petite modification supplémentaire.

Dans /var/lib/xivo-provd/plugins/xivo-snom-*/var/tftpboot/snom-general.xml, on peut trouver cette ligne :

<provisioning_order perm="R">dhcp:stop</provisioning_order>

Elle signifie que l'on demande au téléphone d'arrêter toute autre procédure après avoir reçu une réponse (même incomplète) d'un DHCP. Ce paramétrage sera transféré aux téléphones lorsqu'ils viendront se configurer auprès de Xivo.

On peut remplacer cette ligne par :

<provisioning_order perm="R">redirection:proceed dhcp:proceed</provisioning_order>

qui ordonnera au téléphone de ne pas arrêter sa configuration après l'obtention DHCP.

Démarrer les téléphones et leur indiquer l'adresse du serveur de configuration

On peut alors démarrer chaque téléphone, se connecter à l'interface de configuration du téléphone via HTTP, se rendre dans On the Setup > Advanced > Update et saisir ce paramétrage :

On pourra également modifier le paramétrage "allow rtp on mute" tel que détaillé ici. J'imagine, mais je n'ai pas testé, que ce paramétrage peut également être paramétré dans snom-general.xml avec une ligne qui ressemblerait à :

<allow_rtp_on_mute perm="PERMISSIONFLAG">on</allow_rtp_on_mute> 

On re-démarre alors les téléphones. Ils ont se connecter à Xivo, se configurer et bientôt ils apparaîtront dans la liste des périphériques connectés à Xivo.

Et ensuite ?

Il est alors possible de créer les utilisateurs, de leur attribuer des lignes et des terminaisons, et hop le tour est joué !

Il est pratique de pouvoir consulter un annuaire directement depuis des postes téléphoniques (VOIP) connectés au PBX Xivo.

Sur les postes téléphoniques

Si les téléphones utilisés sont compatibles avec Xivo (et sont auto-provisionnés, i.e. qu'ils sont configurés automatiquement par Xivo), alors l'accès à l'annuaire doit être fonctionnel très facilement. Il faudra bien sûr localiser, si elle existe, la touche du téléphone qui permet d'ouvrir l'annuaire. Aucune action spécifique n'est à effectuer.

Sur le serveur Xivo

Nous allons commencer par autoriser une plage d'IPs à se connecter à l'annuaire Xivo : pour cela, il faut se rendre dans IPBX > General settings > Phonebook. Puis cliquer sur le signe '+' pour ajouter un hôte à la liste des hôtes autorisés à se connecter à l'annuaire. On peut alors ajouter l'adresse IP d'un téléphone autorisé à afficher l'annuaire. Alternativement, on peut ajouter toute une plage d'IP par ex. 192.168.1.0 pour tous les postes dont l'IP appartiendra à la plage 192.168.1.x.

La deuxième étape consiste à peupler d'adresses l'annuaire. Il faut aller dans IPBX Services > Phonebook et cliquer sur le '+' visible dans la barre bleue.

et

On peut alors ajouter une entrée manuellement ou bien importer une liste à partir d'un fichier CSV. Le fichier CSV devra contenir une première ligne d'en-têtes donnant la teneur de chaque colonne, les champs devront être séparés par |. La liste des champs obligatoires (il y en a) et autorisés se trouve ici : http://xivo.readthedocs.org/en/latest/administration/phonebook.html.

Et voilà, les téléphones VOIP connectés à Xivo peuvent désormais consulter l'annuaire téléphonique !

Dnsmasq est un super petit serveur DNS et DHCP à destination des bricoleurs : fort simple à déployer et utiliser, il est parfait pour les installations domestiques ou celles des petites entreprises (on en a déjà parlé ici, ici et ici). Dnsmasq est par exemple employé au sein du micrologiciel (firmware) pour routeur Tomato car il est léger et en même temps très puissant.

J'ai découvert aujourd'hui une nouvelle corde à l'arc de Dnsmasq : il possède des fonctionnalités TFTP (Trivial File Transfer Protocol) qui permettent de l'utiliser pour booter un ordinateur (un serveur par exemple) en mode PXE (Preboot Execution Environment) en quelques lignes de configuration seulement.

L'usage est fort simple, tout se règle dans le fichier de configuration /etc/dnsmasq.conf :

dhcp-boot=pxelinux.0,pxeserver,192.168.18.11
pxe-service=x86PC, "Install Linux", pxelinux
enable-tftp
tftp-root=/tmp/tftp

Les 4 lignes sont assez explicites :

dhcp-boot=pxelinux.0,pxeserver,192.168.18.11
pxe-service=x86PC, "Install Linux", pxelinux

propose à chaque système en faisant la requête de démarrer en mode PXE en interrogeant 192.168.18.11 comme serveur de boot PXE. Pour que la suite fonctionne, il faut évidemment que 192.168.18.11 pointe vers l'hôte hébergeant le service Dnsmasq lui-même.

Puis

enable-tftp

active le TFTP de Dnsmasq.

Et enfin,

tftp-root=/tmp/tftp

indique où trouver le répertoire qui sera servi au travers de TFTP.

Si l'on veut démarrer l'installation de Debian par exemple, on aura préalablement décompressé netboot.tar.gz dans ce dossier ! Et miracle, tout périphérique cherchant à démarrer avec PXE sur le réseau va interroger Dnsmasq et récupérer le nécessaire pour le boot. Démarrer un serveur en PXE devient alors très facile !

La mission du jour était simple : redémarrer électriquement un serveur lorsqu'il cessait de répondre au ping. Défi relevé à l'aide d'un Pi, d'un relai et de quelques lignes de bash (et aussi un peu de python).

Parlons d'abord du relai

Un relai est un petit équipement électronique qui joue le rôle d'interrupteur contrôlable. Il existe de nombreuses cartes (pour Arduino notamment) qui comportent des relais en nombre variable : partons sur carte simple munie d'un seul canal.

Le principe de fonctionnement d'un relai est assez simple : une langue métallique, asservie par un ressort, ferme par défaut un circuit. En présence d'un champ électrique dans une bobine, un champ magnétique induit déplace la langue métallique qui vient alors fermer un second circuit. Comme un simple dessin vaut mieux qu'un long discours :

Beaucoup plus d'information sur le principe d'un relai se trouve ici : http://www.astuces-pratiques.fr/electronique/le-relais-principe-de-fonctionnement.

Les relais que nous trouvons classiquement comportent pour chaque canal :

• un bornier destiné au courant alternatif (attention lors de la manipulation ; ce n'est plus du 5V dans le circuit mais du 220V - il convient donc d'être particulièrement prudent notamment lors de l'usage en ne laissant pas le circuit électrique en libre accès !)
• 3 connecteurs pour le contrôle :

* un lien à la terre (par ex. GND ou G)
* un lien à l'alimentation 5V (par ex. Vcc ou V) : à brancher sur les pins d'alimentation
* un pôle pour le contrôle (par ex. IN ou S)

Par défaut, en absence de toute alimentation, 2 des bornes du bornier alternatif sont reliées. Lorsque le relai sera alimenté et que le pin d'entrée (IN ou S) sera amené au potentiel 5V, une bascule de circuit ouvert/fermé s'effectuera. Selon le cas d'usage, on pourra préférer avoir une alimentation active par défaut ou bien une alimentation coupée par défaut... il suffira d'adapter le branchement dans le bornier alternatif.

Branchement du relai sur le Pi et contrôle du relai par le Pi

Tout simplement :

et dès que l'on commandera au Pi de basculer le GPIO (7e pin sur la planche, selon la numérotation de la planche) alors le relai basculera.

Je ne présente pas ici le branchement au niveau du relai qui n'est pas bien compliqué si on le considère comme un simple interrupteur. Il conviendra seulement de placer l'interrupteur sur la phase (il est toujours plus prudent de couper la phase et non le neutre !).

Pour contrôler le relai, on pourra exécuter le code suivant en Python sur le Pi :

#! /usr/bin/python
import RPi.GPIO as GPIO ## Import GPIO library
GPIO.setmode(GPIO.BOARD) ## Use board pin numbering
GPIO.setup(7, GPIO.OUT) ## Setup GPIO Pin 7 to OUT
GPIO.output(7,True) ## Turn on GPIO pin 7

GPIO.output(7,True) pourra bien sûr être remplacé par GPIO.output(7,False) pour effectuer la bascule inverse.

Dans mon cas (c'est selon le branchement du relai), l'ouverture du circuit (i.e. son interruption) est commandée par ouvrir-circuit.py :

#! /usr/bin/python
import RPi.GPIO as GPIO ## Import GPIO library
GPIO.setmode(GPIO.BOARD) ## Use board pin numbering
GPIO.setup(7, GPIO.OUT) ## Setup GPIO Pin 7 to OUT
GPIO.output(7,True) ## Turn on GPIO pin 7

et la fermeture du circuit par fermer-circuit.py :

#! /usr/bin/python
import RPi.GPIO as GPIO ## Import GPIO library
GPIO.setmode(GPIO.BOARD) ## Use board pin numbering
GPIO.setup(7, GPIO.OUT) ## Setup GPIO Pin 7 to OUT
GPIO.output(7,False) ## Turn off GPIO pin 7

Et ce petit script bash (eteint-redemarre.sh) effectue une déconnexion/reconnexion de l'alimentation avec 5 secondes de pause intercalaire :

#!/bin/sh
/path/to/ouvrir-circuit.py 
sleep 5
/path/to/fermer-circuit.py 

Détecter la chute du serveur pour en provoquer le redémarrage

On peut alors demander au Pi de surveiller un hôte particulier et d'en provoquer le redémarrage électrique à l'aide de ce script :

#! /bin/sh
HOST=192.168.1.3
LOGFILE=/tmp/ce_que_le_pi_surveille.log
ping -c5 $HOST > /dev/null 2> /dev/null
if [ $? -eq 0 ] 
then 
	echo `date +%Y-%m-%d\ %H:%M` Host found >> $LOGFILE 
else
	echo `date +%Y-%m-%d\ %H:%M` Host not found >> $LOGFILE
	/path/to/eteint-redemarre.sh
fi

Et voilà, le tour est joué !

D'aucuns trouveront la sortie audio Jack du Raspberry Pi un peu limitée... et pour cause ! Transformer le Pi en véritable ampli est attractif... Et c'est heureusement possible grâce au Hifiberry Amp+ vendu par la société helvète Hifiberry.

L'Hifiberry Amp+ se branche sur les pins GPIO du Raspberry Pi (B+ ou 2). Il permet alors de brancher les enceintes de son système Hifi sur le Pi.

Paramétrage du Pi

Dans /etc/modprobe.d/raspi-blacklist.conf, on peut commenter ces lignes pour ne plus 'blacklister' ces modules :

blacklist i2c-bcm2708
blacklist snd-soc-pcm512x
blacklist snd-soc-wm8804

Puis, dans /etc/modules, on commente également cette ligne :

snd_bcm2835

Ensuite, dans /boot/config.txt, on ajoute cette ligne en fin de fichier :

dtoverlay=hifiberry-amp

Enfin, dans /etc/asound.conf, on ajoute ces quelques lignes :

pcm.!default  {
 type hw card 0
}
ctl.!default {
 type hw card 0
}

Et voilà le Pi est alors capable d'émettre du son au travers de son amplificateur. Il ne reste plus qu'à brancher des enceintes pour profiter d'une musique de qualité !

Aller plus loin en transformant le Pi en chaîne Hifi connectée

On peut alors installer sur le Pi tout système de son choix pour une gestion facilitée de l'audio. On pourra par exemple déployer MPD ou Volumio. C'est l'objet d'un prochain article.