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