Configuration d'une redondance DNS

Je suis dans la situation suivante : j'ai une machine exécutant entre autres un serveur DHCP et un serveur DNS, et je souhaite réinstaller cette machine. Problème, si je la réinstalle, le DHCP et le DNS seront indisponibles. Il me faut donc redonder ces deux services pour ne pas perturber les autres machines. Après la redondance DHCP, ce billet aborde la redondance DNS. Ce billet, comme le précédent, n'aborde pas la configuration complète d'un serveur DNS mais détaille les options de configurations liées à la redondance

Une redondance basique dans un LAN est très facile à mettre en œuvre car il n'y a pas besoin de modifier quoi que ce soit chez un registrar. Il faudra cependant ajouter l'adresse IP du second serveur DNS dans la configuration de toutes les machines ayant une adresse IP statique, car celles-ci ne récupèrent pas la liste des serveurs DNS via DHCP. Une redondance DNS se compose généralement d'au moins deux serveurs : un serveur maître et un ou plusieurs serveurs esclaves. Toutes nos futures modifications dans le DNS s'effectueront sur le serveur maître et seront répliquées automatiquement vers le serveur esclave. Dans notre cas, le serveur maître utilise NetBSD 4.0 et le serveur esclave utilise NetBSD 5.1; dans les deux cas, ISC Bind est utilisé dans sa version embarquée avec l'OS, et configuré dans un chroot.

Sur notre serveur maître, configurons nos zones dans le fichier /var/chroot/named/etc/named.conf :

zone "anotherhomepage.loc" IN {
        type master;
        file "anotherhomepage.loc";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

zone "37.13.10.in-addr.arpa" IN {
        type master;
        file "anotherhomepage.loc.reverse";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

Remarquons que nous autorisons le transfert vers 10.13.37.11 qui est le serveur esclave. Continuons dans le fichier de zone anotherhomepage.loc dont voici quelques extraits :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601 ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)

; Name servers
anotherhomepage.loc.    IN      NS     ns0
anotherhomepage.loc.    IN      NS     ns1
; Mail servers
anotherhomepage.loc.    IN      MX      10      mail
; "A" entries
ns0                  IN      A       10.13.37.10
ns1                  IN      A       10.13.37.11
mail                 IN      A       10.13.37.12

Notre serveur esclave est donc renseigné pour le DNS, voyons voir dans le DNS inverse, fichier de zone anotherhomepage.loc.reverse :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601  ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)
        IN      NS      ns0.anotherhomepage.loc.
        IN      NS      ns1.anotherhomepage.loc.
        IN      MX      10      mail.anotherhomepage.loc.
10      IN      PTR     ns0.anotherhomepage.loc.
11      IN      PTR     ns1.anotherhomepage.loc.
12      IN      PTR     mail.anotherhomepage.loc.

Occupons-nous à présent de notre serveur esclave. De ce côté, un seul fichier à modifier, /var/chroot/named/etc/named.conf, car les autres seront transférés par les mises à jour de zone :

zone "anotherhomepage.loc" IN {
        type slave;
        masters { 10.13.37.5; };
        file "anotherhomepage.loc";
        allow-update { 10.13.37.5; };
        allow-query { any; };
        allow-notify { 10.13.37.5; };
};

zone "37.13.10.in-addr.arpa" IN {
        type slave;
        masters { 10.13.37.10; };
        file "anotherhomepage.loc.reverse";
        allow-update { 10.13.37.10; };
        allow-query { any; };
        allow-notify { 10.13.37.10; };
};

Il ne reste maintenant qu'à vérifier notre configuration. Par défaut, les logs vont dans /var/log/messages. Vous pouvez définir un autre emplacement pour les logs, comme par exemple :

logging {
        channel simple_log {
                file "/var/log/named/bind.log" ;
                severity info;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
        category default{
                simple_log;
        };
        category queries{
                simple_log;
        };
};

Cet exemple est à insérer dans votre named.conf. Incrémentons les numéros de série, effectuons une relance de bind sur le serveur esclave puis le serveur maître :

root@ns0:/var/chroot/named/var# /etc/rc.d/named reload
Reloading named config files.

Regardons le résultat sur le serveur esclave pour la relance du serveur maître :

root@ns1:/var/chroot/named/etc# tail -f /var/chroot/named/var/log/named/bind.log
26-Apr-2011 19:14:10.864 notify: info: client 10.13.37.5#64893: received notify for zone '37.13.10.in-addr.arpa'
26-Apr-2011 19:14:10.923 general: info: zone 37.13.10.in-addr.arpa/IN: Transfer started.
26-Apr-2011 19:14:10.924 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: connected using 10.13.37.60#65525
26-Apr-2011 19:14:11.335 general: info: zone 37.13.10.in-addr.arpa/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.336 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 258 records, 8672 bytes, 0.411 secs (21099 bytes/sec)
27-Apr-2011 19:14:11.337 notify: info: zone 37.13.10.in-addr.arpa/IN: sending notifies (serial 2011042601)
26-Apr-2011 19:14:11.383 notify: info: client 10.13.37.5#64893: received notify for zone 'anotherhomepage.loc'
26-Apr-2011 19:14:11.388 general: info: zone anotherhomepage.loc/IN: Transfer started.
26-Apr-2011 19:14:11.390 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: connected using 10.13.37.60#65524
26-Apr-2011 19:14:11.654 general: info: zone anotherhomepage.loc/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.654 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 268 records, 8464 bytes, 0.263 secs (32182 bytes/sec)
26-Apr-2011 19:14:11.657 notify: info: zone anotherhomepage.loc/IN: sending notifies (serial 2011042601)

Houra ! Les transferts ont eu lieu ! Maintenant, il reste à modifier dans notre serveur DHCP les adresses IP des serveurs DNS. Dans le cas d'ISC DHCP :

option domain-name-servers 10.13.37.10, 10.13.37.11;

Notez que ce billet permet une redondance assez basique, et loin d'être totalement sécurisée : quelqu'un d'assez malin peut, en utilisant une attaque de type Man-in-the-middle peut appliquer des modifications au serveur esclave. Pour les personnes qui aimeraient corriger ce défaut, il faut se tourner vers DNSSEC.

Configuration d'une redondance DHCP

Ce billet est basé sur l'excellent billet de Paul Heinlein et publié avec son aimable autorisation. Le billet original se trouve ici.

Je suis dans la situation suivante : j'ai une machine exécutant entre autres un serveur DHCP et un serveur DNS, et je souhaite réinstaller cette machine. Problème, si je la réinstalle, le DHCP et le DNS seront indisponibles. Il me faut donc redonder ces deux services pour ne pas perturber les autres machines. Ce billet ne porte cependant que sur DHCP.

Commençons par jeter un oeil à la configuration actuelle du serveur DHCP, elle ressemble un peu à ceci :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

On y trouve un pool, un groupe et une machine dans ce groupe avec une adresse IP fixée grâce à son adresse MAC : n'importe quelle machine se verra attribuer une adresse entre 10.13.37.200 et 10.13.37.249, mais la machine dont l'adresse MAC est 08:00:27:d3:8f:2d se verra attribuer l'IP 10.13.37.199.

Que se passe-t-il si je stoppe le serveur DHCP ? Les clients n'ont plus d'IP, donc plus d'accès au réseau, ce qui peut s'avérer gênant. Recopions la configuration sur l'autre serveur puis modifions celle-ci, qui va maintenant ressembler à ça :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
failover peer "dhcp-failover" {
        primary; # declare this to be the primary server
        address 10.13.37.5;
        port 647;
        peer address 10.13.37.60;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        failover peer "dhcp-failover";
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

Maintenant notre machine est serveur primaire DHCP et communique avec le serveur désigné après peer address. Allons d'ailleurs voir la nouvelle configuration du serveur secondaire :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
failover peer "dhcp-failover" {
        secondary; # declare this to be the secondary server
        address 10.13.37.60;
        port 647;
        peer address 10.13.37.5;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        failover peer "dhcp-failover";
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

A noter que si vous utilisez un pare-feu sur vos machines, il faudra autoriser les ports 647/tcp et 647/udp qui permettent la communication entre les deux serveurs.

Que se passe-t-il au démarrage et arrêt des serveurs ?

Exemple dans les logs du serveur primaire, après ajout de la configuration, le serveur dhcp primaire est nommé master-dhcp et le secondaire slave-dhcp :

Apr 20 22:28:30 master-dhcp dhcpd: Wrote 0 deleted host decls to leases file.
Apr 20 22:28:30 master-dhcp dhcpd: Wrote 0 new dynamic host decls to leases file.
Apr 20 22:28:30 master-dhcp dhcpd: Wrote 53 leases to leases file.
Apr 20 22:28:31 master-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to startup
Apr 20 22:28:45 master-dhcp dhcpd: failover peer dhcp-failover: I move from startup to communications-interrupted

Démarrons maintenant DHCPD sur le serveur secondaire, et voyons le résultat sur le serveur primaire :

Apr 20 22:30:29 master-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to normal
Apr 20 22:30:29 master-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
Apr 20 22:30:29 master-dhcp dhcpd: pool 80c3200 192.168.6/24 total 50  free 26  backup 24  lts -1

Et regardons les logs du serveur secondaire :

Apr 20 22:30:28 slave-dhcp dhcpd: Wrote 0 deleted host decls to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: Wrote 0 new dynamic host decls to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: Wrote 50 leases to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: I move from normal to startup
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to communications-interrupted
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: I move from startup to normal
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from communications-interrupted to normal
Apr 20 22:30:29 slave-dhcp dhcpd: pool 7f7ffd8a5150 192.168.6/24 total 50  free 26  backup 24  lts 1

Si je stoppe le serveur primaire, on le voit dans les logs du serveur secondaire :

Apr 20 22:32:08 slave-dhcp dhcpd: peer dhcp-failover: disconnected
Apr 20 22:32:08 slave-dhcp dhcpd: failover peer dhcp-failover: I move from normal to communications-interrupted

Et le redémarrage est aussi visible :

Apr 20 22:32:40 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to normal
Apr 20 22:32:40 slave-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
Apr 20 22:32:40 slave-dhcp dhcpd: pool 7f7ffd8a5150 192.168.6/24 total 50  free 26  backup 24  lts 1

Pour finir, cette configuration n'est possible que si les deux serveurs DHCP ont la même version d'ISC DHCP. Heureusement (?), de NetBSD 4.0 jusqu'à NetBSD 5.1 inclus, ISC DHCP est toujours en version 3.0.3 ;-)

Effectuer une netinstall de NetBSD 5

J'avais déjà rédigé un petit tip pour NetBSDfr, mais cette fois-ci je suis allé un peu plus loin : J'ai documenté l'installation par le réseau, incluant un démarrage PXE de NetBSD 5, pour i386 et amd64. Et c'est sur le wiki NetBSDfr que ça se passe.

Faites chauffer les cartes réseau !

configuration basique pour bozohttpd

NetBSD possède dans ses sets de base quelques logiciels intéressants pour un serveur : un serveur SSH, un serveur DNS, un serveur DHCP, même un serveur TFTP et celui qui m'intéresse plus particulièrement aujourd'hui, un serveur HTTP. Il ne s'agit pas, comme on pourrait s'y attendre, d'Apache HTTP Server, mais de bozohttpd, un serveur web peu connu mais particulièrement léger et à la configuration minimaliste, pour peu que le besoin le soit aussi. D'ailleurs c'est très simple, mon besoin est on ne peut plus simple : je désire créer un miroir local de distributions Linux et NetBSD et je ne souhaite pas y passer des heures à configurer un virtualhost. Autre avantage de bozohttpd dans ce cas précis, comme il est installé par défaut dans le système de base, pas besoin de l'installer. Ca fera toujours un paquet de moins à maintenir.

Une fois passée l'extase du "pas besoin de l'installer, c'est déjà fait", on se met à la recherche d'un fichier de configuration. Après la frustration d'être rentré bredouille, la page d'accueil du logiciel explique très simplement que "it has no configuration file by design". Il faut donc le configurer en le lançant avec différentes options. Un petit grep bien senti permet de voir comment ça va se passer :

root@arreat:~# grep -i http /etc/defaults/rc.conf 
httpd=NO                httpd_flags=""
                        httpd_wwwdir="/var/www"
                        httpd_wwwuser="_httpd"

Il suffit donc de positionner les options dans la directive "httpd_flags" de son rc.conf, et éventuellement de changer "httpd_wwwdir" selon l'emplacement de ses fichiers. D'abord, copions ces options dans notre rc.conf :

root@arreat:~# grep -i http /etc/defaults/rc.conf >> /etc/rc.conf

Ensuite, pour pouvoir lancer bozohttpd, on édite /etc/rc.conf et on passe httpd=NO à httpd=YES. Une fois l'édition terminée, on lance le serveur :

root@arreat:~# /etc/rc.d/httpd start

Par défaut, bozohttpd cherche un fichier index.html dans "httpd_wwwdir", et affiche son numéro de version. Paranoïa oblige, je souhaite enlever le numéro de version, et comme je veux juste mettre à disposition un miroir local de logiciels, je me fiche qu'il n'y ait pas d'index dans les répertoires. Et pour finir, je change le répertoire de base :

httpd=YES
httpd_flags="-X -S 'AHP Intranet'"
httpd_wwwdir="/srv/www"
httpd_wwwuser="_httpd"

L'option "-X" active le directory indexing, en clair, le listage des fichiers. L'option "-S" suivie d'une chaîne de caractère permet de substituer le nom réel du serveur à un nom personnalisé, ici "AHP Intranet". Une fois le service httpd relancé, j'obtiens ma liste de fichiers :-)

En bref, je n'ai pas eu à passer deux heures à configurer un virtual host, ni à retirer des modules, à tuner le nombre de processus. 10 minutes montre en main. Et pour plus d'options, la documentation peut être accédée via man 8 httpd ou sur le site de bozohttpd.

Flasher son BIOS sans DOS ni Windows

Mettre à jour le BIOS de sa carte mère, voilà une activité qui peut s'avérer exaspérante au possible : par le passé, cela se faisait en utilisant une disquette (voire deux), contenant un système DOS et deux fichiers, l'utilitaire de flashage et l'image du BIOS proprement dite.

Il fallait donc : - disposer d'un lecteur de disquettes en état de marche, ainsi que de disquettes elles-aussi en état de marche; - disposer d'un système d'exploitation DOS ou d'un système Windows, lequel permettait de créer une disquette de démarrage DOS.

Cela doit faire quelques années qu'on ne vend plus d'ordinateurs équipés de lecteur de disquettes, aussi de nombreux constructeurs fournissent des outils fonctionnant directement sous Windows. Problème : la machine dont je souhaite mettre à jour le BIOS ne possède ni lecteur de disquette, ni de Windows, et pour couronner le tout, même pas de lecteur de CD-ROM. Pour la petite histoire, le système d'exploitation de cette machine a été installé grâce à PXE, et j'avais aussi installé un autre en démarrant sur une clé USB.

Il me faut donc trouver un système capable d'exécuter des programmes DOS, et capable d'être démarré depuis le réseau ou une clé USB. Pour la première partie, c'est assez facile et archi-connu, il s'agit de FreeDOS. Pour la deuxième partie, c'est en fait tout aussi facile : FreeDOS est fourni sous forme d'image ISO. Cette image peut être copiée sur clé USB grâce à l'utilitaire UNetbootin. Il suffit, une fois FreeDOS installé sur la clé USB, de copier l'utilitaire de flashage et l'image du BIOS à la racine de cette clé USB.

Le démarrage d'un ordinateur sur clé USB peut s'avérer plus difficile que prévu : il faut s'assurer en regardant dans le BIOS que celui-ci accepte de démarrer sur USB (ce n'est pas le cas de vieilles machines). Il se peut aussi qu'une option sur le type de périphérique USB (ZIP, disque dur, etc...) soit à modifier, ou la taille (fixe, dynamique). Bref, même aujourd'hui, démarrer sur l'USB, ce n'est pas trivial.

Arrive ensuite le menu de démarrage. UNetbootin semble avoir son propre menu, qui m'affiche plusieurs entrées (qui ne mènent à rien), dont une nommée fdos et l'autre nommée freedos. Dans mon cas, c'est la première qui a fonctionné et qui m'a amené à l'écran de démarrage de FreeDOS. Là encore, je ne détaillerai pas les options, cela dépend vraiment de la machine.

Une fois le prompt obtenu, reste à retrouver l'utilitaire de flashage. On remarque que le prompt affiche "A:\>". La clé USB est en fait en C: donc on tape :

A:\> C:
C:\>

On peut lire le contenu du répertoire courant par la commande "dir", comme sous le vieux DOS de Microsoft. On peut donc vérifier que l'utilitaire de flashage est bien présent dans C: et aller vérifier dans les sous-dossiers si besoin. Ensuite, la commande varie selon les outils, mais lancer l'outil via un truc du genre :

outildeflash.exe

ou alors :

outildeflash.exe help

devrait aider à connaître la bonne syntaxe.

Propulsé par Dotclear