[technique] Puppetisation des serveurs NS

[Fabien Dupont]

Bonjour,

Puppetisation des NS, phase 2 OK : gw (le primaire) l'est.

Par contre, à l'heure actuelle, les zones sont dans une configuration
tordue.

Le problème, actuellement est que gw a plein d'IP et que ns1 et ns2 sont
des IP routées sur cette même machine. Bind utilise une IP pour
effectuer les notify et les transferts vers les NS mais elle ne
correspond pas au SOA des zones. Au final, ça ne marche pas très bien,
voire pas du tout. A mon avis même, la zone sur le NS de gandi va
expirer et disparaitre.

Les NS, c'est simple à gérer si l'architecture est simple (un NS = une
IP). Je ne pense pas qu'on ait envie de s'encombrer de patch en mode
ghetto pour faire marcher un NS :).

Voilà ce que je propose pour simplifier la chose :

Modifier les zones pour avoir :
- NS primaire   : ns1.tetaneutral.net = une IP de GW (à voir laquelle)
- NS secondaire : ns2.tetaneutral.net = l'IP de la VM grenode
- NS secondaire : ns3.tetaneutral.net = l'IP d'une VM à Toulouse
- NS secondaire : ns6.gandi.net

Pour cela, il faut effectuer ces 5 étapes :
- Modifier les enregistrements ns1, 2 et 3 et différentes zones.
- Modifier les NS de toutes les zones dans l'interface gandi.
- Modifier la conf' de bind sur ns1 (gw, en fait) :
  - transfert-source = ns1
  - notify-source = ns1
  - slaves de chaque zone = ns2, ns3, ns6.gandi.net
- Modifier la conf' de bind sur ns2 (grenode) :
  - allow-notify = ns1
  - master de chaque zone = ns1
- Créer une VM à Toulouse (ns3) et la puppetiser en mode slave (copie de
  la conf' de celle de grenode).

Je pense que ça n'implique pas grand chose du point de vue « client NS »
car :
- soit les zones sont sur les différents serveurs cache du monde entier
  avec pas les bons NS mais c'est pas grave,
- soit les zones ne sont pas dans ces caches, ils interrogeront les
  root, les tld, les glues records et retomberont sur ns1 (c'est le
  fonctionnement normal, en fait).

Je vois plusieurs avantages à cette architecture :
- elle est robuste du point de vue NS : 4 NS, dans des lieux
  géographiques différents et sur des bouts de réseau différents,
- elle est facile à réparer en cas de panne : il suffit de créer une VM,
  lui donner le nom et l'IP du bout en panne et la réinstaller en 5
  minutes grâce à puppet,
- et c'est celle utilisée partout, c'est sûrement pas pour rien :).

D'ici là, je vais améliorer la pupettisation de bind pour que les zones
soient reloadées dés qu'elles sont pushées dans git avec le module
puppet qui va bien pour ça (vcs-quelque chose). Et dans le même
mouvement, je vais faire une p'tite page dans le wiki pour expliquer
comment mettre à jour une zone (emacs/vi, git commit, git push, puppet
agent -vt et voilà). 

Ça a l'air compliqué ce puppet, mais ça sert juste à décrire dans son
langage la manière dont une machine est installée. Si on commence à
faire des patches dans puppet pour intégrer des bouts de conf' manuels,
d'une part ça fait perdre sont sens à l'outil...autant faire du git et
des scripts en SH...d'autre part, c'est dangereux parce que, forcément,
un jour on oubliera que c'est là. Autant regrouper toute la conf' d'un
même service dans puppet, à la mode de chez lui.

Si personne n'a rien contre, je peux faire tout ça sans problème au
cours d'une après-midi/soirée (aujourd'hui mercredi ? :)).

Fab, qui a trop chaud pour dormir.
-- 
((__))  
 (00)    Fabien Dupont   
(o__o)  www.kafe-in.net