{"id":812,"date":"2012-11-12T22:04:58","date_gmt":"2012-11-12T21:04:58","guid":{"rendered":"https:\/\/akim.sissaoui.com\/?p=812"},"modified":"2015-09-02T15:48:05","modified_gmt":"2015-09-02T13:48:05","slug":"dns-secondaire-pour-plusieurs-serveurs-plesk","status":"publish","type":"post","link":"https:\/\/akim.sissaoui.com\/en\/informatique\/dns-secondaire-pour-plusieurs-serveurs-plesk\/","title":{"rendered":"DNS secondaire pour plusieurs serveurs plesk"},"content":{"rendered":"

Je m’attaque \u00e0 la cr\u00e9ation d’un serveur DNS secondaire pour mes serveurs plesk. En effet, je vais en avoir plusieurs. Je me base sur l’article cit\u00e9 ci-dessous en source. Mais je vais l’adapter \u00e0 ma sauce. En effet, je ne veux pas avoir \u00e0 maintenir un site web pour faire transiter les fichiers de zones. Je vais donc me servir de ssh pour transf\u00e9rer les fichiers.<\/p>\n


\n
\n== Sur les serveurs plesk ==<\/p>\n

Les op\u00e9rations suivantes peuvent \u00eatre faites sur tous les serveurs plesk.<\/p>\n

Avant de commencer, faites une copie de s\u00e9curit\u00e9 du fichier \/etc\/named.conf. On est jamais trop prudent.<\/p>\n

=== Cr\u00e9ation d’un utilisateur pour les op\u00e9rations automatiques ===<\/p>\n

D’abord, pour tout ce qui est automatique, je cr\u00e9e un nouvel utilisateur. Par exemple “robotuser”, et, pour rester coh\u00e9rent avec mon article sur la s\u00e9curisation d’un serveur<\/a>, je l’ajoute au groupe sshusers. J’utilise sudo, toujours en accord avec l’article en question.<\/p>\n

sudo usermod -G sshusers robotuser<\/pre>\n
Je lui g\u00e9n\u00e8re un mot de passe tr\u00e8s complexe. Dans mon cas, un g\u00e9n\u00e9rateur me donne un mot de passe de 30 caract\u00e8res al\u00e9atoires, sp\u00e9ciaux, \u00e9tendus, etc….<\/p>\n
sudo passwd robotuser<\/pre>\n
Je cr\u00e9e ensuite une cl\u00e9 ssh pour cet utilisateur. Comme je ne le fais pas logu\u00e9 depuis l’utilisateur en question, il faudra penser \u00e0 changer le propri\u00e9taire, et les droits<\/p>\n
sudo mkdir \/home\/robotuser\/.ssh\r\nsudo ssh-keygen -f \/home\/robotuser\/.ssh\/id_rsa -N \"\"\r\nsudo chown robotuser:robotuser \/home\/robotuser -R\r\nsudo chmod 700 \/home\/robotuser\/.ssh\r\nsudo chmod 600 \/home\/robotuser\/.ssh\/id_rsa\r\nsudo chmod 600 \/home\/robotuser\/.ssh\/id_rsa.pub<\/pre>\n
Nous avons donc maintenant un utilisateur robotuser qui fait partie du groupe sshusers et qui a une cl\u00e9 priv\u00e9e et une cl\u00e9 publique.<\/p>\n
=== Scripts de cr\u00e9ation des fichiers de zones ===<\/p>\n
Nous pouvons maintenant faire un script que l’utilisateur en question pourra ex\u00e9cuter pour r\u00e9cup\u00e9rer 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.<\/p>\n
Commen\u00e7ons par cr\u00e9er un dossier scripts dans \/home\/robotuser<\/p>\n
sudo mkdir \/home\/robotuser\/scripts<\/pre>\n
Dans ce dossier, nous allons cr\u00e9er le script qui va r\u00e9cup\u00e9rer la liste des domaines de named.conf.<\/p>\n
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\u00e9er un fichier contenant cette liste. On va ensuite modifier le propri\u00e9taire car, comme on va le voir ci-dessous, on va l’ex\u00e9cuter avec sudo, et il sera donc cr\u00e9\u00e9 en tant que root.<\/p>\n
#!\/bin\/sh\r\n#\r\nfor domain in `\/bin\/grep ^zone \/etc\/named.conf | grep -v '\".\"' | grep -vi in-addr | \/bin\/awk '{print $2}'| \/bin\/awk -F\\\" '{print $2}'`\r\n\r\ndo\r\n\/usr\/bin\/printf \"zone \\\"${domain}\\\" {\\n\\ttype slave;\\n\\tfile \\\"slaves\/${domain}.db\\\";\\n\\tmasters { 192.168.1.1; };\\n};\\n\"\r\ndone > \/robotuser\/scripts\/monserveur.zones\r\n\r\nchown robotuser:robotuser \/home\/robotuser\/scripts\/monserveur.zones<\/pre>\n
On donne les droits d’ex\u00e9cution \u00e0 robotuser pour ce fichier apr\u00e8s avoir changer le propri\u00e9taire:<\/p>\n
sudo chown robotuser:robotuser \/home\/robotuser\/scripts\/generatezones.sh\r\nsudo chmod +x \/home\/robotuser\/scripts\/generatezones.sh<\/pre>\n
Comme named.conf n’est pas accessible, nous allons autoriser robotuser \u00e0 utiliser sudo pour ex\u00e9cuter le script. Pour ce faire, on \u00e9dite sudoers et on ajoute la commande n\u00e9cessaire.<\/p>\n
On ajoute donc \u00e0 la fin de sudoers:<\/p>\n
robotuser monserveur = NOPASSWD: \/home\/robotuser\/scripts\/generatezones.sh<\/pre>\n
On commente \u00e9galement la ligne Defaults requireTTY sinon cron ne pourra pas utiliser sudo.<\/p>\n
On peut maintenant tester le script. On se logue avec l’utilsateur robotuser, et on ex\u00e9cute le script:<\/p>\n
su robotuser\r\nsudo \/home\/robotuser\/scripts\/generatezones.sh<\/pre>\n
Pour v\u00e9rifier si \u00e7a a march\u00e9, d’abord, on ne doit avoir aucun message d’erreur sur la console, bien s\u00fbr. Ensuite, on peut lister le dossier \/home\/robotuser\/scripts, et on doit avoir ceci:<\/p>\n
[monserveur scripts]$ ls -lshtr \r\n4.0K -rwx------. 1 robotuser robotuser 410 Nov 12 15:58 generatezones.sh\r\n4.0K -rw-r--r--. 1 robotuser robotuser 282 Nov 12 15:58 monserveur.zones<\/pre>\n
Ensuite, on peut v\u00e9rifier le contenu du fichier monserveur.zones. Ca doit ressembler \u00e0 \u00e7a.<\/p>\n
[monserveur scripts]$ cat monserveur.zones\r\nzone \"domain1.com\" {\r\n        type slave;\r\n        file \"\/etc\/named\/slaves\/domain3.com.db\";\r\n        masters { 192.168.1.1; };\r\n};\r\nzone \"domain3.com\" {\r\n        type slave;\r\n        file \"\/etc\/named\/slaves\/domain3.com.db\";\r\n        masters { 192.168.1.1; };\r\n};\r\nzone \"domain3.com\" {\r\n        type slave;\r\n        file \"\/etc\/named\/slaves\/domain3.com.db\";\r\n        masters { 192.168.1.1; };\r\n};\r\nzone \"domain3.com\" {\r\n        type slave;\r\n        file \"\/etc\/named\/slaves\/domain3.com.db\";\r\n        masters { 192.168.1.1; };\r\n};<\/pre>\n
=== Envoi du fichier de zone vers le serveur secondaire ===<\/p>\n
Pour continuer on ressort du contexte de l’utilisateur robotuser, pour revenir \u00e0 notre utilisateur de base et on recommence a utiliser sudo comme un grand.<\/p>\n
On a maintenant un fichier de zone pr\u00eat \u00e0 \u00eatre transf\u00e9r\u00e9 vers le serveur secondaire. On va ajouter \u00e0 notre script une commande scp pour l’envoyer sur le serveur secondaire. On se prend pas la t\u00eate, 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\u00e9 sudo pour lancer le script, il est ex\u00e9cut\u00e9 en tant que root, mais on veut ex\u00e9cuter le scp en tant que robotuser.<\/p>\n
Donc on \u00e9dite \u00e0 nouveau generatezones.sh<\/p>\n
sudo nano \/home\/robotuser\/scripts\/generatezones.sh<\/pre>\n
et on ajoute:<\/p>\n
su robotuser -C 'scp \/home\/robotuser\/scripts\/monserveur.zones 192.168.1.2:'<\/pre>\n
Avant de tester le script, il faut mettre la cl\u00e9 publique dans le fichier authorized_keys de l’utilisateur robotuser sur le serveur secondaire. Il faut donc cr\u00e9er l’utilisateur et tout le tintoin. Je la refais pas. Les instructions sont plus hautes. On prend les m\u00eames et on recommence. Cr\u00e9ation de l’utilisateur, cr\u00e9ation du dossier .ssh, et l\u00e0 on cr\u00e9e un fichier authorized_keys dans lequel on copie la cl\u00e9 public, sans oubli\u00e9 \u00e0 la fin de mettre toutes les permissions au bon niveau, sans oublier bien s\u00fbr de changer le propri\u00e9taire. Entre mon article sur la s\u00e9curisation et celui-l\u00e0, vous devriez vous en sortir.<\/p>\n
Une fois donc l’utilisateur cr\u00e9\u00e9 et la cl\u00e9 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:<\/p>\n
su robotuser\r\nsudo \/home\/robotuser\/scripts\/generatezones.sh<\/pre>\n
On a v\u00e9rifi\u00e9 que \u00e7a marche ? reste plus qu’\u00e0 mettre \u00e7a dans crontab pour l’utilisateur robotuser:<\/p>\n
sudo crontab -u robotuser -e<\/pre>\n
On va ex\u00e9cuter le script tous les quart d’heure pr\u00e9cis:<\/p>\n
0,15,30,45 * * * * sudo \/home\/robotuser\/scripts\/generatezones.sh<\/pre>\n
Apr\u00e8s 30 \u00e0 40 minutes, on peut v\u00e9rifier dans \/var\/log\/cron que notre script est bien ex\u00e9cut\u00e9.<\/p>\n
Si vous avez plusieurs serveurs plesk, on fait la m\u00eame chose sur chaque serveur, et ils vont tous envoyer leur fichier de zone \u00e0 la meme heure. Si vraiment c’est n\u00e9cessaire, on peut toujours d\u00e9caler un peu les heures, des fois que vous ayez des milliers de zones. Mais on va s’arranger pour ne pas d\u00e9passer H moins 4 minutes. Parce qu’on fera la seconde partie \u00e0 05, 20, 35, et 50.<\/p>\n
== Sur le serveur de noms secondaire ==<\/p>\n
On va cr\u00e9er un script qui va d\u00e9placer les fichiers de zones re\u00e7us dans \/home\/robotuser\/ dans le dossier \/etc\/named\/servers (c’est mon choix. Faites le v\u00f4tre). Ce script va devoir \u00e9galement changer le propri\u00e9taire pour mettre bind<\/p>\n
A noter que j’ai chroot\u00e9 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\u00e0 dessus pour le reste de cet article.<\/p>\n
Retour donc au serveur secondeaire pour cr\u00e9er ce script.<\/p>\n
On cr\u00e9e les dossiers \/var\/named\/chroot\/etc\/named\/servers et \/var\/named\/chroot\/etc\/named\/slaves pour accueillir les fichiers et change le owner \u00e0 bind:<\/p>\n
sudo mkdir \/var\/named\/chroot\/etc\/named\/servers\r\nsudo mkdir \/var\/named\/chroot\/etc\/named\/slaves\r\nsudo chown named:named \/var\/named\/chroot\/etc\/named\/servers\r\nsudo chown named:named \/var\/named\/chroot\/etc\/named\/slaves<\/pre>\n
On cr\u00e9e le dossier \/home\/robotuser\/scripts pour rester coh\u00e9rent et on y cr\u00e9e directement le script, comme \u00e7a on s’\u00e9vite une double commande chown:<\/p>\n
sudo mkdir \/home\/robotuser\/scripts\r\nsudo touch \/home\/robotuser\/scripts\/fetchzones.sh\r\nsudo chmod 700 \/home\/robotuser\/scripts\/fetchzones.sh\r\nsudo chown robotuser:robotuser \/home\/robotuser\/scripts -R<\/pre>\n
On \u00e9dite ensuite le script:<\/p>\n
sudo nano \/home\/robotuser\/scripts\/fetchzones.sh<\/pre>\n
et on met en place les commandes pour d\u00e9placer les fichiers dans l’environnement chroot\u00e9 de bind. Ce script va \u00e9galement cr\u00e9er un fichier foreign.zones dans \/var\/named\/chroot\/etc\/named\/ \u00e0 inclure dans le fichiers \/var\/named\/chroot\/etc\/named.conf. Ceci va permettre d’ajouter des nouveaux serveurs masters sans avoir \u00e0 ajouter un include manuellement dans named.conf pour chaque nouveau serveur.<\/p>\n
#!\/bin\/sh\r\n\r\nmv \/home\/robotuser\/*.zones \/var\/named\/chroot\/etc\/named\/servers\/\r\nchown named:named \/var\/named\/chroot\/etc\/named\/servers -R\r\n\r\nrm \/var\/named\/chroot\/etc\/named\/foreign.zones\r\ntouch \/var\/named\/chroot\/etc\/named\/foreign.zones\r\n\r\ncd \/var\/named\/chroot\/etc\/named\/servers\r\nfor file in `ls`\r\n    do echo \"include \\\"\/etc\/named\/servers\/$file\\\";\" >> \/var\/named\/chroot\/etc\/named\/foreign.zones\r\ndone\r\n\r\nchown named:named \/var\/named\/chroot\/etc\/named\/foreign.zones\r\n\r\nservice named reload<\/pre>\n
Reste a mettre un include dans le fichier \/var\/named\/chroot\/etc\/named.conf<\/p>\n
include=\"\/etc\/named\/foreign.zones\";<\/pre>\n
On va de nouveau utiliser sudo pour ex\u00e9cuter le script. On ajoute donc \u00e0 sudoers la ligne ad\u00e9quate:<\/p>\n
robotuser monserveur = NOPASSWD: \/home\/robotuser\/scripts\/fetchzones.sh<\/pre>\n
et on commente \u00e9galement la ligne Defaults requireTTY sinon cron ne pourra pas utiliser sudo.<\/p>\n
On ins\u00e8re le job dans crontab<\/p>\n
sudo crontab -u robotuser -e<\/pre>\n
5,20,35,50 * * * * sudo \/home\/robotuser\/scripts\/fetchzones.sh<\/pre>\n
Le tour est jou\u00e9. Reste plus qu’\u00e0 tester comme avant… Et esp\u00e9rer que \u00e7a marche… Je passe sur les tests nslookup etc… Je ferai \u00e7a quand \u00e7a aura commencer \u00e0 copier les zones. Pour l’instant, \u00e7a d\u00e9marre.<\/p>\n
Source: http:\/\/forum.parallels.com\/pda\/index.php\/t-258488.html<\/p>\n","protected":false},"excerpt":{"rendered":"
Je m’attaque \u00e0 la cr\u00e9ation d’un serveur DNS secondaire pour mes serveurs plesk. En effet, je vais en avoir plusieurs. Je me base sur l’article cit\u00e9 ci-dessous en source. Mais je vais l’adapter \u00e0 ma sauce. En effet, je ne veux pas avoir \u00e0 maintenir un site web pour faire transiter les fichiers de zones. […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[220],"tags":[190,191,63,100],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts\/812"}],"collection":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/comments?post=812"}],"version-history":[{"count":10,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts\/812\/revisions"}],"predecessor-version":[{"id":988,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/posts\/812\/revisions\/988"}],"wp:attachment":[{"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/media?parent=812"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/categories?post=812"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/akim.sissaoui.com\/en\/wp-json\/wp\/v2\/tags?post=812"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}