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.