Atelier Systèmes d’Exploitation
Chapitre I : Introduction Générale
Amine DHRAIEF 1 [ère] année Licence LFIG
Présentation de Linux
03/10/17 Atelier S.E 2
Historique
Unix est né, en 1969, dans les Bell Laboratories (AT&T)
Ken Thompson et Dennis
Ritchie.
03/10/17 Atelier S.E 3
Historique
En 1974, la version 4 d’Unix est « donnée » à l’université de Berkeley, Californie, qui commence alors son propre développement du système . C’est le début d’une divergence entre les deux versions d’Unix : AT&T et BSD (Berkeley Software Distribution).
De 1977 à 1979, Ken Thompson et Dennis Ritchie réécrivent Unix pour le rendre réellement portable. Et en 1980 les premières licences de distribution d’Unix System V d’AT&T sont délivrées aux constructeurs.
03/10/17 Atelier S.E 4
Historique
Linux, système Unix libre sur plate–forme PC, était au départ un projet de loisirs de Linus Torvalds, étudiant finlandais.
Le 5 octobre 1991, Linus Torvalds
annonça la première version officielle de Linux
Linux fut inspiré de Minix, un petit système Unix développé par Andrew Tanenbaum
Définition d'un S.E
03/10/17 Atelier S.E 6
Notion de Système d'Exploitation
Multi-tâche ?
Pseudo-parallélisme ?
Temps partagé ?
Multi-programmation ?
Multi-utilisateurs ?
03/10/17 Atelier S.E 7
Notion de Système d'Exploitation
multi-tâche (multitasking)
Selon Silbershatz :
« Time sharing (or multitasking)….»
« In time-sharing systems, the CPU executes multiple jobs by switching among them, but the switches occur so frequently that the users can interact with each program while it is running. »
Source : Operating System Concepts Essentials. Second Edition, 2013. Chapter 1 Introduction, page 20
03/10/17 Atelier S.E 8
Notion de Système d'Exploitation
multi-tâche (multitasking)
Selon Tannenbaum:
« timesharing, a variant of multiprogramming….»
« In reality, of course, the real CPU switches back and forth from process to process, but to understand the system, it is much easier to think about a collection of processes running in (pseudo) parallel than to try to keep track of how the CPU switches from program to program. This rapid switching back and forth is called multiprogramming, »
Source : MODERN OPERATING SYSTEMS. Fourth Edition, 2014. Chapter 2 Process and Threads, page 86
03/10/17 Atelier S.E 9
Notion de Système d'Exploitation
multi-tâche cas d'UNIX
La plupart des systèmes d'exploitation modernes permettent l'exécution de plusieurs tâches à la fois
un ordinateur peut, pendant qu'il exécute le programme
d'un utilisateur, lire les données d'un disque ou afficher des résultats sur un terminal ou une imprimante.
On parle de système d'exploitation multi-tâches ou multi-programmé dans ce cas.
03/10/17 Atelier S.E 10
Notion de Système d'Exploitation
multi-tâche cas d'UNIX
La plupart des systèmes d'exploitation multi-tâches sont implémentés sur un ordinateur ayant un seul micro-processeur.
Celui-ci, à un instant donné, n'exécute réellement qu'un seul programme, mais le système peut le faire passer d'un programme à un autre ceci donne aux utilisateurs l'impression que tous les programmes sont exécutés en même temps.
03/10/17 Atelier S.E 11
Notion de Système d'Exploitation
cas d'UNIX
Unix est un système d’exploitation, constitué
du noyau Unix,
d’un interpréteur de commandes
et d’un grand nombre d’utilitaires.
Le noyau assure la gestion des ressources physiques (processeur, mémoires, périphériques) et logicielles (processus, fichiers...).
Le noyau est constitué d’un ensemble de procédures et de
Advertisement
fonctions écrites pour l’essentiel en langage C
Unix est un système multi–utilisateur, temps partagé, multi-tâche
03/10/17 Atelier S.E 12
Notion de Système d'Exploitation
cas d'UNIX
Un système multi-utilisateurs est capable d'exécuter de façon (pseudo-) concurrente et indépendante des applications appartenant à plusieurs utilisateurs.
Concurrente signifie que les applications peuvent être
actives au même moment et se disputer l'accès à différentes ressources comme le processeur, la mémoire, les disques durs…
Indépendante signifie que chaque application peut
réaliser son travail sans se préoccuper de ce que font les applications des autres utilisateurs.
03/10/17 Atelier S.E 13
Notion de Système d'Exploitation
cas d'UNIX
Un système multi-utilisateurs est nécessairement multi-tâches mais la réciproque est fausse :
le système d'exploitation MS-DOS
est mono-utilisateur et mono-tâche ;
- les systèmes MacOS 6.1 et
Windows 3.1 sont monoutilisateurs mais multi-tâches ;
multiutilisateurs.
03/10/17 Atelier S.E 14
Notion de Système d'Exploitation
cas d'UNIX
Comme pour les systèmes multi-tâches, la multi- utilisation est émulée en attribuant des laps de temps à chaque utilisateur.
Naturellement, le fait de basculer d'une application à l'autre ralentit chacune d'entre elles et affecte le temps de réponse perçu par les utilisateurs.
03/10/17 Atelier S.E 15
Notion de Système d'Exploitation
cas d'UNIX
Lorsqu'ils permettent la multi-utilisation, les systèmes d'exploitation doivent prévoir un certain nombre de mécanismes :
Un mécanisme d'authentification permettant de vérifier
l'identité de l'utilisateur ;
Un mécanisme de protection contre les programmes utilisateur
erronés, qui pourraient bloquer les autres applications en cours d'exécution sur le système, ou mal intentionnés, qui pourraient perturber ou espionner les activités des autres utilisateurs ;
Un mécanisme de comptabilité pour limiter le volume des
ressources allouées à chaque utilisateur.
03/10/17 Atelier S.E 16
Connexion d’un utilisateur
03/10/17 Atelier S.E 17
Connexion d’un utilisateur
Tout utilisateur est identifié par un nom (login) et ne peut utiliser le système que si son nom a préalablement été défini par l’administrateur du système (ou super–utilisateur), dont le nom est généralement root .
Ce dernier a tous les droits et aucune restriction d’accès ne lui est applicable.
03/10/17 Atelier S.E 18
Connexion d’un utilisateur
Connexion en mode texte
03/10/17 Atelier S.E 19
Connexion d’un utilisateur
Connexion en mode graphique
03/10/17 Atelier S.E 20
Connexion d’un utilisateur
Mot de passe
Un utilisateur peut à tout moment changer son mot de passe, ou s’en attribuer un par la commande passwd .
Lors du changement, il faut fournir l’ancien mot de
passe
03/10/17 Atelier S.E 21
Connexion d’un utilisateur
Mot de passe
« La sécurité d'un mot de passe repose sur la force de l'algorithme de chiffrement et sur la taille de l'espace de clés utilisé. La méthode de chiffrement des systèmes UNIX est basée sur l'algorithme NBS DES . Des méthodes plus récentes sont maintenant recommandées (voir ENCRYPTMETHOD_ ). La taille de l'espace de clés dépend de l'aléa du mot de passe utilisé. »
Extrait $man passwd
03/10/17 Atelier S.E 22
Fichier /etc/passwd
Lors des diverses connexions de l’utilisateur, la lecture du mot de passe se fera sans écho.
Lorsque le nom et le mot de passe sont corrects, login récupère dans le fichier /etc/passwd toutes les informations utiles pour cet utilisateur.
Advertisement
03/10/17 Atelier S.E 23
Fichier /etc/passwd
Fichier /etc/passwd
root:x:0:0:root:/root:/bin/bash
Ce fichier est accessible en lecture à tous les utilisateurs et contient, pour chaque utilisateur, les champs suivants :
nom de connexion (login) de l’utilisateur,
un caractère x (indique qu’un mot de passe existe pour le compte)
le numéro de l’utilisateur (UID = user identifier),
le numéro de groupe (GID = group identifier),
Commentaires : informations complémentaire sur l'utilisateur (num
de téléphone, adresse courriel,...)
le répertoire d’accueil,
programme à lancer
03/10/17 Atelier S.E 25
Fichier /etc/shadow
Le fichier /etc/shadow contient les mots de passe et l'information sur l'expiration des comptes
03/10/17 Atelier S.E 26
Fichier /etc/shadow
amine : $6$VnYAAYRG$pwj1PIa25WRqaoqQcUvr68J/JjnnqG.IL3RiOCc582kcP7Ii54nL.luoZGTt 6yuetLzmIoYR.dZvXqWxX/gb00:16686:0:99999:7:::
Nom d'utilisateur, jusqu'à 8 caractères. Case-sensitive, habituellement uniquement des minuscules.
Exactement la même entrée que dans le fichier /etc/passwd.
Mot de passe, 13 caractères codés. Une entrée nulle (eg. ::) indique qu'un mot de passe n'est pas
demandé pour entrer dans le système (une mauvaise idée en général), et une entrée ``'' (eg. ::) indique que le compte a été désactivé.
Le nombre de jours (depuis le 1er Janvier 1970) depuis le dernier changement du mot de passe.
Le nombre de jours avant que le mot de passe ne puisse être changé (un 0 indique qu'il peut être changé
à n'importe quel moment).
Le nombre de jours après lesquels le mot de passe doit être changé (99999 indique que l'utilisateur peut
garder son mot de passe inchangé pendant beaucoup, beaucoup d'années)
Le nombre de jours pour avertir l'utilisateur qu'un mot de passe ne va plus être valable (7 pour une
semaine entière)
Le nombre de jours avant de désactiver le compte après expiration du mot de passe
Le nombre de jours depuis le 1er Janvier 1970 pendant lesquels un compte a été désactivé
Un champ réservé pour une utilisation future possible
03/10/17 Atelier S.E 27
Algorithme de hashage utilisé dans /etc/shadow
Format du mot de passe $ ID $ Salage $H ash
ID: l’algorithme utilisé :
**$1$ is MD5**
**$2a$ is Blowfish**
**$2y$ is Blowfish**
**$5$ is SHA-256**
**$6$ is SHA-512**
Salage : dynamique/statique
Hash : empreinte du mot de passe
03/10/17 Atelier S.E 28
Principe de hashage
03/10/17 Atelier S.E 29
Les shells Les commandes & les terminaux
03/10/17 Atelier S.E 30
Les shells
Un script est fichier contenant une série d’ordres que l’on va soumettre à un programme externe pour qu’il les exécute.
Ce programme est appelé interpréteur de
commandes.
Script Interpréteur de commande Résultat
03/10/17 Atelier S.E 31
Les shells
langage interprété
Il existe de nombreux interpréteurs de commandes.
Naturellement, le shell en fait partie, tout comme
certains outils tels que Sed et Awk, ainsi que d’autres langages tels que Perl, Python, Tcl/Tk, Ruby, etc.
Ces langages sont dits interprétés, par opposition aux langages compilés (comme C, C++, Fortran, Ada, etc.).
03/10/17 Atelier S.E 32
Les langages compilés
Un code source écrit en langage compilé doit être traduit en instructions de code machine compréhensibles pour le processeur.
Cette étape de compilation nécessite plusieurs outils et peut
parfois s’avérer longue.
Advertisement
Code source Compilation Fichier binaire Résultat
03/10/17 Atelier S.E 33
Les shells
langages interprétés vs compilés
Le code compilé étant directement compris par le processeur du système, son exécution est très rapide
Un script doit être
interprété dynamiquement, ce qui
ralentit sensiblement
l’exécution
03/10/17 Atelier S.E 34
Les shells
langages interprétés vs compilés
Le fichier exécutable issu d’une compilation est souvent volumineux et n’est utilisable que sur un seul type de processeur et un seul système d’exploitation .
À l’inverse, un fichier script est
l’interpréteur de commandes correspondant soit disponible)
d’autres systèmes d’exploitation (pour peu que
généralement assez réduit et
directement portable sur
d’autres processeurs ou
03/10/17 Atelier S.E 35
Les shells
langages interprétés vs compilés
Un fichier compilé est incompréhensible par un lecteur humain . Il n’est pas « possible » d’en retrouver le code source . Cela peut garantir le secret commercial d’un logiciel
sous forme de commentaires, ce qui est intéressant dans le cadre des
Inversement, un fichier script
logiciels libres .
est directement lisible et modifiable, et peut contenir
sa propre documentation
03/10/17 Atelier S.E 36
Les shells
Le shell fait partie intégrante d’Unix depuis les débuts de celui-ci en 1971.
Le shell est avant tout un interpréteur de commandes, chargé de lire les ordres que l’utilisateur saisit au clavier, de les analyser, et d’exécuter les commandes correspondantes.
03/10/17 Atelier S.E 37
Les shells
Bourne Shell
Le premier shell fut écrit par Steve Bourne et le fichier exécutable correspondant était traditionnellement /bin/sh .
Il permettait d’écrire de véritables scripts complets, avec
des structures de contrôle performantes.
Toutefois, son utilisation quotidienne de manière
interactive péchait quelque peu par manque d’ergonomie.
03/10/17 Atelier S.E 38
Les shells C Shell
Un nouveau shell – dit shell C – fut donc mis au point par William Joy à l’université de Berkeley. Cet outil fut officiellement introduit dans certaines distributions Unix en 1978.
Le fichier exécutable était /bin/csh .
Le shell C fut doté d’un langage de programmation ressemblant quelque peu au langage C, mais dont l’implémentation était fortement boguée.
En dépit des corrections qui y furent apportées, le comportement des
scripts pour shell C n’était pas satisfaisant.
03/10/17 Atelier S.E 39
Les shells Korn Shell
En 1983, David G. Korn, travaillant aux laboratoires AT&T Bell, développa un nouveau shell, nommé Korn Shell, dont le but était de réunir à la fois les qualités du shell C et du shell Bourne.
Le fichier exécutable était /bin/ksh .
03/10/17 Atelier S.E 40
Les shells Standard POSIX
À la fin des années 1980, il existait une pléthore de systèmes compatibles Unix – ou prétendument compatibles Unix – qui implémentaient chacun de nouvelles fonctionnalités par rapport au système Unix original.
Chaque fabricant de matériel, chaque éditeur de logiciels désirait disposer de sa propre version compatible Unix, et la situation était devenue catastrophique en ce qui concerne la portabilité des applications.
03/10/17 Atelier S.E 41
Les shells Standard POSIX
Même les commandes shell simples pouvaient disposer de variantes différentes sur chaque système. Il fut donc nécessaire d’uniformiser le paysage proposé par toutes ces versions d’Unix.
Une norme fut proposée par l’IEEE : POSIX.
Elle décrivait l’interface entre le cœur du système d’exploitation (le noyau) et les applications, ainsi que le comportement d’un certain nombre d’outils système dont le shell
03/10/17 Atelier S.E 42
Premier script shell
Advertisement
03/10/17 Atelier S.E 43
Exécution d’un script
Invocation de l’interpréteur
Exécution d’un script
Invocation de l’interpréteur
Remarquez que le suffixe .sh ajouté à la fin du nom du script n’a aucune importance ; il ne s’agit que d’une information pour l’utilisateur.
Le système Unix ne tient aucun compte des suffixes éventuels des noms de fichiers.
Par exemple, renommons-le et réessayons :
03/10/17 Atelier S.E 45
Exécution d’un script
Appel direct
Le shell ne reconnaît pas essai comme une commande
03/10/17 Atelier S.E 46
Exécution d’un script
Appel direct
Lorsque nous invoquons une commande Unix (par exemple, echo ), le système devra trouver un fichier exécutable de ce nom ( /bin/echo en l’occurrence).
Mais il est impossible de parcourir tous les répertoires de tous les disques pour rechercher ce fichier, le temps de réponse serait horriblement long !
03/10/17 Atelier S.E 47
Exécution d’un script
Appel direct
Pour améliorer les performances, le système Unix ne recherche les fichiers implémentant les commandes que dans un nombre restreint de répertoires.
Ceux-ci sont énumérés dans la variable d’environnement PATH, que nous pouvons consulter.
03/10/17 Atelier S.E 48
Exécution d’un script
Appel direct
Le script ne s’exécute pas plus qu’avant, mais le message d’erreur a changé.
Ceci est dû aux permissions accordées pour ce fichier, et que l’on peut observer avec l’option -l de ls
La première colonne décrit le type de fichier et les permissions concernant sa manipulation
03/10/17 Atelier S.E 49
Exécution d’un script
Appel direct
Le premier tiret - correspond à un fichier normal ( d pour un répertoire, l pour un lien symbolique, etc.).
Les trois lettres suivantes indiquent que le propriétaire amine du fichier a les droits de lecture ( r ) et d’écriture ( w ) sur son fichier, mais l’absence de lettre x, remplacée ici par un tiret, signifie que le propriétaire ne peut pas exécuter ce fichier. C’est justement notre problème.
Les trois lettres rw- suivantes décrivent les droits fournis aux autres utilisateurs appartenant au même groupe que le fichier ( users ).
Enfin les trois dernières lettres indiquent les permissions accordées à tous les autres utilisateurs du système ( r-- lecture seulement).
03/10/17 Atelier S.E 50
Exécution d’un script
Appel direct
Le fichier n’étant pas exécutable, il est impossible de le lancer. Pour modifier les permissions d’un fichier, il faut utiliser la commande chmod
03/10/17 Atelier S.E 51
Exécution d’un script Ligne shebang
Nous avons créé le fichier essai contenant une seule ligne affichant un message ; nous avons rendu le fichier exécutable avec chmod ; puis nous l’avons lancé en utilisant la notation ./essai .
Nous savons que ce fichier doit être interprété par un shell, c’est-à-dire qu’un shell disponible sur le système ( sh, bash, ksh ...) doit lire le script et traduire son contenu ligne à ligne.
03/10/17 Atelier S.E 52
Exécution d’un script Ligne shebang
Mais comment le système sait-il que ce fichier doit être interprété par un shell ? Comment sait-il qu’il s’agit d’un script shell et non d’un script Sed, Awk, Perl, ou autre ? Comment se fait l’association entre notre fichier et le shell du système ?
En réalité, nous n’avons rien précisé, et si le script fonctionne quand même, c’est uniquement grâce à un comportement par défaut dans le cas où cette information est absente
03/10/17 Atelier S.E 53
Exécution d’un script Ligne shebang
On précise l’interpréteur à employer, on utilise le principe de la ligne shebang (contraction de shell et de bang – point d’exclamation en anglais).
Lorsque le noyau s’aperçoit que les deux premiers caractères du fichier sont #!, il considère que tout le reste de la ligne représente le nom de l’interpréteur à utiliser.
Et si l’on demande à exécuter le fichier mon_script.sh écrit ainsi :
03/10/17 Atelier S.E 54
Exécution d’un script Ligne shebang
le système d’exploitation traduira l’invocation : $ ./mon_script.sh
En $ /bin/bash ./mon_script.sh
03/10/17 Atelier S.E 55
The END
03/10/17 Atelier S.E 56