Friday, July 22, 2016

CentOS - à la ligne de commande - 07 : YUM

YUM... De quoi s'agit-il ?

C'est un outil qui nous permet d'installer, de mettre à jour, et de supprimer des logiciels.

Ces logiciels existent sous forme de "paquets" et, par défaut, yum accède à des dépôts de paquets en ligne, hébergés par diverses organisations (des universités de recherche comme Columbia ou Princeton, par exemple).

Nous pouvons donc décrire yum comme un "gestionnaire de paquets".

Remarque : en français, pour traduire "packet", on se sert soit du mot "paquet" soit du mot "paquetage". Dans ce texte, je vais choisir le premier.

Il est possible de télécharger des paquets et de créer un dépôt local afin d'éviter que chaque serveur doive charger les mêmes paquets via une connexion Internet avec (sans doute) moins de bande passante que le réseau local.

Pour la petite histoire, yum signifie "Yellow Dog Updater, Modified". A l'origine, c'est l'équipe responsable de la distribution Yellow Dog Linux qui l'a conçu. Ensuite, il a été modifié pour fonctionner avec d'autres distributions, CentOS/Red Hat en particulier.

Je vais présenter quelques commandes que j'ai essayées pour réaliser différentes tâches.

***


Afficher une liste de paquets

yum list

Cette commande affiche une liste de paquets. Le résultat est surabondant. Je ne m'y retrouve pas.

De plus, ce n'est pas clair. De quels paquets s'agit-il ?

Les commandes suivantes s'expliquent mieux...

yum list available

Ce sont les paquets qui sont disponibles (mais pas installés)


yum list installed

Cette commande affiche les paquets installés.


yum list all

Cette commande affiche à la fois les paquets disponibles et les paquets installés.


Toutefois, ce qui s'affiche à l'écran est interminable. Nous avons plusieurs options pour gérer la masse des paquets énumérés.

Nous pouvons afficher la première page des résultats et puis faire défiler le reste, ligne par ligne, avec cette commande (et en appuyant sur la touche Retour - ou Entrée) :

yum list | more


Nous pouvons rediriger les résultats vers un fichier avec cette commande (et puis ouvrir avec cat ou un éditeur de texte comme vi) :

yum list > liste
cat liste


Si nous voulions chercher une paquet spécifique, pour vérifier qu'il est installé (ou disponible), nous pourrions faire appel à grep, comme dans les exemples suivants :

yum list installed | grep net-tools



yum list available | grep nmap




Nous avons une autre option qui a l'avantage de fournir une petite description du paquet :

yum search nmap




Si nous avons affaire à un paquet dont nous ne connaissons pas la nature, nous pouvons toujours en afficher une description (souvent en anglais) avec la commande suivante :

yum info nmap



Abordons la chose par encore un autre côté. Les listes de paquets sont organisées en groupes. Au lieu d'afficher chaque paquet, nous pouvons plutôt afficher les groupes :

yum grouplist



Parmi les groupes disponibles, remarquons les bureaux GNOME et KDE (des interfaces graphiques pour Linux que nous pouvons installer).


J'ai écrit plus haut que yum télécharge les paquets à partir de dépôts en ligne ("repository" en anglais). Nous pouvons voir les dépôts que yum utilise par défaut avec cette commande :

yum repolist




Voir l'histoire des opérations

Outre les logiciels installés par défaut avec le système d'opération, quels paquets ont été ajoutés ensuite avec yum ? Nous pouvons le savoir avec la commande "yum history".

La commande suivante affiche une liste des paquets (ou "modules") chargés :

yum history list


Mais cette liste n'offre pas beaucoup de détail sur les opérations effectuées. Nous voyons, sous l'en-tête "Action", qu'il s'agissait surtout d'installations. Mais qu'est-ce qui a été installé au juste ? Nous pouvons savoir cela avec cette commande (suivie par le numéro de l'opération) :

yum history info 2


Dans ce cas (ci-dessus), c'est perl (langage de script) qui a été installé.

Dans les cas suivants, ce sont ces paquets qui ont été installés :

  • net-tools (le paramètre facultatif -y évite les confirmations)
  • bind-utils (pour DNS)
  • telnet telnet-server








Installer une interface graphique

Je me suis dit que le plus intéressant serait d'utiliser yum pour installer une des interfaces graphiques pour Linux, GNOME, KDE ou Xfce étant parmi les mieux connues. J'ai fini par réussir mais il a fallu que je fasse plus d'un essai.

D'abord, j'ai choisi Xfce (pour des raisons qui dépassent le cadre de ce billet de blogue). Or, Xfce ne fait pas partie des paquets disponibles par défaut (Voir la capture d'écran plus haut, sous "yum grouplist").

Comment faire alors ?

Outre les paquets disponibles dans les dépôts auxquels nous pouvons accéder par défaut (après la simple installation de CentOS), d'autres dépôts sont mis à notre disposition par des tierces parties.

"Extra Packages for Enterprise Linux" (EPEL) est un de ces dépôts. Il s'agit d'un groupe associé à la distribution Fedora qui fournit des paquets additionnels pour Red Hat Enterprise Linux (RHEL), CentOS et Oracle Linux, entre autres.

En voici un survol (en anglais - le français ne figure pas parmi les autres langues en option) :

EPEL

J'ajoute EPEL à la liste de mes dépôts avec la commande suivante :

yum install epel-release

Remarque : il existe apparemment d'autres méthodes pour faire cela, utilisant les commandes "wget" et "rpm". Je n'ai pas essayé ces méthodes mais elles produisent sans doute les mêmes effets. 

Une sorte d'installation a lieu (de l'index sans doute) et maintenant, si j'exécute la commande "yum repolist", je vois EPEL parmi les dépôts :




Pour l'étape suivante, j'installe Xfce avec cette commande :

yum groupinstall Xfce

Remarque : j'ai vérifié la présence de Xfce parmi les dépôts avec "yum grouplist".


Puis, je configure le démarrage pour que l'interface graphique soit lancée :

systemctl set-default graphical.target



Remarque : il y a aussi d'autres méthodes d'ajuster l'interface qui se présente au démarrage. Je me suis contenté de celle-ci.

Mais au démarrage, Xfce ne se charge pas... Pourquoi ?

Je mets à jour tous les paquets installés...

yum update

Toujours rien.

En principe, yum devrait savoir s'il y a des logiciels qu'il faut installer d'abord, en tant que "pré-requis", les installer, et puis installer le paquet que nous souhaitons.

En pratique, il semblerait que ces calculs ne soient pas toujours parfaits.

Je découvre la cause du problème en tentant de lancer Xfce depuis la ligne de commande avec...

startx

Ce message d'erreur s'affiche :



Après avoir consulté diverses sources, j'ai conçu l'hypothèse que Xfce nécessite "X Windows" comme pré-requis. En effet, certaines sources présentaient Xfce comme un "gestionnaire" de X Windows. Si celui-ci était absent, il serait difficile de le "gérer".

J'installe donc X Windows :

yum groupinstall "X Windows System"

Cette fois, au redémarrage, je vois une interface graphique et après avoir ouvert une session, j'ai devant moi le bureau Xfce :



***

En conclusion, je veux ajouter encore quelques commandes que je n'ai pas utilisées mais qui me seront sans doute utiles à l'avenir.

Pour supprimer un paquet :

yum remove


Pour supprimer un group de paquets :

yum groupremove


Nous avons vu la commande pour mettre à jour les paquets installés (yum update) mais si nous voulons seulement voir s'il y a des mises à jour, nous nous servons de cette commande :

yum check-update


Pour recréer l'index des paquets disponibles aux dépôts :

yum clean all

Monday, July 11, 2016

CentOS - à la ligne de commande - 06 : Network Manager (nmcli)

Dans le passé, la gestion des interfaces réseau consistait surtout à éditer des fichiers de configuration définissant les paramètres de ces interfaces. Cette méthode est encore valable. Mais avec RHEL/CentOS7, nous avons une autre option pour la configuration des paramètres réseau : "Network Manager" ou son équivalent à la ligne de commande "nmcli".

Dans ce billet de blogue, je vais me concentrer sur nmcli.

***

Network Manager est un service. Nous pouvons vérifier son état avec "systemctl".

Nous devons nous rappeler que sous Linux, la casse compte. Par exemple, j'ai d'abord tapé (exprès) :

systemctl status networkmanager.service

Ce qui a donné lieu à un message d'erreur. En effet, il faut respecter la casse et pour Network Manager, il faut plutôt taper :

 systemctl status NetworkManager.service



En outre, nous pouvons voir (et même modifier) la configuration réseau avec "ip address".

Cependant, quelques remarques s'imposent...
  • Je crois, sans être certain, que "ip address" est un outil qui remplace ifconfig, tout en étant distinct de Network Manager. En effet, les commandes nmcli commencent toutes par "nmcli quelque chose" tandis que "ip address" semble fonctionner sans avoir recours aux éléments de Network Manager.
  • Bien qu'il soit possible de configurer des interfaces avec "ip address", la configuration n'est pas permanente et ne "survit" pas à un redémarrage de la machine.
  • Nous avons une grande latitude pour abréger les différentes commandes.
Concernant ce dernier point, en voici quelques exemples. Pour afficher la configuration d'une interface, nous pouvons obtenir le même résultat avec n'importe laquelle de ces variations :
  • ip address show
  • ip address (apparement, la commande affiche la configuration en l'absence d'autres paramètres)
  • ip addr
  • ip a

Cela donne quelque chose comme ceci (avant la configuration d'une adresse statique) :



Entre autres choses, cet affichage montre l'adresse IP et le masque de réseau.

Pour voir la passerelle par défaut, nous devons taper "ip route" :



Quoi qu'il en soit, nous devons préférer "nmcli" à "ip" si nous voulons configurer les interfaces réseau avec des paramètres permanents.

nmcli comprend cinq sections dans lesquelles nous pouvons exécuter des commandes :
  • connection (c)
  • device (d)
  • general (g)
  • networking (n)
  • radio (r)
Remarque : nous pouvons abréger en ne tapant que la première lettre du mot en question, "c" pour "connection" par exemple.

Il y a une multitude de commandes que nous pourrions exécuter, mais je vais m'en tenir à celles que j'ai trouvées les plus utiles pour la configuration de l'interface réseau de ma machine virtuelle. Je destine cette machine à jouer le rôle de serveur dans les expériences à venir. Dans ce contexte, et bien qu'il puisse y avoir de multiples "profils" réseau (plus intéressant pour un portable), nous n'aurons qu'un seul profil à gérer dans ce cas.

Prenons donc quelques exemples pour illustrer la manière de voir les paramètres d'une interface réseau.

nmcli device

Cette commande affiche les interfaces réseau, y compris "lo" (loopback ou "boucle").

Encore une fois, nous pouvons abréger avec la première lettre du mot  "device", donc "d", comme j'ai fait dans la capture d'écran ci-dessous (voir plus bas).


nmcli device show eno16777736

Cette commande affiche plus de détails, tels que l'adresse IP, le masque de réseau et la passerelle par défaut.

Voici à quoi cela ressemble :




nmcli connection add

Cette commande nous permet d'ajouter une connexion (ou profil)  réseau - à ne pas confondre avec un périphérique ("device") :


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

Dans l'exemple ci-dessus, je désigne notamment...

  • le nom de la connexion : lxlab (c'est un nom que je choisis - lxlab come "Linux lab"
  • le nom de l'interface : eno16777736 (la seule présente, outre la boucle ou "loopback"

C'est avec cette commande donc que je configure l'adresse IP, le masque de réseau et la passerelle par défaut.

Pour les serveurs DNS, je me sers de cette commande :

nmcli con mod lxlab ipv4.dns "adresse IP du serveur ou des serveurs DNS" :



Quant au nom d'hôte, c'est la commande "nmcli general hostname" qu'il faut utiliser (et puis relancer le service systemd-hostnamed) :



J'observe qu'un nouveau fichier de configuration vient d'être créé dans le répertoire "network-scripts" :


Ainsi, au lieu de modifier les paramètres du fichier ifcfg-eno16777736, Network Manager (nmcli) a créé un nouveau fichier avec les paramètres que nous avons définis plus haut, soit le fichier  "ifcfg-lxlab" :


Cependant, j'ai aussi observé que c'est le fichier ifcfg-eno16777736 qui est toujours associé à l'interface eno16777736 (il l'est par défaut). Pour que les nouveaux paramètres prennent effet, il faut que je fasse de "lxlab" la connexion active (ou le "profil" actif ) :



Résultat : ce sont maintenant les paramètres que j'ai configurés plus haut qui sont associés au périphérique eno16777736 :



***


En somme, il convient donc de distinguer "device" et "connection" :

  • Le premier, c'est une interface réseau, un périphérique physique ou virtuel, bref, une chose.
  • Le second, c'est un ensemble de paramètres qui constitue la configuration logique de l'interface, synonyme de "profil".

Il y a, dans le répertoire "network-scripts", un fichier associé à chaque profil réseau (ou connexion), par example "ifcfg-lxlab" ou "ifcfg-eno16777736".

Pour un serveur à un seul profil, nous utiliserons le plus souvent les commandes "nmcli device" et "nmcli connection". "nmcli general" sert (entre autres) à configurer le nom d'hôte alors que "nmcli networking" affiche l'état de la connexion (activée ou inactivée). "nmcli radio" concerne les interfaces sans-fil, d'habitude peu utilisées dans le serveurs.


Tuesday, July 5, 2016

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

Mes premières expériences avec la ligne de commande de Linux (CentOS en particulier), m'ont amené à utiliser deux commandes qui se ressemblent par certains côtés mais qu'il convient de distinguer : sudo et su. Voici quelques observations et remarques.

sudo

sudo sert à exécuter une commande que normalement seul root pourrait exécuter. Il faut faire précéder par sudo chaque commande qu'on voudrait exécuter.

Nous avons vu dans un billet précédent que c'est le fait d'appartenir au groupe "wheel" (oui, "roue" en français) qui autorise ce genre d'opération.

su

su sert a emprunter l'identité d'un autre utilisateur après avoir saisi le mot de passe de celui-ci. Il faut donc connaître le mot de passe de l'autre utilisateur.

Une fois que nous "devenons" l'autre utilisateur, nous pouvons exécuter toutes les commandes qu'il pourrait normalement exécuter.

Donnons un exemple (voir la capture d'écran qui suit).

  • Je me connecte d'abord comme Alex Heyne, ou "aheyne", mais je veux emprunter l'identité de "boss" pour exécuter tout un ensemble de tâches (plutôt qu'une ou deux commandes).
  • Je tape "su boss" et je saisis le mot de passe de boss à l'invite.
  • Je tape "whoami" pour vérifier que je suis bien "boss".
  • Je quitte l'identité de "boss" en tapant "exit".




Remarque : à l'invite, nous voyons d'abord...

[aheyne@localhost ~]$

puis...

[boss@localhost aheyne}$

après l'exécution de la commande "su boss" puis...

 [aheyne@localhost ~]$

à nouveau après avoir quitté l'identité de "boss".

Quand nous utilisons "su", le nom de l'utilisateur dont nous empruntons l'identité vient d'abord, suivi du nom de l'utilisateur "effectif", celui qui a ouvert la session initiale.

***

su nous permet d'emprunter l'identité d'un autre utilisateur et d'exécuter des commandes avec ses privilèges. Pourtant, la transformation n'est pas totale. Nous agissons toujours dans l'environnement de l'utilisateur qui a ouvert la session : Alex Heyne dans l'exemple ci-dessus.

Par exemple, que se passe-t-il quand nous exécutons la commande "ls", ciblant le répertoire home de l'utilisateur ?



Avant "su boss", nous voyons s'afficher le contenu du répertoire /home/aheyne.

Après "su boss", j'ai beau avoir emprunté l'identité de boss, je ne peux pas afficher le contenu de son répertoire /home/boss

Mais si nous utilisons l'option "su -l nom d'utilisateur" (-l signifie "logon") c'est comme si nous ouvrions une nouvelle session (logon) en tant que l'utilisateur en question et nous avons accès à tout son environnement.

Quand nous tentons alors d'exécuter la commande "ls", nous pouvons en voir le contenu : dans le cas de "boss", rien.  

***

Si je tape su (sans rien de plus), une invite pour un mot de passe s'affiche.

Mais quel mot de passe ?

Quand nous utilisons sudo, c'est le mot de passe de l'utilisateur en session qui nous saisissons. A condition d'être membre du groupe  "wheel", nous pouvons exécuter des commandes avec les privilèges de root.

Quand nous utilisons su, c'est le mot de passe de l'utilisateur dont nous voulons emprunter l'identité que nous devons saisir.

Dans ce cas particulier, il faut savoir que "su", sans autre paramètre, est en fait un raccourci pour "su root".

Autrement dit, "su" suppose qu'il s'agit de root à moins que nous précisions un autre utilisateur.

Je saisis donc le mot de passe de root (avant d'appuyer sur Retour) et nous constatons que j'ai emprunté l'identité de root.



Pour reprendre l'identité de "boss", il suffit de taper "exit".

Si, pour une raison ou une autre, nous voulons accéder à tout l'environnement de root, nous pouvons ouvrir une session (sans fermer la session courante) comme nous avons fait plus haut, en utilisant la paramètre -l :

su -l












Monday, July 4, 2016

CentOS - à la ligne de commande - 04 : Telnet et plus

Dans ce billet, je vais jeter un coup d'oeil sur trois aspects de Linux qui n'ont sans doute pas a priori un rapport bien clair entre eux :

  • telnet
  • firewalld
  • sudo

Voici ce qui relie ces trois éléments et en fait les sujets de ce billet de blogue.

Au fond, c'est quelque chose d'aussi banal que pratique.

J'avais l'habitude, en composant mes billets de blogue, de sélectionner les caractères que je tapais à la ligne de commande, de les copier et puis de les coller à tel ou tel endroit dans le billet de blogue. Cela fonctionnait à la perfection dans VMware Workstation avec Windows (une fois les outils VMware installés) mais pas du tout avec Linux (et cela même après avoir installé les outils VMware). J'ai essayé une session SSH depuis un client Windows avec Putty mais les opérations copier/coller n'étaient pas efficaces, là non plus. Je me suis alors demandé si je pourrais mieux réussir avec le client Telnet de Windows, à condition d'autoriser des connexions Telnet entrantes du côté Linux.

Cette tentative constitue la toile de fond de ce billet.


Telnet (et firewalld)

J'ai donc commencé par installer le client Telnet sur LX1 (le nom de hôte de ma machine virtuelle Linux) et autoriser les connexions entrantes. Voici comment je m'y suis pris...

1. J'installe le client Telnet :

yum install telnet telnet-server


2. Je fais démarrer le service et le configure afin qu'il s'active au démarrage.

systemctl start telnet.socket
systemctl enable telnet.socket

Remarque : j'en ai profité pour apprendre à gérer les services sous Linux avec la commande systemctl.


3. Je modifie les règles du pare-feu pour autoriser les connexions entrantes au port 23 (Telnet).

firewall-cmd --permanent --add-port=23/tcp
firewall-cmd --reload

Remarque : la seconde commande fait que le changement prenne effet tout de suite et sans attendre le redémarrage du client.

Remarque : "iptables" était le pare-feu de préférence pour les versions précédentes de RHEL/CentOS, notamment les versions 5 et 6. Désormais, il est recommandé d'utiliser "firewalld" bien que nous puissions encore utiliser iptables (si nous y tenons).


Et malgré tout cela... je n'arrive pas à établir une connexion.

C'est parce que, jusqu'ici, je me suis contenté d'ouvrir des sessions sous "root".

En fait, nous devrions éviter d'utiliser le compte root et préférer d'autres comptes dits "standard". C'est le même principe dans le monde de Windows. Nous ne devrions pas utiliser, sauf raison exceptionelle, le compte "administrator" par défaut (ou dans le cadre d'Active Directory, le compte de l'administrateur de domaine par défaut).

J'ai maintenant deux options. Je pourrais autoriser les connections de root via Telnet. Mais, même dans ce réseau d'essai, sans aucune donnée confidentielle à sauvegarder, je désapprouve ces entorses aux bonnes pratiques de sécurité. Mieux avisé, je pourrais plutôt (seconde option) créer un simple compte de base tout en lui accordant la capacité de recourir à sudo en cas de besoin.

Remarque : nous ferions mille fois mieux d'utiliser SSH au lieu de Telnet. J'ai bien utilisé SSH pour mes premiers exercices sous Linux mais la fonction copier/coller (pour que je puisse coller les commandes exécutées dans mes textes de blogue) n'était pas efficace. C'est d'ailleurs la seule raison pour laquelle j'ai envisagé l'idée, a priori folle, de recourir à Telnet. Avec celui-ci, à une console de Windows, je peux sélectionner du texte, le copier, et puis le coller dans mes billets de blogue ou simplement dans mes brouillons.


sudo

D'abord, je veux résumer ce qu'est sudo afin que ce soit clair non seulement pour le lecteur mais déjà pour moi-même !

sudo est un mécanisme commun aux systèmes Linux/Unix qui permet à de simples utilisateurs, avec des permissions limitées, d'exécuter des commandes avec les permissions de "root" (soit le "compte administrateur par défaut" pour ceux qui connaissent mieux Windows). Cela, c'est le principe. La mise en oeuvre exacte varie selon les versions de Linux/Unix et ces variations dépassent le cadre de ce billet de blogue. Au fond, il s'agit de créer un compte d'utilisateur simple ou "standard" et d'ajouter ce compte au groupe d'utilisateurs autorisés à exécuter des commandes avec les privilèges de root. Pour des raisons historiques, remontant aux années 1960 (oui !), le groupe en question s'appelle "wheel" ("roue" en français). Au préalable, il faut modifier le fichier de configuration /etc/sudoers afin d'activer cette fonction.

Remarque : une autre option existe : su. Nous pouvons agir en tant qu'un autre utilisateur en tapant "su", le nom de l'utilisateur, et puis, à l'invite, le mot de passe de cet utilisateur dont nous prenons l'identité. Avec sudo, nous n'avons pas besoin de connaître le mot de passe de root. A condition d'être membre du groupe "wheel", nous pouvons exécuter des commandes avec les privilèges de root.


1. J'ouvre le fichier de configuration /etc/sudoers avec la commande visudo.

Remarque : il suffit de taper "visudo" pour ouvirir le fichier en question.

2. Je supprime le carré devant la ligne suivante :



3. Je crée un compte utilisateur simple que je nommerai "boss".

useradd boss
passwd boss


4. J'ajoute l'utilisateur au groupe "wheel" :

usermod -aG wheel boss

Ensuite, je vérifie que le compte "boss" est bien membre du groupe  "wheel" et que les commandes que j'envoie s'exécutent bien comme si j'étais root :



Avec "su" ("substitute user"), je "deviens" boss et dois saisir son mot de passe.

Je tape "groups" et les groupes dont boss est membre s'affichent.

Puis, j'exécute la commande "whoami" précédée de "sudo". C'est "root" qui s'affiche tout en bas (à gauche dans la capture d'écran ci-dessus).

***


Et maintenant, essayons de voir si je suis capable d'ouvrir une session Telnet avec le compte boss...


Oui ! Cela réussit. Mieux encore, les objets s'affichent en couleur, bleu désignant les répertoires par exemple.

Et j'atteins l'objectif de pouvoir copier/coller du texte pour mes billets de blogue :

Kernel 3.10.0-327.el7.x86_64 on an x86_64
localhost login: boss
Password:
Last login: Thu Jun 30 21:41:54 on tty1
[boss@localhost ~]$
[boss@localhost ~]$ ls
[boss@localhost ~]$ ls /
bin  boot  dev  etc  home  lib  lib64  media  mnt [snip]
[boss@localhost ~]$

(oui, j'ai copié et collé ce qu'on voit dans la capture d'écran plus haut).