Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Installation et configuration d'un serveur internet
  3. Bref exposé d'Unix et de POSIX
Extrait - Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
Extraits du livre
Installation et configuration d'un serveur internet (BIND, Apache, Nginx, Dovecot, Postfix...)
3 avis
Revenir à la page d'achat du livre

Bref exposé d'Unix et de POSIX

Introduction

BSD et Linux sont des systèmes d’exploitation de type Unix (parfois appelés Unices), descendant de, ou inspirés par Unix, le système d’exploitation dont la première version a été développée dans les années 60 par Bell Labs, qui fait partie de AT&T, la compagnie de téléphone américaine.

POSIX (abréviation anglaise de Portable Operating System Interface, Interface portable de système d’exploitation) est un standard qui définit la collection minimale de fonctionnalités, de commandes et d’interfaces qui doivent être implémentées sur un système Unix, tout comme la structure des répertoires.

On pourrait écrire des ouvrages entiers sur Unix et POSIX. Seuls les sujets importants dans le cadre de ce livre seront traités.

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)

Chaque périphérique, physique ou virtuel, dispose d’un fichier spécial dans le système de fichiers, qui permet la communication entre le système et le périphérique. Des exemples de périphériques sont la carte réseau et le générateur de nombres aléatoires qui, lui, fait partie du noyau.

Les liens (en anglais, singulier link)

Une adresse dans le système de fichiers peut faire référence...

Extensions des fichiers

Les extensions des noms de fichiers (.zip, .txt, .html) n’indiquent pas nécessairement le contenu de ces fichiers. Souvent, l’extension est une indication fiable, mais les systèmes Unix ne décident pas de l’action à exécuter avec un fichier en se basant sur l’extension, comme d’autres systèmes d’exploitation le font. Les systèmes Unix se basent sur le contenu du fichier. La commande file (fichier) sert à vérifier le type de fichier.

Un fichier ZIP :

$ file fichierzip.zip 
zipfile.zip: Zip archive data, at least v2.0 to extract 

Un script shell qui prétend être un fichier ZIP :

$ file shellscript.zip 
shellscript.zip: POSIX shell script, ASCII text executable 

Pour les fichiers exécutables et les fichiers texte, les extensions sont souvent omises.

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.

1. Afficher les processus

Vous pouvez notamment consulter les processus et les PID correspondants grâce aux applications ps et top. La commande ps affiche une liste de processus...

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.

1. Démarrer et arrêter les daemons

Normalement, les daemons sont lancés par init au démarrage du système...

Journaux

De nombreux fichiers journaux sont stockés dans le répertoire /var/log. La plupart de ces fichiers sont des fichiers texte qui peuvent être lus à l’aide d’applications d’affichage comme more et less.

Les systèmes utilisant systemd comme système init ont remplacé un grand nombre de journaux par des fichiers binaires. Ces fichiers ne peuvent pas être ouverts à l’aide d’applications d’affichage ou d’éditeurs de texte, mais seulement à l’aide de l’application journalctl.

Les fichiers journaux sont étudiés plus en détail dans le chapitre Sauvegarde et surveillance.

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.

1. Pages man et info

La forme de documentation la plus utilisée est les pages de manuel (en anglais : manual page ou, plus souvent, simplement man page). Très peu d’applications sont installées sans man page. Il y a des pages de manuel qui détaillent à l’extrême comme il en existe qui ne donnent que quelques astuces et indiquent un site web pour le reste de la documentation.

La commande man sert à afficher les pages de manuel :

$ man ls 

Cette commande affiche la page de manuel de l’application ls.

Pour faire défiler la page de manuel ligne par ligne, on utilise les flèches du clavier et pour faire défiler page par page, on utilise les touches [Page Down] et [Page Up]. Pour retourner...