[technique] Puppetisation des serveurs NS

Fabien Dupont fab at kafe-in.net
Jeu 9 Aou 10:33:43 CEST 2012


Bonjour,

Hier on a puppetisé un bind secondaire, encore non actif, sur la VM à
grenode.

Concrètement, voilà la conf' de puppet niveau bind pour ce « node » :

----8<---------------------------------------------------------------

node "tetaneutral.grenode.net" {
        class { 'ttnn_secondary_ns': primary_ns => '91.224.148.1'}
}

class ttnn_secondary_ns(
        $primary_ns,
){
        class { 'bind':
                views   => [
                        {
                                name      => 'lan',
                                acl       => ['127.0.0.1', '::1/128'],
                                recursion => true,
                        },
                        {
                                name      => 'wan',
                                recursion => false,
                                zones     => [
                                        { name   => 'tetaneutral.info'                , type => 'slave', master => [$primary_ns], },
                                        { name   => 'tetaneutral.biz'                 , type => 'slave', master => [$primary_ns], },
                                        { name   => 'tetaneutral.com'                 , type => 'slave', master => [$primary_ns], },
                                        { name   => 'tetaneutral.org'                 , type => 'slave', master => [$primary_ns], },
                                        { name   => 'tetaneutral.eu'                  , type => 'slave', master => [$primary_ns], },
                                        { name   => 'tetaneutral.fr'                  , type => 'slave', master => [$primary_ns], },
                                        { name   => 'tetaneutral.net'                 , type => 'slave', master => [$primary_ns], },
                                        { name   => 'as197422.net'                    , type => 'slave', master => [$primary_ns], },
                                        { name   => 'ipv6.tetaneutral.net'            , type => 'slave', master => [$primary_ns], },
                                        { name   => '236.213.91.in-addr.arpa'         , type => 'slave', master => [$primary_ns], },
                                        { name   => '148.224.91.in-addr.arpa'         , type => 'slave', master => [$primary_ns], },
                                        { name   => '149.224.91.in-addr.arpa'         , type => 'slave', master => [$primary_ns], },
                                        { name   => '0.8.0.0.6.6.1.0.a.2.ip6.arpa'    , type => 'slave', master => [$primary_ns], },
                                        { name   => '0.0.0.8.0.0.6.6.1.0.a.2.ip6.arpa', type => 'slave', master => [$primary_ns], },
                                        { name   => '0.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa', type => 'slave', master => [$primary_ns], },
                                        { name   => '1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa', type => 'slave', master => [$primary_ns], },
                                ]
                        }
                ]
        }
}

----8<---------------------------------------------------------------

Voilà un plan d'action pour transporter la gestion des zones vers le
serveur primaire (gw) :

Etape 1: Modifier les glue records des zones chez les registrars (gandi,
ovh, etc.) pour coller en tant que NS :

- ns1.tetaneutral.net. 91.224.148.1
- ns2.tetaneutral.net. 91.216.110.40
- Un secondaire du registrar (je sais que c'est ns6.gandi.net pour gandi
  mais pour OVH, je ne sais pas). Sauf pour les reverses, bien sûr.

Etape 2: Modifier tous les fichiers de zones pour y définir en tant que
NS : ns1 et ns2 ainsi que le secondaire du registrar. Puis attendre la
propagation sur les secondaires (quelques secondes...).

Etape 3: Backupper dans un coin la conf' de bind actuelle. On ne sait
jamais :) .

Etape 4: Une fois que le secondaire a les zones, on peut réinstaller
bind sur le primaire sans perte de zone. Les NS cache qui auront
l'ancienne zone pendant 24H interrogeront les anciens NS mais ils auront
toujours l'info. Les autres NS interrogeront soit le primaire en cours
de réinstallation puis du coup le secondaire car lui répondra, soit
directement le secondaire (roundrobin, tout ça tout ça...).

Dans tout la cas, on peut maquetiser un bind dans un coin pour valider
la conf' de puppet.

Justement, côté conf' de puppet du master, voilà ce que ça pourrait
donner :

----8<---------------------------------------------------------------

node "gw.tetaneutral.net" {
        class { 'ttnn_primary_ns': ttnn_ns => '91.216.110.40', gandi_ns => '217.70.177.40', ovh_ns => '213.251.128.137'}
}

class ttnn_primary_ns(
        $ttnn_ns,
        $gandi_ns,
        $ovh_ns,
){
        class { 'bind':
                views   => [
                        {
                                name      => 'lan',
                                acl       => ['127.0.0.1', '::1/128'],
                                recursion => true,
                        },
                        {
                                name      => 'wan',
                                recursion => false,
                                zones     => [
                                        { name   => 'tetaneutral.info'                , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'tetaneutral.biz'                 , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'tetaneutral.com'                 , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'tetaneutral.org'                 , type => 'master', slaves => [$ttnn_ns, $gandi_ns], },
                                        { name   => 'tetaneutral.eu'                  , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'tetaneutral.fr'                  , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'tetaneutral.net'                 , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'as197422.net'                    , type => 'master', slaves => [$ttnn_ns, $ovh_ns], },
                                        { name   => 'ipv6.tetaneutral.net'            , type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '236.213.91.in-addr.arpa'         , type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '148.224.91.in-addr.arpa'         , type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '149.224.91.in-addr.arpa'         , type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '0.8.0.0.6.6.1.0.a.2.ip6.arpa'    , type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '0.0.0.8.0.0.6.6.1.0.a.2.ip6.arpa', type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '0.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa', type => 'master', slaves => [$ttnn_ns], },
                                        { name   => '1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa', type => 'master', slaves => [$ttnn_ns], },
                                ]
                        }
                ],
                zonerepo => 'git://git.tetaneutral.net/zones-bind.git'
        }
}

----8<---------------------------------------------------------------

Les zones devront alors être dans un GIT contenant les fichiers suivants :

wan/tetaneutral.info.zone
wan/tetaneutral.biz.zone
wan/tetaneutral.com.zone
wan/tetaneutral.org.zone
wan/tetaneutral.eu.zone
wan/tetaneutral.fr.zone
wan/tetaneutral.net.zone
wan/as197422.net.zone
wan/ipv6.tetaneutral.net.zone
wan/236.213.91.in-addr.arpa.zone
wan/148.224.91.in-addr.arpa.zone
wan/149.224.91.in-addr.arpa.zone
wan/0.8.0.0.6.6.1.0.a.2.ip6.arpa.zone
wan/0.0.0.8.0.0.6.6.1.0.a.2.ip6.arpa.zone
wan/0.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.zone
wan/1.8.0.8.0.0.6.6.1.0.a.2.ip6.arpa.zone

Puppet s'occupe de faire un premier clone du git dans /var/named qui, en
fait, est un lien symbolique vers /var/bind/chroot/var/named.

On pourrait très facilement rajouter un NS slave de plus (H3 ?) ou même
avoir un master, côté bind, non visible d'internet qui basarde les zones
sur plusieurs slaves visibles.

D'ailleurs, je viens de voir que bind sur GW ne « listen » pas sur
toutes ses interfaces. Si on veut garder ça, je dois faire une légère
modification du module puppet (2 minutes de boulot :)). Idem pour le
paramètre « transfert-source ». Je fais ces modifications dans la
journée niveau module.

Bref, /discuss :)

Cldt,
-- 
((__))  
 (00)    Fabien Dupont   
(o__o)  www.kafe-in.net



Plus d'informations sur la liste de diffusion technique