Odoo-11 & serveur de test/dev
|
|
Description générale
Introduction
Cette marche à suivre fait suite à celle sur Odoo-11 & HTTPS et décrit les étapes pour créer un serveur de test/développement pour vérifier les mises à jour d'Odoo-11 etc....
Le nouveau serveur peut être virtuel ou physique.
Cette marche à suivre assume que vous avez réalisé l'installation d'un Serveur SME-9.2 virtuel ou physique, branché sur le réseau LOCAL du serveur principal, et que vous y avez installé Odoo-11 en suivant les procédures du document: Odoo-11.
- Conventions: #Particularités de ce document.
But final
Pour le présent document, sur le serveur dev-11.dev.micronator-101.org, nous avons installé Fail2ban et suivi les mêmes procédures qu'auparavant pour une nouvelle installation d'Odoo-11.
L'installation de SME-9.2 sur le serveur local est exactement telle que décrite dans le cahier 2 du cours Micronator-101: https://www.micronator.org/affaires/produit/micronator-101-cahier-2installation-dun-serveur-sme/
Ce nouveau serveur est configuré en mode Serveur uniquement.
L'installation de Fail2ban est décrite dans: https://www.micronator.org/affaires/produit/sme-9-x8-x-fail2ban/.
L'installation du serveur BackupPC provient de: Micronator-101, Supplément: SME & BackupPC: https://www.micronator.org/affaires/produit/micronator-101-supplementsme-backuppc/
Préparation du serveur
Ajout d'un nouveau domaine
Serveur principal vs serveur local
Si nous voulions accéder au gestionnaire Server Manager du serveur interne, on devrait spécifier micronator-101.org/server-manager; malheureusement c'est le serveur principal qui pourrait répondre...
Les noms des serveurs sont différents (odoo-11 pour le serveur principal et dev-11 pour le serveur local) mais, leur domaine principal est toujours: micronator-101.org.
Le serveur physique vs serveur virtuel
Pour éviter toute confusion, lors de la configuration initiale du serveur local, nous choisissons dev.micronator-101.org comme nom de domaine.
Si nous redirigeons tous les accès de notre serveur dev-11.dev.micronator-101.org vers le port 8069 à l'aide d'un gabarit personnalisé, le gestionnaire Server Manager sera lui aussi redirigé vers le port 8069 et il générera alors une erreur de connexion.
C'est pour cette raison que nous allons créer le sous-domaine interne.micronator-101.org. Les accès à ce domaine particulier ne seront pas redirectionnés et nous pourrons alors accéder au gestionnaire Server Manager en spécifiant le nom de ce domaine: https://www.interne.micronator-101.org/server-manager.
Création du domaine
|
Server Manager > Domaines > Ajouter un domaine. |
- Entrer les informations telles que ci-dessous.
- Ajouter. |
On s'assure du succès de l'opération. |
 |
 |
 |
Certificat Let's Encrypt
Description
Un certificat émis par l'autorité de certification Let's Encrypt vous permettra de chiffrer les connexions de votre serveur avec une clé TLS reconnue mondialement. Les usagers pourront utiliser https et, vu que le certificat aura été émis par une autorité de certification reconnue, le cadenas sera vert.
Ce chapitre est inspiré de la contribution Letsencrypt produite par: DanB35, Unnilennium, Mdo, Mercyh, RayMitchell et Gieres à l'URL: https://wiki.contribs.org/Letsencrypt.
Référence: https://fr.wikipedia.org/wiki/Let's_Encrypt.
Let's Encrypt est une autorité de certification (CA) lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d'un mécanisme automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites Internet.
Installation
On installe la contribution smeserver-letsencrypt.
# yum install -y --enablerepo=smecontribs smeserver-letsencrypt ... Installation de 2 paquet(s) Taille totale des téléchargements : 56 k Taille d'installation : 98 k ... Installé: smeserver-letsencrypt.noarch 0:0.4-4 Dépendance(s) installée(s) : dehydrated.noarch 0:0.5.0-3.el6.sme Terminé ! ============================================================== WARNING: You now need to run BOTH of the following commands to ensure consistent system state: signal-event post-upgrade; signal-event reboot You should run these commands unless you are certain that yum made no changes to your system. ==============================================================
Signalisation des changements
On applique les changements en signalant une mise à jour et un réamorçage.
# signal-event post-upgrade ; signal-event reboot
Ne pas signaler les changements pourrait empêcher la contribution de fonctionner correctement et vos certificats ne seront pas renouvelés.
Mise à jour de la Contrib
Vous pouvez manuellement mettre à jour la contribution i.e. smeserver-letsencrypt et dehydrated en utilisant la commande ci-dessous.
| # yum update -y --enablerepo=smecontribs smeserver-letsencrypt dehydrated
|
S'il y avait une mise à jour, cette commande l'installerait automatiquement.
Signalisation des changements
Si vous avez fait une mise à jour, vous devez signaler les changements.
| # signal-event post-upgrade ; signal-event reboot |
Choix des domaines et des hôtes
On affiche les nom d'hôtes de notre Serveur SME.
# db hosts show | grep .org dev-11.dev.micronator-101.org=host dev-11.interne.micronator-101.org=host ftp.dev.micronator-101.org=host ftp.interne.micronator-101.org=host mail.dev.micronator-101.org=host mail.interne.micronator-101.org=host proxy.dev.micronator-101.org=host proxy.interne.micronator-101.org=host wpad.dev.micronator-101.org=host wpad.interne.micronator-101.org=host www.dev.micronator-101.org=host www.interne.micronator-101.org=host
Si certains de vos défis sont renvoyés sans erreur, mais que certains échouent, il est possible que vous n'ayez pas d'enregistrements DNS A, MX ou CNAME pour tous les noms d'hôtes que vous avez ajoutés à votre certificat. Lorsque Let's Encrypt lance les défis pour une liste de noms d'hôtes et qu'un de ceux-ci ne répond pas, le défi échoue et le certificat n'est pas généré.
CNAME
Les noms d'hôtes pour les "sous-domaines" interne.micronator-101.org et dev.micronator-101.org chez le régistraire du domaine micronator-101.org.
| ftp.interne, mail.interne, interne, proxy.interne, wpad.interne et www.interne. | ftp.dev, mail.dev, dev, proxy.dev, wpad.dev et www.dev. |
 |
 |
On entre les noms des domaines et des hôtes ci-dessus chez le régistraire du nom de notre domaine.
Si on veut obtenir un certificat pour tous (all) les domaines et tous les hôtes de notre Serveur SME.
| # config setprop letsencrypt configure all |
La commande config setprop letsencrypt configure all est susceptible de provoquer une erreur de défi.
Nous voulons tous les noms d'hôtes affichés avec la commande db hosts show | grep .org sauf ceux des noms des serveurs: dev-11.dev.micronator-101.org et dev-11.interne.micronator-101.org car, ces derniers ne répondent pas au défis de Let's Encrypt.
Pour utiliser des hôtes ou des domaines activés individuellement, on spécifie le paramètre configure à none et ensuite, on ajoute les domaines et les noms d'hôtes désirés.
# config setprop letsencrypt configure none
Domaines
On inclut le domaine dev.micronator-101.org.
# db domains setprop dev.micronator-101.org letsencryptSSLcert enabled
On inclut le domaine interne.micronator-101.org.
# db domains setprop interne.micronator-101.org letsencryptSSLcert enabled
On vérifie.
# db domains show dev.micronator-101.org=domain Content=Primary Description=Sous domaine Nameservers=localhost letsencryptSSLcert=enabled interne.micronator-101.org=domain Content=Primary Description=Primary domain Nameservers=localhost Removable=no SystemPrimaryDomain=yes letsencryptSSLcert=enabled
Hôtes
On inclut tous les hôtes suivants:
ftp
# db hosts setprop ftp.dev.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop ftp.interne.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop mail.dev.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop mail.interne.micronator-101.org letsencryptSSLcert enabled
proxy
# db hosts setprop proxy.dev.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop proxy.interne.micronator-101.org letsencryptSSLcert enabled
wpad
# db hosts setprop wpad.dev.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop wpad.interne.micronator-101.org letsencryptSSLcert enabled
www
# db hosts setprop www.dev.micronator-101.org letsencryptSSLcert enabled
# db hosts setprop www.interne.micronator-101.org letsencryptSSLcert enabled
Autres propriétés de configuration
Aucun autre paramètre n'est obligatoire; cependant, il est recommandé de configurer une adresse courriel. Si un problème est rencontré lors du renouvellement de votre certificat, les serveurs de Let's Encrypt vous en informeront.
Ajout d'une adresse courriel
Le domaine de messagerie spécifié n'a nul besoin de correspondre à l'un des domaines pour lesquels vous demandez un certificat.
# config setprop letsencrypt email admin@micronator.org
Longueur de la clé privée
Si vous ne voulez pas la valeur par défaut de 4096 bits, vous pouvez définir la longueur de la clé privée de votre certificat,. Ceci ne devrait pas être nécessaire dans la plupart des cas mais, si vous le souhaitiez, il faudrait utiliser la commande ci-dessous pour ce faire.
| # config setprop letsencrypt keysize LONGUEUR-EN-BITS |
Termes et conditions
Veuillez d'abord lire les conditions d'utilisation de Let's Encrypt: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf
Seulement si vous acceptez les termes et conditions de Let's Encrypt, lancez la commande ci-dessous.
# config setprop letsencrypt ACCEPT_TERMS yes
Activation du mode TEST
L'étape suivante consiste à activer le mode TEST. Ce mode va obtenir des certificats du serveur de TEST de Let's Encrypt. Les limites 5/7 (5 certificats par 7 jours) ne s'appliqueront pas. Toutes erreurs ou autres problèmes rencontrés ne vous empêcheront pas, plus tard, d'obtenir votre certificat de Production.
On active le mode TEST.
# config setprop letsencrypt status test
On signale les changements. (Peut prendre plusieurs secondes.)
# signal-event console-save
Vérification de la configuration
On vérifie si on est bien en mode TEST.
# cat /etc/dehydrated/config | grep CA
CA="https://acme-staging.api.letsencrypt.org/directory"
On vérifie l'adresse courriel.
# cat /etc/dehydrated/config | grep CONTACT CONTACT_EMAIL=admin@micronator.org
On vérifie la configuration complète.
# cat /etc/dehydrated/config #!/bin/bash WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge" CA="https://acme-staging.api.letsencrypt.org/directory" BASEDIR="/etc/dehydrated" CONTACT_EMAIL=admin@micronator.org HOOK="/usr/bin/hook-script.sh" PARAM_ACCEPT_TERMS="yes"
Il n'y a pas de ligne vide avant #!/bin/bash. Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande.
On vérifie les domaines et les hôtes.
# cat /etc/dehydrated/domains.txt
dev.micronator-101.org ftp.dev.micronator-101.org mail.dev.micronator-101.org proxy.dev.micronator-101.org wpad.dev.micronator-101.org www.dev.micronator-101.org interne.micronator-101.org ftp.interne.micronator-101.org mail.interne.micronator-101.org proxy.interne.micronator-101.org wpad.interne.micronator-101.org www.interne.micronator-101.org
Il n'y a pas de ligne vide avant dev.micronator-101.org... Ci-dessus, nous avons inséré une ligne vide pour faciliter la copie de la commande.
Tout le contenu du fichier domains.txt doit être entièrement sur une seule ligne sinon, vous aurez autant de certificats que de lignes et vous atteindrez la limite 5/7 de Let's Encrypt.
Le certificat sera émis au nom du premier domaine de la ligne; ici ce sera: dev.micronator-101.org.
Obtention d'un certificat pour un serveur local
Référence: https://wiki.contribs.org/Letsencrypt#Obtaining_certificates_for_a_private_SME_Server.
Votre Serveur SME doit normalement être accessible depuis l'Internet afin que les serveurs Let's Encrypt puissent valider votre contrôle sur celui-ci. Toutefois, si votre Serveur SME n'est pas accessible depuis l'Internet, la contribution smeserver-letsencrypt fournit une méthode permettant de valider votre contrôle sur ce domaine intranet. Pour utiliser cette méthode, les conditions suivantes doivent être remplies:
- Le domaine de votre hôte interne (dev.micronator-101.org), lorsque résolu par le DNS de l'Internet, pointe vers une adresse IP publique valide.
- Le domaine vers lequel dev.micronator-101.org pointe depuis l'Internet, i.e. vers micronator-101.org, dispose d'un serveur Web actif sur le port 80.
- L'utilisateur root de dev.micronator-101.org peut se connecter au serveur micronator-101.org via SSH sans devoir utiliser un mot de passe (c'est-à-dire que vous avez configuré l'authentification par clé publique SSH).
Cette méthode utilise un script simple, inclus dans la contribution smeserver-letsencrypt mais, il requiert obligatoirement la définition de quatre entrées supplémentaires dans la base de données letsencrypt:
| config setprop letsencrypt hookScript enabled
config setprop letsencrypt host mon-domaine-externe.tld config setprop letsencrypt user root config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge |
Les parties en bleu ci-dessus doivent être modifiées pour correspondre à votre situation. La variable path doit être l'emplacement du répertoire dans lequel micronator-101.org sauvegarde les défis: le répertoire /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge. Lorsque le script dehydrated crée les fichiers de défis, il les transfère via SCP vers user@host:path puis, demande au serveur Let's Encrypt de les valider. Une fois la validation effectuée, le script dehydrated supprime le contenu du répertoire des défis: user@host:path.
Après avoir défini ces entrées, il faut en signaler les changements.
| # signal-event console-save |
Résolution Internet pour le domaine du serveur local
Nous avons ajouté les CNAME pour le sous domaine dev.micronator-101.org chez le régistraire du domaine micronator-101.org.
On ne peut vérifier les CNAME du serveur à sa console car il répondra lui-même, il faut demander à un autre serveur de les vérifier.
On va donc envoyer une commande au serveur principal (192.168.1.11) pour qu'il lance trois ping vers le serveur dev.micronator-101.org. Le premier ping du serveur principal va débuter en demandant au serveur DNS de son FAI (Fournisseur d'Accès Internet) de résoudre le nom dev.micronator-101.org puis, il va compléter les pings vers l'adresse IP retournée par le DNS du FAI.
# ssh -p 2222 root@192.168.1.11 "ping -c3 dev.micronator-101.org"
|
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 |
ssh -p 2222 root@192.168.1.11 "ping -c3 dev.micronator-101.org"
The authenticity of host '192.168.1.11 (192.168.1.11)' can't be established. RSA key fingerprint is be:a1:2f:cf:c1:5f:05:53:1a:12:c8:75:c7:a5:6c:6f. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.1.11' (RSA) to the list of known hosts. root@192.168.1.11's password: mot-de-passe-du-serveur-principal PING micronator-101.org (206.248.138.152) 56(84) bytes of data. 64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=1 ttl=64 time=0.027 ms 64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=2 ttl=64 time=0.038 ms 64 bytes from 206-248-138-152.dsl.teksavvy.com (206.248.138.152): icmp_seq=3 ttl=64 time=0.047 ms
--- micronator-101.org ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.027/0.037/0.047/0.009 ms |
- #01: La commande qui demande de se loguer en SSH (au port 2222) avec l'usager root à l'adresse 192.168.1.11 et d'exécuter la commande entre les guillemets.
- #02: Ligne vide pour faciliter la copie de la commande avec la souris.
- #05: On confirme que root veut se loguer, yes.
- #07: Le mot de passe de root sur le serveur 192.168.1.11.
- #08: Le DNS a retourné l'adresse IP (206.248.138.152) pour le domaine micronator-101.org. Cette adresse est celle pointée par le CNAME dev chez notre régistraire; c'est celle du serveur principal car, l'enregistrement @ chez le régistraire pointe vers cette adresse.
- #09-11: L'usager root lance les trois ping,
- #13-15: Statistiques des ping.
Authentification par clé publique SSH
Il faut générer une clé SSH dont la partie publique devra être envoyée au serveur passerelle (serveur principal - 192.168.1.11) afin que l'usager root puisse s'y loguer sans devoir utiliser un mot de passe.
Génération de la clé SSH
Il faut être l'usager root pour générer la clé SSH de celui-ci.
# whoami
root
On génère une clé SSH de type RSA de 2048 bits.
- On accepte le nom du fichier par défaut en tapant la touche [Entrée].
- On n'utilise pas de phrase de passe[1] en tapant la touche [Entrée].
- On confirme en tapant encore la touche [Entrée].
# ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): [Entrée] Enter passphrase (empty for no passphrase): [Entrée] Enter same passphrase again: [Entrée] Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 4b:d5:f0:31:8b:56:c0:68:f3:6c:89:a3:be:ea:c7:7e root@dev-11 The key's randomart image is: +--[ RSA 2048]----+ | ..... | | ...o. | | o.... . | |ooC . | |++++ S | |+*oo | |.D= | |. . | | | +-----------------+
On vérifie.
# ls -ls .ssh/ total 12 4 -rw------- 1 root root 1675 12 sept. 21:00 id_rsa 4 -rw-r--r-- 1 root root 393 12 sept. 21:00 id_rsa.pub 4 -rw-r--r-- 1 root root 221 12 sept. 19:08 known_hosts
La clé id_rsa est la clé privée qui doit toujours être cachée et n'être divulguée à absolument personne.
La clé id_rsa.pub est la clé publique et peut être partagée avec n'importe qui. Elle sert à chiffrer un message qui vous est destiné et que seule votre clé privée peut déchiffrer.
Différence entre les jeux de clés SSH de l'utilisateur root et celle du Serveur SME
Ce jeu de clés SSH, id_rsa / id_rsa.pub, servira uniquement à l'utilisateur root pour ses communications SSH entre le serveur intranet et le serveur principal.
Ce jeu de clés SSH est différent du jeu standard d'un Serveur SME qui se trouve dans le répertoire /etc/ssh/ et qui comprend: ssh_host_rsa_key / ssh_host_rsa_key.pub.
# ls -als /etc/ssh/ssh_host_rsa* 4 -rw------- 1 root root 1675 16 juil. 10:04 /etc/ssh/ssh_host_rsa_key 4 -rw-r--r-- 1 root root 382 16 juil. 10:04 /etc/ssh/ssh_host_rsa_key.pub
Port SSHD
Le port standard utilisé par le démon SSHD est 22. Pour déjouer un peu plus les pirates malveillants, lors de l'installation de nos Serveurs SME, nous configurons toujours le port 2222 comme port par défaut pour SSHD.
La contribution smeserver-letsencrypt utilise le port standard 22 pour les communications (ssh et scp) entre les serveur local et le serveur principal.
Nous allons forcer ces communications, pour l'utilisateur root, à utiliser le port 2222 en créant un fichier de configuration pour le démon SSHD. Ce fichier, config, doit être créé dans le répertoire .ssh de l'usager root.
Les paramètres dans le fichier de configuration SSH de root auront préséance sur tous les autres paramètres spécifiant le port SSH pour cet utilisateur seulement.
Spécification du port SSH pour l'utilisateur root
Il existe plusieurs façons de spécifier ce port mais, la plus efficace est celle ci-dessous.
| Host *
Port 2222 |
Pour plus d'information, voir: https://www.digitalocean.com/community/tutorials/how-to-configure-custom-connection-options-for-your-ssh-client.
Nous aurions pu utiliser l'expression suivante pour spécifier uniquement le nom d'un hôte particulier.
| Host 192.168.1.11
Port 2222 |
Ou celle-ci pour spécifier tous les serveur sur le réseau 192.168.1.0.
| Host 192.168.1.0/24
Port 2222 |
On peut aussi spécifier des hôtes utilisant des ports différents.
| Host 192.168.1.11
Port 2222 Host 192.168.1.1 Port 3333 |
Il faut que le mot "Port" soit à au moins un espace de la marge de gauche.
On spécifie le port à utiliser pour communiquer avec notre serveur passerelle à l'adresse 192.168.1.11.
Prendre tout le contenu de l'encadré pour la commande.
cat > /root/.ssh/config <<'EOT'
Host 192.168.1.11
Port 2222
EOT
On vérifie le contenu.
# cat /root/.ssh/config
Host 192.168.1.11
Port 2222
Il peut y avoir une ligne vide avant la ligne Host 192.168.1.11.
Téléversement de la clé SSH publique de root
Sommes-nous toujours l'usager root?
# whoami
root
On téléverse la clé publique de root sur le serveur passerelle (192.168.1.11) afin qu'il puisse entrer en communication SSH avec ce serveur sans devoir utiliser un mot de passe.
# cat .ssh/id_rsa.pub | ssh root@192.168.1.11 "cat >> /root/.ssh/authorized_keys2"
root@192.168.1.1's password: mot-de-passe-de-root-du_serveur-passerelle
cat .ssh/id_rsa.pubindique d'afficher la clé publiqueid_rsa.pubde l'usager root du serveur local.- Le caractère de pipe "|" indique de passer le résultat de la commande précédente (cat) à la commande suivante (ssh). Le paramètre
-p 2222n'est pas utilisé car, il l'est dans le fichierconfig. Le paramètreroot@192.168.1.11indique de se connecter en tant que root à l'adresse192.168.1.11. - La commande qui est entre guillemets "...", indique au serveur de destination i.e. odoo-11 (le serveur principal - passerelle) d'exécuter la commande qui se trouve entre ces guillemets. Donc, le serveur odoo-11 va afficher avec
catce qu'il reçoit et va l'ajouter (>>) à son fichier:/root/.ssh/authorized_keys2.
Vérification de la connexion
On vérifie la connexion SSH sans spécifier le port et sans utiliser un mot de passe. (Notez le changement dans les invites des commandes.)
[root@dev-11 ~]# ssh root@192.168.1.11 Last login: Wed Sep 12 13:14:44 2018 from 192.168.1.81 ************ Welcome to SME Server 9.2 ************* ... **************************************************** [root@odoo-11 ~]#
Nous sommes à la console du serveur passerelle. La connexion sans mot de passe fonctionne.
On se désengage de la connexion sans mot de passe.
[root@odoo-11 ~]# exit logout Connection to 192.168.1.11 closed. [root@dev-11 ~]#
Nous sommes de retour à la console du serveur local.
Entrées supplémentaires dans la base de données letsencrypt
hookScript
Activation du point d'accès qui s'occupe de récupérer le certificat Let's Encrypt pour un serveur interne.
# config setprop letsencrypt hookScript enabled
host
On indique l'adresse IP de la passerelle.
# config setprop letsencrypt host 192.168.1.11
user
L'usager qui récupérera le certificat.
# config setprop letsencrypt user root
path
Le chemin du répertoire de stockage des défis sur le serveur passerelle.
# config setprop letsencrypt path /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
On signale les changements (peut prendre plusieurs secondes).
# signal-event console-save
On vérifie les quatre entrées ajoutées dans la BD letsencrypt.
# config show letsencrypt
letsencrypt=service
ACCEPT_TERMS=yes
configure=none
email=admin@micronator.org
hookScript=enabled
host=192.168.1.11
path=/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
status=test
user=root
Fichier hosts
Référence: https://fr.wikipedia.org/wiki/Hosts.
Le fichier hosts est un fichier utilisé par le système d'exploitation d'un ordinateur lors de l'accès à un réseau, comme Internet par exemple. Son rôle est d'associer des noms d'hôtes à des adresses IP. Lors de l'accès à une ressource réseau par nom de domaine, ce fichier est consulté avant l'accès au serveur DNS et permet au système de connaître l'adresse IP associée au nom de domaine sans avoir recours à une requête DNS.
Si nous n'avons pas de serveur DNS sur le réseau LOCAL, on peut faire des entrées dans le fichier hosts de la station de travail et y indiquer les adresses IP de notre Serveur SME local.
Sur une station Windows, le fichier hosts se trouve dans le répertoire: C:\Windows\System32\drivers\etc\. Pour une station Linux, il réside dans le répertoire /etc.
| Clac (clic droit) sur le fichier > Propriétés. Le fichier est en Lecture seule, on décoche ce paramètre > OK. |
 |
On édite le fichier hosts et on entre les noms et l'adresse IP de notre Serveur SME intranet après les lignes localhost.
...
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
# Serveur SME sur le réseau local
192.168.1.101 dev.micronator-101.org
192.168.1.101 www.dev.micronator-101.org
192.168.1.101 interne.micronator-101.org
192.168.1.101 www.interne.micronator-101.org
...
| On remet le fichier en Lecture seule. |  |
- Vidange du cache DNS
Sur la station de travail, on ouvre un écran de commande et on vide le cache DNS de la station.
> ipconfig /flushdns Configuration IP de Windows Cache de résolution DNS vidé.
- Vidange de l'historique
On vidange l'historique de notre navigateur.
 |
 |
Il faut autoriser java script et les témoins dans notre navigateur Internet.
Lancement du script dehydrated
Vous pouvez maintenant exécuter le script dehydrated pour la première fois et vous assurer qu'il lui est possible de: se connecter aux serveurs de Let's Encrypt, valider les noms d'hôtes que vous demandez, relever les défis et requérir le certificat.
# dehydrated -c # INFO: Using main config file /etc/dehydrated/config Processing dev.micronator-101.org with alternative names: ftp.dev.micronator-101.org mail.dev.micronator-101.org proxy.dev.micronator-101.org wpad.dev.micronator-101.org www.dev.micronator-101.org interne.micronator-101.org ftp.interne.micronator-101.org mail.interne.micronator-101.org proxy.interne.micronator-101.org wpad.interne.micronator-101.org www.interne.micronator-101.org + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for dev.micronator-101.org... ... MgVbNZ7kU3Rzmh5SZb0cNo3Womr6_ywMqkzYph8PLcU 100% 87 0.1KB/s 00:00 + Responding to challenge for dev.micronator-101.org... + Challenge is valid! ... + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + Walking chain... Set up modSSL db keys Signal events All complete + Done!
Si vous recevez l'erreur ci-dessous, simplement relancer la demande.
| # INFO: Using main config file /etc/dehydrated/config
ERROR: Problem connecting to server (get for https://acme-staging.api.letsencrypt.org/directory; curl returned with 6 |
Vérification du certificat
Si la commande fonctionne sans erreur, essayez de vous connecter à la page du gestionnaire Server Manager https://interne.micronator-101.org/server-manager. Vous devriez voir une erreur indiquant que le certificat de sécurité n'a pas été émis par une autorité de certification approuvée. C'est parfaitement normal. Cependant, il devrait incorporer tous les noms d'hôtes que vous avez inclus et être valide pour les quatre-vingt-dix prochains jours.
Avec Firefox, on se connecte au gestionnaire Server Manager sur le serveur local.
| Après avoir accepté le certificat, on clique le cadenas puis, >. | Plus d'informations. | Afficher le certificat. |
 |
 |
 |
| - Certificat de test car, émis par Fake LE Intermediate XI.
- Détails. |
- Nom alternatif du sujet du certificat.
- Nos noms d'hôtes sont présents. |
Valide pour 90 jours. |
 |
 |
 |
Mode Production
Tout fonctionne correctement, on peut passer en mode Production et demander un certificat officiel.
Activation du mode Production.
# config setprop letsencrypt status enabled
On signale les changements qui peuvent prendre plusieurs secondes.
# signal-event console-save
On vérifie.
# cat /etc/dehydrated/config
#!/bin/bash
WELLKNOWN="/home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge"
CA="https://acme-v01.api.letsencrypt.org/directory"
BASEDIR="/etc/dehydrated"
CONTACT_EMAIL=admin@micronator.org
HOOK="/usr/bin/hook-script.sh"
PARAM_ACCEPT_TERMS="yes"
Demande d'un certificat officiel
On fait la demande d'un certificat officiel. Le paramètre -x est nécessaire pour forcer un nouveau certificat
# dehydrated -c -x # INFO: Using main config file /etc/dehydrated/config + Generating account key... + Registering account key with ACME server... Processing dev.micronator-101.org with alternative names: ftp.dev.micronator-101.org mail.dev.micronator-101.org proxy.dev.micronator-101.org wpad.dev.micronator-101.org www.dev.micronator-101.org interne.micronator-101.org ftp.interne.micronator-101.org mail.interne.micronator-101.org proxy.interne.micronator-101.org wpad.interne.micronator-101.org www.interne.micronator-101.org + Checking domain name(s) of existing cert... unchanged. + Checking expire date of existing cert... + Valid till Dec 13 18:22:51 2018 GMT (Longer than 30 days). Ignoring because renew was forced! + Signing domains... + Generating private key... + Generating signing request... + Requesting challenge for dev.micronator-101.org... ... hI3Yhd8hdrdAGdP4F42TKbVr_lpE1Yig0xvGhxqT86s 100% 87 0.1KB/s 00:00 + Responding to challenge for dev.micronator-101.org... + Challenge is valid! ... + Requesting certificate... + Checking certificate... + Done! + Creating fullchain.pem... + Walking chain... Set up modSSL db keys Signal events All complete + Done!
Si cette demande a réussie, félicitations! Vous avez obtenu un certificat TLS officiel et valide qui se renouvellera automatiquement à perpétuité.
Si vous recevez l'erreur ci-dessous, simplement relancer la demande.
| # INFO: Using main config file /etc/dehydrated/config
ERROR: Problem connecting to server (get for https://acme-staging.api.letsencrypt.org/directory; curl returned with 6 |
Vérification
On se rend à: https://interne.micronator-101.org/.
| Le cadenas est vert. | Émis par: Let's Encrypt Authority X3. | Tous les domaines et noms d'hôtes sont présents. |
 |
 |
 |
Connexion sécuritaire SSL/TLS (https)
Lorsqu'on se logue à Odoo, sans utiliser une connexion sécuritaire TLS[2], notre mot de passe est transmis en clair sur le réseau.
Pour remédier à la situation:
- Nous avons déjà ajouté le sous-domaine interne.micronator-101.org que nous utiliserons pour accéder au gestionnaire Server Manager.
- À l'aide d'un gabarit personnalisé, nous allons rediriger les accès à dev.micronator-101.org et les contraindre à utiliser une connexion sécurisée TLS vers le port 8069.
Redirection
Gabarit personnalisé
Vu qu'on ne doit pas modifier directement un fichier de configuration, nous allons créer un gabarit personnalisé pour accomplir les modifications nécessaires. Ainsi, lorsqu'on mettra le Serveur SME à jour, les modifications seront conservées.
Copie du fragment à modifier
Le fragment de la configuration d'Apache à modifier est le fichier: 25SSLDirectives. Ce fichier se trouve dans le répertoire: /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts.
Nous devons créer un répertoire qui contiendra la copie de ce fragment qu'on pourra alors modifier.
# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
On copie le fragment original vers le gabarit personnalisé. (La commande est sur deux lignes.)
# cp /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives \ /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
On vérifie.
# ls -ls /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
total 4
4 -rw-r--r-- 1 root root 196 14 sept. 20:41 25SSLDirectives
Modification du fichier du gabarit personnalisé
Fichier original.
| {
return " # skipping SSL directives\n" unless $port eq "443"; |
On peut modifier le contenu du fichier du gabarit personnalisé avec vi / Notepad++ / ... ou exécuter la commande du prochain paragraphe.
{ if ( $port eq "80" && $virtualHost eq "dev.micronator-101.org") { $OUT .= " \n"; $OUT .= " # Pour la redirection d'Odoo.\n"; $OUT .= " # Michel-André / 2018-09-12_22h06\n"; $OUT .= " Redirect / https://dev.micronator-101.org/\n"; } return " # skipping SSL directives\n" unless $port eq "443"; return "" unless $modSSL{'status'} eq 'enabled'; $OUT = <<SSL_END; # SSL Directives SSLEngine on SSL_END if ( $virtualHost eq "dev.micronator-101.org" ) { $OUT .= " \n"; $OUT .= " # Pour la redirection vers le port 8069\n"; $OUT .= " # Michel-André / 2018-09-12_22h06\n"; $OUT .= " ProxyPass / http://localhost:8069/ retry=0\n"; $OUT .= " ProxyPassReverse / http://localhost:8069/\n"; } }
La ligne SSL_END doit obligatoirement débuter sur la première colonne.
Prendre tout le contenu de l'encadré pour la commande.
cat > /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives <<'EOT'
{
if ( $port eq "80" && $virtualHost eq "dev.micronator-101.org")
{
$OUT .= " \n";
$OUT .= " # Pour la redirection d'Odoo.\n";
$OUT .= " # Michel-André / 2018-09-12_22h06\n";
$OUT .= " Redirect / https://dev.micronator-101.org/\n";
}
return " # skipping SSL directives\n" unless $port eq "443";
return "" unless $modSSL{'status'} eq 'enabled';
$OUT = <<SSL_END;
# SSL Directives
SSLEngine on
SSL_END
if ( $virtualHost eq "dev.micronator-101.org" )
{
$OUT .= " \n";
$OUT .= " # Pour la redirection vers le port 8069\n";
$OUT .= " # Michel-André / 2018-09-12_22h06\n";
$OUT .= " ProxyPass / http://localhost:8069/ retry=0\n";
$OUT .= " ProxyPassReverse / http://localhost:8069/\n";
}
}
EOT
On développe le gabarit httpd.conf pour qu'il intègre le gabarit personnalisé.
# expand-template /etc/httpd/conf/httpd.conf
On vérifie le fichier de configuration de httpd.conf pour s'assurer que le gabarit personnalisé a bien été intégré.
# cat /etc/httpd/conf/httpd.conf | grep "Pour la redirection" # Pour la redirection d'Odoo. # Pour la redirection vers le port 8069
Redémarrage des démons
On redémarre le démon httpd.
# /etc/rc.d/init.d/httpd-e-smith restart
On redémarre le démon odoo.
# /etc/rc.d/init.d/odoo restart
Vérification
Connexion à Server Manager
On supprime l'historique de notre navigateur.
On s'assure qu'on peut toujours accéder au gestionnaire Server Manager du serveur local en allant à: [https://www.interne.micronator-101.org/server-manager.
 |
 |
Connexion à Odoo
On se rend sur notre site Odoo en spécifiant toujours dev.micronator-101.org:
- http://dev.micronator-101.org
- http://www.dev.micronator-101.org
- https://dev.micronator-101.org
- https://www.dev.micronator-101.org
Le résultat est toujours le même, on est automatiquement redirigé vers la page de connexion d'Odoo: https://dev.micronator-101.org/web/login et le cadenas est vert.
 - Vu que notre certificat a été émis par Let's Encrypt Authority X3, une véritable autorité de certification reconnue, le serveur Web d'Odoo a accepté le certificat et a émis une connexion sécurisée. - On se logue, la page d'accueil d'Odoo apparaît et le cadenas est toujours vert. |
 |
Certificat
|
On clique le cadenas puis, >. |
Plus d'informations. |
Afficher le certificat. |
- Le certificat a été émis par Let's Encrypt Authority X3 qui est une autorité de certification reconnue.
- Détails. |
 |
 |
 |
 |
| Pas avant. | Pas après donc, valide pour 90 jours. | Nos CNAME sont tous là. |
 |
 |
 |
Fichier index de l'i-bay Primary
Le fichier index.html dans l'i-bay Primary peut contenir un texte en HTML décrivant notre organisation et sera affiché lors d'une visite à la page: http://www.micronator-101.org ou https://www.micronator-101.org.
Mise en garde
Il ne faut plus utiliser: https://dev.micronator-101.org:8069, car vous obtiendrez l'erreur de connexion suivante: SSL_ERROR_RX_RECORD_TOO_LONG.
Certificat standard SME
On veut recréer un certificat original émis et certifié par le Serveur SME lui-même.
Après s'être logué avec l'utilisateur root, on devrait être dans le répertoire personnel de ce dernier.
# pwd
root
Création d'un répertoire de sauvegarde
# mkdir dehydrated
On se rend dans le répertoire de sauvegarde.
# cd dehydrated/
Sauvegarde des fichiers du certificat actuel
Recherche des chemins des fichiers du certificat présentement actif.
# cat /etc/httpd/conf/httpd.conf | grep SSLCertificate SSLCertificateChainFile /etc/dehydrated/certs/micronator-101.org/chain.pem SSLCertificateFile /etc/dehydrated/certs/micronator-101.org /cert.pem SSLCertificateKeyFile /etc/dehydrated/certs/micronator-101.org /privkey.pem
On sauvegarde le fichier de la chaîne de certification.
# cp /etc/dehydrated/certs/micronator-101.com/chain.pem .
On sauvegarde le fichier du certificat.
# cp /etc/dehydrated/certs/micronator-101.com/cert.pem .
On sauvegarde le fichier de la clé privée.
# cp /etc/dehydrated/certs/micronator-101.com/privkey.pem .
On vérifie le fichier pem.
# ls -ls /home/e-smith/ssl.pem/
total 8
8 -rw-r--r-- 1 root root 7637 2 mars 20:46 dev-11.micronator-101.org.pem
Il n'est pas nécessaire de le faire, mais on sauvegarde quand même le fichier pem.
# cp /home/e-smith/ssl.pem/dev-11.micronator-101.com.pem .
On vérifie les sauvegardes.
# ls -ls total 20 4 -rw------- 1 root root 2329 3 mars 17:23 cert.pem 4 -rw------- 1 root root 1684 3 mars 17:23 chain.pem 4 -rw------- 1 root root 3243 3 mars 17:23 privkey.pem 8 -rw-r--r-- 1 root root 7637 3 mars 17:25 dev-11.micronator-101.org.pem
Suppression de certaines propriétés de modSSL
On affiche les propriétés de modSSL.
# config show modSSL
modSSL=service
CertificateChainFile=/etc/dehydrated/certs/micronator-101.org/chain.pem
TCPPort=443
access=public
crt=/etc/dehydrated/certs/micronator-101.org /cert.pem
key=/etc/dehydrated/certs/micronator-101.org /privkey.pem
status=enabled
On supprime la propriété CertificateChainFile.
# config delprop modSSL CertificateChainFile
On supprime la propriété CommonName.
# config delprop modSSL CommonName
On supprime la propriété crt.
# config delprop modSSL crt
On supprime la propriété key.
# config delprop modSSL key
À nouveau, on vérifie les propriétés de modSSL.
# config show modSSL
modSSL=service
TCPPort=443
access=public
status=enabled
Suppression des paramètres de tous les anciens certificats
On utilise la très dangereuse commande rm -rf pour supprimer tous les anciens fichiers: .crt, .key et .pem du Serveur SME.
.crt
# rm -rf /home/e-smith/ssl.crt/*
.key
# rm -rf /home/e-smith/ssl.key/*
.pem
# rm -rf /home/e-smith/ssl.pem/*
Il faut signaler les changements avec un des blocs de commandes ci-dessous:
- Si on ne veut pas réamorcer, on lance le bloc de commandes ci-dessous. Sans réamorçage, le serveur ne prendra que quelques secondes pour effectuer les modifications nécessaires.
|
signal-event domain-modify; \ |
- Si on veut réamorcer, le bloc de commandes ci-dessous applique les changements en signalant une mise à jour et un réamorçage.
# signal-event post-upgrade ; signal-event reboot
Si on choisit le bloc de commandes avec réamorçage, la commande signal-event post-upgrade mettra à jour les paramètres de configuration de modSSL, le serveur réamorcera avec la commande signal-event reboot pour activer tous les nouveaux paramètres et prendra environ une minute pour redevenir actif.
Vérification
- Console du serveur
On affiche la date.
# date
ven. mars 3 18:30:02 EST 2017
Fichier pem.
# ls -ls /home/e-smith/ssl.pem/
total 4
4 -rw-r--r-- 1 root root 3564 3 mars 18:23 dev-11.micronator-101.com.pem
Le fichier pem vient tout juste d'être recréé depuis quelques minutes seulement.
- Navigateur Web
On se rend au site: https://www.interne.micronator-101.com.
Firefox affiche un écran d'avertissement. Avancé > Ajouter une exception... > Voir... > onglet Détails > Validité > Pas avant.
Le certificat est au nom de: dev-11.micronator-101.com.
On voit qu’il vient d'être émis (3 mars 2017 18:23:01) en même temps que la création du fichier pem (lors du réamorçage).
Fermer les fenêtres et ajouter l'exception.
Le nouveau certificat, émis et certifié par le Serveur SME lui-même, est fonctionnel.
Mot de la fin
Cette troisième marche à suivre conclut notre étude sur l'application Odoo-11.
- Description de l'installation d'Odoo-11 sur un Serveur SME-9.2: https://wiki.contribs.org/Odoo-11.
- Description ses étapes pour assurer une connexion sécuritaire à Odoo-11 roulant sur un Serveur SME: https://wiki.contribs.org/Odoo-11_%26_HTTPS.
Particularités de ce document
Avertissement
Bien que nous utilisions ici un vocabulaire issu des sciences informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.
Notes au lecteur
- Les captures d’écrans ne sont que des références.
- Les informations écrites ont préséance sur celles retrouvées dans les captures d’écrans. Se référer aux différents tableaux lorsque ceux-ci sont présents.
Conventions
- Toutes les commandes à entrer à la console du Serveur SME commencent habituellement avec l'invite # pour l'usager root ou $ pour un usager sans privilège particulier.
- L'invite
mysql>de la console MySQL est toujours présente. - La sortie de la commande est séparée de celle-ci par une ligne vide sans couleur de fond.
- L'invite de retour n'est jamais présent pour la plupart des commandes.
- Les affichages à surveiller sont en rouge, bleu, orange ou magenta.
# ping 192.168.1.149
192.168.1.149 is alive
Les liens de référence Internet sont en bleu de même que ceux intra-document mais, ces derniers débute par un " # ".
Manipulation, truc ou ruse pour se tirer d’embarras.
Une recommandation ou astuce.
Une note.
Une étape, note ou procédure à surveiller.
Danger pour la sécurité du système.
Indique que la commande est sur une seule ligne. Pour ce document en PDF, il faudra copier la commande entière dans un éditeur de texte ASCII tel que NotePad++ et la mettre sur une seule ligne avant de la copier à la console.
Une chaîne de caractères en magenta indique qu’il faut remplacer cette chaîne par vos propres paramètres.
| Commande à exécuter si ce n'est déjà fait. |
| Commande indiquée à titre d'information seulement. |
 |
Cours SME-101
Après avoir suivi le cours SME-101, l'Étudiant possédera un site de Commerce en ligne fiable et hautement sécuritaire.
De plus, il pourra utiliser un clone de son site, sur un Serveur SME virtuel sur sa station de travail, pour tester de nouvelles extensions et applications sans compromettre la sécurité ou l'intégrité de son site en ligne.
Tous les logiciels nécessaires sont du domaine public ou LIBRE sous licence GPL; ils ne coûtent pas un sou. Le seul achat nécessaire est l'obtention d'un nom de domaine FQDN au prix initial de $15 CAD et son renouvellement annuel d'environ $30 CAD.
Documentation
Se voulant une base solide pour la création d'un site de Commerce en ligne, le cours SME-101 comprend plusieurs cahiers :
|
- Cahier-00: "SME-101.00 Linux de base". Les bases de Linux, SME-101.00 Linux de base.
|
- Cahier-01: Installation et configuration des logiciels prérequis sur le poste de travail de l'Étudiant de même que le téléchargement des fichiers qui seront installés sur le Serveur SME virtuel, https://wiki.contribs.org/SME-101.01_Logiciels_de_la_station_de_travail SME-101.01 Logiciels de la station de travail].
|
- Cahier-02: Description du parcours des paquets IP du Serveur SME vers l'Internet, création de la machine virtuelle, installation/configuration du serveur Linux SME et enfin, sauvegarde/restauration de ce dernier, SME-101.02 Serveur SME.
- Cahier-03: Abonnement à un FAI, installation et configuration d'un modem ADSL/VDSL, création d'un domaine chez un fournisseur de Service DNS dynamique avec installation d'un script pour sa mise à jour et enfin la marche à suivre pour l'obtention et la configuration d'un domaine FQDN[3], SME-101.03 ADSL/VDSL, DDNS et Domaine FQDN.
- Cahier-04: Installation d'un certificat SSL de l'autorité de certification Let's Encrypt et script de mise à jour, SME-101.04 Certificat Let's Encrypt.
|
- Cahier-05A: Installation et configuration de WordPress, SME-101.05A WordPress.
- Cahier-05B: Installation et configuration de l'extension de sécurité Wordfence, SME-101.05B Wordfence.
- Cahier-06: Installation et configuration de l'extension de vente en ligne WooCommerce, création de comptes chez Stripe et PayPal pour les paiements en ligne, SME-101.06 WooCommerce.
|
- Cahier-07: Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator, SME-101.07 Duplicator.
- Cahier-08: Serveur mandataire inversé, SME-101.08 Serveur mandataire inversé.
- Cahier-09: Supplément: SME & BackupPC-4.2, SME-101.09: Supplément: SME & BackupPC-4.2.
- Cahier-10: Supplément: Fail2ban, SME-101.09: SME-101.10: Supplément: Fail2ban.
 |
Cours SME-201
 |
* Cahier-01: Proxmox, SME-201.01: Proxmox-5.2.1. |
 |
* Cahier-02: MediaWiki, SME-201.02 MediaWiki-1.31.1. |
 |
* Cahier-03: Dolibarr (À venir). |
 |
* Cahier-04: OsTicket, SME-201.04: osTicket-1.10.4. |
Michel-André
Victoire totale, hissons la bannière de la victoire.
- ↑ phrase de passe: Groupe de mots et de caractères alphanumériques ou spéciaux, faisant office de mot de passe, connu de l'utilisateur seulement, qui sert à protéger sa clé privée et à l'identifier lors d'une connexion ou d'un transfert de fichier, tout en lui assurant une plus grande sécurité.
Notes: Les phrases de passe ne diffèrent des mots de passe que par la longueur. Les mots de passe sont généralement très courts - de 6 à 10 caractères -, alors que les phrases de passe peuvent comporter jusqu'à 100 caractères (et même plus). Leur longueur et la combinaison des mots et des caractères alphanumériques contribuent à les rendre plus difficiles à deviner que les mots de passe, et donc plus sûres.
Une phrase de passe doit être: connue que de l'utilisateur, suffisamment longue pour être sûre, difficile à deviner, facile à retenir et à saisir sans erreur. Certains considèrent qu'elle devrait atteindre 80 à 100 caractères pour être vraiment efficace.
Référence: http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=8361195. - ↑ Transport Layer Security (TLS) ou Sécurité de la couche de transport et son prédécesseur, Secure Sockets Layer (SSL), sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL a été développé à l'origine par Netscape. L'IETF en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS. Référence: https://fr.wikipedia.org/wiki/Transport_Layer_Security.
- ↑ FQDN: Dans le DNS, un Fully Qualified Domain Name (FQDN, ou nom de domaine complètement qualifié) est un nom de domaine qui révèle la position absolue d'un nœud dans l'arborescence DNS en indiquant tous les domaines de niveau supérieur jusqu'à la racine. On parle également de domaine absolu, par opposition aux domaines relatifs. Par convention, le FQDN est ponctué par un point final.
Référence: https://fr.wikipedia.org/wiki/Fully_qualified_domain_name.
