Bref exposé d'Unix et de POSIX

Comptes d’utilisateur

Comme sur tous les systèmes d’exploitation modernes, chaque utilisateur d’un système Unix dispose de son propre compte. Ce dernier sert à stocker les paramètres et les fichiers de l’utilisateur, et permet à l’administrateur système de régler l’accès aux fichiers, aux répertoires, aux applications et aux périphériques. De plus, certaines applications, appelées daemons, disposent d’un compte qui leur est propre ; ceci permet à l’administrateur système, par exemple, de limiter l’accès du serveur web aux répertoires qui contiennent les sites web.

Le compte de gestion d’un système Unix s’appelle root (racine) ; celui-ci est comparable au compte nommé admin ou administrator sur d’autres systèmes, et c’est le seul avec des droits suffisants pour pouvoir modifier chaque composant du système. Normalement, il n’y a pas d’utilisateur physique derrière le compte root ; il s’agit d’un compte qui sert à des administrateurs sélectionnés pour réaliser des interventions spécifiques.

Les comptes d’utilisateur et leurs droits seront décrits dans le chapitre Gestion des utilisateurs et des droits.

Normalement, chaque compte d’utilisateur dispose d’un...

Shell

Après s’être connecté au système, l’utilisateur se trouve dans un environnement dans lequel des commandes peuvent être entrées ; ce dernier s’appelle le shell (coque). Le shell reçoit des commandes de l’utilisateur et les exécute à l’aide des applications installées sur le système.

En plus des commandes pour les applications installées sur le système, le shell dispose de ses propres commandes. Le shell installé détermine les commandes disponibles et leur syntaxe. Plusieurs shells existent, et même s’ils ont tous le même but, les utilisateurs Unix développent souvent une préférence pour un certain shell, basée par exemple sur les raccourcis-clavier proposés, ou sur la syntaxe des commandes intégrées.

Le shell le plus utilisé s’appelle Bash ; il est installé comme shell par défaut sur beaucoup de systèmes Linux, et la majorité des utilisateurs ne prend pas la peine d’en essayer d’autres. Le standard POSIX impose qu’au moins un shell nommé sh soit installé et qu’il exécute les commandes selon la syntaxe du Shell Command Language (Langage des commandes du shell), également défini par POSIX. Souvent, sh (installé sous /bin/sh sous Linux et FreeBSD) est un raccourci vers Bash. Si Bash est exécuté sous /bin/sh, son comportement sera comparable à celui de sh ; si Bash est exécuté en tant que bash, son comportement diffère et il a davantage de fonctionnalités.

Sous FreeBSD, le shell par défaut est sh. Le prochain chapitre, Gestion des logiciels, expliquera comment installer Bash sur FreeBSD.

L’interface qui reçoit des commandes de l’utilisateur pour les exécuter en les validant avec [Entrée] s’appelle l’interface en ligne de commande (en anglais : Command Line Interface, ou simplement CLI).

Le shell indique attendre des commandes en montrant dans l’invite de commandes (en anglais prompt) une chaîne de caractères reconnaissable. Une convention suivie par beaucoup de shells est que l’invite se termine par le symbole du dollar ($) pour les utilisateurs ordinaires et qu’elle se termine par dièse...

Structure des répertoires

La structure des répertoires d’un système Unix peut être dispersée sur plusieurs stations physiques (disques, partitions, stations de réseau, etc.). Les endroits qui se trouvent en dehors du disque ou de la partition primaire peuvent être montés sur un répertoire existant. Comme le système a déjà été installé, que tous les disques et partitions présents ont donc été montés, et que le serveur n’utilisera pas de stations amovibles comme les CD et les clés USB, ce livre n’abordera pas le montage des stations physiques. L’administrateur système qui chercherait à en apprendre davantage, pourra se référer à la documentation des commandes mount et umount, et du fichier fstab.

Une adresse dans la structure des répertoires est appelée un chemin, ou path en anglais. Ce chemin est composé des noms de répertoires, séparés par des barres obliques (/ ; en anglais : slash). Les barres obliques séparent les répertoires et sous-répertoires. Le répertoire à la droite d’une barre oblique est le sous-répertoire de celui qui précède la barre oblique ; le chemin /etc/ssh/sshd_config indique que le fichier sshd_config figure dans le répertoire ssh, qui à son tour se trouve dans le répertoire etc. Comme les stations supplémentaires sont montées sur des répertoires dans le système de fichiers, et non pas en dehors de celui-ci, le chemin ne commence pas par une lettre, comme sous Windows.

En dehors des fichiers et des répertoires, il existe quelques autres éléments importants dans le système de fichiers Unix :

Les périphériques (en anglais, singulier device)

Les liens (en anglais, singulier link)

Ports logiciels

Les ports logiciels ne sont pas une fonctionnalité Unix. Cependant, ils sont davantage visibles sur Unix que sur des systèmes non Unix ou des stations de travail ; il est donc utile de les traiter brièvement.

Les ports logiciels sont des adresses virtuelles qui sont attribuées aux différents services et protocoles traités par le serveur. Les ports 80 (HTTP) et 443 (HTTPS), par exemple, sont normalement attribués au serveur web. Si le navigateur web demande à recevoir le fichier http://www.example.com/index.html, cette requête est envoyée au port 80 du serveur et une requête pour la variante HTTPS est envoyée au port 443. Côté serveur de cette communication, le serveur web (Apache ou Nginx par exemple) ’écoute’ sur ces ports et répond aux requêtes entrantes.

Il est essentiel pour un administrateur système de savoir, ou en tout cas de savoir trouver, quels ports sont utilisés par quels services. Cette information sert surtout à la résolution des problèmes au niveau réseau et à la configuration du pare-feu.

Le fichier /etc/services contient un grand nombre d’associations port/protocole.

Pour une vue d’ensemble des ports sur lesquels écoutent (attendent des requêtes des clients) des services à un moment donné, la commande netstat est utile :...

Processus

Les applications chargées dans la mémoire vive - donc les applications démarrées et pas encore terminées - sont appelées des processus. Il existe des processus qui sont actifs pendant longtemps, comme le serveur web qui est démarré et attend des requêtes et des processus qui sont actifs pendant une courte durée, comme la commande cd, pour changer de répertoire.

Les processus peuvent s’afficher dans une arborescence : chaque processus, sauf le premier, a été lancé par un autre processus. Évidemment, un processus peut être lancé par un utilisateur en tapant une commande dans le shell, mais le shell est un processus lui-même. Le shell, à son tour, a été lancé par le processus de connexion, etc. Le premier processus dans cette arborescence s’appelle init, comme l’application d’origine SysV init, même si l’application peut porter un autre nom aujourd’hui ; init est le premier processus à être lancé, et le dernier à être terminé.

Chaque processus porte un numéro unique, ce qui sert par exemple à forcer son arrêt. Ce numéro s’appelle le PID (en anglais : process identifier, identifiant du processus) et init porte le PID 1.

Chaque processus est exécuté sous l’identifiant d’un utilisateur ; il dispose des droits de cet utilisateur. Si le processus est lancé par un utilisateur, par exemple en entrant une commande sur la ligne de commande, le processus hérite généralement du nom et des droits de l’utilisateur. Dans certains cas, le processus obtient un autre nom d’utilisateur ; ces processus seront traités dans la section Daemons.

Daemons

Les daemons (prononcé dimon ou démon) sont des processus exécutés en arrière-plan, ce qui veut dire qu’ils ne sont pas liés à une ligne de commande, et que les utilisateurs ne peuvent donc pas communiquer directement avec eux. Sous d’autres systèmes d’exploitation, ces processus sont aussi connus comme des services. Des exemples de daemons sont le serveur web et le serveur DNS, mais aussi, par exemple, le processus init, le parent de tous les autres processus, qui a été décrit plus haut. On pourrait dire que, en service normal, chaque logiciel serveur est un daemon, mais les daemons ne sont pas tous des logiciels serveur.

Souvent, les daemons enregistrent leur PID dans un fichier texte, pour facilement le retrouver. Un tel fichier s’appelle un PID file (fichier PID) et est stocké dans le répertoire /run ou dans le répertoire /var/run.

Normalement, les daemons sont lancés par l’utilisateur root, directement ou indirectement. Par contre, les exécuter pour le compte de root présente un risque : cela donne au processus les mêmes droits qu’à root, ce qui peut causer de grands dommages sur le serveur, délibérément ou pas. C’est pour cette raison que, historiquement, les daemons s’exécutent souvent sous le nom d’utilisateur nobody (personne) et sous le nom de groupe nogroup (sans groupe), un utilisateur et un groupe sans droits spéciaux. Par contre, si tous les daemons s’exécutent sous le même compte, ils peuvent s’envoyer des signaux et parfois même modifier la configuration d’autres daemons. C’est pour cela qu’aujourd’hui, à l’installation d’un daemon, un utilisateur est normalement créé spécialement pour ce daemon ; cela permet à l’administrateur système de limiter les droits de chaque daemon.

Les noms de daemons se terminent souvent par la lettre "d", pour indiquer qu’il s’agit d’un daemon (sshd, named, httpd, crond) mais pas tous (dovecot, freshclam). Par contre, tous les processus dont le nom se termine par "d" ne sont pas des daemons.

Documentation

La documentation sur les concepts, les configurations et les installations sont nombreuses sur internet et dans les livres. Mais il est parfois pratique de pouvoir rechercher des informations rapides au quotidien, comme par exemple les arguments de ligne de commande acceptés pour une certaine commande. 

Même si cette information est disponible sur internet, il est bon de savoir que presque toutes les applications installent leur propre documentation sur le système et qu’il n’est souvent pas très apprécié sur les forums internet de poser des questions dont la réponse peut facilement être retrouvée dans la documentation installée sur le serveur.

$ man ls