Monday, June 18, 2018

CentOS (FR) - 06 - commandes pour la gestion des répertoires et fichiers

English summary: I present some new aspects (for me) about the management of folders and files at the Linux command line, in particular the commands listed just below.

***

Dans cet article, je vais traiter la gestion des répertoires et des fichiers et en particulier les commandes suivantes :


  • ls
  • mkdir / rmdir / rm
  • find
  • grep


J'ai étudié cet aspect de CentOS dans un article de 2016 et je veux éviter de répéter ce qui a déjà été écrit :

CentOS - à la ligne de commande - 02 : gérer répertoires et fichiers

Ma présentation ne sera donc pas exhaustive mais simplement axée sur de nouvelles découvertes ou des choses non-incluses dans l'article précédent.


***


ls  - afficher le contenu d'un répertoire

Parfois, la sortie à l'écran est telle que nous ne pouvons pas tout voir, selon les dimensions de notre écran. Ces commandes seraient susceptibles de produire une telle sortie :

  • ls /etc
  • ls -1 /etc

D'abord, nous pouvons remonter vers le haut (ou descendre vers le bas) avec ces combinaisons de touches...

Shift+PgUp
Shift+PgDn

Remarque : selon le clavier, cela pourrait être un peu différent : Maj. ou une flèche vers le haut.


Nous pouvons limiter la sortie avec les commandes more ou less :

ls -1 /etc | more

Remarque : nous ne pouvons nous déplacer que vers le bas avec la touche Retour / Entrée. Nous pouvons revenir à l'invite avec la combinaison de touches Ctrl+C.


ls -1 /etc | less

Remarque : nous pouvons nous déplacer vers le haut ou le bas avec les touches PgUp et PgDn (sur le clavier que j'utilise en tout cas). Nous revenons à l'invite comme si nous utilisions l'éditeur de texte vi (taper ":q" - sans les parenthèses). 


Toujours concernant la commande ls, nous avons plusieurs options conçues pour donner un affichage plus ou moins détaillé :

  • -a (--all) affiche tous les fichiers y compris les fichiers précédés d'un ".", les fichiers cachés.
  • -d (--directory) affiche les détails du répertoire. A utiliser avec "l".
  • -h (--human-readable) affiche la taille du fichier en Ko, Mo, Go (etc.) au lieu de laisser la taille en octets.
  • -t (time) affiche les objets (fichiers et répertoires) triés selon la date de modification. Note : ce n'est pas en raccourci pour --time qui est une option distincte.
  • -r (reverse) affiche les objets en ordre inverse.


Parfois un répertoire contient tellement d'objets que nous avons intérêt à restreindre la sortie en mettant un astérisque avant, après ou autour du terme recherché.  Par exemple, supposons que je me trouve dans le répertoire /etc et que je ne m'intéresse qu'aux répertoires et aux fichiers relatifs à yum. Il suffit de mettre un astérisque comme suit pour n'afficher que ces éléments :

ls *yum*



Remarque : ls semble faire un affichage récursif, dressant la liste des répertoires et fichiers dans /etc mais aussi le contenu des répertoires.

Quelques autres astuces méritent une simple mention.

Si nous voulons limiter l'affichage aux documents contenant deux termes possibles, deux dates par exemple, nous mettons des crochets autour des nombres qui nous intéressent, comme ceci :

ls *199[12]*

Cela affiche tout objet avec la date 1991 ou 1992 dans le nom.

Autres variations :

ls [Nord,Sud]*

Cela affiche tout objet dont le nom commence par "Nord" ou "Sud". Nous mettrions un astérisque avant le premier crochet pour trouver tout objet avec "Nord" ou "Sud" quelle que soit sa position dans le nom (au début, au milieu, à la fin).


ls *{1990..92}

Avec des accolades au lieu des crochets, et deux points, nous pouvons afficher tout fichier dont le nom finit par 1990, 1991 ou 1992.


ls [AB][0-9][0-9]??

Voilà un exemple encore plus complexe : ls affiche tout fichier avec A ou B pour le premier caractère, tout nombre entre 0 et 9 pour les deuxième et troisième caractères et n'importe quel caractère pour les quatrième et cinquième.



mkdir / rmdir /rm / cp / mv

Nous avons vu (dans mon article de 2016, cité en introduction) les commandes pour créer et supprimer un répertoire, respectivement :

  • mkdir
  • rmdir

Dans l'article précédent, j'ai écrit qu'il existe une option -R (récursif) pour supprimer le fichier et son contenu. En fait, ni rmdir -r ni rmdir -R ne nous permet de supprimer un répertoire contenant d'autres objets. Il faut plutôt utiliser une de ces commandes :

  • rm -r
  • rm -R
  • rm --recursive

Toutes ont le même résultat :




Je vois des exemples où l'on ajoute aussi l'option -f ou --force.

Selon man (man rm), cette option fait que rm ne tient pas compte des fichiers non-existants (?) et ne demande jamais une confirmation.

Il n'y a pas d'option -F dans ce cas.

Autre chose apprise, nous pouvons même supprimer des répertoires vides avec cette commande :

rm -d 


En ce qui concerne les commandes cp et mv, si nous voulons retenir les propriétés (propriétaire, permissions) des objets copiés, nous devrions mettre l'option -p :

cp -p

En revanche, il n'est pas nécessaire d'ajouter l'option -p pour les déplacements avec mv. Bien entendu, il n'est pas nécessaire non plus pour renommer un objet. Enfin, nous pouvons tout à fait déplacer et renommer un objet en même temps.



find

Ou la "recherche des fichiers avec la commande find".

Nous effectuons la recherche dans le répertoire courant sauf à indiquer le chemin.

La recherche se fonde sur des termes de recherche qu'on appelle "motifs", parmi lesquels :

  • -name (sensible à la casse)
  • -iname (insensible à la casse)
  • -type
  • -user (recherche selon le propriétaire du fichier)
  • -size

Par exemple, je viens d'installer le navigateur Firefox (sur une machine avec une interface graphique) et je suis curieux de voir les répertoires créés et les fichiers installés :

find / -iname firefox


Certes, il pourrait y avoir des répertoires ajoutés dont le nom ne comprend pas le motif  "firefox".



grep

J'ai découvert grep en étudiant Network Manager dans un article précédent. Les paramètres de réseau se trouvent dans des fichiers de configuration que nous pouvons ouvrir et lire avec cat mais il s'agit de l'ensemble du fichier avec, peut-être, des dizaines ou des centaines de lignes. Avec grep, nous pouvons choisir un terme de recherche - ou un "motif" - et grep n'affiche que les lignes contenant le motif en question. En cela, grep est plus précis que cat.

cat versus grep :


Dans l'exemple ci-dessus, nous cherchons les services disponibles dans la zone de pare-feu "public". L'affichage avec cat n'est pas excessif mais dans un fichier avec plus de lignes il pourrait l'être. J'ai ajouté l'option "-i " pour que la recherche soit insensible à la casse. Cette option n'est pas obligatoire. La recherche réussirait aussi bien sans cette option mais ne relèverait que les mots avec la casse présente dans la commande (minuscule ou majuscule).





Thursday, May 31, 2018

CentOS (FR) - 05 - nouveau regard sur le shell, les terminaux et su

English summary: I revisit some basic elements of CentOS (and Linux in general) such as the shell, the command line prompt, terminals and su (switch user function). These notions are more or less related (su could have been presented equally well in another context). Compared to my first set of blog posts in 2016, I discovered some new aspects outlined here: existence of multiple shells and multiples terminals, the ability to use multiple terminals at the same time, and the importance of adding a dash when executing the su command.

***

Dans les lignes qui suivent, je vais jeter un nouveau regard sur quelques notions de base de CentOS, notamment le shell, l'invite, les terminaux et su (switch user). Ces notions sont plus ou moins liées entre elles. En particulier, j'aurais pu traiter su ailleurs. En comparaison avec mes premiers articles sur CentOS en 2016, j'ai fait quelques nouvelles découvertes cette fois-ci : l'existence de multiples shell (en plus de BASH), la possibilité d'utiliser plusieurs terminaux, et de passer des uns aux autres, et puis l'importance d'ajouter un tiret lors de l'exécution de la commande su.



Shell

Sous Linux, nous gérons le noyau (kernel) via le shell. Plusieurs types de shell existent mais CentOS utilise par défaut BASH (Bourne-Again Shell). Il est possible d'installer un autre shell si nous le souhaitons. En cas d'incertitude, nous pouvons voir le shell installé avec cette commande :

echo $0

Si nous ne pouvons avoir qu'shell à la fois, nous pouvons ouvrir plusieurs terminaux et passer de l'un à l'autre en fonction de nos besoins. J'ai cru comprendre que nous pourrions, par exemple, effectuer une opération dans un terminal et voir se dérouler la journalisation des événements en temps réel dans un autre. A ma connaissance (plutôt débutant en Linux), nous ne pouvons pas afficher les deux terminaux l'un à côté de l'autre, sinon dans le cadre d'une interface graphique.

En principe, nous passons d'un terminal à l'autre avec la combinaison de touches [Ctrl][Alt][F1] pour le terminal 1 (tty1), [Ctrl][Alt][F2] pour le terminal 2 (tty2) et ainsi de suite. En pratique, j'ai découvert qu'avec mon clavier (et peut-être parce que j'utilise des machines virtuelles dans VMware Workstation) il faut plutôt taper [Fn][Alt][F1], (etc).

Nous pouvons voir le terminal utilisé avec cette commande :

tty






Invite

Quand nous ouvrons le terminal, et après notre ouverture de session, nous nous trouvons à une "invite" (prompt). L'invite comprend les éléments suivants :

  • le nom de l'utilisateur (avant l'arobase).
  • le nom de la machine (après l'arobase)
  • le répertoire de travail (ou le dernier emplacement du chemin que nous avons parcouru dans l'arborescence).

Si nous voulons voir le chemin complet, il suffit de taper "pwd".

Encore une chose :

# - Le dièse indique que nous avons ouvert une session en tant que root.
$ - Le dollar indique tout utilisateur autre que root.


SU

En principe, nous devrions ouvrir une session en tant que simple utilisateur et devenir root seulement pour les tâches d'administration.

Nous passons d'un compte à un autre avec "su - " suivi du nom de l'utilisateur dont nous voulons assumer l'identité. S'il s'agit de root, nous pouvons omettre le nom d'utilisateur : en l'absence d'un nom, le système suppose qu'il s'agit de root par défaut.

Par contre, il est important de mettre le tiret, car cela simule une nouvelle ouverture de session et change l'environnement de l'utilisateur (dans le cas contraire, seul le variable PATH change).

Dans l'exemple ci-dessous, je montre qu'il est parfaitement possible d'omettre "root" après "su -" (le résultant est pareil dans les deux cas) mais que le fait d'omettre le tiret donne une invite différente :



Dans ma première série d'articles sur Linux/RHEL/CentOS en 2016, je n'ai pas observé cette distinction:

CentOS - à la ligne de commande - 05 : sudo versus su



***


A l'avenir, je vais m'efforcer de redonner une ligne directrice à la composition de mes articles et à leur succession, mais pour le moment je vais me contenter de découvrir - ou redécouvrir - différents éléments de base de CentOS.


Avant de terminer, voici quelques autres commandes utiles :

who : montre l'identité de l'utilisateur en session, le terminal où la session a été ouverte ainsi que la date et l'heure. La commande affiche de multiples sessions dans des terminaux différents le cas échéant.

whoami : montre seulement l'identité de l'utilisateur dans le terminal courant.

Chez Linux, tout est un fichier, y compris les commandes à exécuter. La commande which montre où le fichier (la commande) se trouve. Par exemple :



which systemctl

/bin/systemctl

Si nous pouvons exécuter ces commandes sans être dans le répertoire qui les contient, c'est parce que le shell cherche automatiquement certains répertoires présents dans la variable PATH :

echo $PATH

Monday, May 28, 2018

CentOS (FR) - 04 - systemd et services réseau

English summary: in my previous blog posts, I often had to start and stop various network related services, which led me to take a closer look at managing CentOS services in general. Without leaving the subject of networking entirely (most of the examples below concern network services), I explore the use of the latest tool for service management in CentOS: systemd and the command systemctl.


***

Dans mes articles précédents, j'ai été amené assez souvent à manipuler des services réseau, ce qui m'a donné envie de jeter un coup d’œil sur la gestion des services sous CentOS 7 en général. Sans quitter le domaine de la réseautique tout à fait, je vais présenter l'outil systemd et la commande systemctl.

Depuis sa version 7 donc, l'outil qui sert à gérer les services sous CentOS s'appelle systemd. A une échelle plus large, la plupart des distributions GNU/Linux ont remplacé les outils précédents par ce nouvel outil.

Entrons dans le vif du sujet.

Dans le monde de systemd, les services s'appellent "unité de service" et se terminent par l'extension de fichier ".service".

Par exemple :

NetworkManager.service

Nous pouvons vérifier l'état d'un service avec cette commande (toujours avec l'exemple de NetworkManager) :

systemctl status NetworkManager.service


Remarque : il est possible d'omettre l'extension de fichier pour être un peu plus concis :

systemctl status NetworkManager

C'est ce que je ferai dans le reste de cet article.


L'affichage abonde en détails, entre autres : l'état du service, sa durée d'activité, les fichiers de configuration systemd pour le service, et les éléments du journal les plus récents (coupés dans la capture d'écran ci-dessous) :





Si nous voulons seulement voir si le service s'exécute (s'il est démarré - started) ou s'il est autorisé à tourner (enabled), nous pouvons recourir plutôt à ces deux commandes :

systemctl is-active NetworkManager

systemctl is-enabled NetworkManager




Comme la commande PowerShell "Get-Service" sous Windows, cette commande nous donne une vue d'ensemble des services :

systemctl list-units --type service



Cela nous montre le nom de chaque service (unité de service) et s'il a été...

1. Chargé (LOAD)
2. Activé (ACTIVE)

En plus d'une description.

Par défaut, seuls les services activés sont affichés. Pour les voir tous, quel que soit l'état d'activation, il suffit d'ajouter --all

systemctl list-units --type service --all




Les commandes de base (pour arrêter, lancer, redémarrer, recharger) sont assez simples :

systemctl stop NetworkManager

systemctl start NetworkManager

systemctl restart NetworkManager

systemctl reload NetworkManager



Le dépannage des services

Et des services réseau en particulier... Quelques notes.
  • Si un service réseau ne fonctionne pas, nous devons vérifier si le service s'exécute (voir les exemples plus haut).
  • Même si le service s'exécute, le pare-feu pourrait bloquer les connexions. Nous devons vérifier la zone active de firewalld et les services autorisés.
  • En plus de tenter une simple connexion depuis un ordinateur distant, nous pouvons utiliser netstat au serveur local pour afficher les services qui écoutent (aux ports...) et portqry ou nmap à distance.
  • Le fait d'arrêter un service de réseau n'arrête pas obligatoirement les sessions réseau en cours.

Voici un exemple qui montre les rapports entre différents "services".

Dans mon article précédent, j'ai ajouté le service "https" à la zone par défaut de firewalld, soit "public".



Pourtant, si j'exécute la commande netstat avec les paramètres suivants (pour une présentation plus concise), https ne se trouve pas parmi les services :



A y réfléchir, cela est tout à fait logique puisque notre serveur n'est pas un serveur Apache et aucun service n'écoute au port 443 (bien que les paquets entrants seraient autorisés en raison de la configuration de notre pare-feu) :




Note de la fin : il faudrait voir si, comme sous Windows, le fait d'installer un rôle ouvre automatiquement les ports nécessaires.

Wednesday, May 16, 2018

CentOS (FR) 03 - firewalld et firewall-cmd

English summary: I examine firewalld, the new firewall for RHEL/CentOS 7, and in particular, concepts such as interfaces, services and zones as well as the command line tool firewall-cmd.

***

Dans cet article, je vais examiner le nouveau pare-feu de RHEL/CentOS 7. J'allais écrire le pare-feu firewalld mais je crois comprendre que c'est un peu plus subtile.

RHEL/CentOS 7 comporte un filtre de paquets intégré qui s'appelle NetFilter. Nous avons à notre disposition deux services qui nous permettent de gérer ce filtre :

1. iptables - outil historique mais toujours disponible.
2. firewalld - désormais le service par défaut.

A lire différents forums, je constate que certains de ceux ayant connu iptables préfèrent ce service hérité à firewalld. Quant à moi, qui n'ai jamais connu iptables, je vais me concentrer entièrement sur le service firewalld et, pour sa configuration, l'outil firewall-cmd.


***

Quelques notions générales

  • Service (daemon) - firewalld est un service. Nous avons deux interfaces pour sa gestion: firewall-cmd à la ligne de commande et firewall-config (GUI). Je traite seulement la première dans cet article.
  • firewallctl - La version 0.4.3 de firewalld comporte une nouvelle interface en ligne de commande avec des options de configuration plus courtes : firewallctl. Cependant, il n'est pas disponible sous RHEL/CentOS version 7.4. Ce qui se passera à l'avenir n'est pas clair.

https://bugzilla.redhat.com/show_bug.cgi?id=1494048

  • Paquets entrants - La gestion du pare-feu concerne surtout les paquets entrants qu'on rejette ou accepte selon les règles mises en place. Au contraire, tous les paquets sortants sont autorisés par défaut.
  • ICMP - Si les ports TCP/UDP sont bloqués par défaut, les paquets ICMP entrants sont autorisés. Il faut ajouter un "blocage ICMP" (ICMP block) pour les en empêcher.
  • Permanent - Nous devrions faire attention à ajouter l'option --permanent si nous voulons que nos changements survivent au redémarrage. Sinon, le changement de configuration existe seulement en mémoire vive, sans enregistrement sur disque. C'est l'opposition entre la configuration "runtime" et la configuration  "permanent".
  • Zones - firewalld comporte des jeux de règles plus ou moins restrictives qu'on appelle "zones" . Les zones "block" et "drop" sont les plus restrictives. Tous les paquets entrants sont rejetés. Avec la zone "trusted", au contraire, tous les paquets sont acceptés. La zone par défaut s'appelle "public". Nous choisissons entre elles selon le niveau de confiance que nous avons en notre réseau. Si nous nous branchions directement sur Internet, nous ferions bien de choisir une zone (un jeu de paramètres) plus restrictive. A l'intérieur d'un réseau sûr, nous pourrions accepter un jeu de paramètres moins restrictifs.
  • Interfaces - Nous associons une zone à une interface pour que les paramètres de la zone contrôlent le va-et-vient des paquets entre le serveur et le réseau. Une interface ne peut être que dans une seule zone à la fois, mais si le serveur comptait de multiples interfaces, celles-ci pourraient se trouver dans la même zone. Si on n'assigne pas une zone à une interface, celle-ci se trouve dans la zone par défaut, soit la zone "public".

Maintenant, je vais développer certaines de ces notions.


Service

firewalld est un service. Nous pouvons vérifier son état avec systemctl :

systemctl status firewalld.service

Ou en plus court :

systemctl status firewalld

Nous arrêtons et démarrons le service avec ces commandes :

systemctl stop firewalld

systemctl start firewalld


L'outil firewall-cmd (présenté plus bas) peut lui aussi afficher l'état du pare-feu :

firewall-cmd --state





Fichiers de configuration

Les fichiers de configuration de firewalld se trouvent en deux endroits distincts :

/usr/lib/firewall/



Ce sont les fichiers de base avec les paramètres par défaut. Parmi eux, nous verrons en particulier la liste des zones prédéfinies dans un moment.

Nos modifications aux configurations par défaut sont enregistrées plutôt à cet endroit :

/etc/firewalld



En pratique, il s'agit de copier le fichier de configuration à modifier de son répertoire à /usr/lib/firewalld vers le répertoire correspondant à /etc/firewalld. C'est seulement ensuite qu'on fait les changements. Dans le cas de la zone par défaut ("public"), une copie existe déjà à /etc/firewalld/zones :



Nul besoin donc de copier le fichier dans ce cas-là.

Avertissement : nous ne devrions pas modifier les fichiers originaux à /usr/lib/firewalld. Nous devons les garder en l'état au cas où nous serions obligés de revenir à la configuration par défaut. Si nous gâchions la copie originale, ce serait plus difficile. 



Zones

Nous pouvons afficher la liste des zones prédéfinies avec cette commande :

ls -1 /usr/lib/firewall/zones



En outre, nous pouvons afficher les services autorisés d'une zone, la zone "public" par exemple, avec cette commande :

cat /usr/lib/firewalld/zones/public.xml



Seuls les services SSH et dhcpv6-client sont autorisés.

Je ne présente pas les détails de chaque zone. Je me contente de faire remarquer que les zones "block" et  "drop" rejettent tout paquet entrant - qui ne fait pas partie d'une communication amorcée depuis l'intérieur - et autorisent tous les paquets sortants. Quelle différence alors entre ces deux zones ? La zone "drop" est plus discrète, ou "furtive" en ce qu'elle ne donne aucune réponse aux parties extérieures qui tentent une connexion.

Astuce : pour ne voir que le services, nous pouvons utiliser grep :

grep -i service /usr/lib/firewalld/zones/public.xml



A propos du terme "service", il faut préciser que firewalld est un service (daemon) mais que nous appelons aussi services "ssh" ou "samba". Ce sont deux choses différentes mais désignées par le même mot.



firewall-cmd

A moins d'utiliser firewall-config (outil graphique), nous devrions utiliser firewall-cmd pour la configuration de firewalld - plutôt que la manipulation directe des fichiers de configuration.

Afficher les services disponibles

firewall-cmd --get-services

Cela produit une liste de tous les services qu'on pourrait autoriser dans une zone (https, ssh, etc.). La liste est longue et je ne la reproduis pas ici.


Ajouter un service à une zone

En ce qui concerne la configuration de notre pare-feu, nous avons plusieurs options dont la plus simple sans doute est de modifier la zone qui répond le mieux à nos besoins (à supposer que les paramètres prédéfinis ne suffisent pas).

Les commandes exécutées ci-dessous modifient la zone par défaut et plus précisément la copie se trouvant à /etc/firewall/zones, ce que je peux démontrer en affichant les services présents dans chacun des fichiers .xml :



Dans cet exemple, je vais ajouter le service "https", un choix assez commun dans la mesure où les serveurs Linux sont souvent utilisés pour fournir des services http/https. Mais j'ai oublié quelque chose, ce qu'on constate à l'absence de changement dans les deux fichiers :




Si nous voulons que le changement soit permanent, nous devons ajouter l'option --permanent :



Maintenant, nous observons le nouveau service dans le fichier public.xml à /etc/firewall/zones (voir la capture d'écran ci-dessus).

Attention !

Si nous ajoutons l'option --permanent, le changement survivra au redémarrage mais ne prend pas effet tout de suite (ce qui est pourtant le cas en l'absence de cette option). Au lieu de répéter la commande sans l'option --permanent (une solution possible), nous pouvons charger la configuration nouvelle avec cette commande :

firewall-cmd --reload 


Il n'est pas nécessaire d'afficher le contenu des fichiers .xml pour voir les services inclus. Cette commande donne le même résultat :

firewall-cmd --list-services



Sauf indication contraire, c'est la zone par défaut ("public") qui s'affiche, ce que nous pouvons confirmer en ajoutant l'option --zone=public. De plus, nous pouvons afficher ainsi les services d'autres zones :

firewall-cmd --list-services --zone=public




Afficher la zone par défaut

Il suffit d'exécuter cette commande :

firewall-cmd --get-default-zone

Nous pouvons aussi voir le rapport entre zone et interface avec ces commandes :

firewall-cmd --get-active-zones
firewall-cmd --get-zone-of-interface=ens33


Remarque : ens33 n'est qu'un exemple.


Nous pouvons changer la zone par défaut comme ceci :

firewall-cmd --set-default-zone=work

Encore une fois, "work" est un exemple.


Entre beaucoup d'autres détails, nous pouvons aussi voir la zone d'une interface dans son fichier ifcfg. Dans ce cas, l'interface ens33 se trouve dans la zone "public" (dernier paramètre de la liste ) :




Ajouter un port à une zone

A priori, nous ajouterions un service (http ou https) à une zone mais nous pourrions aussi ajouter un port si les circonstances l'exigeaient (peut-être dans le cas d'une application qui utilise un port particulier, non inclus dans un des services existants).

Avant d'ajouter le port, je tiens à montrer les paramètres de la zone en leur état actuel. Nous voyons que la zone comprend l'interface ens33, trois services dont https que nous avons ajouté plus haut, mais aucun port :



Nous ajoutons un port avec cette commande, avec le port TCP 8080 comme exemple :

firewall-cmd -add-port=8080/tcp

Nous pouvons alors confirmer l'ajout :


Certains lecteurs auront remarqué que j'ai oublié une option importante - si je veux que l'ajout du port soit permanent.

Le plus souvent, nous n'aurons pas besoin d'ajouter des ports spécifiques parce que les services prédéfinis sont configurés avec tous ceux qui sont nécessaires. Nous pouvons vérifier les ports compris dans chaque service avec une de ces deux commandes :






***


Je crois avoir présenté beaucoup d'aspects de firewalld, tout en me rendant compte qu'il reste encore des éléments intéressants comme la "configuration riche", le blocage ICMP, le mode panique, et autres. Il est possible que je traite ces aspects dans un article à venir. Sinon, j'invite le lecteur à faire une recherche en ligne sur les éléments en question.

Sunday, May 6, 2018

CentOS (FR) 02 - nmcli encore

English summary: in this series of blog posts, I'm taking another look at RHEL/CentOS 7 and notably nmcli, the command line version of Network Manager. In particular, I'm examining some of the aspects not fully covered in the first post, for example:

man nmcli
nmcli help
nmcli conn add (variations)
nmcli conn up / down

***

Dans mon premier article de cette nouvelle série, j'ai repris l'apprentissage de RHEL/CentOS (version 7), et notamment la mise en réseau d'un hôte avec l'outil en ligne de commande nmcli. Chemin faisant, je me suis rendu compte que l'outil comportait beaucoup trop d'aspects pour tout présenter en un seul article. Dans les paragraphes suivants, j'aborde quelques autres aspects de l'outil en plus grand détail.


Comment obtenir de l'assistance pour les commandes nmcli ?

D'abord, nous pouvons lire le manuel :

man nmcli

En principe, nous pouvons obtenir des exemples plus concrets avec cette commande :

man nmcli-examples

Cependant, à cette étape de mon apprentissage, je trouve que la plupart des exemples ne sont pas très utiles (configurations trop avancées) mais l'exemple 9 montre comment ajouter un profil avec une configuration IP statique - plutôt qu'en DHCP.

L'option la plus utile selon moi est "help". A la différence de "man" qu'on met avant la commande à exécuter, nous mettons "help" après la commande, et éventuellement les objets (general, device, connection, etc.) et les options (-terse, -pretty, etc.) pour avoir les renseignements les plus spécifiques possibles.

Quelques exemples...

nmcli help

nmcli networking help

nmcli device help



Analyse de la commande nmcli conn add con-name

Certaines sources utilisent des alias (raccourcis ou formes abrégées) que je préfère en général mais il m'arrive aussi de vouloir connaître la forme complète des paramètres.

  • ip4 est un alias pour ipv4.addresses
  • gw4 est un alias pour ipv4.gateway

Mais aucun alias n'existe pour ipv4.dns

Au lieu de ce que j'ai fait dans mon article précédent, nous aurions pu faire ceci :


Remarque : vous pouvez cliquer sur l'image pour l'agrandir.

Je constate plusieurs choses :

  • Nous pouvons mettre au moins certains paramètres dans un ordre différent. Dans mon exemple de l'article précédent, "con-name" vient avant "ifname" et "type" mais dans l'exemple présent, "type" vient en premier. Cela ne semble poser aucun problème.
  • Je peux bel et bien utiliser la forme complète des paramètres : ipv4.addresses et ipv4.gateway.
  • Il ne suffit pas d'indiquer une adresse IP pour que la configuration soit "statique". Si j'omets l'option ipv4.method, la méthode n'est pas "manual" par défaut mais plutôt "auto". Cela nous donne une adresse IP statique (celle que nous avons paramétrée) et une adresse IP dynamique allouée par un serveur DHCP.






De plus, si un profil est déjà activé pour une interface donnée (ens33 dans notre exemple), le nouveau profil ne le remplace pas automatiquement :


Remarque : observez que le profil PRD est toujours actif pour le périphérique ens33.

J'ai désactivé le profil PRD avec la commande suivante :

nmcli conn down PRD

Alors, le profil CONN1 devient (automatiquement, paraît-il) le profil actif :



Mais si je désactive CONN1, PRD ne redevient pas automatiquement le profil actif. Il faut que je l'active :



Cette fois, nous n'avons plus qu'une seule adresse IP (v4) pour l'interface ens33 (sans compter l'adresse de bouclage 127.0.0.1) :





Corriger la configuration d'un profil

J'aurais dû ajouter "ipv4.method manual" lors de la création du profil CONN1. Que faire ? Je peux modifier un profil existant avec la syntaxe suivante (utilisant l'exemple "ipv4.method") :

nmcli conn modify CONN1 ipv4.method manual


Si j'active le profil CONN1 maintenant, et regarde la sortie de "ip addr", je constate qu'il n'y a plus d'adresse allouée par DHCP.

Je pourrais aussi supprimer le profil et le recréer. Ce serait gaspiller mon temps pour corriger un seul paramètre mais je vais le faire ici seulement parce que cela me permettra d'expérimenter avec d'autres options.

Je supprime donc le profil avec cette commande :

nmcli conn delete CONN1



Et je rajoute le profil avec cette commande :



Mais j'ai oublié de définir un second serveur DNS. Comment corriger cela ?

Si j'exécute cette commande...

nmcli conn modify CONN1 ipv4.dns 208.67.222.222


Je me retrouve avec un seul serveur DNS : x.x.222.222 remplace x.x.220.220

Voici la commande qu'il faut :

nmcli conn modify CONN1 +ipv4.dns 208.67.220.220

Remarque : faites attention au signe " +  " devant ipv4.dns.

Maintenant, j'ai deux serveurs DNS :



Si je veux créer un profil qui utilise un server DHCP pour la configuration des paramètres de réseau, je configure la connexion à peu près de la même manière mais en omettant l'adresse IP, la passerelle par défaut, et éventuellement les serveurs DNS :

nmcli conn add con-name CONN2 type ethernet ifname ens33




Activer et désactiver profils, interfaces et davantage

Entre autres choses, nous avons donc vu comment activer ou désactiver un profil :

nmcli conn up PRD
nmcli conn down PRD

Nous pouvons combiner les commandes avec " ; "pour rendre effectif un changement récent :

nmcli conn down PRD ; nmcli conn up PRD 


Mais qu'en est-il pour les interfaces ?

Encore une fois :

Profil = connexion = jeu de paramètres
Interface = périphérique (device)


Il faut exécuter les commandes suivantes (selon l'objectif et utilisant l'exemple de l'interface "ens33") :

nmcli device disconnect ens33
nmcli device connect ens33




Par ailleurs, nous pouvons désactiver (et réactiver) la fonctionnalité réseau de façon globale avec cette commande :

nmcli network off
nmcli network on




***


Je viens d'acquérir beaucoup plus d'expérience avec nmcli mais il reste encore des aspects à explorer. Par exemple, il existe un éditeur de connexion interactif que nous pouvons lancer ainsi :

nmcli conn edit

Cependant, je ne le traiterai pas ici.

De plus, nous avons la possibilité d'utiliser plutôt l'outil nmtui mais une présentation plus détaillée dépasse de loin le cadre de cet article. Je dirai simplement qu'il suffit de taper "nmtui" pour le lancer. Voici à quoi ressemble l'outil :



Parmi les aspects de la communication réseau que je voudrais traiter à l'avenir (dans mes prochains articles ou plus tard) il faut compter les outils de diagnostic (comme ping, traceroute et netstat) ainsi que SSH et firewalld.



Saturday, April 28, 2018

CentOS (FR) 01 - le retour - Network Manager - nmcli

English summary: after a first look at CentOS/RHEL in 2016, I take a new look at some components like Network Manager. Network Manager (and its command line equivalent nmcli) is now the primary tool for managing network devices and connectivity, rather than the manual editing of configuration files.

***

En 2016, j'ai composé une série d'articles sur CentOS 7 qui a pour source "RHEL" (Red Hat Enterprise Linux). Sur le plan technique, le système d'exploitation est le même mais CentOS ne s'accompagne d'aucun contrat d'assistance technique (sinon le soutien communautaire, notamment via des forums en ligne).

Je tiens à me remettre à l'apprentissage de Linux (et CentOS/RHEL en partculier) parce que Linux s'utilise un peu partout désormais et représente sans conteste un système utile à connaître. De plus, CentOS/RHEL évolue comme n'importe quel autre système et certaines nouveautés, comme nmcli pour la gestion des paramètres de réseau, sont désormais la méthode préférée (plutôt que la modification des fichiers de configuration avec un éditeur de texte).

C'est justement le branchement au réseau que je veux revoir ici. Il y a deux ans, je n'avais fait que jeter un coup d'oeil à nmcli. Dans les paragraphes qui suivent, je vais configurer tous les paramètres de base avec cet outil.

*** 

En quelques mots, je vais présenter de nouveau les bases de nmcli.

D'abord, Network Manager (nmcli à la ligne de commande) est un service dont nous pouvons vérifier la bonne marche avec un autre outil, systemctl :

systemctl status NetworkManager.service


Ceux qui viennent de l'univers Windows doivent garder à l'esprit que Linux est sensible à la casse.

Exécuter la commande avec "networkmanager.service" donnerait lieu à une erreur.

Note de dépannage : si le service ne tourne pas, nous pouvons le lancer avec cette commande :

systemctl start NetworkManager.service

Autres options :

systemctl restart NetworkManager.service
systemctl stop NetworkManager.service


Network Manager (nmcli) nous permet de gérer cinq aspects de la mise en réseau :

  • general (g)
  • device (d)
  • connection (c)
  • networking (n)
  • radio (r)

Nous pouvons abréger nos commandes en ne tapant que la première lettre du mot en question, "c" pour "connection" par exemple.

Remarque : comme il s'agit de la configuration d'un serveur dans mon scénario, je ne traite pas ici la configuration sans-fil ("radio" ou "r").


Si nous exécutons les commandes de base, sans autres options ou paramètres, en voici le résultat :



Nous pouvons afficher plus de détails avec l'option "show" comme ceux du périphérique "ens33" dans l'exemple ci-dessous (commande complète et abrégée) :

nmcli device show ens33
nmcli d sh ens33



Le terme "device" désigne un périphérique réseau, de type "ethernet" dans ce cas. C'est une sorte d'interface.

Le terme "connection" correspond à un profil composé d'un ensemble de paramètres (adresse IP, passerelle, etc.) qu'on associe à l'interface.

Nous pouvons configurer plusieurs profils (plusieurs jeux de paramètres) mais un seul peut être actif pour une interface donnée à un moment donné.

Le nom de périphérique "ens33" est un "nom d'interface réseau prévisible" ou "predictable network interface name". Je ne redonne pas d'explication ici mais renvoie le lecteur à mon article précédent :

Network Manager - premiers pas

Bien entendu, vous pouvez aussi recourir à la documentation Red Hat, entre autres :

4.7.3. Nouveau schéma d'affectation de noms de réseau


***

Je pourrais continuer à présenter d'autres aspects de nmcli, les uns après les autres, mais je ferais sans doute mieux de passer à la configuration réseau d'un serveur, une forme d'apprentissage plus pratique.

En premier lieu, je configure le nom d'hôte. Par défaut, il est "localhost". Je renomme le serveur avec la commande suivante :

nmcli general hostname LX1

ou bien :

nmcli g hostname LX1

Note : j'aurais peut-être pu abréger davantage (nmcli g h LX1 ?) mais je n'insiste pas toujours quand la commande n'est pas longue.

Grâce a nmcli, nous ne sommes plus obligés de modifier les fichiers de configuration à la main mais j'étais tout de même curieux de voir ce qui se passerait dans le fichier de configuration "hostname". Voici la comparaison avant-après :



Pour constater le changement à l'invite, nous devons faire redémarrer le serveur :

shutdown --reboot (ou "-r")

Et voilà la nouvelle invite:


Nous sommes toujours "root" mais le nom d'hôte a bel et bien changé.


En second lieu, je configure le profil, c'est-à-dire les paramètres de réseau. Il est possible de modifier un profil existant mais nous pouvons aussi bien en créer un nouveau et l'associer à l'interface. Comme plusieurs profils peuvent coexister, mais un seul associé à une interface à la fois, tout autre profil en serait détaché. Je vais présenter chacun des paramètres, un à un, avec des valeurs de mon choix, puis l'ensemble dans la capture d'écran :

nmcli connection add
con-name PRD
ifname ens33
type ethernet
ipv4.method manual
ip4 10.2.2.1/8
gw4 10.1.1.3
ipv4.dns "200.67.220.220"

Remarque : oui, c'est l'adresse d'un serveur DNS chez OpenDNS.



Quand j'exécute "nmcli connection" de nouveau, je vois que l'association avec l'interface ens33 s'est faite de manière automatique (et s'affiche en vert - à comparer à la capture d'écran plus haut avec les commandes dites "de base") :


En cas de besoin, nous pouvons activer un profil nous-mêmes avec cette commande :

nmcli connection up PRD
nmcli c up PRD


Mais puis-je accéder à l'Internet ? Oui :



Remarque : ce n'est pas toujours le cas par défaut.


Je n'ai rien dit plus haut sur l'option "nmcli network" mais nous pourrions dire qu'elle donne l'état de l'accès Internet, "plein" dans notre exemple :

nmcli network connectivity


Selon le manuel, cinq états sont possibles (il les donne en anglais, même en version française) :

man nmcli network 



Si j'exécute les commandes "nmcli device" et "nmcli connection" maintenant, je vois plus de couleurs (notamment le vert) et l'association entre "device" et "connection" (périphérique et profil) :



Par ailleurs, je constate que la commande "ip address show" (et ses formes abrégées) fonctionne toujours (mais ne nous permet pas de faire de la configuration) :



L'affichage de certaines commandes peut être long. Pour nous déplacer là-dedans, nous pouvons recourir à la combinaison de touches Shift+PgUp et Shift+PgDn (sur mon clavier au moins). Nous pouvons aussi utiliser l'option d'affichage -p ("pretty") que je trouve assez utile dans cet exemple :

nmcli -p connection show PRD

L'affichage n'est pas moins long mais s'organise en catégories plus lisibles pour les humains.

Les fichiers de configuration se modifient selon les commandes nmcli que nous exécutons. Nous pouvons le constater en affichant le fichier qui correspond à l'interface en question :

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


Je constate cependant que nmcli possède sa propre syntaxe et ne modifie pas celle du fichier de configuration, les noms de paramètre par exemple :

nmcli : ip4 10.2.2.1/8

fichier : IPADDR=10.2.2.1
fichier : GATEWAY=10.1.1.3

Si nous y tenions par habitude, nous pourrions modifier les fichiers à la main avec vi ou un autre éditeur de texte et nmcli en tiendrait compte.