Variables d’environnement

La variable PATH contient les chemins dans lesquels le shell cherche les programmes à lancer.

Afficher le contenu de cette variable via la commande echo $PATH.
Modifier cette variable pour y ajouter le chemin de Desktop : PATH=$PATH:~/Bureau. Exécuter which firefox pour voir le chemin complet du navigateur. which ls.
Créer un script truc.sh dans ~/Bureau. Le lancer sans chemin. which truc.sh.
Modifier la variable PATH pour qu’elle ne contienne rien (PATH=). Qu’arrive-t-il aux commandes ?
La variable HOME contient le chemin de votre dossier personnel. La variable PWD contient le chemin courant. HOST contient le nom de l’ordinateur courant. RANDOM contient un nombre aléatoire (change à chaque appel). PROMPT contient l’invite de commande du shell.
la commande env permet de voir l’environnement.

Toutes ces variables se comportent comme PATH : si elles sont exportées, elles se transmettent aux processus fils ; le contenu de la variable est obtenu en le précédant d’un $.

Le fichier .bashrc est lu à chaque démarrage du shell. Si on veut que des réglages se conservent au prochain démarrage, on peut ajouter ces réglages dans ce fichier. Si on y met des commandes, elles seront elles aussi exécutées au démarrage du shell. Par exemple, ajoutons echo Bonjour $USER dans le .bashrc. Au prochain lancement de bash, nous serons salué.

Changer la valeur de la variable HOME (par exemple pour /tmp). Que fait cd sans argument.
Quelles autres variables sont données par env ?

Alias

Il est également possible d’ajouter des raccourcis de commande. Par exemple pour que cd.. fasse l’effet de cd .., on peut ajouter alias cd..="cd ..". On peut même aliaser des commandes existantes (par exemple remplacer ls par echo *, ou de façon plus intéressante lui ajouter des options).

Créer un alias ll qui donnera la liste avec plus d’information que ls.
Créer un alias acp qui donnera la version d’un paquet passé en argument.

FHS

Les systèmes Unix s’attachent à respecter un certain nombre de normes et standards, parmi ceux-ci, le FHS (Filesystem Hierarchy Standard) décrit la structure du système de fichier. Des distinctions existent dans certains Unix (en particulier Mac OSX), mais il est bon de connaître cette hiérarchie. Le tableau suivant est inspiré de Wikipedia.

Chemin	Description
/bin	Binaires (commandes) de base
/boot	Amorçage (bootloader + noyaux)
/dev	Périphériques (devices)
/etc	Fichiers de configuration (Editable Text Configuration)
/home	Répertoires utilisateurs
/lib	Bibliothèques logicielles de base (libraries)
/media	Points de montage pour les médias amovibles (clefs USB)
/mnt	Points de montage temporaires (mount)
/proc	Processus (système de fichiers virtuel)
/root	Répertoire de l’utilisateur root
/sbin	Binaires pour administrateur (system binaries)
/tmp	Fichiers temporaires
/usr	Hiérarchie système (contient des dossiers bin, lib, …)
/var	Fichiers variables

Intéressons-nous maintenant plus en profondeur à certains de ces dossiers :

/dev

Les périphériques sont listés dans le dossier /dev. On peut ainsi y voir les disques durs ‘/dev/[hs]d[a-e]*’. Des périphériques virtuels /dev/null, /dev/zero, /dev/random…

Afficher le contenu de /dev/null.
Rediriger la sortie d’une commande vers /dev/null. Que contient /dev/null ?
À l’aide de la commande dd, copier 128 ko de /dev/zero dans un fichier.
Afficher le contenu du fichier (utiliser xxd ou hd plutôt que cat).
À l’aide de la commande dd, copier 128 ko de /dev/urandom dans un fichier. En afficher le contenu.

/proc

/proc
|-- 1
|   |-- cmdline
|   |-- environ
|   |-- fd
|   |   `-- ...
|   `-- status
|-- 1186
|   `...
|-- cpuinfo
|-- loadavg
|-- stat
|-- uptime
`-- version

man 5 proc
Trouver le PID de firefox et explorer le dossier de /proc correspondant. Regarder en particulier les fichiers et dossiers énumérés ci-dessus.
Trouver dans ce dossier le modèle du CPU, sa fréquence, son nombre de coeurs.
Trouver la version du noyau et de la distribution utilisée.
Trouver depuis combien de temps l’ordinateur tourne.

/etc

etc = Editable Text Configuration

Ce dossier abrite les fichiers de configuration générales au système des différents outils installés.

Nous avons déjà vu /etc/sudoers, /etc/passwd et /etc/shadow.

Mais on trouve aussi /etc/bash.bashrc : configuration de base du shell bash. /etc/apt/sources.list liste des dépôts utilisés par apt. /etc/hostname contient le nom de la machine…

Administration

Locate

Un service nommé updatedb se charge régulièrement d’indexer les fichiers présents sur la machine. Grace à lui, on peut localiser un fichier dont on connaît le nom mais pas le chemin.

locate firefox
man locate
man updatedb
man 5 mlocate.db

Tâches programmées

Il est possible de programmer des tâches pour qu’elles se lancent plus tard (par exemple dans 17 minutes ou à minuit) ou encore pour qu’elles soient exécutées régulièrement.

Autrefois, les commandes utilisées pour cela étaient cron, crontab et at. Aujourd’hui, sous Linux, c’est systemd qui s’en occupe ; sous macOS, c’est launchd qui s’en charge ; sous BSD, on utilise toujours cron et at.

Avec systemd, on utilise des timers. Les timers sont des fichiers décrivant les activités à faire et leur périodicité. Ils peuvent activer des services (qui sont eux-mêmes gérés par systemd)

systemctl list-timers
Choisir une UNIT, rechercher le fichier la décrivant, lire ce fichier.
Dans le fichier .timer, la ligne OnCalendar décrit quand ce service doit s’exécuter. Essayer de comprendre le codage de cette périodicité (man systemd.time).

On peut créer des tâches à n’exécuter qu’une seule fois. On parle alors de “Transient timers” (par opposition aux tâches répétées qui sont “persistent”).

Créer avec la commande systemd-run une tâche qui va copier le dossier Bureau dans un dossier backup dans quelques minutes.
Cette tâche apparait-elle dans la sortie de systemctl list-timers ?
Ces tâches sont effectuées dans un autre shell, donc la sortie de la commande n’apparaitra pas dans le terminal !

Arrêt et redémarrage

L’arrêt, le redémarrage et la veille d’une machine peuvent être exécutées depuis la ligne de commande. Cela se fera à l’aide de sous-commandes de systemctl (c’est-à-dire avec systemd).

systemctl poweroff
systemctl halt
systemctl reboot
systemctl hibernate
systemctl suspend
systemctl hybrid-sleep
Que font ces commandes ?
Qui a le droit d’exécuter ces commandes ?

Services

On nomme services (ou en Unix daemons) les programmes lancés en tâche de fond par le système. Par exemple le serveur ssh, le serveur http, le serveur postgresql sont des services. Il est possible de contrôler les services lancés : les stopper, les relancer, définir s’ils doivent être exécutés à chaque démarrage de l’ordinateur à l’aide de systemctl (encore une fois, sur les linux modernes, c’est systemd qui gère les services, sur d’autes systèmes, il peut s’agir d’upstart, init, sysV, launchd qui sont en général utilisables par la commande service).

Note : les commandes suivantes peuvent être “pipées” vers cat pour éviter dêtre en mode interactif.

systemctl status
systemctl list-units
systemctl list-unit-files

Les unit sont donc des fichiers définissant la façon de lancer un service et les units dont il dépend. Ainsi le sshd.service nécessite d’avoir du réseau (network.target) et est nécessaire pour le démarrage en mode multi-utilisateur (multi-user.target). Note : les target sont des unités qui ne lancent pas forcément de programmes mais sont pratiques pour définir les dépendances.

Trouver les informations de dépendances de sshd.

Certains services ne sont pas lancés au démarrage mais quand ils sont utilisés. Ainsi, pour un serveur http ou ssh ou…, on pourrait décider de ne lancer le serveur que si une connexion sur le port 80 (respectivement 22) est demandée. Dans ce cas, on a des unit qui sont des .socket au lieu de .service. Cela signifie que les informations transmises par netstat ou ss sur les ports sur lesquels l’ordinateur écoute peuvent ne pas être tout à fait fiable : le fait que systemd écoute sur le port 80 pour savoir s’il faut lancer un serveur http n’implique pas que le serveur fonctionne.