Mise en place d'un serveur DNS
Qu'est-ce que le DNS
Le service DNS sert à attribuer un nom à une adresse IP. Concrètement, grâce au service DNS (par exemple pour venir sur ce Wiki), nous pouvons simplement y mettre un nom de domaine (donc wiki.support-vtx.ch) et non l'adresse IP du serveur où le wiki est hébergé, car il est plus aisé de se rappeler d'un nom que d'une suite de chiffre. D'autant plus que maintenant il est assez rare de voir un serveur n'héberger qu'un seul site web. Si nous mettons l'adresse IP dans la barre URL du navigateur, celui-ci ne saura pas quel site web afficher s'il y a plusieurs "hosts" sur le serveur.
Les domaines
Un domaine est un nom que nous réservons auprès d'un registrar. Une fois enregistré, nous avons aussi une zone DNS qui nous est fournie avec afin de pouvoir gérer les différents enregistrements de ce dernier.
Un nom de domaine est composé de plusieurs parties. En premier, il y a le Top Level Domain (TLD), ce sont les .ch, .com, .net, etc. que nous retrouvons à la fin dans nom. Ensuite, il y a le second niveau qui est le nom que nous avons choisi, par exemple google, support-vtx, etc.
Ceci est la base, mais nous pouvons trouver également comme pour le wiki un sous-domaine que nous créons au domaine qui est par exemple dans notre cas, wiki.support-vtx.ch.
Enregistrement
Il existe plusieurs types d'enregistrement pour les différents services, notamment :
- A : fait correspondre un nom domaine à une adresse IPv4 ;
- AAAA : fait correspondre un nom domaine à une adresse IPv6 ;
- CNAME : permet de faire un alias sur un nom d'une machine pour avoir plusieurs noms alternatifs pour une machine faisant plusieurs services ;
- MX : indique le serveur de mails pour le nom de domaine ;
- PTR : fait correspondre une adresse IPv4/IPv6 à un nom de domaine ;
- SOA : indique le serveur de nom maître (primaire) ;
- NS : indique les serveurs DNS responsable de la zone DNS.
Résolution
Par exemple, si on souhaite accéder au site internet de support-vtx.ch, nous allons faire une requête DNS qui va être envoyé au resolver de votre fournisseur d'accès internet pour avoir l'enregistrement A du site en question.
- En premier temps, le resolver va recevoir la requête DNS pour l'enregistrement A du site internet support-vtx.ch. S'il ne l'a pas dans son cache, il va aller interroger les serveurs DNS racine.
- Ensuite, les serveurs racine vont répondre qu'ils ne connaissent pas l'adresse IP du serveur web du domaine en question, mais par contre il connaissent les serveurs DNS qui s'occupent de tous les domaines avec le TLD .ch. Ils vont donc répondre en donnant leurs FQDN + IP.
- Maintenant que le resolver connait l'IP des serveurs DNS du TLD .ch, il va les interroger en demandant l'adresse IP du serveur web du domaine à nouveau.
- Les serveurs DNS du TLD .ch ne connaissent pas l'IP de ce dernier. Par contre, ils connaissent les NS qui gèrent le domaine. Ils fournissent donc au resolver le FQDN + IP.
- Pour terminer, le resolver a maintenant l'IP des NS qui s'occupent de la zone DNS du domaine support-vtx.ch. Il va leurs demander quel est l'enregistrement A pour ce nom de domaine et ils vont répondre avec l'adresse IP.
Cette fois-ci, voici un autre exemple avec un nom de domaine qui a comme TLD .me mais qui est géré par les serveurs DNS VTX qui sont avec le TLD .ch. Pareil que l'autre exemple, si on souhaite accéder au site internet de stajic.me, une requête DNS va être envoyée au resolver du fournisseur d'accès internet que vous avez pour avoir l'enregistrement A du site en question.
- Dans un premier temps, le resolver va demander au serveur racine quelle est l'adresse IP du site internet de stajic.me s'il ne l'a pas dans son cache.
- Le serveur racine va répondre qu'il ne sait pas, par contre il connait les serveurs DNS du TLD .me qui s'occupe de tous les domaines avec ce TLD. Il va donc donner au resolver le FQDN + IP.
- Ensuite, le resolver va interroger les serveurs DNS du TLD .me pour connaître l'adresse IP du serveur web du site internet.
- Les serveurs DNS vont répondre qu'ils ne savent pas. Par contre, ils vont donner uniquement le FQDN des NS qui gèrent la zone DNS.
- Le resolver va retourner vers les serveurs racines et va demander l'adresse IP des serveurs NS de VTX en leur fournissant le FQDN qu'il a reçu.
- Ils vont répondre qu'ils ne savent pas, par contre, ils donnent le FQDN + IP des serveurs DNS du TLD .ch.
- Cette fois-ci, le resolver va demander l'adresse IP des NS de VTX aux serveurs DNS du TLD .ch.
- Ils vont fournir l'adresse IP des NS au resolver.
- Pour terminer, le resolver va interroger les NS de VTX et va demander l'enregistrement A du nom de domaine stajic.me, ils vont répondre en donnant l'adresse IP.
Délégation
La délégation DNS ce fait tout le long d'une résolution DNS, par exemple, lorsque on interroge les serveurs racines, ils ne vont pas avoir la réponse mais vont nous donner l'IP du serveur TLD du nom de domaine, donc, il délègue.
Pour la création d'un sous-domaine, c'est le même principe. 1. Nous allons crée dans la zone DNS de support-vtx.ch un enregistrement de type NS pour wiki.support-vtx.ch vers les NS en question.
Ensuite, nous allons ajouter un enregistrement A des NS en question vers l'adresse IP du serveur où ils ce trouvent.
Whois vs Dig
Les commandes Whois et Dig sont utilisés pour but d'interroger des noms de domaine sur internet afin d'avoir des informations sur ce dernier.
La différence entre les deux, c'est que avec le Whois on aura principalement deux informations, les nameserver ainsi que le registrat.
Dig permet d'avoir des informations sur la zone DNS du nom de domaine, notamment les différents enregistrements.
Le problème, c'est que Dig permet aussi de savoir les NS d'un nom de domaine, sauf que ce n'est pas toujours la réalité.
La raison, c'est que comme dis plus haut, Dig permet d'avoir des informations sur la zone, donc si on fait un Dig NS on aura les enregistrements NS qui sont inscrit dans la zone. C'est uniquement une information et pas la réalité, car l'enregistrement peut être différent des glues-records.
Avec le Whois, on aura l'information officiel sur les NS, car il va chercher les glues-records directement.
Pour un sous-domaine, nous sommes obligés de faire un Dig pour connaître les NS, car il n'existe pas de glue-record pour eux.
Time to Live
Lors de l'ajout d'un enregistrement DNS, nous sommes obligés d'ajouter une valeur numérique, les TTL. Cette valeur permet d'indiquer aux serveurs DNS qui font la requête combien de temps ils doivent garder l'information de l'entrée dans leur cache avant de le supprimer.
Par exemple, lorsqu'un resolver va faire les requêtes pour connaître l'entrée MX d'un nom de domaine, il va recevoir l'information avec une valeur numérique, donc les TTL (86 400 secondes généralement, soit 24h).
Donc, à partir de là, si un autre utilisateur fait la même requête auprès du même resolver, il va lui donner l'information qu'il a récupérée du serveur MX qu'il a dans son cache, sans aller vérifier si l'enregistrement est toujours d'actualité. La prochaine fois qu'il va aller revérifier, c'est dès que le TTL expire et que quelqu'un refait la requête.
Serveur DNS vs Resolver
Il existe deux types de serveur DNS : les serveurs itératifs et les récursifs.
La différence entre les deux, c'est que le serveur récursif ira faire les requêtes nécessaires pour pouvoir avoir la réponse de la demande initiale. Le serveur itératif, lui, n'ira pas interroger les autres serveurs DNS. Il va simplement répondre avec ce qu'il sait déjà.
Par exemple, un serveur racine qui reçoit une requête pour un domaine ne va pas avoir les informations pour ce dernier. Mais, par contre, il connait les serveurs DNS du TLD du domaine en question. Il va donc répondre en donnant uniquement cette information. Pourquoi ? Tout simplement parce que ce serveur est un serveur itératif et non récursif.
Un serveur resolver (récursif) lui va aller interroger les différents serveurs afin d'avoir les informations du nom de domaine demandé.
Dans le monde, nous avons des resolvers comme ceux de Cloudfare (1.1.1.1, 1.0.0.1) ou par exemple ceux de Google (8.8.8.8, 8.8.4.4).
Protocole
Par défaut, le service DNS utilise le protocole UDP. Mais il ce peut que si le paquet dépasse 512 octets, il passe sur le protocole TCP.
La raison de pourquoi l'UDP est le protocole principale est parce qu'il y a moins de sécurité, ce qui permet d'aller plus vite dans les requêtes car il y a pas l'aspect de vérification et autres.
Informations
Voici le matériel à disposition pour ce projet :
- Un serveur Dell R610 avec un ESXi VMware
Le serveur est à utiliser avec le Sonicwall TZ300, son IP local est réservée par adresse MAC : 172.16.0.6, une règle NAT existe pour se connecter dessus depuis le réseau VTX : https://virt.support-vtx.ch:1338
Machine virtuelle
- Système d'exploitation utilisé : Debian 10.10
Pour ce projet, nous allons utiliser 1 VMs :
- SRV-DEB-003 (BIND) : 172.16.0.9;
- SRV-DEB-002 (PowerDNS) : 172.16.0.8;
Enregistrement
- Pour crée votre machine virtuelle, cliquez sur Crée/Enregistrer une machine virtuelle dans l'onglet Machine virtuelle.
- Ensuite, faites Crée une machine virtuelle.
- Rentrer un Nom pour votre machine et sélectionner la Compatibilité, Famille de systèmes d'exploitation invités et Version du SE invité.
- Configurer ensuite votre machine avec les paramètres suivants :
- Modifier le Lecteur de CD/DVD en mettant le fichier ISO de votre OS.
- Une fois que c'est, faites Terminer.
Configuration
- Une fois l'enregistrement de votre VM terminé, exécuté-la.
- Dans un premier temps, faites une installation sans l'interface graphique. Cliquez donc sur Install.
- Sélectionner votre langue.
- Ensuite, sélectionner votre localisation.
- Europe\Switzerland
- Configurer ensuite le langage de votre clavier.
- Rentrer un mot de passe pour l'utilisateur root (admin).
- Choisissiez un nom d'utilisateur pour l'utilisateur simple.
- Rentrer également un mot de passe pour cette utilisateur.
- Sélectionner la méthode de partition.
- Sélectionner ensuite le disque pour la partition.
- Mettez tout les fichiers dans la même partition.
- Appliquer ensuite le partitionnement sur les disques.
- Sélectionner l'archive miroir.
- Choisissiez ensuite les logiciels de base.
- Désélectionner ensuite tout sauf la dernière option.
- Installer le GRUB boot loader.
- Une fois installer, vous allez pouvoir vous s'authentifier sur votre machine virtuelle.
- Une adresse IP a été assigner sur mes VMs depuis le Sonicwall.
Snapshot
- Un snapshot est unique par VM. Aussi, l'adresse IP attribué par le Sonicwall va resté car il ce base sur l'adresse MAC.
- Faites un clic droit sur la VM concerné puis sous Snapshots, faites Prendre un snapshot.
- Ensuite, pour restaurer le snapshot, faites clic droit sur la VM puis Restaurer.
Secure Shell
Pour faciliter le travail, nous allons activer le SSH. Sur le firewall, le port 1339 correspond à SRV-DEB-001, 1340 à SRV-DEB-002 et 1341 à SRV-DEB-003. La règle à été mise en place sur le firewall.
- Dans un premier temps installez le package SSH sur la VM.
apt-get install openssh-server
- Une fois installer, il faudra mettre à jour le port sur le fichier de configuration de votre SSH par rapport à ce qui a été appliquer sur le firewall.
nano /etc/ssh/sshd_config
- Ensuite, dès que vous êtes dans le fichier, vous pouvez retirer le commentaire (#) et mettre le port en question. Si vous souhaitez utiliser l'utilisateur root pour le SSH, il faudra faire pareil pour PermitRootLogin.
- Pour appliquer les modifications, il faudra simplement redémarrer le service.
/etc/init.d/ssh reload
- Vous pouvez vérifier si le port à bien été modifié.
systemctl status ssh
- Maintenant que tout est prêt, vous pouvez lancer votre logiciel d'émulateur de terminal. Dans mon cas, j'utilise PuTTY.
- Host Name : Ici, j'ai mis l'adresse du firewall, mais nous aurions très bien pu mettre également virt.support-vtx.ch qui est l'adresse du serveur où sont les VMs ;
- Port : Le port SSH que nous avons mis par rapport à la VM qu'on souhaite accéder ;
- Connexion type : SSH.
Capture de paquet
Pour mieux comprendre ce qui transite sur les VMs, on peut utiliser tcpdump et ensuite récupérer le fichier .pcap et l'ouvrir sur Wireshark pour voir les paquets.
Il est important de faire ces commandes directement sur l'interface de ESXi et non en SSH.
- Dans un premier temps, nous allons installer le package tcpdump.
apt-get install tcpdump
- Ensuite, nous allons lancez une capture de paquet et accéder au site au même temps. Il est important de nommer le fichier .pcap.
tcpdump -w capture-wiki.pcap
- Après avoir fait la capture de paquet, vous pouvez faire CTRL+C pour arrêter. La capture sera stocké à l'endroit ou vous avez lancer le tcpdump.
ls
- Pour récupérer la capture que vous avez fait, il faudra utiliser un client SFTP pour vous connectez sur la VM et accéder aux fichiers. Dans mon cas, j'utilise WinSCP.
Une fois connecté, vous allez pouvoir récupérer le fichier .pcap et l'ouvrir sur Wireshark.
Bind 9
Berkeley Internet Name Domain (BIND) 9 (version) est un service DNS open source les plus utilisés dans le monde. Le service est tenu à jour, la dernière version 9.18.1 date de mars 2022.
L’avantage avec ce dernier c'est le faite qu'il soit complet, stable et le fait qu’il soit beaucoup utilisé fait que nous avons énormément d’information à ce sujet (documentation).
Aussi, nous pouvons l'utiliser comme simple serveur DNS mais aussi le configurer pour faire resolver DNS. Aussi, il propose la sécurité DNSSEC.
Les inconvenants c’est que BIND n’a pas d’API pour l’automatisation des zones DNS (configuration), nous sommes obligés d’utiliser d’autres services afin de compléter.
Maintenant que notre VM est prête, que nous sommes connecté en SSH, nous allons installer notre serveur DNS (Bind9).
- Dans un premier temps, nous allons installer le package de Bind 9.
apt-get install bind9 -y
- Ensuite, vous pouvez vérifier si le service fonctionne correctement.
systemctl status bind9
- Il est aussi, il est important que le port 53 (port DNS) soit bien ouvert.
netstat -lnp
- Pour éviter des bugs, nous allons désactiver le port sur l'IPv6.
- Afin de désactiver, il faut ce rendre dans le répertoire /etc/bind puis ouvrir le fichier named.conf.options.
cd /etc/bind
- Ensuite, il suffit de passer la ligne listen-on-v6 any en none.
vi named.conf.options
- Afin de désactiver, il faut ce rendre dans le répertoire /etc/bind puis ouvrir le fichier named.conf.options.
- Pour appliquer vos modifications, il suffit de redémarrer le service.
systemctl restart bind9
Zone DNS
Notre serveur va être configuré comme serveur maître pour le domaine testdomaine.ch.
- En premier lieu, il faut indiquer dans /etc/bind/named.conf.local où ce trouve le fichier de la zone qui comporte tous les enregistrements et autres.
vi /etc/bind/named.conf.local
- Ensuite, il faudra crée dans le même répertoire le fichier indiqué dans named.conf.local, en l'occurrence db.testdomaine.ch.
vi /etc/bind/db.testdomaine.ch
- Voici la syntaxe pour un enregistrement de type NS :
@ IN NS ns.NAMESERVER. // ns IN A IPv4
- Voici la syntaxe pour un enregistrement de type A :
@ IN A IPv4
- Voici la syntaxe pour un enregistrement de type AAAA :
@ IN A IPv6
- Voici la syntaxe pour un enregistrement de type CNAME:
alias IN CNAME DOMAIN.
- Voici la syntaxe pour un enregistrement de type MX :
@ IN MX 10 SRV.
- Voici la syntaxe pour un enregistrement de type TXT :
@ IN TXT TEXT
- Le @ correspond automatiquement au nom de domaine, donc testdomaine.ch dans notre cas.
- On met le . à la fin du contenu afin d'éviter d'avoir testdomaine.ch qui s'ajoute dans l'entrée.
- Voici la syntaxe pour un enregistrement de type NS :
- Pour appliquer vos modifications, il suffit de redémarrer le service.
systemctl restart bind9
- Maintenant que notre zone DNS est crée, on peut la tester. Pour ce faire, il faudra installer un outil DNS.
apt-get install dnsutils
- Une fois l'outil installé, nous allons faire le test. Il est très important de spécifié qu'on souhaite faire la résolution avec l'adresse IP loopback.
dig testdomaine.ch @127.0.0.1
Sous-domaine
Notre sous-domaine sera test.testdomaine.ch et il sera crée sur la plateforme DNS de VTX et non sur une VM. Aussi, ce sous-domaine utilisera les NS ns01.vtx.ch et ns02.vtx.ch.
- Afin de le mettre en place, sachant qu'un sous-domaine n'a pas de glue record directement attribué, nous allons inscrire dans la configuration de testdomaine.ch que "test" correspond à ces NS.
- Pour appliquer vos modifications, il suffit de redémarrer le service.
systemctl restart bind9
- Ensuite, nous allons tester afin de voir si la résolution ce fait correctement.
dig ns test.testdomaine.ch @127.0.0.1
- 212.147.10.10 est l'adresse IP d'un des resolvers DNS de VTX. C'est le seul qui est autorisé dans la configuration de mon firewall.
Logs
Afin de résoudre les problèmes plus facilement lors de la mise en place du serveur DNS, nous allons mettre en place un système de log.
- Dans un premier temps, nous allons indiqué dans l'AppArmor où va ce trouver notre fichier de log pour le service Bind. Ici, nous allons simplement mettre dans /var/log/bind.
vi /etc/apparmor.d/usr.sbin.named
- Une fois la modification faites, il faudra redémarrer le service AppArmor.
systemctl restart apparmor
- Maintenant que nous avons autorisé dans AppArmor, nous allons le crée.
mkdir /var/log/bind
- Afin que Bind puisse écrire dedans, nous allons devoir donner le droit à l'utiliser et au groupe.
chown bind:bind /var/log/bind
- Pour terminer, nous allons mettre dans le fichier /etc/bind/named.conf.options quel logs nous souhaitons répertorier.
vi /etc/bind/named.conf.options
- Category permet de spécifier les données qu'ont souhaite log et Channel permet de spécifier où nous souhaitons les répertorier.
- Category permet de spécifier les données qu'ont souhaite log et Channel permet de spécifier où nous souhaitons les répertorier.
- Maintenant, il reste plus qu'à surveiller en regardant les logs en directe.
tail -f /var/log/bind/general
PowerDNS
Power DNS est un service DNS open source qui fonctionne comme une alternative à BIND. Le service est tenu à jour, la dernière date de mars 2022.
L’avantage avec ce dernier, en plus d’avoir certaines fonctionnalités comme BIND, c’est qu’il fournit une interface graphique, ce qui facilite la gestion des zones DNS. Il peut utiliser de nombreux backends comme base de données, LDAP, BIND … pour sauvegarder ces informations.
Ici, nous allons mettre en place un service PowerDNS et Poweradmin afin de pouvoir crée des zones DNS et pouvoir les gérer depuis une interface graphique.
Base de donnée (MariaDB)
- Nous allons installer dans un premier temps une base de donnée (MariaDB) qui servira pour stocker nos données.
apt-get install mariadb-server -y
- Afin de mettre une sécurité sur la base de donnée, il faudra définir un mot de passe et désactiver/activer certaines fonctionnalité.
mysql_secure_installation
- Change the root password? [Y/n]
- Remove anonymous users? [Y/n]
- Disallow root login remotely? [Y/n]
- Remove test database and access to it? [Y/n]
- Reload privilege tables now? [Y/n]
- Ensuite, nous allons supprimer les logs déjà existante de mysql.
rm -f /var/lib/mysql/ib_logfile*
- Maintenant, nous pouvons nous connecter à la base de donnée.
mysql -u root -p
- Une fois connecté, nous allons crée notre base de donnée pour PowerDNS.
CREATE DATABASE powerdns;
- Nous allons crée un utilisateur pour notre base de donnée afin d'éviter d'utiliser les logins root.
GRANT ALL ON powerdns.* TO 'powerdns_user'@'localhost' IDENTIFIED BY 'PASSWORD';
- Afin de pouvoir faire des manipulations sur la base de donnée, nous allons mettre des privilèges à notre utilisateur (il faut retourner sur l'utilisateur root).
FLUSH PRIVILEGES;
- Pour faire des modifications sur la base de donnée, il faut la sélectionner.
USE powerdns;
- Quand vous êtes dans une base de donnée, vous pouvez voir les tables.
SHOW TABLES;
- Vous pouvez également voir dans les détails le contenu d'une table.
DESC records;
- Aussi, vous pouvez également voir le contenu d'une table.
SELECT * FROM users;
- Par défaut, lors de l'installation de la base de donnée de PowerDNS, il manque les valeurs auth ainsi que disabled.
ALTER TABLE records ADD auth TINYINT(1) DEFAULT 1;
ALTER TABLE records ADD disabled TINYINT(1) DEFAULT 0;
- Vous pouvez voir l'état du service afin d'être sûr qu'il y a pas d'erreur et si il démarre correctement.
systemctl status mariadb
PDNS
- Maintenant que nous avons crée et configuré notre base de donné, nous allons installer le service PowerDNS avec le back-end mysql.
apt-get install -y pdns-server pdns-backend-mysql
- Ensuite, il faudra supprimer les fichiers par défaut qui sont dans le répertoire pdns.d.
rm /etc/powerdns/pdns.d/*
- Crée le fichier pdns.local.gmysql.conf afin d'indiquer à PowerDNS la base de donné utilisé.
vim /etc/powerdns/pdns.d/pdns.local.gmysql.conf
- Pour terminer, nous allons tester afin d'être sur que powerdns écoute correctement.
netstat -tap | grep pdns
Poweradmin
- Désormais, PowerDNS et la base de donnée est configuré, nous allons nous attaquer à l'installation de Poweradmin. Nous allons commencer par installer Apache, PHP ainsi que ces modules.
apt-get install -y apache2 gettext libapache2-mod-php php php-common php-curl php-dev php-gd php-pear php-imap php-mysql php-xmlrpc php-initl
- Ensuite, installer avec
pear
les deux modules pour la base de donnée.pear install DB && pear install pear/MDB2#mysql
- Maintenant, télécharger la dernière version GitHub de Poweradmin.
apt-get install wget && wget https://github.com/poweradmin/poweradmin/archive/refs/tags/v2.2.2.tar.gz
- Une fois téléchargé, il faudra extraire les fichiers.
tar xvzf v2.2.2.tar.gz
- Après avoir extrait les fichiers, il faudra les déplacés dans le répertoire ou Apache va charger le site.
mv poweradmin-2.2.2 /var/www/html/poweradmin
- Crée par la suite le fichier de configuration.
touch /var/www/html/poweradmin/inc/config.inc.php
- Pour terminer, donner les droits à Apache pour le répertoire Poweradmin.
chown -R www-data:www-data /var/www/html/poweradmin/
Interface
Une règle NAT à été mise en place sur le Sonicwall pour accéder à l'interace de Padmin via l'adresse virt.support-telecom.ch:1349.
Le firewall derrière à une règle configuré pour le port 1349, il va envoyer la requête automatiquement à la VM 172.16.0.8 (DEB-002) sur son port 80, 80 qui est le port par défaut de Poweradmin.
- Pour accéder à la partie installe, il faudra ce rendre sur l'adresse virt.support-vtx.ch1349/poweradmin/install. Dans un premier temps, sélectionnez la langue.
- Ensuite, cliquez sur passez à l'étape 3.
- Troisième étape, rentrez les informations demandés.
- Username : nom d'utilisateur crée pour la base de donnée PowerDNS (sur MariaDB) ;
- Password : mot de passe crée pour la base de donnée PowerDNS (sur MariaDB) ;
- Database type : nous avons une base de donnée de type MySQL ;
- Hostname : localhost ;
- DB Port : 3306 (défaut) ;
- Database : base de donnée crée powerdns (sur MariaDB) ;
- DB charset : vide ;
- DB collation : vide ;
- Poweradmin administrator password : mot de passe pour Poweradmin.
- Pour l'étape 4, complétez également les différents champs :
- Username : nom d'utilisateur pour Poweradmin ;
- Password : mot de passe pour Poweradmin ;
- Hostmaster : vide ;
- Primary nameserver : indique les serveurs DNS responsable de la zone DNS (1) ;
- Secondary nameserver : indique les serveurs DNS responsable de la zone DNS (2).
- A cette étape, nous avons un résumé des informations rentrés.
- Ensuite, Poweradmin va écrire les informations de l'installation dans le fichier config.inc.php que nous avions crée.
- Pour terminer, on nous informes que l'installation est fini. Aussi, il nous es indiqué qu'il faut supprimer le dossier Install dans Poweradmin.
- Nous allons maintenant renommer le fichier Install afin de pouvoir accéder à l'interface de connexion.
mv install/ install_old/
- Vous pouvez maintenant accéder à l'interface de connexion de Poweradmin avec l'adresse virt.support-vtx.ch:1349/poweradmin.
- Username : l'utilisateur par défaut de poweradmin admin ;
- Password : mot de passe défini au point 1.
Logs
Principalement pour faire du débogage je me suis servis des logs qui ce trouve dans Apache. C'est ici ou les requêtes PHP sont inscrites.
tail -f /var/log/apache2/error.log
Ensuite, les logs de PowerDNS ce trouvent dans un autre endroit.
tail -f /var/logs/syslog