Cours-ESEN-2016-2017-ASE

Atelier Systèmes d’Exploitation
Chapitre I :
Introduction Générale
ESEN
Université De La Manouba
Présentation de Linux
Historique
●
Unix est né, en 1969, dans
les Bell Laboratories (AT&T)
–
21/09/16
Ken Thompson et Dennis
Ritchie.
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.
21/09/16
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
21/09/16
Atelier S.E
5
User
Mode
Interface
prorgamme
utilisateur
Software
Définition d'un S.E
Hardware
Kernel
Mode
21/09/16
Atelier S.E
6
Kernel Mode vs. User Mode
• Kernel mode:
• User mode:
– Mode de
fonctionnement du S.E
– Accès complet et total à
toutes les ressources
matérielle
– Exécute n’importe qu’elle
instruction que la
machine peut exécuter
21/09/2016
– Mode de
fonctionnement de
tous les programmes
– Une partie seulement
des instructions sont
accessibles
– Les instructions qui
affectent les I/O sont
inaccessibles
Systèmes d’Exploitation et
Programmation Concurrente
7
Notion de Système d'Exploitation
cas d'UNIX
●
●
●
La plupart des systèmes d'exploitation multitâ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.
On parle alors de système à temps partagé
21/09/16
Atelier S.E
8
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 fonctions
écrites pour l’essentiel en langage C
Unix est un système multi–utilisateur, temps partagé,
multi-tâche
21/09/16
Atelier S.E
9
Notion de Système d'Exploitation
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 multitâches ou multi-programmé dans ce cas.
21/09/16
Atelier S.E
10
Notion de Système d'Exploitation
cas d'UNIX
●
●
●
La plupart des systèmes d'exploitation multitâ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.
On parle alors de système à temps partagé
21/09/16
Atelier S.E
11
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.
21/09/16
Atelier S.E
12
Notion de Système d'Exploitation
cas d'UNIX
• Un système multi-utilisateurs
est nécessairement multitâ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 mono-utilisateurs mais multitâches ;
– Unix et Windows NT sont
multiutilisateurs.
21/09/16
Atelier S.E
13
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.
21/09/16
Atelier S.E
14
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.
21/09/16
Atelier S.E
15
Connexion d’un utilisateur
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.
21/09/16
Atelier S.E
17
Connexion d’un utilisateur
Connexion en mode texte
21/09/16
Atelier S.E
18
Connexion d’un utilisateur
Connexion en mode texte
21/09/16
Atelier S.E
19
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.
–
21/09/16
Lors du changement, il faut fournir l’ancien mot de
passe
Atelier S.E
20
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 ENCRYPT_METHOD). La taille de l'espace de clés dépend de l'aléa du mot de passe utilisé. »
Extrait $man passwd
21/09/16
Atelier S.E
21
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.
21/09/16
Atelier S.E
22
Fichier /etc/passwd
21/09/16
Atelier S.E
23
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
–
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
21/09/16
Atelier S.E
24
Fichier /etc/shadow
●
Le fichier /etc/shadow contient les mots de
passe et l'information sur l'expiration des comptes
21/09/16
Atelier S.E
25
Fichier /etc/shadow
amine:6$VnYAAYRG$pwj1PIwl8WRv7osQsUvr79J/JjnnqG.IL3RiOCc582kcP7Ii54nL
.luoZGTt6yuetLzmIoYR.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
21/09/16
Atelier S.E
26
Les shells
Les commandes & les terminaux
21/09/16
Atelier S.E
27
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.
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.).
21/09/16
Atelier S.E
28
Les shells
langages interprétés vs compilés
●
●
●
Après l’écriture d’un fichier script, il est possible de le
soumettre directement à l’interpréteur de commandes
Tandis qu’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.
21/09/16
Atelier S.E
29
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
alors qu’un script doit être interprété
dynamiquement, ce qui ralentit sensiblement
l’exécution.
21/09/16
Atelier S.E
30
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 généralement assez
réduit et directement portable sur d’autres processeurs
ou d’autres systèmes d’exploitation
–
21/09/16
pour peu que l’interpréteur de commandes correspondant soit
disponible
Atelier S.E
31
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.
Inversement, un fichier script est directement lisible et
modifiable, et peut contenir sa propre documentation
sous forme de commentaires, ce qui est intéressant dans
le cadre des logiciels libres.
21/09/16
Atelier S.E
32
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.
Curieusement, les tubes de communication (pipes) permettant
de faire circuler des données entre deux commandes et
donnant toute leur puissance aux scripts shell, ne sont apparus
que plus tard, fin 1972.
21/09/16
Atelier S.E
33
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.
21/09/16
Atelier S.E
34
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.
21/09/16
Atelier S.E
35
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 .
21/09/16
Atelier S.E
36
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.
21/09/16
Atelier S.E
37
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
21/09/16
Atelier S.E
38
Premier script shell
21/09/16
Atelier S.E
39
Exécution d’un script
Invocation de l’interpréteur
21/09/16
Atelier S.E
40
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 :
21/09/16
Atelier S.E
41
Exécution d’un script
Appel direct
●
Le shell ne reconnaît pas essai comme une
commande
21/09/16
Atelier S.E
42
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 !
21/09/16
Atelier S.E
43
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.
21/09/16
Atelier S.E
44
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
21/09/16
Atelier S.E
45
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).
21/09/16
Atelier S.E
46
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
21/09/16
Atelier S.E
47
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.
21/09/16
Atelier S.E
48
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
21/09/16
Atelier S.E
49
Exécution d’un script
Ligne shebang
●
●
●
our préciser 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 :
21/09/16
Atelier S.E
50
Exécution d’un script
Ligne shebang
●
le système d’exploitation traduira l’invocation :
$ ./mon_script.sh
En
$ /bin/bash ./mon_script.sh
21/09/16
Atelier S.E
51
The END
21/09/16
Atelier S.E
52