Saturday, May 4, 2019

CentOS7 (FR) 4 : configuration DNS - client (et vérifications avec nslookup).

English summary: in this short blog post, I present the client-side DNS configuration and verify name resolution with a number of tests including nslookup.


***


Après avoir mis sur pied un serveur DNS (BIND) et effectué un peu de dépannage avec named-checkconfig et named-checkzone, je tourne maintenant à la configuration DNS des deux clients de mon réseau d'essai, LX2 et LX3. Celle-ci s'est faite au moment où j'en ai configuré les paramètres réseau avec les commandes suivantes, la première pour LX2 et la seconde pour LX3. Faites attention en particulier aux caractères en gras :

nmcli conn add con-name NET1 ifname eth0 type ethernet ipv4.method manual ip4 10.4.4.2/8 gw4 10.1.1.3 ipv4.dns 10.4.4.1


nmcli conn add con-name NET1 ifname eth0 type ethernet ipv4.method manual ip4 10.4.4.3/8 gw4 10.1.1.3 ipv4.dns 10.4.4.1


Utilisant la commande "nmcli", j'ai donc créé une nouvelle connexion "NET1", une sorte de profil, ou ensemble de paramètres réseau, associée au périphérique réseau "eth0" et dans laquelle j'ai désigné le serveur LX1 comme serveur DNS par son adresse IP (10.4.4.1).

Ces paramètres sont conservés dans un fichier texte nommé ifcfg-NET1 qu'on trouve à cet emplacement :

/etc/sysconfig/network-scripts




Si nous n'avions pas ajouté le paramètre pour le serveur DNS tout de suite, nous pourrions l'ajouter plus tard en modifiant le fichier texte avec l'éditeur de notre choix (vi ou vim, par exemple) ou plus simplement avec cette commande :

nmcli conn mod NET1 ipv4.dns "10.4.4.1"

Remarque : j'abrège, comme cela se fait souvent, les paramètres : "connection" en "conn" par exemple. On pourrait, bien sûr, écrire le paramètre complet.


Dans mon réseau d'essai, je n'ai qu'un serveur DNS. Si j'en avais deux à désigner, 10.4.4.1 et 10.4.4.11 (par exemple), je ferais plutôt ceci :

nmcli con mod NET1 ipv4.dns "10.4.4.1 10.4.4.11"



Ensuite, je vérifie la résolution des noms avec la commande ping. À LX2 comme à LX3, je peux résoudre le nom de l'autre en adresse IP :







NSLOOKUP

J'aurais voulu faire quelques essais avec nslookup mais lorsque j'essaie d'exécuter la commande, je rencontre un message d'erreur :

"commande introuvable"




C'est parce que nslookup ne fait pas partie des binaires installés avec une "installation minimale" pour un serveur sans interface graphique (GUI).

Pourtant, nous pouvons l'installer avec yum:

yum install bind-utils

Remarque : oui, nslookup fait partie des utilitaires BIND.


Maintenant que nslookup est disponible, je tente une simple requête :

- nslookup
- set type=a
- LX1

Mais cela ne réussit toujours pas :




Quand j'ai installé CentOS 7.6 pour la première fois, j'ai configuré le profil réseau avec les adresses IP des serveurs OpenDNS, ce qui m'a permis de récupérer des mises à jour avec YUM.

Mais cela signifie (quel paradoxe) que mon serveur DNS ne peut pas résoudre les noms des serveurs de mon réseau d'essai pour lui-même (même s'il le fait parfaitement bien pour les clients DNS, LX2 et LX3 par exemple).

Je dois donc désigner le serveur LX1 comme son propre serveur DNS (avec son adresse IP) :

nmcli con mod NET1 ipv4.dns 10.4.4.1

Remarque : NET1 est le nom de la "connexion" ou "profile de réseau".

Je remarque que le changement ne devient pas effectif tout de suite. De ce fait, je recharge le profil :

nmcli con down NET1
nmcli con up NET1

Maintenant LX1 est bel et bien son propre serveur DNS :



Et si j'essaie nslookup, j'ai un bon résultat :




***


Au niveau de mon réseau local (LAN), DNS fonctionne désormais comme il faudrait mais il reste un problème : comment faire la résolution des noms à l'extérieur comme microsoft.com ou google.com ? Je pensais que je devrais configurer des "redirecteurs" ou spécifier des indicateurs de racine (les "root hints" en anglais) mais j'ai eu une bonne surprise. Si j'essaie de résoudre google.com ou microsoft.com, j'obtiens un résultat :



Comme je n'ai spécifié aucun redirecteur, je conclus que BIND sait déjà accéder aux serveurs DNS racine, comme DNS sous Windows, sans configuration supplémentaire. 

Je me demande encore :

  1. Comment ferais-je si, pour une raison ou une autre, je voulais ou je devais utiliser des redirecteurs au lieu des indicateurs de racine ?
  2. Comment ferais-je si je gérais un réseau avec des centaines voire des milliers de clients DNS ? J'ai édité un fichier de zone manuellement pour cette première expérience. Cela me semble un moyen peu efficace à une plus grande échelle. J'ai vu que "DDNS" (Dynamic DNS) existe aussi sous Linux et je tiens à en savoir plus.
Voici des sujets pour un futur article.


Saturday, April 27, 2019

CentOS7 (FR) 3 : résolution des erreurs de configuration DNS avec named-checkconf (BIND)

English summary: I present some of the errors committed when configuring BIND DNS for the first time on a server running Linux CentOS (version 7.6) and the resolution of these errors with the verification commands named-checkconf and named-checkzone.


***

Dans mon article précédent, j'ai configuré un serveur DNS BIND pour la première fois. Comme on aurait pu s'y attendre, j'ai commis plusieurs erreurs mais les commandes named-checkconf et named-checkzone se sont révélées utiles pour la détection et puis la correction de ces erreurs.


Configuration

Après avoir terminé la configuration, j'en ai commencé la vérification par la commande named-checkconf, ce qui a donné le résultat suivant :



En fait, je m'étais trompé dans les expressions et j'avais mis "auto-update" au lieu de "allow-update" dans le fichier de configuration :



Remarque : je réutilise des photos prises à d'autres fins. Les points rouges ne marquent pas l'erreur en question. Il faut plutôt regarder la seconde ligne après celles désignées par le point rouge, et commençant par "auto-update" justement.

J'ai dû changer ces termes pour éliminer l'erreur :




Zones

Quant aux zones (directe et inversée), j'ai compris qu'il fallait corriger d'autres erreurs en regardant le résultat de la même commande, après le changement de "auto-update" en "allow-update". A en croire named-checkconfig, la zone machlinkit.biz ne contient aucun enregistrement :


Remarque : cliquez sur l'image pour l'agrandir.


Pourtant, je suis certain d'avoir bien mis des enregistrements :

(zone directe)



(zone inversée)



Cette erreur était subtile. Dans les fichiers de zone, j'ai oublié de mettre le point après le nom de domaine :





Une fois que cet oubli a été corrigé, la vérification a réussi :



Encore une fois, il y a des variations pour ces commandes. Si nous exécutons cette commande...

named-checkconf /etc/named.conf

Rien ne devrait s'afficher si la configuration est bonne.

Remarque : il ne faut pas oublier de spécifier le fichier de configuration, soit /etc/named.conf

Pour les autres commandes, c'est-à-dire...

named-checkconf  -z /etc/named.conf

named-checkzone forward /var/named/forward.machlinkit.biz

named-checkzone reverse /var/named/reverse.machlinkit.biz

 Nous devrions avoir, comme bonne résponse :

loaded serial 0


***


Voilà donc quelques erreurs de configuration possibles et des commandes de vérification utiles pour les corriger. Dans mon prochain article, nous verrons la configuration des clients DNS.

Wednesday, April 10, 2019

CentOS7 (FR) 2 : mise en place de BIND (DNS)

English summary: I prepare a server running CentOS 7.6 for BIND DNS, install BIND and then configure services, zones and resource records. I configure DNS clients in the following blog post.

***

Dans cet article, je prépare un serveur CentOS 7.6 pour l'installation de BIND et ensuite configure services, zones et enregistrements ressource. La configuration des clients DNS se fera dans l'article suivant.

D'abord, notre futur serveur DNS (LX1) a déjà une adresse IP statique (une des exigences pour le rôle), soit :

10.4.4.1

Quant au nom d'hôte, "LX1", nous devons le changer en FQDN. Nous pourrions utiliser un domaine imaginaire tel que "exemple.net" mais, comme j'ai acheté quelques domaines pour mes réseaux d'essai, je me servirai de l'un d'entre eux, machlinkit.biz, pour cette expérience. Nous avons donc :

LX1.machlinkit.biz

Je change donc le nom d'hôte avec cette commande :

hostnamectl set-hostname LX1.machlinkit.biz

Je fais redémarrer le service :

systemctl restart systemd-hostnamed

Je ferme et rouvre ma session.

Et je vois ceci (ce qui est sans doute normal) :



En d'autres mots, l'invite de commande affiche toujours "LX1" plutôt que le FQDN.

Et maintenant, je vais installer et configurer BIND. L'ordre des étapes de la configuration varie selon les différentes sources que j'ai consultées (livres ou en ligne). En gros, je vais suivre cet ordre :
  1. Installer BIND.
  2. Configurer le démarrage du service "named".
  3. Configurer le pare-feu (s'il est activé) pour autoriser les requêtes DNS entrantes.
  4. Editer le fichier named.conf
  5. Définir des zones
  6. Définir des enregistrements ressource.
  7. Changer le propriétaire des fichiers de zone.
  8. Valider la configuration et les zones.


1. Installer BIND

Nous installons BIND avec cette commande :

yum install bind

Certaines sources ajoutent aussi bind-utils alors que d'autres affirment que ces outils sont installés quand nous installons les binaires pour le serveur. Nous verrons.

Quand yum me demande de confirmer que je souhaite vraiment installer les binaires ou importer une clé, je saisis "y" (pour "yes") ou "o" (pour "oui") afin de continuer l'installation.



2. Configurer le démarrage de named

Si j'exécute la commande suivante, je vois que le service named n'apparaît pas, bien que nous venions d'installer BIND :

systemctl list-units --type service

Cette commande n'affiche que les services actifs et nous n'avons pas fait démarrer named ou configuré le service pour qu'il se lance de façon automatique au démarrage.

Remarque : la liste des services est assez longue et je ne mettrai pas les multiples captures d'écran ici.

Si nous voulons afficher tous les services, actifs ou inactifs, nous devons ajouter le paramètre --all :

systemctl list-units --type service --all


Mais cela n'affiche toujours pas named (ceci ne donne rien) :

systemctl list-units --type service --all | grep named


Il faut cette commande-ci pour constater que le service est bien installé mais désactivé :

systemctl list-unit-files | grep named



Ces commandes nous donnent encore une autre perspective :

systemctl is-active named

systemctl is-enabled named



Je vais donc faire démarrer le service avec cette commande :

systemctl start named

L'état change alors et nous avons comme valeur "active" et disabled" respectivement.

Je configure le service pour un démarrage automatique (au démarrage du serveur) avec cette commande :

systemctl enable named


Remarque : cliquez dessus pour agrandir.

Les commandes nous donnent maintenant ces résultats :




Remarque : nous pourrions aussi utiliser cette commande :

systemctl status named


Quoi qu'il en soit, le service named est prêt.



3. Configurer firewalld

Cette étape n'est pas nécessaire si le pare-feu est inactif. J'ai choisi d'activer le pare-feu (et trouvé qu'il l'était déjà) précisément pour apprendre comment le gérer au cas où la politique de l'entreprise serait de toujours activer le pare-feu (et bien que la nécessité d'activer le pare-feu sous Linux fasse l'objet d'un débat).

Au départ, les règles du pare-feu ne tiennent pas compte de l'installation de BIND :

firewall-cmd --state

(Cette commande - en haut - est seulement pour vérifier l'état du pare-feu)

firewall-cmd --list-services


Ainsi, seuls les services ssh et le client dhcpv6 s'affichent.


Comme nous devrions savoir, si nous visons à gérer un serveur DNS, ce dernier utilise le port 53 (TCP et UDP). Nous devons donc exécuter les commandes suivantes, l'une après l'autre, pour configurer notre pare-feu en conséquence :

firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp



Cependant, comme nous pouvons observer en bas de la capture d'écran ci-dessus, rien n'est ajouté pour DNS. C'est parce que nous avons ajouté les ports qu'utilise DNS plutôt que le service lui-même. D'abord, il faut recharger le service firewalld et utiliser une autre commande pour voir les ports ouverts :

firewall-cmd --reload

firewall-cmd --list-all


Remarques : nous pouvons constater dans la capture d'écran ci-dessus que rien ne s'affiche pour DNS (ni service, ni ports) sans relancer le service. Ensuite, le service ne s'affiche toujours pas mais nous voyons l'exception faite pour les ports avec la dernière commande.



4. Editer le fichier named.conf

Les éléments relatifs à BIND se trouvent aux emplacements suivants :
  • /etc/named.conf (c'est le fichier pour la définition des zones).
  • /var/named/ (c'est ici que nous définissons les enregistrements ressource pour chacune de nos zones).
  • /var/log/messages (c'est ici que les journaux se trouvent - ou les "logs").

J'ajoute qu'un fichier modèle se trouve à cet endroit :

/usr/share/doc/bind*/sample/etc/named.conf


La configuration peut se faire de plusieurs manières. Après avoir renommé le fichier named.conf original, nous pouvons copier le fichier modèle vers /etc/ et l'utiliser. Nous pouvons aussi éditer directement le fichier named.conf original, en nous rapportant, le cas échéant, au fichier modèle. C'est cette approche que je vais adopter mais après avoir créé une copie de sauvegarde du fichier original tout de même.

Le fichier named.conf se compose de trois grandes sections : une section pour les "options" DNS du serveur, une section "logging" pour la journalisation et une section "zones" où nous définissons les zones hébergées sur le serveur. D'habitude, il y a au moins deux zones dans la mesure où nous configurons normalement une zone directe et une zone inverse pour chaque domaine.

Il s'agit donc de modifier le fichier avec l'éditeur de texte de votre choix. Je vais utiliser vi et rappelle quelques éléments du mode d'emploi :

  • Au départ, nous sommes en mode "command".
  • Nous passons en mode "insert" en tapant sur la touche "i".
  • Nous sortons du mode "insert" en tapant sur la touche "Esc" (ou l'équivalent sur votre clavier).
  • Nous enregistrons nos modifications en tapant ":wq" (sans les guillemets).

Avant tout, je tiens à créer une copie de sauvegarde de named.conf :

cp /etc/named.conf /etc/named.conf.backup

Cela donne ceci :



Ensuite, j'ouvre le fichier /etc/named.conf avec vi.

Avant les modifications, la section "options" ressemble à ceci :



Et après, nous avons ceci :



La définition des zones se fait dans le même fichier mais je traite cet aspect dans la prochaine section.



5. Définir nos zones

Toujours dans le fichier named.conf, nous devons définir (ou déclarer) les zones pour lesquelles nous voulons résoudre des noms en adresses IP et l'inverse. Dans mon exemple, j'ai une configuration simple où je définis une zone directe et une zone inverse (en anglais, "forward" et "reverse" respectivement). Je me suis inspiré des exemples trouvés en ligne ainsi que de la documentation Red Hat (voir la section "Sources" en bas). Pour une configuration simple, donc, il suffit de faire comme j'ai fait dans la capture d'écran ci-dessous. Encore une fois, il ne s'agit pas d'exécuter des commandes mais de modifier le fichier named.conf avec l'éditeur de texte de votre choix.



Je ne traite pas de la syntaxe des paramètres qu'on voit dans la capture d'écran.Une présentation plus globale de BIND dépasserait du reste le cadre de cet article. Mon seul objectif ici, plus pratique, est de permettre la résolution de noms entre serveurs et clients de mon réseau d'essai. Dans un tel cadre, la configuration plus haut suffit tout à fait.

En revanche, il est crucial de comprendre que chaque fichier désigné par le mot "file" doit bel et bien exister dans le répertoire /var/named. La création de ces fichiers est le sujet de la prochaine section.



6. Définir des enregistrements ressource

Chacun des fichiers qu'on désigne dans la section précédente doit effectivement exister dans le répertoire /var/named. Encore une fois, plusieurs options se présentent à nous. Nous pourrions créer un fichier de toutes pièces, copier un fichier modèle, ou faire une copie de named.localhost. J'ai retenu cette dernière option.

cp localhost.named forward.machlinkit.biz

Remarque : il faut se trouver dans le répertoire /var/named pour faire la copie.

Avant toute modification, nous avons un contenu qui ressemble à ce que nous voyons dans la capture d'écran ci-dessous :



Je n'expliquerai pas chaque modification mais nous devrions avoir un fichier comme celui-ci à la fin :


Remarque : faites attention à mettre un point à la fin de l'enregistrement NS. A mon premier essai, j'ai oublié cela et la validation a échoué (voir plus bas pour la validation de la configuration et des zones).

Nous faisons pareil dans le fichier reverse.machlinkit.biz pour la zone inverse :




7. Changer le propriétaire des fichiers de zone

Après avoir créé nos zones directe et inverse, je lis qu'il faut en changer le propriétaire. Pour l'instant, le propriétaire, c'est root :


Il faut, paraît-il, que le service named en soit le propriétaire, ce que nous accomplissons en exécutant ces commandes :

chown root:named forward.machlinkit.biz
chown root:named reverse.machlinkit.biz



Jusqu'ici, je n'ai pas étudié en détail les permissions et la propriété sous Linux, et en particulier l'obligation (?) de changer le propriétaire de ce type de fichier DNS. En attendant de combler cette lacune un jour, je me contente de confirmer que le propriétaire des fichiers a changé :





8. Valider la configuration et les zones

Je valide ma configuration (dans le fichier /etc/named.conf) avec cette commande :

named-checkconf /etc/named.conf

Si la configuration est bonne, cela ne devrait rien afficher (rien du tout).

J'ai vu aussi exécuter cette commande et si tout est correct, nous devrions voir "loaded serial 0" :

named-checkconf -z /etc/named.conf


Pour les zones, nous utilisons les commandes suivantes :

named-checkzone forward /var/named/forward.machlinkit.biz

named-checkzone reverse /var/named/reverse.machlinkit.biz


Voici une capture d'écran qui montre les résultats que nous devrions voir si tout est configuré comme il faut :



***

Je m'en tiendrai là pour le moment. Nous pourrions aussi faire des vérifications avec nslookup ou dig mais il faudrait installer les "bind-utils" pour cela (non, ces outils n'ont pas été installés avec les binaires BIND). Ce sera pour un autre article. De même, j'aurais voulu montrer certaines erreurs commises lors de ma première tentative et la façon dont je les ai résolues utilisant les commandes de vérification présentées plus haut. Mais une telle analyse aurait sans doute alourdi le texte et j'ai décidé que, si je finis par partager ces détails, ce sera, là aussi, dans un article séparé. Par ailleurs, la configuration des clients DNS (qui peuvent être serveurs d'ailleurs) sera aussi le sujet d'un article à venir.



Sources

J'ai consulté une multitude de sources en ligne mais la référence essentielle reste la documentation Red Hat sur BIND :

Red Hat Enterprise Linux 7 | Networking Guide | 14.2 BIND

Et en version française :

BIND (FR)

Enfin, j'estime que cette présentation est un bon survol pour quelqu'un qui essaie la mise en place d'un serveur BIND pour la première fois :

How to configure DNS Name Server in Centos7 , Redhat7 (Server and Client Configuration)

Sunday, March 31, 2019

CentOS7 (FR) 1 : configuration de base d'un serveur

English summary: after an interruption of almost one year, I'm going to continue my experiences with CentOS Linux. My approach is slightly different. My objective is to configure a BIND (DNS) server, which is where I stopped my last series of blog posts on Linux. I will configure elements such as the hostname, networking, firewall and security updates with yum.


***


Après presque un an d'interruption, je vais essayer de reprendre mon apprentissage de CentOS (il s'agit, en substance, de la version gratuite de Red Hat Linux, donc moins la marque et surtout moins l'assistance technique).

L'an passé, je me suis heurté à la configuration d'un serveur BIND (DNS) et c'est ce qui a brisé mon élan. Je ne me trouvais pas confronté à un manque de sources mais plutôt à une variété de sources dont j'avais du mal à faire la synthèse des différentes approches.

Aujourd'hui, je recommence par la configuration d'un serveur qui sera un serveur DNS. Je commence par la configuration générale (nom d'hôte, adresse IP, pare-feu, mise à jour avec yum). Ce sera une révision des choses apprises autrefois et peut-être le modèle pour la mise en service d'autres serveurs à l'avenir.

Je ne présente pas l'installation de CentOS dont j'ai simplement accepté les choix par défaut.


***


Nom d'hôte

La première tâche consiste à configurer le nom d'hôte, ce que j'accomplis avec cette commande :

nmcli general hostname LX1

Dans la capture d'écran ci-dessous, vous remarquerez que le changement ne se fait pas tout de suite. Nous sommes toujours "root@localhost". Cette commande ne force pas le changement non plus :

systemctl restart systemd-hostnamed



Il a fallu que je ferme la session en cours et en ouvre une nouvelle pour voir le changement:



Nous pouvons afficher le nom d'hôte avec cette commande :

hostname

Comme cela arrive souvent, c'est en faisant des recherches sur ces commandes que j'ai appris qu'il existe d'autres méthodes de gérer le nom d'hôte.

D'abord, il suffit d'exécuter cette commande pour changer le nom :

hostname LX1

En outre, je découvre qu'une commande de la famille *ctl existe pour les noms d'hôte : hostnamectl. Nous aurions pu changer le nom avec cette commande :

hostnamectl set-hostname LX1

Et nous pouvons afficher le nom d'hôte avec ces commandes qui ont le mérite de montrer beaucoup plus de détails que la simple "hostname" :

hostnamectl

hostnamectl status

Remarque : ces deux commandes sont équivalentes et produisent le même résultat.



Nous pouvons toujours nous contenter de "hostname" si nous préférons la concision.

Remarque : à ma connaissance, il n'est pas obligatoire de commencer par la configuration du nom d'hôte. C'est simplement un choix que j'ai fait.



Paramètres IP

Je configure les paramètres IP avec cette commande :

nmcli conn add con-name NET1 ifname eth0 type ethernet ipv4.method manual ip4 10.4.4.1/8 gw4 10.1.1.3 ipv4.dns 208.67.200.220


Je n'explique pas ici la syntaxe de la commande nmcli et de des paramètres ci-dessus. Je me contente de préciser que la commande crée bien une nouvelle connexion (ou profil) et le chiffre "200" en rouge est une erreur que vous me verrez corriger dans un moment. Il est souvent instructif de présenter ses erreurs et la façon de les résoudre.

Je constate que ma nouvelle connexion (profil) devient active et s'associe au périphérique eth0 :



Je vérifie la connectivité réseau avec ping (tout va bien) :


Si nmcli nous permet de configurer les paramètres réseau sans devoir éditer des fichiers à la main (avec vi ou vim par example), je crois qu'il est utile de rappeler que nous pouvons trouver les fichiers en question à cet emplacement...

/etc/sysconfig/network-scripts



Et que nous pouvons voir les paramètres eux-mêmes dans le fichier portant le nom de la connexion :

cat /etc/sysconfig/network-scripts/ifcfg-NET1




Pare-feu (firewalld)

Je croyais que le pare-feu n'était pas activé par défaut sous Linux et j'allais l'activer quand j'ai remarqué qu'il tourne déjà, comme la sortie de ces commandes l'atteste :


Note: cliquer dessus pour agrandir.




Puis, un pare-feu est-il nécessaire sous Linux ? C'est le sujet de maintes discussions en ligne, par exemple :

https://unix.stackexchange.com/questions/99104/do-i-need-a-special-firewall-on-a-personal-computer

Quoi qu'il en soit, je voulais activer le pare-feu pour apprendre à gérer les règles au cas où je me trouverais dans une entreprise où l'utilisation du pare-feu d'hôte... serait la règle.


Un petit problème...

A cette étape, j'allais installer les mises à jour de sécurité avec yum mais n'arrivais pas à établir un lien avec le dépôt (repository) :



Je confirme encore l'état des éléments réseau :



Y compris l'état du service NetworkManager :



Cela a l'air d'être un problème de résolution de noms (puisque ping réussit à passer).

Je revois mes paramètres DNS et j'ai un doute sur l'adresse IP du serveur OpenDNS que j'ai désigné :



Vérification faite, j'ai mal saisi l'adresse IP qui devrait être plutôt 208.67.220.220. Chemin faisant, je décide d'ajouter l'adresse d'un second serveur DNS, ce qui n'est pas crucial dans mon réseau d'essai mais constitue toujours une bonne pratique dans le monde réel (voir la commande saisie en bas de la capture d'écran ci-dessus).

Cela donne ceci :



Contre toute attente, les choses empirent. Non seulement la résolution de noms continue à échouer mais je perds la connectivité de base. Je ne peux même pas atteindre ma passerelle par défaut :



J'édite même le fichier ifcfg-NET1, observant que le paramètre pour le second serveur DNS se trouve à la fin, et pensant que cette position n'est peut-être pas valable. Rien n'y fait.

Je trouve quelques références à ce problème en ligne, par exemple :

ping - connect: No buffer space available

Je ne vois pas pourquoi il faudrait augmenter des ressources pour ARP et je choisis plutôt de faire redémarrer la machine, ce qui résout le problème. La cause exacte en reste un mystère.



Mettre à jour (yum)

Je mets ci-dessous les commandes que j'ai essayées. En fin de compte, mon installation n'aurait pas eu besoin de mises à jour de sécurité.

Pour voir les "erratas" disponibles, sans les installer, je dois exécuter :

yum updateinfo list available

Aucun résultat - je dois être à jour

Et de même pour ces commandes qui affichent les mises à jour de sécurité (sans les installer) :

yum updateinfo list security all
yum updateinfo list sec

Pour afficher les mises à jour installées :

yum updateinfo list security installed

Si je voulais installer des mises à jour disponibles, j'exécuterais cette commande :

yum update --security -y

Des mises à jour s'affichent mais à la fin je vois : "No packages needed for security; 61 packages available".


Autres remarques

Cette installation est pour un serveur DNS (et peut-être d'autres rôles plus tard). De ce fait, je me contente de l'interface à la ligne de commande et n'ajoute pas d'interface graphique. S'il y avait une interface graphique disponible, nous pourrions la lancer avec cette commande :

systemctl isolate graphical.target

A supposer, bien entendu, qu'une telle interface soit disponible (par exemple, si nous avions installé GNOME ou KDE). Nous pouvons voir le défaut avec cette commande:

systemctl get-default

Et éventuellement faire de l'interface graphique le cas défaut avec celle-ci :

systemctl set-default graphical.target