DNS secondaire pour plusieurs serveurs plesk

Je m’attaque à la création d’un serveur DNS secondaire pour mes serveurs plesk. En effet, je vais en avoir plusieurs. Je me base sur l’article cité ci-dessous en source. Mais je vais l’adapter à ma sauce. En effet, je ne veux pas avoir à maintenir un site web pour faire transiter les fichiers de zones. Je vais donc me servir de ssh pour transférer les fichiers.

Sur les serveurs plesk

Les opérations suivantes peuvent être faites sur tous les serveurs plesk.

Avant de commencer, faites une copie de sécurité du fichier /etc/named.conf. On est jamais trop prudent.

Création d’un utilisateur pour les opérations automatiques

D’abord, pour tout ce qui est automatique, je crée un nouvel utilisateur. Par exemple « robotuser », et, pour rester cohérent avec mon article sur la sécurisation d’un serveur, je l’ajoute au groupe sshusers. J’utilise sudo, toujours en accord avec l’article en question.

sudo usermod -G sshusers robotuser

Je lui génère un mot de passe très complexe. Dans mon cas, un générateur me donne un mot de passe de 30 caractères aléatoires, spéciaux, étendus, etc….

sudo passwd robotuser

Je crée ensuite une clé ssh pour cet utilisateur. Comme je ne le fais pas logué depuis l’utilisateur en question, il faudra penser à changer le propriétaire, et les droits

sudo mkdir /home/robotuser/.ssh
sudo ssh-keygen -f /home/robotuser/.ssh/id_rsa -N ""
sudo chown robotuser:robotuser /home/robotuser -R
sudo chmod 700 /home/robotuser/.ssh
sudo chmod 600 /home/robotuser/.ssh/id_rsa
sudo chmod 600 /home/robotuser/.ssh/id_rsa.pub

Nous avons donc maintenant un utilisateur robotuser qui fait partie du groupe sshusers et qui a une clé privée et une clé publique.

Scripts de création des fichiers de zones

Nous pouvons maintenant faire un script que l’utilisateur en question pourra exécuter pour récupérer la liste des zones sur le serveur plesk. Pour l’exemple, j’utiliserai 192.168.1.1 comme IP de mon serveur plesk, et 192.168.1.2 comme IP de mon serveur DNS secondaire.

Commençons par créer un dossier scripts dans /home/robotuser

sudo mkdir /home/robotuser/scripts

Dans ce dossier, nous allons créer le script qui va récupérer la liste des domaines de named.conf.

Nous y mettons les commandes suivantes. Ce script va lire le fichier named.conf et en tirer tous les noms de zones existants, et créer un fichier contenant cette liste. On va ensuite modifier le propriétaire car, comme on va le voir ci-dessous, on va l’exécuter avec sudo, et il sera donc créé en tant que root.

#!/bin/sh
#
for domain in `/bin/grep ^zone /etc/named.conf | grep -v '"."' | grep -vi in-addr | /bin/awk '{print $2}'| /bin/awk -F\" '{print $2}'`
 
do
/usr/bin/printf "zone \"${domain}\" {\n\ttype slave;\n\tfile \"slaves/${domain}.db\";\n\tmasters { 192.168.1.1; };\n};\n"
done > /robotuser/scripts/monserveur.zones
 
chown robotuser:robotuser /home/robotuser/scripts/monserveur.zones

On donne les droits d’exécution à robotuser pour ce fichier après avoir changer le propriétaire:

sudo chown robotuser:robotuser /home/robotuser/scripts/generatezones.sh
sudo chmod +x /home/robotuser/scripts/generatezones.sh

Comme named.conf n’est pas accessible, nous allons autoriser robotuser à utiliser sudo pour exécuter le script. Pour ce faire, on édite sudoers et on ajoute la commande nécessaire.

On ajoute donc à la fin de sudoers:

robotuser monserveur = NOPASSWD: /home/robotuser/scripts/generatezones.sh

On commente également la ligne Defaults requireTTY sinon cron ne pourra pas utiliser sudo.

On peut maintenant tester le script. On se logue avec l’utilsateur robotuser, et on exécute le script:

su robotuser
sudo /home/robotuser/scripts/generatezones.sh

Pour vérifier si ça a marché, d’abord, on ne doit avoir aucun message d’erreur sur la console, bien sûr. Ensuite, on peut lister le dossier /home/robotuser/scripts, et on doit avoir ceci:

[monserveur scripts]$ ls -lshtr 
4.0K -rwx------. 1 robotuser robotuser 410 Nov 12 15:58 generatezones.sh
4.0K -rw-r--r--. 1 robotuser robotuser 282 Nov 12 15:58 monserveur.zones

Ensuite, on peut vérifier le contenu du fichier monserveur.zones. Ca doit ressembler à ça.

[monserveur scripts]$ cat monserveur.zones
zone "domain1.com" {
        type slave;
        file "/etc/named/slaves/domain3.com.db";
        masters { 192.168.1.1; };
};
zone "domain3.com" {
        type slave;
        file "/etc/named/slaves/domain3.com.db";
        masters { 192.168.1.1; };
};
zone "domain3.com" {
        type slave;
        file "/etc/named/slaves/domain3.com.db";
        masters { 192.168.1.1; };
};
zone "domain3.com" {
        type slave;
        file "/etc/named/slaves/domain3.com.db";
        masters { 192.168.1.1; };
};

Envoi du fichier de zone vers le serveur secondaire

Pour continuer on ressort du contexte de l’utilisateur robotuser, pour revenir à notre utilisateur de base et on recommence a utiliser sudo comme un grand.

On a maintenant un fichier de zone prêt à être transféré vers le serveur secondaire. On va ajouter à notre script une commande scp pour l’envoyer sur le serveur secondaire. On se prend pas la tête, on le met dans le dossier /home/robotuser. Il suffit donc d’ajouter la bonne commande dans le script generatezones.sh. On va utiliser su. Car comme on a utilisé sudo pour lancer le script, il est exécuté en tant que root, mais on veut exécuter le scp en tant que robotuser.

Donc on édite à nouveau generatezones.sh

sudo nano /home/robotuser/scripts/generatezones.sh

et on ajoute:

su robotuser -C 'scp /home/robotuser/scripts/monserveur.zones 192.168.1.2:'

Avant de tester le script, il faut mettre la clé publique dans le fichier authorized_keys de l’utilisateur robotuser sur le serveur secondaire. Il faut donc créer l’utilisateur et tout le tintoin. Je la refais pas. Les instructions sont plus hautes. On prend les mêmes et on recommence. Création de l’utilisateur, création du dossier .ssh, et là on crée un fichier authorized_keys dans lequel on copie la clé public, sans oublié à la fin de mettre toutes les permissions au bon niveau, sans oublier bien sûr de changer le propriétaire. Entre mon article sur la sécurisation et celui-là, vous devriez vous en sortir.

Une fois donc l’utilisateur créé et la clé mise en place, on peut tester les script. Pour ce faire, on tape la commande suivante, et on aura besoin du mot de passe robotuser. C’est normalement les deux uniques fois (ci-dessus et ici) qu’on utilisera ce mot de passe:

su robotuser
sudo /home/robotuser/scripts/generatezones.sh

On a vérifié que ça marche ? reste plus qu’à mettre ça dans crontab pour l’utilisateur robotuser:

sudo crontab -u robotuser -e

On va exécuter le script tous les quart d’heure précis:

0,15,30,45 * * * * sudo /home/robotuser/scripts/generatezones.sh

Après 30 à 40 minutes, on peut vérifier dans /var/log/cron que notre script est bien exécuté.

Si vous avez plusieurs serveurs plesk, on fait la même chose sur chaque serveur, et ils vont tous envoyer leur fichier de zone à la meme heure. Si vraiment c’est nécessaire, on peut toujours décaler un peu les heures, des fois que vous ayez des milliers de zones. Mais on va s’arranger pour ne pas dépasser H moins 4 minutes. Parce qu’on fera la seconde partie à 05, 20, 35, et 50.

Sur le serveur de noms secondaire

On va créer un script qui va déplacer les fichiers de zones reçus dans /home/robotuser/ dans le dossier /etc/named/servers (c’est mon choix. Faites le vôtre). Ce script va devoir également changer le propriétaire pour mettre bind

A noter que j’ai chrooté bind en suivant l’article suivant: http://bachem.wordpress.com/2012/04/14/setup-dns-server-bind-chroot-centos-6-2/ Je me base donc là dessus pour le reste de cet article.

Retour donc au serveur secondeaire pour créer ce script.

On crée les dossiers /var/named/chroot/etc/named/servers et /var/named/chroot/etc/named/slaves pour accueillir les fichiers et change le owner à bind:

sudo mkdir /var/named/chroot/etc/named/servers
sudo mkdir /var/named/chroot/etc/named/slaves
sudo chown named:named /var/named/chroot/etc/named/servers
sudo chown named:named /var/named/chroot/etc/named/slaves

On crée le dossier /home/robotuser/scripts pour rester cohérent et on y crée directement le script, comme ça on s’évite une double commande chown:

sudo mkdir /home/robotuser/scripts
sudo touch /home/robotuser/scripts/fetchzones.sh
sudo chmod 700 /home/robotuser/scripts/fetchzones.sh
sudo chown robotuser:robotuser /home/robotuser/scripts -R

On édite ensuite le script:

sudo nano /home/robotuser/scripts/fetchzones.sh

et on met en place les commandes pour déplacer les fichiers dans l’environnement chrooté de bind. Ce script va également créer un fichier foreign.zones dans /var/named/chroot/etc/named/ à inclure dans le fichiers /var/named/chroot/etc/named.conf. Ceci va permettre d’ajouter des nouveaux serveurs masters sans avoir à ajouter un include manuellement dans named.conf pour chaque nouveau serveur.

#!/bin/sh
 
mv /home/robotuser/*.zones /var/named/chroot/etc/named/servers/
chown named:named /var/named/chroot/etc/named/servers -R
 
rm /var/named/chroot/etc/named/foreign.zones
touch /var/named/chroot/etc/named/foreign.zones
 
cd /var/named/chroot/etc/named/servers
for file in `ls`
    do echo "include \"/etc/named/servers/$file\";" >> /var/named/chroot/etc/named/foreign.zones
done
 
chown named:named /var/named/chroot/etc/named/foreign.zones
 
service named reload

Reste a mettre un include dans le fichier /var/named/chroot/etc/named.conf

include="/etc/named/foreign.zones";

On va de nouveau utiliser sudo pour exécuter le script. On ajoute donc à sudoers la ligne adéquate:

robotuser monserveur = NOPASSWD: /home/robotuser/scripts/fetchzones.sh

et on commente également la ligne Defaults requireTTY sinon cron ne pourra pas utiliser sudo.

On insère le job dans crontab

sudo crontab -u robotuser -e

5,20,35,50 * * * * sudo /home/robotuser/scripts/fetchzones.sh

Le tour est joué. Reste plus qu’à tester comme avant… Et espérer que ça marche… Je passe sur les tests nslookup etc… Je ferai ça quand ça aura commencer à copier les zones. Pour l’instant, ça démarre.

Source: http://forum.parallels.com/pda/index.php/t-258488.html