Passons maintenant à Laravel-mix. En poussant la configuration de webpack, je commençais à avoir envie de pleurer. Puis Laravel-mix est arrivé. C’est un Webpack prêt à l’usage, qui colle parfaitement à ce que je veux faire. Il se colle sur n’importe quelle application, contrairement à ce que son nom laisse entendre, donc allons-y !

Installation avec Yarn

Il faut donc déjà avoir Yarn d’installé en global. Ensuite, on va installer Webpack, également en global. Une dépendance qui n’est pas encore documentée (mais qui vous évitera de chercher), est cross-env, qu’il faut aussi avoir en global :

sudo npm install -g webpack cross-env

Effectivement, je n’utilise pas Yarn pour installer en global, il y a des soucis dans les liens symboliques, donc npm est plus approprié.

Ensuite on est prêt à accueillir Mix dans l’application :

yarn add laravel-mix && cp -r node_modules/laravel-mix/setup/** ./

Ajouter les commandes npm

Pour s’éviter d’avoir à taper les longues commandes avec webpack, voici ce que vous devez ajouter au fichier packages.json :

"scripts": {
    "webpack": "cross-env NODE_ENV=development webpack --progress --hide-modules",
    "dev": "cross-env NODE_ENV=development webpack --watch --progress --hide-modules",
    "hmr": "cross-env NODE_ENV=development webpack-dev-server --inline --hot",
    "production": "cross-env NODE_ENV=production webpack --progress --hide-modules"
  }

La commande webpack vous permet de compiler vos fichiers une seule fois.
La commande dev va recompiler à chaque changement de fichier
La commande hmr vous permet d’activer le hrm (duh?)
Et la commande production va compiler, minifier, et générer les .map pour la production.

Modifier la configuration apache

On a vu dans un article précédent comment configurer un vhost apache pour Django. Mais si on livrait les assets compilés dans le repertoire /assets de l’application (c’est le comportement par défaut de Django il me semble), je préfère changer et passer ça dans /dist.
/assets contiendra tous les fichiers non compilés, donc voici ce qu’on ajoute :

Alias /static/  /chemin/vers/helpmepyz.dev/helpmepyz/dist/

La fonction mix pour Python/Django

Alors c’est ma toute première fonction python, c’est pas parfait, mais ça fait le job. Il faudra juste remplacer le retour avec un objet request, pour déterminer l’url complète.

Mais globalement, qu’est ce que fait cette fonction :

Ignorons la partie hot reload pour l’instant, mais Laravel Mix génère un fichier mix-manifest.json. Dans ce fichier, il y a les chemins vers les chunks versionnés, ce qui va vous éviter de dire « vous pouvez rafraichir la page syouplai? F5 ».

from os.path import isfile, abspath
from os import getcwd
from json import loads


def mix(path, manifest = False, should_hot_reload = False):
    if not manifest:
        manifest_path = getcwd() + '/mix-manifest.json'
        should_hot_reload = isfile(abspath('/dist/hot'))
        if not isfile(manifest_path):
            raise Exception( 'The Laravel Mix manifest file does not exist. Please run "npm run webpack" and try again.')

        manifest_file = loads(open(manifest_path).read())

    # if (not path.startswith('/')): path = f"/{path}"

    if not path in manifest_file:
        raise Exception('Unknown Laravel Mix file path: f"{path}".'
                        'Please check your requested webpack.mix.js output path, and try again.')

    return 'http://localhost:8080f"{manifest_file[path]}"' if should_hot_reload else manifest_file[path]

Donc on va bientôt être prêt coté front !

Sinon, en lisant Sam et Max, je suis tombé sur cette phrase, qui m’a permis de comprendre la différence entre les 2 termes, et de manière très simple, donc je vous la laisse :

Donc, quand vous faites import os, Python va faire une boucle for là dessus et chercher dans chaque dossier si un package (un dossier avec un fichier __init__.py) ou un module (un fichier avec l’extension .py) nommé os existe.

Eloquent

Quand vous prenez un modèle Laravel, une fois instancié, vous pouvez directement appeler la méthode save() dessus. Etant donné que ce modèle étend Eloquent, c’est Eloquent qui va directement s’occuper de la sauvegarde et de la restauration des données : La persistance.

Doctrine2

Même si ça se passe autrement pour Doctrine, en regardant un modèle, on s’aperçoit qu’il n’étend aucune classe. Donc il ne traitera pas directement avec la base de données, et vous devez donc définir toutes les propriétés du modèle puisqu’il n’est pas directement connecté à la base.
Ce qui rend potentiellement Doctrine plus léger (en mémoire) à l’usage.

Migrations VS Annotations

Là où Laravel va gérer la structure de la base de données, via des fichiers de migration qui sont executé manuellement, Doctrine2 va utiliser un système d’annotation pour que l’Entity Manager puisse structurer la base en fonction de ce qui a été décrit.

Voici l’exemple d’annotation pour Doctrine, directement extrait de la documentation :

<?php
/**
 * @Column(type="string", length=32, unique=true, nullable=false)
 */
protected $username;

/**
 * @Column(type="string", columnDefinition="CHAR(2) NOT NULL")
 */
protected $country;

/**
 * @Column(type="decimal", precision=2, scale=1)
 */
protected $height;

/**
 * @Column(type="string", length=2, options={"fixed":true, "comment":"Initial letters of first and last name"})
 */
protected $initials;

/**
 * @Column(type="integer", name="login_count" nullable=false, options={"unsigned":true, "default":0})
 */
protected $loginCount;

Ca a l’avantage de déresponsabiliser le développeur sur la gestion de la base. Avec Eloquent, et plus particulièrement avec Laravel, si tu ne mets pas les bonnes infos dans la méthode down(), tu peux simplement tout casser.

L’Entity Manager

Vu que votre modèle ne s’occupe pas de la persistance, c’est l’entity manager qui s’en charge. Le résultat c’est qu’il faut écrire beaucoup plus de choses pour le même résultat, mais l’avantage c’est la légèreté.

Voici comment on va créer, et sauvegarder une propriété avec Eloquent :

<?php
$user = new User;
$user->email('foo@bar.com');
$user->save();


EntityManager::persist($user);
EntityManager::flush();

Et voici comment ça se passe pour Doctrine2 :

<?php
$user = new User;
$user->setEmail('foo@bar.com');

EntityManager::persist($user);
EntityManager::flush();

En gros, la différence vient du fait que persist() est utilisé pour générer la transaction vers la base de donnée. Flush() est appelé pour valider la transaction et faire la modification dans la base de données.

Setters && Getters

Là aussi une différence fondamentale, toujours liée au fait que le modèle n’a aucun lien avec la base de données :
Là où Eloquent va aller chercher les propriétés demandées dans la base de données (si le champ existe), Doctrine2 a besoin d’avoir tous les getters et tous les setters pour accéder à un champ.

Donc là aussi, Doctrine2 va être plus verbeux, mais ça a l’avantage d’en savoir tout de suite plus sur son modèle aussi. Et n’oublions pas encore, la légèreté.

Les requêtes

Bel avantage pour Eloquent sur ce point selon moi. La grande majorité des requètes avec Eloquent peut se faire avec une véritable syntaxe PHP. C’est à dire que tu n’écris presque plus de SQL.
Forcément, écrire peu de requète SQL a ses avantages, et ses inconvénients, mais ce n’est pas le sujet ici. Au quotidien, je trouve ça pratique quand même.

Requêtes Eloquent

<?php

$users = User::where('email', strtolower($user->email))->whereNotNull('deleted_at')->get();

Requêtes Doctrine2

<?php

$query = EntityManager::createQuery("select u from User u where u.email = LOWER({$email}) and u.deteled_at IS NOT NULL");

$users = $query->getResult();

Lequel choisir

Il n’y a pas de meilleur choix, les 2 ont leurs avantages – oui, et leurs inconvénients aussi. Au début on peut être plus facilement accroché par Eloquent, et Active Record donc. Plus simple, moins verbeux etc. Ca passe pour toutes les applications CRUD, et c’est très bien.

Vu que je préfère éviter les débats Vim/Emacs, Chocolatine/Pain au chocolat, je vous recommande la lecture de ce billet (en) qui vous donnera des pistes pour choisir lequel correspond le mieux à votre application.

C’est l’occasion d’apprendre ou réapprendre à se servir des outils inclus dans toute bonne distribution qui se respecte, mais aussi comment compléter ces outils.

Monitoring « sur site »

Journaux

Ce que j’appelle « monitoring sur site », c’est comment surveiller son système depuis un shell. Un certain nombre de commandes existent pour nous permettre de diagnostiquer le fonctionnement de notre serveur.

Pour commencer, rien ne vaut les journaux. Concernant notre serveur, voici ceux qui sont principalement à surveiller :

• /var/log/syslog, probablement le plus important de tous
• /var/log/fail2ban.log, pour surveiller ce que fail2ban fait
• /var/log/mail.log, pour surveiller le serveur mail
• /var/www/*/*/log/, pour surveiller les accès et erreurs sur l’ensemble de vos sites Internet

Pour consulter en temps réel un journal, utilisez la commande suivante :

tail -f /var/log/syslog

Pour consulter les X dernières lignes d’un journal :

tail -X /var/log/syslog

Processus

Le monitoring sur site implique également la surveillance des processus. La commande suivante :

ps aux

Vous indiquera l’état des processus au moment où vous lancez la commande. Pour consulter l’état des processus en temps réel, utilisez la commande :

top

Cette commande vous informe également de l’état de la mémoire, de l’utilisation CPU, et d’autres choses encore.

Matériel

Si vous hébergez vous-même votre serveur « à la maison », vous pourrez également avoir besoin de quelques capteurs de température :

apt-get install lm-sensors
sensors-detect

De même pour les disques durs :

apt-get install hddtemp
hddtemp /dev/sd*

D’autres informations relatives à votre matériel peuvent être extraites du pseudo système de fichiers /proc :

cat /proc/cpuinfo
cat /proc/meminfo

RAID

Si vous bénéficiez d’un raid logiciel, vous pouvez consulter son état de différentes manières :

cat /proc/mdstat
mdadm --detail /dev/md0

Monitoring distant

Le monitoring distant est effectué depuis une interface web par exemple. J’ai choisi phpSysInfo, que je trouve plus agréable à configurer et utiliser que munin, trop centré sur la création de graphs, et relativement compliqué à mettre en œuvre.

Hôte virtuel

Première chose, comme d’habitude, on s’occupe de l’hôte virtuel dans apache :

mkdir -p /var/www/exemple.fr/system/www
nano /etc/apache2/sites-available/system.exemple.fr

<VirtualHost *:80>
    ServerName system.exemple.fr
    Redirect / https://system.exemple.fr/
</VirtualHost>

<VirtualHost *:443>
    ServerName system.exemple.fr

    DocumentRoot /var/www/exemple.fr/system/www

    SSLEngine On
    SSLCertificateFile /scripts/certificate_authority/apache/system.exemple.fr.crt
    SSLCertificateKeyFile /scripts/certificate_authority/apache/system.exemple.fr.key
</VirtualHost>

Nous avons créé un hôte virtuel non sécurisé redirigeant vers un hôte virtuel sécurisé, nous avons déjà vu le principe. Créons maintenant les certificats :

/scripts/certificate_authority/make_request apache system.exemple.fr
/scripts/certificate_authority/sign_request apache system.exemple.fr
chown www-data:www-data /scripts/certificate_authority/apache/*

On active le site, et on redémarre apache :

a2ensite system.exemple.fr
/etc/init.d/apache2 restart

Dans ce cas, il n’y a pas vraiment besoin de tenir des journaux.

Installation de phpSysInfo

Rien de particulier à signaler : une fois l’application téléchargée et installée dans son répertoire (/var/www/exemple.fr/system/www), il suffit juste de la configurer en fonction des blocs que vous souhaitez afficher.

Certaines dépendances peuvent être nécessaires, en fonction des blocs que vous aurez configuré. L’application vous informera via des messages d’erreurs si des dépendances ne sont pas satisfaites. Vous pourrez alors aisément les installer.

Notifications

Si vous faites appel à crontab pour effectuer des tâches routinières, il peut être intéressant d’avoir des rapports par mail. Il vous suffit d’éditer votre crontab et d’y insérer la ligne suivante :

MAIL="contact@exemple.fr"

Nous avons installé un serveur XMPP, on peut également s’en servir comme service de notification. Ainsi, pour toute application qui permet d’exécuter une commande suivant un évènement donné, on peut demander à cette application d’envoyer un message à un compte XMPP que vous aurez créé à cet effet. Nous utiliserons pour cela le script sendxmpp :

apt-get install sendxmpp

Que l’on utilisera de la manière suivante :

echo "Votre message" | sendxmpp -u <utilisateur> -p <mot de passe> -j exemple.fr <destinataire>@exemple.fr

Liste des paquets installés

Il peut être utile de récupérer la liste de tous les paquets installés, par exemple dans le cas d’une réinstallation ou d’un mirroring. Pour récupérer cette liste, on utilisera la commande suivante :

dpkg -l | grep ii | awk -F ' ' '{print $2}'

On peut, du coup, exporter cette liste dans un fichier :

dpkg -l | grep ii | awk -F ' ' '{print $2}' > packages.list

Conclusion

Plein d’autres choses manquent surement à l’appel. On ne peut pas tout voir, mais théoriquement, ce qu’on a vu jusqu’aujourd’hui devrait être suffisant pour que vous puissiez jouer avec votre propre instance.

Et bien parce qu’il faut recharger apache à chaque modification de fichier. En discutant sur IRC #django-fr c’est ce que j’avais pensé lire, et ça s’est confirmé quand j’ai réussit à faire fonctionner le bouzin. Mais de toute façon notre application va partir en production, donc autant savoir quoi faire.

Apache

Au risque de dire quelques bêtises, l’équivalent de fast-cgi quand on veut pythonner, c’est wsgi. Pour ceux qui veulent en savoir plus, je vous recommande l’article de Sam et Max qui traite du sujet. Il faut donc installer le module apache correspondant à votre distribution GNU/Linux. Ensuite, il faut activer le module en modifiant le httpd.conf et en ajoutant :

LoadModule wsgi_module modules/mod_wsgi.so
#ça peut changer en fonction de votre distribution aussi. Ici on est sur archlinux, donc Apache est brut.

Vu le temps que ça m’a pris d’avoir le bon template pour avoir un vhost qui fonctionne, dans le virtualenv, avec les bons chemins, ce n’est pas une mauvaise idée de t’en faire cadeau :

La homepage : première app du projet

On rembobine

Dans le billet précédent, je pensais que pour utiliser django-dotenv, il fallait importer la fonction parse_dotenv pour l’utiliser en précisant la clé désirée, et bien padutou. En fait, cette lib ajoute les variables d’environnement, pour qu’elles soient disponibles via votre système. Donc quand on a configuré le package, il faut simplement utiliser ce que Python propose pour les lire :

os.getenv('DBCONNECTION')

La homepage

Il faut donc créer une app pour la home. Donc :

python manage.py startapp home

Et on va aller modifier le fichier url comme ceci pour faire pointer / vers la méthode index de la vue home :

from django.conf.urls import url
from django.contrib import admin
from home import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^$', views.index)
]

Ensuite on va créer un layout de base à étendre, et insérer le hello world dans le template qui va afficher la page d’accueil. En tout cas, je commence à bien saisir la structure, et ce système de template, même si à première vue est redondant, est en fait une très bonne solution pour la surcharge, et avec ce que j’ai en tête, ça peut être très utile.

La prochaine fois, on verra comment préparer la stack front-end, avec webpack et npm. En attendant, si vous voulez le détail, c’est par ici .

Je vous présente aujourd’hui deux techniques pour bloquer l’accès à certains sites. On va même s’amuser à bloquer google.fr parce qu’on est des crypto cyberpunks anarcho-communisme complètement dingues.

Première technique : le proxy

Un serveur proxy est un serveur (matériel ou logiciel) s’intercalant entre deux machines. En l’occurrence, nous allons installer l’un des plus célèbres, Squid, sur une Debian. L’installation est on ne peut plus simple :

apt-get install squid

On édite le fichier de configuration :

nano /etc/squid/squid.conf

Vous devriez avoir trois lignes relatives à la déclaration du réseau local :

acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network

Décommentez celle(s) qui s’applique(nt) à votre configuration. En dessous, on rajoute les domaines à bloquer :

acl blocked_domains dst google.fr
acl blocked_domains dst adsense.com
[...]

Puis, plus loin, juste avant la ligne :

http_access deny all

Rajoutez :

http_access allow localnet
http_access deny blocked_domains

Il suffit maintenant de configurer votre navigateur pour qu’il utilise le proxy ainsi installé (par défaut, sur le port 3128).

Pour aller plus loin, on pourrait en faire un proxy transparent : si la machine sur laquelle vous avez installé Squid est aussi la machine qui partage votre connexion Internet, mettre en place une règle iptables pour intercepter tout paquet qui cherche à atteindre le port 80 en sortie, et le rediriger vers l’hôte local, port 3128 :

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

On pourrait également déplacer la liste des domaines à bloquer dans un fichier distinct. Pour ce faire, au lieu des directives « acl blocked_domains […]« , on créé celle-ci :

acl blocked_domains dst "/etc/squid/blocked_domains"

Puis on créé le fichier spécifié, et on le remplit avec les domaines souhaités (un par ligne).

Une fois les modifications effectuées, n’oubliez pas de relancer Squid :

/etc/init.d/squid restart

Deuxième technique : invalidation DNS

La deuxième technique fait appel à un serveur DNS présent sur votre réseau. Pour l’occasion, j’explique la technique avec bind, mais le principe est valable quel que soit votre serveur DNS. Commencez par éditer le fichier de configuration principal de bind :

nano /etc/bind/named.conf

Rajoutez-y la ligne suivante :

include "/etc/bind/named.conf.blocked";

Créez le fichier named.conf.blocked, et mettez-y les informations suivantes :

zone "google.fr" { type master; file "dummy-block"; };

Cette ligne bloque tout trafic vers google.fr. Si ce n’est pas ce que vous voulez, pensez à changer cette ligne pour mettre le domaine à bloquer. Cette technique a ceci de contraignant que le fichier named.conf.blocked doit contenir une ligne de ce type par domaine à bloquer, ce qui peut être pénible à maintenir, d’autant qu’il faut relancer bind après chaque modification. Nous verrons plus loin comment se faciliter un peu la vie. En attendant, il faut encore créer le fichier /etc/bind/dummy-block :

$TTL 24h

@ IN SOA yourdomain.com. hostmaster.yourdomain.com. (
2003052800 86400 300 604800 3600 )

@ IN NS yourdomain.com.
@ IN A 127.0.0.1
* IN A 127.0.0.1

Pensez juste à changer yourdomain.com et le faire pointer sur votre propre machine par exemple, puis redémarrez bind :

/etc/init.d/bind9 restart

Cette technique, encore une fois, est contraignante si vous souhaitez bloquer un nombre conséquent de sites. Pour une dizaine de domaines, c’est gérable, mais quand on cherche à en bloquer une centaine (par exemple, tous les serveurs de publicités) c’est une autre paire de manche. Je vais donc vous livrer un petit script qui va bosser pour vous.

En ce qui concerne la configuration de bind, si vous avez créé le fichier named.conf.blocked, supprimez-le. Créez un fichier blocked_domains, et comme pour Squid, remplissez-le avec les domaines à bloquer, un par ligne. Créez ensuite un fichier nommé par exemple build_conf, et rendez-le exécutable avant de l’éditer :

touch build_conf && chmod +x build_conf && nano build_conf

Mettez-y le code suivant :

#!/bin/bash

# Script permettant de générer un fichier de configuration bind
# visant à bloquer les domaines contenus dans un fichier à part
# Auteur : Metrogeek `francois@metrogeek.fr`
# Licence : GNU/GPL dans sa dernière version

# Configuration générale

# Fichier contenant la liste des domaines
domains_file="blocked_domains"

# Fichier à générer
blocked_conf="named.conf.blocked"

# Fichier de définition du domaine
dummy_block="dummy-block"

# Maintenant on peut bosser

# On formate un peu la liste des domaines

echo "Suppression des lignes vides et espaces superflus..."
sed '/^$/d' ` "${domains_file}" ` "${domains_file}_temp"
sed '/./!d' ` "${domains_file}_temp" ` "${domains_file}_temp2"
sed 's/^[ \t]*//' ` "${domains_file}_temp2" ` "${domains_file}"

rm "${domains_file}_temp" "${domains_file}_temp2"

echo "Suppression des doublons..."
sort -u "${domains_file}" ` "${domains_file}_temp"
mv "${domains_file}_temp" "${domains_file}"

echo "Génération du fichier de configuration..."
rm "${blocked_conf}"
touch "${blocked_conf}"

while read line
do
echo "zone \"${line}\" { type master; file \"${dummy_block}\"; };" `` "${blocked_conf}"
done ` "${domains_file}"

echo "Terminé, redémarrage de bind"
/etc/init.d/bind9 restart

Chaque fois que vous ajouterez un ou plusieurs domaines au fichier blocked_domains, il suffira de lancer ce script.  Cela sortirait du cadre de cet article, mais on pourrait aussi faire appel à inotify par exemple, pour relancer automatiquement ce script dès que le fichier blocked_domains est modifié.

Ca fait maintenant quelques mois que je mets régulièrement le nez dans Python (plus dans Django, il faut bien le dire). J’ai bien les notions de base, mais il y a un point qui reste un peu abstrait, c’est la gestion des app.

La semaine dernière, j’ai tenté d’approfondir cet aspect, mais rien de bien concluant. Donc concrètement, au lieu d’attendre, je vais commencer à coder, on verra ce que ça donne, et au pire, je casserai ce qui n’est pas fait correctement, pour le refaire correctement quand j’aurais compris !

Il est temps d’y aller, donc go.

Construire le projet

mkdir helpmepyz && cd helpmepiz

virtualenv env

source env/bin/activate

pip install django

django-admin.py startproject helpmepyz

Ensuite, on va créer le gitignore :

env
*.DS_Store
*.pyc
__pycache__

Et ensuite il faut initialiser git :

git init && git add . && git commit -m "$(curl -s http://whatthecommit.com/index.txt )"

git remote add origin git@github.com:rikless/helpmepyz.git

On va partir sur une base de donnée Mysql. Je n’ai pas encore testé le nouveau support de JSON ça sera l’occasion :

pip install MySQL-python

En fait non, ce paquet ne supporte pas python 3.5, donc :

pip install mysqlclient

On va tout de suite installer un outil qui va permettre de gérer les variables d’environnement. django-env a l’air de faire le boulot.

pip install django-dotenv

Vu qu’on a déjà 2 dépendances, on va tout de suite utiliser cette commande :

pip freeze > requirements.txt

Ca permet de générer la liste de vos dépendances, un peu comme le composer.json pour ceux qui ont l’habitude de PHP.

On va pouvoir créer les premières apps, et tester la connexion à la base.

La liste des modifs pour cette dernière partie ici

Initialiser le projet

A grands coupe de

composer create-project --prefer-dist laravel/laravel secure-me

On se déplace dans le dossier du projet, et on va demander à composer d’installer 2 dépendances : Une lib qui gère la double authentification avec Laravel, et une autre qui va servir à encoder en Base32.

composer require pragmarx/google2fa
composer require paragonie/constant_time_encoding

google2fa nécessite d’enregistrer le service provider, et on va ajouter la facade pour plus de facilité.
Donc on ouvre config/app.php et on ajoute ces lignes dans les bonnes sections :

//côté service provider
PragmaRX\Google2FA\Vendor\Laravel\ServiceProvider::class
//côté Facade
'Google2FA' => PragmaRX\Google2FA\Vendor\Laravel\Facade::class

Et enfin, on va utiliser cet outil démentiel de Laravel, qui vous permet de scafolder une auth en moins d’une seconde (accrochez-vous, ça va trembler) :

php artisan make:auth

Structurer la base de donnée

On va aller modifier la méthode up() du fichier de migration de la table users, avant de la lancer, comme ceci :

Schema::create('users', function (Blueprint $table) {
    $table->increments('id');
    $table->string('name');
    $table->string('email')->unique();
    $table->string('password');
    $table->rememberToken();
    $table->string('google2fa_secret')->nullable();
    $table->timestamps();
});

Maintenant, il faut modifier le modèle App\User pour ajouter ce champ google2fa_secret à la propriété fillable, pour pouvoir modifier le champ, et en hidden, pour que sa valeur ne soit jamais affichée quand vous retournez l’objet complet, qui sera casté en JSON (on ne sait jamais).

Les controllers

Et hop, dans la console :

php artisan make:controller GoogleAuthController

Et on va tout de suite aller y coller ce code :

<?php

namespace App\Http\Controllers;

use App\Http\Requests\ActivateSecretValidation;
use Illuminate\Http\Request;
use Base32\Base32;

/**
 * Class GoogleAuthController
 * @package App\Http\Controllers
 */
class GoogleAuthController extends Controller
{

    protected $redirectTo = '/';


    /**
     * @param Request $request
     * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
     */
    public function enableTwoFactor(Request $request)
    {
        //Generate a secret key in Base32 format
        $secret = strtoupper(Base32::encode(random_bytes(10)));
        $user = auth()->user();

        session(['google2fa_secret' => \Crypt::encrypt($secret), '2fa:user:id' => auth()->user()->id]);

        //generate image for QR barcode
        $QRCode = \Google2FA::getQRCodeGoogleUrl(
            config('app.name'),
            $user->email,
            $secret,
            200
        );

        return view('2fa/enable', ['image' => $QRCode,
            'secret' => $secret]);
    }


    /**
     * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
     */
    public function disableTwoFactor()
    {
        $user = auth()->user();

        $user->google2fa_secret = null;
        $user->save();

        return view('2fa/disable');
    }

    /**
     * @param ActivateSecretValidation $request
     * @return \Illuminate\Http\RedirectResponse
     */
    public function activateTwoFactor(ActivateSecretValidation $request)
    {

        auth()->user()->google2fa_secret = session('google2fa_secret');
        auth()->user()->save();
        session()->forget(['google2fa_secret', '2fa:user:id']);

        return redirect()->intended($this->redirectTo)->with(['success' => 'Your account is secured !']);
    }

}

3 méthodes : une pour la demande d’activation, qui va générer le QRcode et demander le code de confirmation, une autre pour la demande de désactivation, et enfin une dernière qui va servir à envoyer les données de confirmation, pour valider l’activation de la double authentification. Avec cette 3e méthode, on n’activera la double authentification QUE si l’user a bien confirmé le code.

On va pouvoir maintenant utiliser la méthode authenticated() qui est un petit hook qu’on va surcharger, puisque la méthode de base est simplement vide. Donc on ouvre LoginContoller et on ajoute cette méthode, qui va surcharger celle du Trait :

protected function authenticated(Request $request, Authenticatable $user)
{
    if (!is_null($user->google2fa_secret)) {
        \Auth::logout();

        $request->session()->put('2fa:user:id', $user->id);

        return redirect('2fa/validate');
    }

    return redirect()->intended($this->redirectTo);
}

Donc si l’user a activé la double authentification, il faut déconnecter l’utilisateur, et lui ajouter son user id en session. Quand c’est fait, on peut le diriger vers une page dans laquelle il doit saisir les codes de validation.

Si c’est désactivé, on ne le déconnecte pas et on l’emmène là où il voulait aller.

Maintenant, on ajoute la méthode validate2fa() dans LoginController, pour s’assurer que la valeur existe en session, et renvoyer l’user sur la page login si ce n’est pas le cas :

public function validate2fa()
{
    if (session('2fa:user:id')) {
        return view('2fa/validate');
    }

    return redirect('login');
}

Puis une méthode qui va servir à récupérer les données postées pour valider la double authentification :

public function postValidate2fa(SecretRequestValidation $request)
{
    $userId = $request->session()->pull('2fa:user:id');

    //login and redirect user
    \Auth::loginUsingId($userId);

    return redirect()->intended($this->redirectTo);
}

Et on va donc créer l’objet request correpondant :

php artisan make:request SecretRequestValidation

Et on va coller ceci dedans :

<?php

namespace App\Http\Requests;

use App\User;
use Illuminate\Foundation\Http\FormRequest;

/**
 * Class SecretRequestValidation
 * @package App\Http\Requests
 */
class SecretRequestValidation extends FormRequest
{

    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
        try {
            User::findOrFail(
                session('2fa:user:id')
            );
        } catch (\Exception $e) {
            return false;
        }

        return true;
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'totp' => 'bail|required|digits:6|token_is_ok',
        ];
    }
}

Oui on va créer une (2 en fait) règle de validation supplémentaire, en créant une nouvelle classe dans app/Http/Requests :

<?php

namespace App\Http\Requests;

use App\User;
use Illuminate\Validation\Validator;

/**
 * Class CustomValidator
 * @package App\Http\Requests
 */
class CustomValidator extends Validator
{
    /**
     * @param $attribute
     * @param $value
     * @param $parameters
     * @return bool
     */
    public function validateTokenIsOk($attribute, $value, $parameters)
    {
        try {
            $user = User::findOrFail(session('2fa:user:id'));

        } catch (\Exception $exc) {
            return false;
        }

        $secret = \Crypt::decrypt($user->google2fa_secret);

        return \Google2FA::verifyKey($secret, $value);
    }

    /**
     * @param $attribute
     * @param $value
     * @param $parameters
     * @return mixed
     */
    public function validateTokenIsValid($attribute, $value, $parameters)
    {
        $secret = \Crypt::decrypt(session('google2fa_secret'));

        return \Google2FA::verifyKey($secret, $value);
    }
}

Il faut aussi modifier AppServiceProvider pour ajouter ces règles au boot. Donc on ajoute ceci à la méthode boot() :

public function boot()
{
    $this->app['validator']->resolver(function($translator, $data, $rules, $messages) {
        return new CustomValidator($translator, $data, $rules, $messages);
    });
}

Pensez à ajouter le use.

On peut maintenant valider la dernière requête (qu’on va d’abord créer) :

php artisan make:request ActivateSecretValidation

Et voici son contenu :

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

/**
 * Class ActivateSecretValidation
 * @package App\Http\Requests
 */
class ActivateSecretValidation extends FormRequest
{

    /**
     * Determine if the user is authorized to make this request.
     *
     * @return bool
     */
    public function authorize()
    {
       return \Auth::check();
    }

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'totp' => 'bail|required|digits:6|token_is_valid',
        ];
    }
}

Les routes

Les controllers sont prêts. Maintenant, il faut que les routes soient disponibles. Pour rappel, il faut une route pour activer la double authentification, une pour la désactiver. Une autre pour afficher un formulaire dans lequel l’user va pouvoir taper le code disponible dans l’application Google Autenticator, et enfin, la dernière url sur laquelle il va envoyer ce formulaire.

Route::get('/2fa/enable', 'GoogleAuthController@enableTwoFactor');
Route::get('/2fa/disable', 'GoogleAuthController@disableTwoFactor');
Route::post('/2fa/activate', 'GoogleAuthController@activateTwoFactor');

Route::get('/2fa/validate', 'Auth\LoginController@validate2fa');
Route::post('/2fa/validate', ['middleware' => 'throttle:5', 'uses' => 'Auth\LoginController@postValidate2fa']);

Les vues

3 vues sont à prévoir :

• 1 pour l’activation
• 1 pour la désactivation
• 1 pour la validation après le login

On ne traîne pas, voici les 3 fichiers blade qui se passent d’explication.

disable.blade.php :

@extends('layouts.app')

@section('content')
    <div class="container">
        <div class="row">
            <div class="col-md-10 col-md-offset-1">
               <p>
                   Double authentification désactivée. Mauvaise idée.
               </p>
            </div>
        </div>
    </div>
@endsection

enable.blade.php

@extends('layouts.app')

@section('content')
    <div class="container">
        <div class="row">
            <div class="col-md-10 col-md-offset-1">
                <div class="panel panel-default">
                    <div class="panel-heading">Secret Key</div>

                    <div class="panel-body">
                        Ouvrez Google Authenticator et scannez le QR code suivant :
                        <br />
                        <img alt="Image of QR barcode" src="{{ $image }}" />

                        <br />
                        Si vous avez un souci avec le QR code, vous pouvez taper ce code: <code>{{ $secret }}</code>
                        <br /><br />
                    </div>

                    <form class="form-horizontal" role="form" method="POST" action="/2fa/activate">
                        {!! csrf_field() !!}

                        <div class="form-group{{ $errors->has('totp') ? ' has-error' : '' }}">
                            <label class="col-md-4 control-label">Clé de sécurité</label>

                            <div class="col-md-6">
                                <input type="number" class="form-control" name="totp">

                                @if ($errors->has('totp'))
                                    <span class="help-block">
                                            <strong>{{ $errors->first('totp') }}</strong>
                                        </span>
                                @endif
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                <button type="submit" class="btn btn-primary">
                                    <i class="fa fa-btn fa-mobile"></i>Valider
                                </button>
                            </div>
                        </div>
                    </form>

                </div>
            </div>
        </div>
    </div>
@endsection

et validate.blade.php

@extends('layouts.app')

@section('content')
    <div class="container">
        <div class="row">
            <div class="col-md-8 col-md-offset-2">
                <div class="panel panel-default">
                    <div class="panel-heading">Double Authentification</div>

                    <div class="panel-body">
                        <form class="form-horizontal" role="form" method="POST" action="/2fa/validate">
                            {!! csrf_field() !!}

                            <div class="form-group{{ $errors->has('totp') ? ' has-error' : '' }}">
                                <label class="col-md-4 control-label">Clé de sécurité</label>

                                <div class="col-md-6">
                                    <input type="number" class="form-control" name="totp">

                                    @if ($errors->has('totp'))
                                        <span class="help-block">
                                            <strong>{{ $errors->first('totp') }}</strong>
                                        </span>
                                    @endif
                                </div>
                            </div>

                            <div class="form-group">
                                <div class="col-md-6 col-md-offset-4">
                                    <button type="submit" class="btn btn-primary">
                                        <i class="fa fa-btn fa-mobile"></i>Valider
                                    </button>
                                </div>
                            </div>
                        </form>
                    </div>
                </div>
            </div>
        </div>
    </div>
@endsection

Et voilà, c’est prêt !
Les sources de ce tuto sont dispo sur Github.

Crédits photo : Raphael Schaller raphaelphoto.ch

Voici donc.

Si vous vous êtes déjà retrouvé à écrire un billet de blog qui explique pourquoi PHP c’est naze, alors vous n’êtes pas prêt.

Devenir Directeur Technique (CTO) ne ne veut pas dire que vous êtes le meilleur hacker de l’équipe. Aujourd’hui, écrire du code est probablement la dernière chose que vous seriez en train de faire. Vous êtes plutôt une personne qui est capable de communiquer la technologie aux autres, les guide dans l’exécution du projet. C’est en quelque sorte quelqu’un qui protège les autres des interférences extérieures, et quand c’est nécessaire, prend la responsabilité des erreurs.

C’est facile de devenir Directeur Technique accidentellement, en étant recruté par une petite société qui n’a aucun autre développeur, comme vous pouvez le voir dans beaucoup de startup. Mais bien que le titre dise Directeur Technique, c’est probablement un acronyme un peu chic pour dire : Développeur Surchargé de Travail.

Je déteste les environnements dans lesquels l’équipe technique ne fait qu’implémenter ce qui a été envisagé par les autres. Ca pourrait aussi bien être une équipe en outsourcing puisqu’ils sont complètement séparés du processus de décision. Comme l’écrit Camille Fournier dans ‘On the role of CTO’, “Le directeur technique doit protéger l’équipe IT de devenir un outil d’execution des idées, sans tendre à ses propres besoins et ses propres idées”.

Si une société a besoin d’un directeur technique, alors cette personne définie la vision de l’impact à long terme sur la technologie. De plus en plus d’entreprises aujourd’hui n’utilisent pas la technologie, mais sont définit par elle. Tout est construit avec la technologie, du commerce de détails, à l’application mobile, et tous y tirent un grand bénéfice quand quelqu’un ce qu’il faut pour que la technologie fasse encore mieux. C’est le combat qu’un Directeur Technique ne peut ignorer. L’équipe technique doit pouvoir se positionner en maître d’oeuvre.

Je suis déjà allé dans quelques réunions avec d’autre Directeurs Techniques, et la majorité des discussions portent sur les manières de faire en sorte le reste de l’entreprise respecte les processus de développement. Par exemple, vendre et faire accepter le test unitaire. Non, non non ! Pour ma part, je ne vais pas essayer de vous vendre quoique ce soit. Je vais dire : Voici la direction dans laquelle nous allons, et voilà comment on va faire. En bref, le quand le CTO donne une direction, ça doit se passer comme ça. Si un directeur technique n’a pas ce petit pouvoir pour les décisions techniques, alors il n’est pas CTO, mais plus ingénieur en chef dans un costume.  Le costume étant optionnel.

Le CTO est un emploi stratégique dans l’entreprise , qui définit l’orientation technique à l’intérieure de l’entreprise. Ce n’est pas le bon job si vous détestez les meetings, si vous détestez traiter avec ceux qui ne sont pas techniques, et pensez que les manager sont assis toute la journée, et ne font rien. Chaque meeting est une discussion sur l’orientation que l’entreprise va prendre, et comment la technologie peut aider, ou parfois, comment la technologie peut créer de nouvelles opportunités pour grossir.  Tout ceci doit être expliqué simplement, pour être compréhensible par tout le monde.

Donc, il est essentiel de comprendre les besoins de l’entreprise et des clients. D’après mon expérience, beaucoup de gens techniques aiment se mettre à l’écart de tout ce qui touche au business. Pourtant, c’est la première chose à savoir en tant que CTO. Aucune décision technique ne devrait se prendre dans une préoccupation  purement logicielle ou matérielles. La plupart du temps, le CTO devrait être en phase avec les gestionnaires de produits de sorte que la stratégie du produit soit compatible avec les opérations de développement.

En fin de compte, le CTO créé un environnement qui permet à l’équipe de réaliser de grandes choses. Aujourd’hui, une grande partie du problème est l’embauche. Tout le monde est à la recherche de développeurs, mais ils sont peu nombreux, donc l’environnement doit être aussi accueillant que possible. C’est quelque chose que le CTO devrait savoir faire, car il a été une fois l’un d’eux. Si l’équipe veut faire du TDD, ou coder en binôme, ou s’occuper des serveurs – ça doit être accepter par le CTO. C’est aux CTO de considérer le plus grand impact de ces changements.

Réfléchir sur l’impact financier des opérations technologiques est important. Une startup peut se permettre de se jeter sur toutes les dernières technos, mais une plus grande entreprise ne peut pas se le permettre. Tout doit être pesé sur une base de retour sur investissement, en demandant combien de valeur il faut livrer au client. Donc, dans la plupart des cas, il faut équilibrer l’évolution et les mises à jour des infrastructures existantes, tout en ne tombant pas dans une réécriture trop lourde du code. Trouver ce qui donne 80% de rendement avec seulement 20% du d’investissement, selon la règle des 80-20, y contribue en grande partie.

J’ai fait des entretiens avec des futurs CTO qui disaient, «Pourquoi êtes-vous coincé avec cette vielle version, pourquoi ne pas passez à React.js? » Désolé de vous faire redescendre, mais ce n’est pas une bonne idée. Parfois, des applications deviennent coûteuses à gérer, mais les réécrire offrent presque toujours une valeur nulle au client. Il faut équilibrer les efforts de développement. Construire une équipe de personnes qui veulent seulement utiliser les technologies qui viennent de sortir n’est pas durable.

Il construit un écosystème  pour mettre en œuvre les choses que vous trouvez les plus importantes. Par exemple, je pense que la fiabilité et la sécurité sont les deux des caractéristiques les plus importantes de toute application. Ainsi, tout changement dans les objectifs de l’entreprise sont pesés en tenant compte de ces 2 aspects. La confidentialité aussi importante, mais c’est un sujet qui est encore difficile à appréhender pour les personnes non-techniques. Pourtant, elle limite parfois ce qu’une entreprise peut faire, tout simplement parce que les choses pourraient tomber en dehors du respect de la vie privée. Une partie de mon travail consiste à appréhender ces aspects et à s’assurer que l’équipe l’execute correctement.

Alors que je ne fais que la technologie. Je pense que la technologie devrait être invisible pour l’utilisateur. Alors, quand on débat sur le fait que oui ou non PHP est naze, je pense que c’est une question qui n’est pas pertinente. C’est une question stimulante pour certains, mais pour une entreprise, ça ne devrait pas compter. J’aime à croire que c’est une rampe de lancement pour devenir CTO – ne pas se soucier de ce genre de choses, ne pas se focaliser sur les détails techniques, mais plutôt sur la recherche de l’équipe, etc.

Devenir un CTO c’est avoir une vision d’ensemble de l’impact technologique, qui définit l’entreprise et la façon dont d’aider le client. Ca aide à être génial, et à comprendre la technologie, mais c’est beaucoup plus que ça.

La surcharge

Par défaut, il suffit de modifier le fichier admin.py de votre app, et d’ajouter par exemple admin.site.register(Question). Pour ça, on va supprimer cette ligne, et créer une classe, dans laquelle on va définir nos personnalisations. Puis, il faut enregistrer le modèle pour l’admin – comme la ligne qu’on vient de supprimer – mais en ajoutant un paramètre :

class QuestionAdmin(admin.ModelAdmin):
 fields = ['pub_date', 'question_text']

admin.site.register(Question, QuestionAdmin)

De cette manière, on a juste changé l’ordre des champs, rien de bien foufou, mais c’est pour l’exemple.

On peut aussi créer des groupements de champs, en jouant comme ça :

class QuestionAdmin(admin.ModelAdmin):
 fieldsets = [
 (None, {'fields': ['question_text']}),
 ('Date information', {'fields': ['pub_date']}),
 ]

Si vous avez un formulaire avec une bonne dizaine de champs, ça peut vous aider par exemple à sectionner les choses, par exemple en groupant les dates dans leur propre groupe, etc.

On a travaillé depuis quelques billets avec le couple Question/Choix, donc vous avez probablement déjà enregistré ce modèle dans l’admin. Mais comment rendre ces relations disponibles et lisibles depuis vos formulaires ? C’est ce qu’on va voir maintenant.

Jouer avec les relations

Alors Django est suffisamment intelligent pour deviner que quand il y a une relation, il doit la proposer dans le formulaire, sous forme d’un select. Il y a même un lien qui permet d’ajouter une entité question par exemple, directement depuis ce formulaire.

Mais c’est vrai que ce n’est pas très efficace. En fait, il serait plus simple, quand on veut créer une question, de directement pouvoir ajouter les choix non ?

Et bien ouvrez admin.py :

class ChoiceInline(admin.StackedInline):
model = Choice
extra = 3
class QuestionAdmin(admin.ModelAdmin):
fieldsets = [
(None, {'fields': ['question_text']}),
('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}),
]
inlines = [ChoiceInline]

admin.site.register(Question, QuestionAdmin)

Et du coup, le formulaire d’ajout de question devient :

C’est un aperçu rapide des modifications que vous pouvez faire, mais ça laisse une qualité de possibilités assez grande. Dans le prochain billet, on va voir comment changer l’apparence de l’admin, un truc essentiel non ?

Nous utiliserons le serveur bind. Nous allons tout d’abord l’installer sur le serveur principal en tant que maître. Si vous disposez d’un second serveur, vous pourrez le configurer en tant qu’esclave pour assurer la continuité du service.

Pour la suite de notre article (et pour tous les articles à venir), nous considérerons que vous êtes l’heureux possesseur du domaine exemple.fr, et que vous disposez de deux serveurs ayant les adresses IP 1.1.1.1 et 2.2.2.2. Si vous n’avez qu’un seul serveur à disposition, vous n’aurez besoin de faire que de petits ajustements qui n’empêcheront pas le système de fonctionner correctement. Vous pouvez également installer temporairement bind sur votre propre machine pour passer les tests de validation.

Pare-feu

Dans cet exemple, on va modifier le script pour iptables. Je suis plus un adepte de Shorewall, mais vu que personne ne l’utilise, ça n’aurait pas d’intérêt.

IPT=/sbin/iptables
${IPT} -A SERVICES -p tcp --dport 53 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT

Nous ouvrons donc le port 53 en TCP et en UDP. Normalement, seul le protocole UDP est utilisé pour les requêtes, mais le protocole TCP est utilisé également pour les transferts de zones dont nous aurons besoin plus tard. Il est donc important d’ouvrir les connexions aux deux types de protocoles, à moins que vous ne configuriez pas un serveur esclave. Nous pourrions également spécifier directement l’adresse du serveur esclave afin d’éviter toute demande de transfert directement depuis iptables :

${IPT} -A SERVICES -p tcp --dport 53 -s 2.2.2.2 -j ACCEPT
${IPT} -A SERVICES -p udp --dport 53 -j ACCEPT

Serveur maître

Pour installer bind, rien de plus simple : apt-get install bind9 dnsutils
Le paquet dnsutils contient notamment les outils nslookup et dig, qui nous serviront par la suite à tester notre installation.
Rendez-vous dans le répertoire de configuration de bind :

cd /etc/bind
/etc/init.d/bind9 stop

Réflexe à acquérir : toujours stopper un processus en cours d’exécution avant d’en modifier la configuration. Cela évite quelques surprises du genre configuration qui revient à son état précédent une fois le service relancé.

On créé le fichier le définition de notre domaine :

nano db.exemple.fr
$TTL 86400
@ IN SOA ns.exemple.fr. postmaster.exemple.fr. (
2012020501
2D ; Refresh
15M ; Retry
3W ; Expire
86400 ) ; Negative Cache TTL

IN NS ns.exemple.fr.
IN NS ns2.exemple.fr.

IN A 1.1.1.1

ns IN A 1.1.1.1
ns2 IN A 2.2.2.2

Les domaines se terminent par un « . » !

Quelques explications s’imposent. Dans la ligne relative au SOA, on déclare le serveur DNS autoritaire pour la zone (ns.exemple.fr) et l’adresse email du responsable (postmaster.exemple.fr, le « @ » de l’adresse étant remplacé par un « . »).

Ensuite, on attribue un numéro de série au fichier ; ce numéro ne s’invente pas : il s’agit de la date (au format YYYYMMDD) suivi d’un nombre compris entre 00 et 99. Pour plus de clarté, on va appeler ce nombre la « clé ». Si vous disposez de plusieurs domaines, vous pouvez utiliser le premier chiffre de la clé comme identifiant pour un domaine particulier (par exemple, « j’attribuerai toujours un 1 au domaine exemple.fr, et un 2 au domaine exemple2.fr« ), tandis que le second chiffre de la clé vous servira à indenter les modifications survenues dans ce fichier pour le jour donné.

Par exemple, vous faites 4 modifications sur le fichier db.exemple.fr, et 7 sur le fichier db.exemple2.fr, en date d’aujourd’hui. Vous pouvez attribuer les numéros de série suivants à vos fichiers : 2016101301 et 2016101330. N’oubliez jamais de modifier le numéro de série à chaque modification du fichier !
Si vous ne disposez que d’un seul serveur, vous pouvez omettre les lignes relatives au deuxième serveur DNS (ns2.exemple.fr et son adresse associée 2.2.2.2). Cependant, vous ne passerez pas les tests de validation si votre registrar a recours au Zonemaster (anciennement ZoneCheck) de l’AFNIC, qui exige que vous ayez deux serveurs DNS configurés. Vous devriez installer temporairement un serveur bind sur votre propre machine.

Les valeurs suivantes (refresh, retry, etc.) devraient convenir à la majorité des situations.
Nous définissons ensuite les deux serveurs DNS associés au nom de domaine : ns.exemple.fr. et ns2.exemple.fr.
Ensuite, nous indiquons que le serveur principal a pour adresse IP 1.1.1.1, puis nous associons les adresses 1.1.1.1 et 2.2.2.2 aux deux serveurs de noms. Une fois que vous avez adapté cet exemple à votre propre domaine, vous pouvez enregistrer et fermer.

Théoriquement, dans une installation de base de bind sur une Debian stable, le fichier named.conf contient la ligne suivante :

include "/etc/bind/named.conf.local";
#Si ce n’est pas le cas, rajoutez-là :
echo "include \"/etc/bind/named.conf.local\";" >> named.conf
#Et modifiez le fichier named.conf.local :
nano named.conf.local

Ce fichier va contenir les directives de configuration pour un domaine particulier, en l’occurrence, exemple.fr (et/ou exemple2.fr). C’est une bonne pratique de configuration à laquelle passe la majorité des applications, cela permet de clarifier les choses, et de s’y retrouver facilement.

Mettez donc le contenu suivant dans ce fichier :

zone "exemple.fr" {
type master;
file "/etc/bind/db.exemple.fr";
};

On défini notre instance de bind comme étant maître pour ce domaine, et on lui indique le fichier de configuration correspondant. Enregistrez et fermez ce fichier une fois modifié. Redémarrez ensuite bind, pour procéder à quelques tests :

/etc/init.d/bind9 restart
nslookup exemple.fr
Vous devriez obtenir la sortie suivante :
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1

Vous noterez qu’à cause de la propagation des DNS, votre domaine n’est peut être pas encore disponible depuis l’extérieur. N’hésitez pas à tester (en utilisant la même commande) régulièrement depuis une machine qui n’héberge pas le serveur bind.

Si la commande précédente vous retourne une sortie similaire, c’est que votre domaine est correctement configuré (du point de vue de bind en tout cas). En l’état actuel des choses, bind devrait donc être en mesure de répondre à des requêtes portant sur votre domaine, bien qu’encore aucun domaine « utile » ne soit créé.

Serveur esclave

Pour faire fonctionner deux instances de bind sur le modèle de maître/esclave, on commence par compléter un peu la configuration du serveur maître. On reste donc sur la même machine, pour créer une clé de transfert :

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST .exemple.fr.

dnssec-keygen est un outil livré avec bind. Grâce à la commande suivante, on génère une clé en utilisant l’algorithme HMAC-MD5, d’une longueur de 512 bits, pour un hôte particulier (-n HOST), en l’occurrence, celui indiqué à la fin. Remplacez par le nom d’hôte du serveur. Par exemple, j’ai appelé mon serveur « foo », sur le domaine exemplebis.fr. La commande qui s’applique à mon cas devient donc :

dnssec-keygen -a HMAC-MD5 -b 512 -n HOST foo.exemplebis.fr.

Notez toujours le point à la fin du domaine. On génère une clé pour un hôte donné, mais dnssec-keygen permet bien d’autres choses que nous n’utiliserons pas ici. Notamment, vous pouvez choisir un algorithme différent, ou créer une clé pour toute une zone. Pour l’heure, nous souhaitons avoir la possibilité de transférer de manière sécurisée les données de zones (dans notre exemple, le fichier db.exemple.fr) de notre serveur maître vers le serveur esclave que nous configurerons plus tard. Cette commande est donc suffisante pour le moment.

A l’issue de l’exécution de cette commande (qui peut durer une vingtaine de secondes), deux nouveaux fichiers ont été créés. Ils commencent par la lettre K majuscule, et portent respectivement l’extension .key et .private. Le premier fichier contient une ligne qu’il est possible de rajouter dans un fichier de zone, tandis que le second contient quelques détails sur la création de la clé. Nous n’utiliserons dans notre cas précis aucun des deux dans son état actuel. Cependant, il peut être utile de les conserver pour un usage ultérieur.

La seule chose qui nous intéresse est la clé en elle-même qui figure dans les deux fichiers. Utilisez la commande cat sur le fichier .private, et copiez la clé qui apparaîtra. Créez ensuite le fichier transfer.conf :

nano transfer.conf
key "TRANSFER" {
algorithm hmac-md5;
secret "la clé que vous avez copié";
};

server 2.2.2.2 {
keys {
TRANSFER;
};
};

Dans ce fichier, nous ajoutons une clé au « trousseau » de bind, qui ne sera destinée qu’au transfert des zones entre le maître et l’esclave. Si un cas se présente où nous devrons diffuser d’autres clés, nous en générerons de nouvelles, pour éviter toute interférence.

Ensuite, nous affectons cette clé au serveur esclave, 2.2.2.2. Incluez ce fichier à votre configuration, puis modifiez le fichier named.conf.local :

echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf
nano named.conf.local
zone "exemple.fr" {
type master;
file "/etc/bind/db.exemple.fr";
allow-transfer { 2.2.2.2; };
};

Nous avons rajouté la ligne allow-transfer { 2.2.2.2; }; qui nous permet d’éviter que n’importe qui puisse transférer nos zones sur son serveur. Redémarrez bind :

/etc/init.d/bind9 restart

Désormais, lorsque le serveur maître redémarrera, il notifiera automatiquement le(s) serveur(s) esclave(s) de tout changement, et initiera le transfert des zones de manière sécurisée.

Passons maintenant à la configuration du serveur esclave à proprement parlé. Sur la machine qui hébergera ce serveur, installez bind :

apt-get install bind9 dnsutils

Nous avons créé le fichier transfer.conf sur le serveur maître. Le même fichier doit être créé sur la machine esclave, avec une petite nuance.

cd /etc/bind
/etc/init.d/bind9/stop
nano transfer.conf
key "TRANSFER" {
algorithm hmac-md5;
secret "la clé que vous avez copié";
};

server 1.1.1.1 {
keys {
TRANSFER;
};
};

Vous noterez qu’il s’agit exactement du même fichier, y compris la même clé, mais que l’adresse IP de la clause server change. Dans la configuration du serveur esclave, c’est l’adresse IP du serveur maître qu’il faut indiquer. Ensuite, comme pour la configuration du serveur maître, on ajouter ce fichier à la configuration de bind :

echo "include \"/etc/bind/transfer.conf\" >> /etc/bind/named.conf

Modifions ensuite le fichier named.conf.local pour y ajouter la configuration de votre (vos) domaine(s) :

zone "exemple.fr" {
type slave;
file "/var/cache/bind/db.exemple.fr";
masters { 1.1.1.1; };
allow-notify { 1.1.1.1; };
};

Nous indiquons ici que le fichier de zone db.exemple.fr, une fois transféré, sera stocké dans le dossier /var/cache/bind, qui devrait déjà être créé. Si ce n’est pas le cas, il faut le créer, et donc tous les cas, lui attribuer les bons droits :

mkdir -p /var/cache/bind
chown -R bind:bind /var/cache/bind
chmod -r 644 /var/cache/bind

Il suffit maintenant de redémarrer bind pour que les modifications soient prises en compte.

/etc/init.d/bind9 restart

Consultez immédiatement les journaux utilisés par bind :

tail -100 /var/log/syslog

Il se peut que vous y trouviez une erreur à propos de l’heure qui n’est pas synchronisée. Installez sur les deux serveurs le paquet ntpdate, puis synchronisez les horloges avant de redémarrer bind :

apt-get install ntpdate
ntpdate 0.fr.pool.ntp.org
/etc/init.d/bind9 restart

Testez maintenant votre serveur :

nslookup
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53
> exemple.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: exemple.fr
Address: 1.1.1.1

That’s it !
<3