Openstuff Wiki : HowtoSVNDNS

HomePage :: Categories :: PageIndex :: RecentChanges :: RecentlyCommented :: Login/Register

Revision [556]

Last edited on 2007-12-06 17:24:24 by StanKju
Additions:
Classiquement, les DNS sont mis en maître/esclave avec des transferts de zone entre eux. L'idée ici est de n'avoir plus qu'une machine centrale qui poussera les zones en SSH sur les autoritaire qui seront tous déclaré master. C'est ce que nous appelons une architecture DNS multimaster. Les intérêts sont multiples :
L'utilisation d'un outil de gestion de version tel que Subversion est motivée par les éléments suivants:
~- ajout/modification de zone possible par n'importe quelle personne autorisée (SVN joue ici le rôle d'interface)
~- rollback rapide
~- tracabilité: historique précis des modifications (date, utilisateur, …)
Pourquoi Subversion et pas CVS ? Principalement pour la possibilité d'utiliser des "Hook" qui vont nous permettent d'exécuter des scripts avant et après modification du repository Subversion. Mais d'autres avantages viennent également s'ajouter à cela:
====2. Mise en place====
=== Les serveurs DNS autoritaires ===
=== Le serveur Master ===
Ce serveur doit contenir le repository Subversion avec l'ensemble de vos zones. Deux scripts de "hook" vont être créés qui permettront d'effectuer automatiquement la vérification et la propagation des zones lors d'un commit.
Les serials seront gérés par nos scripts, ils seront donc mis à ''0000000000'' dans le repository. Un remplacement sera fait automatiquement lors du //post-commit// via la commande [[http://www.dns.net/dist/zsu/ zsu]]. Le fichier ''/var/lib/misc/zones.serialZ'' servira de stockage pour l'ensemble des serials. Son format est le suivant:
__Script Hook Subversion: pre-commit__
~- Vérifie la présence d'un serial à ''0000000000''
~- Vérifie la présence d'un ''$ORIGIN'' (pas obligatoire ...)
~- Fait un ''named-checkzone'' des zones modifiées
__Script Hook Subversion: post-commit__
~- fait un ''svn up'' dans le répertoire de bind pour propager les changements en local
~- déclenche le script ''dns_all_ng'' pour déployer les modifications sur les autoritaires et faire un flush sur le cache des résolveurs
# Define return code
__Script de déploiement: dns_all_ng.sh__
~- vérifie la zone à déployer passée en argument via ''named-checkzone''
~- copie les zones sur les autoritaires et fait prendre en compte les changements via un ''rndc reload''
~- se connecte sur les résolveurs et flush les caches pour éviter d'attendre l'expiration du TTL via ''rndc flush''
~- vérifie que tous les serveurs on un serial identique via un ''dig +short -t SOA''
#! /bin/sh
AUTHORITATIVES="serv1.auth.fqdn serv2.auth.fqdn"
RESOLVERS="serv1.solv.fqdn serv2.solv.fqdn"
BIND_DIR="/var/bind/master"
ZONES_DIR="/etc/bind/zones/master"
TMP_FILE=/tmp/dns_all.$$
SSH_OPT="-o ConnectTimeout=10"
ALL_ZONES=""
RET=0
# Delete temp file on exit
trap "rm -f $TMP_FILE" EXIT
# Get zone file from parameters
FILES="$*"
# Synchronize zones files and reload zones
synchro() {
machine=$1
fping $machine > /dev/null || { echo "ERROR: host $machine is dead !" >&2; RET=1; return; }
scp $SSH_OPT $ALL_FILES ${machine}:$BIND_DIR/ > /dev/null
ssh $SSH_OPT ${machine} "for zone in $ALL_ZONES ; do /usr/sbin/rndc reload \$zone > /dev/null || { hostname; echo \"ERROR: rndc reload \$zone failed\" >&2; RET=1; } ; done " || { echo "ERROR: ssh connect failed" >&2; RET=1; }
}
# Flush zone files
flush() {
solv=$1
fping $solv > /dev/null || { echo "ERROR: host $solv is dead !" >&2; RET=1; return; }
ssh $SSH_OPT $solv "/usr/sbin/rndc flush || { hostname; echo \"ERROR: can't flush DNS cache\" >&2; RET=1; }" || { echo "ERROR: ssh connect failed" >&2; RET=1; }
}
# Display SERIAL for all $ALL_ZONES on all authoritatives servers
test_all() {
for machine in localhost $AUTHORITATIVES ; do
echo -n "$machine: "
fping $machine > /dev/null || { echo "ERROR: host $machine is dead, can't test SOA" >&2; RET=1; continue; }
for zone in $ALL_ZONES ; do
dig +short -t SOA $zone @$machine | awk '{ print $3 } ' | xargs echo -n " "
done
echo ""
done
}
# Go to zones directory
cd $ZONES_DIR
# Check zones
for fichier in $FILES ; do
echo "* $fichier"
# Origin check
ZONE=`cat $fichier | grep "\\$ORIGIN" | awk '{print $2}'`
[ -z "$ZONE" ] && echo -e "ERROR: no $ORIGIN defined ! >>> Do nothing !!! <<<" >&2 && RET=1 && continue
# Named check zone
named-checkzone -q $ZONE $fichier || { named-checkzone $ZONE $fichier; echo "ERROR: zone $ZONE is not valid" >&2; RET=1; continue; }
rndc reload $ZONE || { echo "ERROR: rndc reload failed !" >&2; RET=1; }
ALL_ZONES="$ALL_ZONES $ZONE"
ALL_FILES="$ALL_FILES $fichier"
# No zone provided, exit
[ "x$ALL_ZONES" == "x" ] && { echo "ERROR: no zone provided" >&2; exit 1; }
# Reload AUTHORITATIVES
echo ""
echo "reload: "
for i in $AUTHORITATIVES ; do
echo -n "- $i "
synchro $i
echo ""
echo ""
# Flush RESOLVERS
echo "flush: "
for i in $RESOLVERS ; do
echo -n "- $i "
flush $i
echo ""
echo ""
# Check SOA
for count in `seq 3` ; do
test_all > $TMP_FILE
[ `uniq -1 $TMP_FILE | wc -l` -eq "1" ] && break
sleep 1
# If error
if [ $count -eq 3 ] ; then
RET=1
echo "" >&2
echo "ERROR: serial mismatch !" >&2
echo -n "zone: " >&2
for zone in $ALL_ZONES ; do echo -n "$zone " >&2 ; done ; echo "" >&2
cat $TMP_FILE >&2
echo "" >&2
# Delete temp file
rm $TMP_FILE
# Display last logfile message
echo "-----------------"
tail /var/log/bind/named.log
echo "-----------------"
exit $RET
Attention: ce script doit pouvoir se connecter en SSH aux serveurs autoritaires et aux résolveurs. Il faut donc au préalable générer un couple de clé sans passphrase, et déployer les clés publique sur les serveur DNS en question.
Deletions:
Classiquement, les DNS sont mis en maître/esclave avec des transferts de zone entre eux. L'idée ici est de n'avoir plus qu'une machine centrale qui poussera les zones sur tous les serveurs DNS qui seront tous master. C'est ce que nous appelons une architecture DNS multimaster. Les intérêts sont multiples :
~- ajout/modification de zone possible par n'importe quelle personne autorisée (SVN joue le rôle d'interface)
~- rollback rapide grâce à SVN
~- historique précis des modifications (date, utilisateur, …)
L'utilisation de Subversion est motivée par les éléments suivants:
~- possibilité d'utiliser des "Hook" qui permettent d'exécuter des scripts avant et après modification d'un repository Subversion
====2. La mise en place====
Les zones seront maintenant sur un repository Subversion. Deux scripts de "hook" vont être créés qui permettront d'effectuer automatiquement la vérification et la propagation des zones lors d'un commit.
Les serials seront gérés par nos scripts, ils seront donc mis à "0000000000" dans le repository. Un remplacement sera fait automatiquement lors du //post-commit// via la commande [[http://www.dns.net/dist/zsu/ zsu]]. Le fichier /var/lib/misc/zones.serialZ servira de stockage pour l'ensemble des serials. son format est le suivant:
=== Script Hook Subversion: pre-commit ===
~- Vérifie la présence d'un serial à "0000000000"
~- Vérifie la présence d'un $ORIGIN (pas obligatoire ...)
~- Fait un named-checkzone des zones modifiées
=== Script Hook Subversion: post-commit ===
~- fait un "svn up" dans le répertoire de bind pour propager les changements en local
~- déclenche le script "dns_all_ng" pour déployer les modifications sur les autoritaires et faire un flush sur le cache des résolveurs
# Define return code to NOK
=== Script de déploiement: dns_all_ng.sh ===
~- vérifie la zone à déployer passée en argument via //named-checkzone//
~- copie les zones sur les autoritaires et fait prendre en compte les changements via un //rndc reload//
~- se connecte sur les résolveurs et flush les caches pour éviter l'expiration du TTL via //rndc flush//
~- vérifie que tous les serveurs on un serial identique via un //dig +short -t SOA//
L'écriture du script est laissée comme exercice au lecteur :)


Revision [524]

Edited on 2007-11-17 10:38:15 by StanKju
Additions:
~- avec du transfert de zone: si authentification par IP, sécurité faible, si clé partagé, déploiement complexe pour la configuration de Bind (configuration différente à cause des clés partagées)
~- possibilité d'utiliser des "Hook" qui permettent d'exécuter des scripts avant et après modification d'un repository Subversion
~- sorties interprétables, prévues pour être « scripté »
Deletions:
~- Avec du transfert de zone: si authentification par IP, sécurité faible, si clé partagé, déploiement complexe pour la configuration de Bind (configuration différente à cause des clés partagées)
~- Possibilité d'utiliser des "Hook" qui permettent d'exécuter des scripts avant et après modification d'un repository Subversion
~- sorties interprétables, prévus pour être « scripté »


Revision [440]

Edited on 2007-10-21 12:55:15 by StanKju
Additions:
Nous allons voir comment utiliser SVN pour gérer des zones DNS. En effet, Subversion s'intègre particulièrement bien au sein d'une architecture DNS multimaster. Attention, nous considérons que vous êtes déjà familier avec SVN et que vous maîtrisez le fonctionnement du DNS (architecture, configuration, ...).
Classiquement, les DNS sont mis en maître/esclave avec des transferts de zone entre eux. L'idée ici est de n'avoir plus qu'une machine centrale qui poussera les zones sur tous les serveurs DNS qui seront tous master. C'est ce que nous appelons une architecture DNS multimaster. Les intérêts sont multiples :
~- configuration de Bind simplifié (plus de clés partagées, …)
~- déploiement immédiat des zones. Avec du transfert de zone, lors de nombreuses zones à mettre à jour une différence linéaire appairait (cf. "zone transfer deferred due to quota")
~- ajout/modification de zone possible par n'importe quelle personne autorisée (SVN joue le rôle d'interface)
~- retour d'erreur: nous sommes prévenus automatiquement des désynchro lors de nouvelles mises à jour de zones
~- Avec du transfert de zone: si authentification par IP, sécurité faible, si clé partagé, déploiement complexe pour la configuration de Bind (configuration différente à cause des clés partagées)
L'utilisation de Subversion est motivée par les éléments suivants:
~- Possibilité d'utiliser des "Hook" qui permettent d'exécuter des scripts avant et après modification d'un repository Subversion
~- versioning des métadonnées (répertoires, renommages, propriétés)
~- gestion des branches et des tags simplifiés
~- coût proportionnel à la taille des changements (et non des données)
~- sorties interprétables, prévus pour être « scripté »
Nous considérons que l'architecture DNS multimaster est déjà en place. Vous devriez avoir les directives suivantes dans la configuration de vos serveurs (section //options//):
Les zones seront maintenant sur un repository Subversion. Deux scripts de "hook" vont être créés qui permettront d'effectuer automatiquement la vérification et la propagation des zones lors d'un commit.
Les serials seront gérés par nos scripts, ils seront donc mis à "0000000000" dans le repository. Un remplacement sera fait automatiquement lors du //post-commit// via la commande [[http://www.dns.net/dist/zsu/ zsu]]. Le fichier /var/lib/misc/zones.serialZ servira de stockage pour l'ensemble des serials. son format est le suivant:
~- déclenche le script "dns_all_ng" pour déployer les modifications sur les autoritaires et faire un flush sur le cache des résolveurs
~- vérifie la zone à déployer passée en argument via //named-checkzone//
~- se connecte sur les résolveurs et flush les caches pour éviter l'expiration du TTL via //rndc flush//
~- vérifie que tous les serveurs on un serial identique via un //dig +short -t SOA//
L'écriture du script est laissée comme exercice au lecteur :)
Une fois les zones insérées dans le repository, les modifications de zones s'effectuent de la sorte:
Et voilà ! La zone sera vérifiée, le serial sera inséré dans le fichier de zone et celle-ci sera déployée sur les autoritaires. Rapide, efficace, que demande le peuple ? :)
Deletions:
Nous allons voir comment utiliser SVN pour gérer des zones DNS. En effet, Subversion d'intègre particulièrement bien au sein d'une architecture DNS multimaster. Attention, nous considérons que vous êtes déja familier avec SVN et que vous maîtrisez le fonctionnement du DNS (architecture, configuration, ...).
Classiquement, les DNS sont mis en maître/esclave avec des transferts de zone entre eux. L'idée ici est de n'avoir plus qu'une machine centrale qui poussera les zone sur tous les serveurs DNS qui seront tous master. C'est ce que nous appelons une architecture DNS multimaster. Les intérêts sont multiples :
~- configuration de Bind simplifié (plus de clé partagés, …)
~- déploiement immédiat des zones. Avec du transfert de zone, lors de nombreuses zones à mettre à jours une différence linéaire appairait (cf. "zone transfer deferred due to quota")
~- ajout/modification de zone possible par n’importe quel personne autorisé (SVN joue le rôle d'interface)
~- retour d'erreur: nous sommes prévenus automatiquement des désynchro lors de nouvelles mise à jours de zones
~- Avec du transfert de zone: si authentification par IP, sécurité faible, si clé partagé, déploiement complexe pour la configuration de Bind (configuration différente à cause des clés partagés)
L'utilisation de Subversion est motivé par les éléments suivants:
~- Possibilité d'utiliser des "Hook" qui permettent d'exécuter des scripts avant et arès modification d'un repository Subversion
~- versioning des méta-donnée (répertoires, renommages, propriétés)
~- gestion des branches et des tags simplifiée
~- coût proportionnels à la taille des changements (et non des données)
~- sorties interprétables, prévu pour être « scripté »
Nous considérons que l'architecture DNS multimaster est déja en place. Vous devriez avoir les directives suivantes dans la configurations de vos serveurs (section //options//):
Les zones seront maintenant sur un repository Subversion. Deux scripts de "hook" vont être créer qui permettrons d'effectuer automatiquement la vérifications et la propagation des zones lors d'un commit.
Les serials serons gérer par nos scripts, ils serons donc mis à "0000000000" dans le repository. Un remplacement sera fait automatiquement lors du //post-commit// via la commande [[http://www.dns.net/dist/zsu/ zsu]]. Le fichier /var/lib/misc/zones.serialZ servira de stockage pour l'ensemble des serials. son format est le suivant:
~- déclenche le script "dns_all_ng" pour déployer les modification sur les autoritaires et faire un flush sur le cache des résolveurs
~- vérifie la zone à déployer passé en argument via //named-checkzone//
~- se connecte sur les résolveurs et flush les cache pour éviter l'expiration du TTL via //rndc flush//
~- vérifie que tout les serveur on un serial identique via un //dig +short -t SOA//
L'écriture du script est laissé comme exercice au lecteur :)
Une fois les zones insérées dans le repository, les modifications de zones s'effectue de la sorte:
Et voila ! La zone sera vérifiée, le serial sera insérée dans le fichier de zone et celle-ci sera déployée sur les autoritaires. Rapide, efficace, que demande le peuple ? :)


Revision [315]

Edited on 2007-07-06 12:02:39 by StanKju
Additions:
==== 3. Utilisation ====
Une fois les zones insérées dans le repository, les modifications de zones s'effectue de la sorte:
$ svn up
$ vi
$ svn commit -m ""
Et voila ! La zone sera vérifiée, le serial sera insérée dans le fichier de zone et celle-ci sera déployée sur les autoritaires. Rapide, efficace, que demande le peuple ? :)


Revision [314]

The oldest known version of this page was created on 2007-07-06 11:57:31 by StanKju
Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki
Page was generated in 0.0902 seconds