Introduction
Willow Commons possède déjà un site communautaire opérationnel. Avant de le déplacer, déterminez quelle adresse un client utilise réellement. Un enregistrement DNS sauvegardé, une réponse en cache et une réponse du site décrivent des parties différentes du parcours.
Vous utiliserez d'abord le site normal, comparerez un véritable serveur faisant autorité à un résolveur avec cache indépendant, puis modifierez un nom d'entraînement distinct. Le nom du site utilisé par la communauté ne change pas dans cette unité. Deux backends HTTP et les services DNS sont préparés dans des espaces de noms réseau Linux isolés qui partagent le noyau d'une même VM.
Vous devez savoir saisir des commandes, reconnaître des chemins et changer d'onglet. Ce laboratoire explique les commandes DNS et les petites modifications de configuration utilisées. Aucun compte de domaine public ni aucune expérience d'administration BIND ne sont nécessaires. Prévoyez environ 40 minutes, lecture et erreurs courantes comprises ; il s'agit d'une estimation de l'auteur.
Utiliser le site opérationnel par son nom
Dans cette étape, vous consulterez le site actuel de la communauté et sauvegarderez son véritable programme. Commencez dans Community Preview, puis sélectionnez Warm Client. Vous devez voir la page Willow Commons, trois rencontres et une étiquette old location. Sélectionnez Download the programme et ouvrez le texte téléchargé. L'étiquette de localisation identifie le backend ; ce n'est pas une animation de réussite.
Lisez l'étiquette de localisation en haut, puis utilisez Download the programme sous les trois rencontres. La page illustrée est une véritable réponse du backend d'origine.
L'aperçu effectue une véritable recherche DNS et une requête HTTP depuis le client du cours sélectionné. Son URL externe de plateforme est une passerelle pour le navigateur ; elle ne signifie pas que votre ordinateur utilise le DNS du cours. Actualiser le navigateur envoie une nouvelle requête sans vider le cache du résolveur du cours. N'utilisez pas encore Fresh Client.
Passez au terminal Warm Client. Il démarre dans /home/labex/project/site-move/warm, avec ses propres paramètres de résolution. pwd affiche le répertoire courant :
pwd
DNS, le système de noms de domaine, associe un nom à une adresse. Un enregistrement A associe un nom à une adresse IPv4. HTTP utilise ensuite cette adresse et un port pour demander du contenu. Ici, le nom est site.community.test ; 8081 est le port HTTP, pas une valeur d'enregistrement DNS. .test est un suffixe réservé aux tests, pas un domaine communautaire public.
curl effectue une requête HTTP. --noproxy '*' exclut tout proxy pour cette requête ; les guillemets conservent l'astérisque littéral. -f traite les erreurs HTTP comme des échecs, -s masque la progression et -S affiche toujours les erreurs. --max-time 5 limite la requête à cinq secondes :
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Vous devez obtenir du HTML contenant Willow Commons et old location. Le terminal affiche le texte source ; le navigateur présente la même page. Téléchargez maintenant la véritable ressource texte. -o programme.txt sauvegarde la réponse dans le répertoire courant de ce client :
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat affiche le fichier sauvegardé :
cat programme.txt
Vous devez retrouver les trois rencontres, les informations d'accès sans marche et Service location: old. La seule présence d'un fichier ou d'un statut HTTP ne prouve pas que le contenu est correct.
Si curl indique Could not resolve host, vérifiez l'orthographe du nom. Failed to connect signifie qu'aucune connexion HTTP n'a été établie ; ce message diffère d'un HTTP 404, qui signifie qu'un serveur a répondu mais que le chemin était absent. Corrigez la faute, puis réessayez l'URL indiquée. Ne modifiez pas le DNS de la plateforme, /etc/hosts ni un fichier du résolveur du cours. Si vous ouvrez un autre terminal, utilisez le véritable onglet Warm Client et exécutez cd /home/labex/project/site-move/warm avant de sauvegarder. Les fichiers et répertoires de travail appartiennent à ce client ; un téléchargement du navigateur appartient à votre navigateur.
Comparer le serveur faisant autorité et le cache
Dans cette étape, vous distinguerez l'enregistrement source d'une copie temporaire en cache. Restez dans Warm Client. Le serveur faisant autorité gère community.test ; son adresse est 10.94.0.2. Le résolveur avec cache du client écoute sur 127.0.0.1, l'adresse de bouclage interne à ce client. L'autre client possède un résolveur et un cache distincts.
dig pose une question à DNS. @10.94.0.2 sélectionne explicitement le serveur. A demande une adresse IPv4. +noall masque les sections habituelles de dig et +answer affiche les lignes de réponse :
dig @10.94.0.2 site.community.test A +noall +answer
Vous devez obtenir une ligne de cette forme :
site.community.test. 120 IN A 10.94.0.10
Les colonnes indiquent le nom, le TTL, la classe, le type et l'adresse. Le TTL, ou durée de vie, est le nombre de secondes pendant lesquelles une réponse peut rester en cache. IN est la classe Internet. Le point final indique un nom DNS complet. Espaces et tabulations peuvent varier.
Interrogez plutôt le résolveur du client du cours :
dig @127.0.0.1 site.community.test A +noall +answer
Son adresse doit toujours être 10.94.0.10, mais le TTL peut être inférieur, car la requête précédente a alimenté le cache. sleep 5 attend cinq secondes réelles sans modifier DNS :
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
Le TTL restant diminue généralement. Si la copie précédente a expiré, le résolveur interroge de nouveau le serveur faisant autorité et le TTL remonte vers 120. La lecture du laboratoire peut prendre tout cet intervalle. C'est une expiration normale, pas un cache défectueux. Aucune fenêtre d'observation dès la préparation de l'environnement n'est nécessaire.
Utilisez un autre nom pour la modification à venir. Il pointe vers le même ancien backend, mais ce n'est pas le nom officiel du site communautaire :
dig @127.0.0.1 practice.community.test A +noall +answer
Gardez le nom, l'adresse et le TTL restant en vue. Une recherche réussie ne prouve pas qu'un site est accessible ; l'étape 1 a effectué une requête HTTP séparée. Lancez la vérification de cette étape, puis lisez l'étape suivante avant de commencer sa courte séquence de modification et de comparaison.
Modifier un enregistrement d'entraînement et laisser son cache expirer
Dans cette étape, vous validerez une petite modification, la chargerez dans le serveur faisant autorité et observerez pourquoi un TTL réduit ne raccourcit pas une copie déjà en cache. Vous ne pouvez modifier que practice et le serial SOA nécessaire dans community.zone. Conservez le nom officiel site, keep, le serveur de noms et les deux sites.
Lisez d'abord les instructions d'édition ci-dessous. Dans Warm Client, interrogez ensuite le nom d'entraînement juste avant de changer d'onglet :
dig @127.0.0.1 practice.community.test A +noall +answer
S'il ne reste que quelques secondes, attendez la fin de cet intervalle et relancez la recherche tant que le serveur faisant autorité conserve l'enregistrement d'origine. Cela renouvelle la fenêtre d'observation par une véritable requête DNS, sans vider le cache. Une nouvelle copie dure jusqu'à 120 secondes ; travaillez à votre rythme et utilisez le paragraphe de récupération si vous manquez la fenêtre.
Passez dans DNS Desk, dont le répertoire est /home/labex/project/site-move. Lisez le fichier :
cat community.zone
Une zone est l'ensemble de données faisant autorité pour une partie de DNS. $TTL 120 définit une durée par défaut. practice 120 IN A 10.94.0.10 définit explicitement la durée et l'adresse du nom d'entraînement. Le SOA, Start of Authority, comprend un numéro de version appelé serial. Augmentez ce numéro à chaque publication d'une modification et conservez les autres valeurs SOA. Les durées de vie DNS et les temporisateurs SOA ont des fonctions différentes. Ici, @ représente l'origine de la zone, community.test.. NS désigne son serveur faisant autorité et l'enregistrement A de ns donne l'adresse de ce serveur. Les parenthèses regroupent les champs SOA en un seul enregistrement. Les valeurs existantes de rafraîchissement, de nouvelle tentative, d'expiration et de cache négatif relèvent de l'administration de la zone : ne les changez pas. Elles ne sont pas le TTL de l'enregistrement A d'entraînement.
Le here-document suivant écrit la petite zone complète. > remplace le fichier. Les guillemets de 'ZONE' maintiennent $TTL littéral, sans le développer comme variable shell. Le dernier ZONE doit commencer au début de sa ligne. Copiez le bloc entier :
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
Seules l'adresse et la durée d'entraînement, ainsi que le serial, ont changé. named-checkzone valide toute la zone sauvegardée sans la charger. Son premier argument est le nom de zone ; le second est le fichier :
named-checkzone community.test community.zone
Vous devez voir loaded serial 2, puis OK. C'est un résultat de validation du fichier, pas la preuve que le serveur en cours d'exécution l'a chargé. Si la syntaxe est incorrecte, lisez le fichier, restaurez le bloc entier et vérifiez de nouveau. Un fichier sauvegardé mal formé laisse l'ancienne zone en cours d'exécution disponible jusqu'à une recharge valide.
sudo exécute cette unique commande d'administration. L'utilitaire fourni à portée limitée appelle le véritable rndc reload community.test de BIND dans le serveur faisant autorité du cours ; il ne redémarre aucun cache :
sudo /opt/labex/site-move/reload-zone
Vous devez voir zone reload queued. Interrogez le serveur en cours d'exécution pour confirmer ce qui a réellement été chargé. Le poste de travail ne possède pas de résolveur par défaut du cours ; ce diagnostic entre donc explicitement dans l'espace de noms réseau du serveur faisant autorité. ip netns exec site-authority exécute uniquement la commande qui suit dans ce réseau du cours :
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
Vous devez obtenir 45 IN A 10.94.0.20. Passez dans Warm Client et interrogez son cache :
dig @127.0.0.1 practice.community.test A +noall +answer
Pendant la durée restante d'origine, il peut encore retourner 10.94.0.10, même avec plus de 45 secondes restantes. Le nouveau TTL de 45 secondes s'applique aux nouvelles copies ; il ne réécrit pas l'ancienne réponse en cache. Les deux backends restent opérationnels pendant que les clients peuvent légitimement obtenir des résultats différents.
Attendez le TTL restant que vous venez d'observer, plus une seconde, puis relancez la recherche. Par exemple, s'il indiquait 37 secondes, sleep 38 suffit pour cette copie. L'attente prudente suivante couvre le maximum d'origine complet de 120 secondes, même sans avoir noté la valeur exacte :
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
Vous devez maintenant obtenir 10.94.0.20 avec un TTL restant ne dépassant pas 45. Lisez la véritable ligne : la fin d'un temporisateur ne prouve rien à elle seule. Effectuez une requête HTTP par nom depuis le même client :
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Vous devez obtenir Service location: new avec le programme complet. Le nom officiel site.community.test dessert toujours l'ancien emplacement.
Si vous avez manqué la différence : le résultat terminé reste valable. Pour répéter l'observation, utilisez uniquement practice : dans DNS Desk, remettez sa ligne à practice 120 IN A 10.94.0.10 et augmentez le serial SOA actuel avec nano community.zone. nano est un éditeur de texte : déplacez-vous avec les flèches, modifiez seulement cette ligne et le serial, appuyez sur Ctrl+O, Enter pour enregistrer, puis sur Ctrl+X pour quitter. Validez et rechargez avec les mêmes commandes ci-dessus. Attendez l'expiration naturelle du TTL actuellement observé par le client d'entraînement, interrogez-le pour obtenir l'ancienne adresse pendant au plus 120 secondes, puis remettez uniquement practice à la nouvelle adresse et 45 secondes avec un autre serial supérieur. Validez, rechargez et comparez immédiatement. Terminez par l'expiration naturelle et une véritable requête vers le nouveau site. Ne réinitialisez jamais le site officiel, ne redémarrez pas les résolveurs et ne remplacez pas le contenu web pour répéter une fenêtre.
Si vous avez mal saisi un chemin, utilisez pwd et cd /home/labex/project/site-move dans DNS Desk avant de relire le fichier. Une erreur de syntaxe et un contenu incorrect sont deux problèmes distincts : validez le fichier, inspectez le serveur faisant autorité en fonctionnement, inspectez le cache, puis demandez HTTP. Lancez la vérification finale lorsque le client d'entraînement résout la nouvelle adresse.
Résumé
Vous avez utilisé un site opérationnel par son nom, sauvegardé son programme complet et distingué les données faisant autorité, les réponses DNS en cache et le contenu HTTP. Vous avez validé une modification d'entraînement limitée et constaté que réduire le TTL ne raccourcit pas une copie déjà en cache. Le site communautaire officiel et l'ancien backend restent disponibles. L'unité suivante applique ces connaissances à une migration d'adresse par étapes.
