Formation

Scribe :
Administration

Reproduction interdite.
Support de cours

Formation Scribe : Administration

Auteur(s) : Marc Simon.

La reproduction dans ce manuel de noms de marques déposées, de désignations des marques,

etc. même sans stipulation explicite que de tels noms et marques sont protégés par la loi, n’auto-
rise pas à supposer qu’ils soient libres et puissent être utilisés par quiconque.

Cet ouvrage a été mis en page avec LATEX, à partir de fichiers au format XML convertis à l’aide de
xsltproc développé par Daniel Veillard (http://xmlsoft.org/XSLT/). Les logos EOLE ont été
réalisés par Marielle Bourdot. Le logo Logidée a été réalisé par Patrice Weber.

Les feuilles de styles, la DTD et les outils associés ont été developpés par Logidée
(http://www.logidee.com) pour rédiger et maintenir ses supports de formations. Ces outils
sont bien sûr sous licence libre et disponibles sur le site web mentionné ci-dessus.

Reproduction autorisée dans le cadre du projet EOLE.

La reproduction à l’identique, au format numérique ou papier, de ce manuel, est librement autori-

sée. Son utilisation est libre dans le cadre de la formation sur les différents produits constitutifs du
projet EOLE. La reproduction de versions tronquées ou modifiées du support ne peut s’effectuer
sans l’accord préalable des auteurs et de leurs ayants-droits. Merci de contacter l’équipe EOLE,
titulaire des droits d’exploitation de l’ouvrage, pour toute question relative à ce point.
Sommaire
Thème 1 : Le serveur Scribe : quelles fonctions ? . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Le serveur Scribe, pourquoi faire ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Le serveur Scribe est un serveur pédagogique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2 Les technologies de Scribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Le système de déploiement Eole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Le serveur de fichiers Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Exim et Sympa pour la messagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Cups pour la gestion des imprimantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Le déploiement de Scribe : les points à considérer . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Un système peu gourmand en ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
La migration des données est possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Il faut s’assurer au préalable de la compatibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Dimensionnement d’un serveur Scribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Les besoins en disque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Les besoins en mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Les besoins en puissance processeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Thème 2 : Installation d’un système Scribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1 Considérations matérielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Le système Linux reconnaît la plupart du matériel récent . . . . . . . . . . . . . . . . . . . . . . . . . 18
Le matériel reconnu par Scribe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Il peut être utile d’installer plusieurs disques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Aperçu de la méthode d’installation au niveau académique . . . . . . . . . . . . . . . . . . 20
L’installation initiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Les installations suivantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Les opérations à effectuer dans les établissements . . . . . . . . . . . . . . . . . . . . . . . . . 24
L’inscription des stations dans le domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
L’importation des bases GEP dans l’annuaire LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Thème 3 : Finalisation de l’installation avec l’EAD . . . . . . . . . . . . . . . . . . . . . . 25

3.1 Aperçu général de l’outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
L’accès se fait par le Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
L’accès à EAD est authentifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
La page d’accueil permet de savoir si tout fonctionne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
La section centrale contient les dates des opérations importantes . . . . . . . . . . . . . . . . . 27
 La barre de droite est une barre de navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Les différents profils de connexion à l’EAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Le profil administrateur sert aux responsables techniques . . . . . . . . . . . . . . . . . . . . . . . . 28
Le profil professeur permet d’accéder aux fonctions pédagogiques . . . . . . . . . . . . . . . . 28
Le profil professeur principal ajoute des droits sur une classe . . . . . . . . . . . . . . . . . . . . . 28
3.3 Surveillance des ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Les informations sur le matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
L’indication de la charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Les volumes de données transmis par les différentes interfaces . . . . . . . . . . . . . . . . . . . 31
La mémoire utilisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
L’espace disque utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Gestion des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Redémarrage des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Redémarrage du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Mise à jour du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5 Déclencher les mises à jour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
L’opération nécessite un arrêt des services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Les mises à jour peuvent être déclenchées immédiatement . . . . . . . . . . . . . . . . . . . . . . . 34
L’opération peut se faire en différé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
L’opération peut être entièrement automatisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 L’inscription des stations dans le domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Il s’agit de l’opération la plus longue durant l’installation . . . . . . . . . . . . . . . . . . . . . . . . . . 36
La procédure dépend du système d’exploitation utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.7 Le rôle de l’annuaire LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
L’annuaire LDAP sert de support au contrôleur de domaine . . . . . . . . . . . . . . . . . . . . . . . 38
L’annuaire LDAP fait partie des éléments sauvegardés . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.8 Importation des comptes des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
L’importation se fait en plusieurs temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.9 Manipulation ponctuelle des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
L’importation d’une base GEP n’est pas forcément pratique . . . . . . . . . . . . . . . . . . . . . . . 41
Rechercher un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Modifier un utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Thème 4 : Configuration des imprimantes avec CUPS . . . . . . . . . . . . . . . . . . 43

4.1 Présentation de CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
CUPS est un système de gestion d’imprimantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Configuration d’une imprimante supportée par Linux . . . . . . . . . . . . . . . . . . . . . . . . 46
Connexion à CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
 Procédure de déclaration d’une imprimante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3 Prise en compte des quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Pykota est vu comme un pilote particulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Déclaration d’une imprimante indépendante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Publication d’un pilote Windows au moyen de Samba . . . . . . . . . . . . . . . . . . . . . . . 50
Création d’un partage spécifique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Installation des fichiers de pilote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Prise en compte par les stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 L’impression PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Cette imprimante permet d’obtenir un fichier PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
L’impression PDF est configurée par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.6 Gestion des impressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chaque utilisateur peut annuler ses propres tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Le groupe PrinterAdmins peut effacer tous les travaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Les utilisateurs CUPS disposent de tous les droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7 Prise en compte des quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Déclaration de l’imprimante dans Pykota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Déclaration dans l’annuaire LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Manipulation des quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Thème 5 : Gestion des sauvegardes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.1 Les sauvegardes : que sauvegarder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
La procédure automatisée sauvegarde l’essentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Le coeur du système se trouve sur CD-ROM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
La configuration des imprimantes est rapide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Les modifications locales sont conservées sur un serveur externe . . . . . . . . . . . . . . . . . 58
Les partages spécifiques ne sont pas conservés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2 Les sauvegardes se déclenchent depuis l’EAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
L’interface est similaire à celle utilisée pour les MAJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
La sauvegarde interrompt le fonctionnement du service . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Programmation des sauvegardes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3 La sauvegarde sur support local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
La sauvegarde se fait dans /var/sauvegardes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Le répertoire peut servir de point d’ancrage à d’autres supports . . . . . . . . . . . . . . . . . . . 61
Il est possible de faire une sauvegarde plus durable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.4 La sauvegarde distante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
La sauvegarde distante se fait une sur machine du réseau local . . . . . . . . . . . . . . . . . . . 63
Création d’un partage adapté à la sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
 Configuration de la sauvegarde dans l’EAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 Vérifications et restauration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Les fichiers de sauvegarde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Procédure de restauration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Thème 6 : La gestion des droits avec Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.1 La gestion des droits : deux approches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
L’approche Unix : celle des permissions d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Les droits d’accès sous Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Les différents niveaux de droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
L’accès aux fichiers est contrôlé de plusieurs manières . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Les utilisateurs n’ont accès qu’à l’aspect Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
L’administrateur peut changer les droits Unix des partages . . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Manipulation des droits Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
chmod change les permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
chown change le propriétaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4 Fonctionnement de Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Il y a plusieurs niveaux de contrôles d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Samba est un utilisateur Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Le serveur utilise les ACL pour les partages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Il est possible d’imiter la gestion des ACL Microsoft Windows . . . . . . . . . . . . . . . . . . . . . 74
6.5 Comment interpréter les ACL ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Les ACL sont constituées de droits Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.6 Quelques recommandations sur les droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Différencier les droits d’installation et d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Toujours agir sur les droits des groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Ne pas hésiter à multiplier les groupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.7 La réplication des droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Valider les droits sur le serveur père . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Sauvegarder les ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.8 Gestion avancée : la manipulation des partages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
L’héritage des permissions et des ACL peut se configurer . . . . . . . . . . . . . . . . . . . . . . . . 80
On partira généralement d’une configuration fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . 80
Les modifications les plus courantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
 1. Le serveur
Scribe : quelles
fonctions ?
 1.1 : Le serveur Scribe, pourquoi faire ?

Le serveur Scribe est un serveur pédagogique

Il est le pendant d’Horus

Il offre une alternative libre et intégrée à l’établissement

Il ne s’agit pas d’un système imposé

Premier rôle : le service de fichiers

Deuxième rôle : le service de messagerie

Troisième rôle : des fonctions pédagogiques en développement

Quatrième rôle : un serveur Web

Cinquième rôle : un espace de travail collaboratif

Le serveur Scribe est un serveur pédagogique

Il est le pendant d’Horus

Dans le cadre du projet Eole, qui vise à offrir une solution intégrée pour l’ensemble de l’informa-
tique des EPLE, le serveur Scribe a été développé antérieurement à Horus. L’idée était d’offrir,
dans un souci d’économie et d’homogénéité, un serveur de fichier libre, reposant sur les concepts
Eole, qui offrirait tous les services nécessaires tant aux utilisateurs qu’aux administrateurs.

La distinction n’est pas vaine : autant les acteurs de la communauté éducative, tout particulière-
ment sur le réseau pédagogique, expriment-ils des besoins liés à l’informatique, autant les impé-
ratifs de sécurité du réseau et de protection des mineurs imposent-ils des mesures permettant
d’identifier chacun des utilisateurs des ressources communes.

Le serveur Amon propose un mécanisme de filtrage, mais celui-ci n’est complet qu’en permettant
d’offrir une traçabilité des intervenants. Cela n’est possible que si Amon est capable d’interroger
une base d’utilisateurs auprès de laquelle ces derniers s’identifient. Amon tente d’être polyva-
lent et interopérable, mais il était nécessaire de proposer, dans la famille des produits Eole, une
solution gratuite répondant à ce besoin.

Le déploiement d’Amon répond à une logique inévitable de sécurisation et de responsabilisation

liée à l’accès Internet. La responsabilité ne peut se faire dans l’anonymat. Scribe répond donc à
ce besoin, pris très au sérieux par les services juridiques des académies, de se conformer aux
obligations de traçabilité des utilisateurs. Du fait de sa position sur le réseau pédagogique, et de sa
connaisance de chacun des utilisateurs, ce serveur peut offrir un grand nombre de services com-
plémentaires. Tout comme Horus, la fonctionnalité d’annuaire s’est combinée à celle de serveur
de fichiers, et les fonctionnalités ont été peu à peu ajoutées.

Il offre une alternative libre et intégrée à l’établissement

Reproduction interdite.

Le serveur Scribe n’a pas de vocation hégémonique. Les autres éléments d’Eole ne nécessitent
pas l’accès à un serveur Scribe : tout est conçu dans un souci d’interopérabilité. Néanmoins, pour
simplifier l’administration du réseau des établissements, il est préférable que les interfaces soient
similaires d’un système à l’autre.

La contrainte essentielle de Scribe porte sur son intégration au réseau pédagogique, notamment
à la nécessité de reconfigurer les postes clients pour tenir compte de sa présence, ou les interac-

Le serveur Scribe : quelles fonctions ?

8
Le serveur Scribe, pourquoi faire ?
 tions avec les serveurs Microsoft éventuellement présents sur le réseau. Malgré le soin apporté
à limiter l’impact du déploiement, il est indispensable de procéder à une reconfiguration de l’en-
semble des stations de travail pour les intégrer dans le nouveau domaine pris en charge par le
serveur Scribe. C’est d’ailleurs l’étape la plus longue de l’installation.

Il ne s’agit pas d’un système imposé

En conséquence, Scribe n’est pas un serveur aussi indispensable que ne l’est Amon ou Horus,
qui sont des briques indispensables du réseau établissement. Le serveur Scribe est proposé aux
utilisateurs habitués à l’ensemble Eole, et qui veulent bénéficier des fonctionnalités d’administra-
tion et de surveillance disponibles dans Zéphir. On le trouve toutefois déjà déployé dans certaines
académies, aux côtés de serveurs Microsoft Windows, pour servir de supports à des applications
de gestion des notes des élèves, qui doivent être accessibles tant de l’administratif que de la
pédagogie.

Premier rôle : le service de fichiers

La première fonction de Scribe est d’héberger les répertoires personnels des élèves, des classes
et des professeurs. Il s’agit du complément le plus simple à la fonciton d’annuaire : si le serveur
connaît le profil de chaque élève, il peut lui associer un certain nombre de droits d’accès à des
répertoires partagés.

Le serveur Scribe est vu comme un contrôleur de domaine NT. Il connaîtra, par le biais de l’ex-
traction des données issues de GEP, la liste des comptes utilisateurs, et autorisera la connexion
des utilisateurs. Du point de vue des stations, la connexion se fait dans un domaine NT, et les res-
sources partagées par le serveur sont immédiatement vue dans le voisinage réseau des stations.
Le fonctionnement au jour le jour ne devrait pas changer pour les utilisateurs habituels du réseau
pédagogique.

Deuxième rôle : le service de messagerie

Le serveur Scribe héberge un service de messagerie qui fournit plusieurs fonctionnalités. La pre-
mière est la messagerie interne, utilisée au sein de l’établissement. Elle sert pour la communica-
tion des élèves et des professeurs. Elle est secondée par un système de listes de diffusion, appuyé
sur l’annuaire, qui permettra aux enseignants de contacter aisément des groupes de travail ou des
classes entières.

En présence d’un système de relais académique, le serveur Scribe pourra aussi communiquer
avec l’extérieur, si le chef d’établissement souhaite autoriser cette fonction. Les élèves pourront
alors échanger avec des boîtes aux lettres externes, en utilisant une adresse électronique routable
sur Internet.

Cette fonctionnalité nécessite l’appui d’une configuration au rectorat, car l’accès permanent au
serveur (notamment durant les grandes vacances) ne peut pas vraiment être garanti partout. De
plus, il est nécessaire de prévoir un secours en cas de défaillance : le rectorat se chargera de ces
redirections.

Troisième rôle : des fonctions pédagogiques en développement

Scribe pouvant remplacer, à terme, les serveurs Microsoft sur le réseau pédagogique, il est né-
cessaire d’offrir sur cette plateforme des équivalents aux applications que l’on trouve encore ac-
tuellement, notamment pour le verrouillage des stations clientes et les applications pédagogiques.
Reproduction interdite.

Il s’agit d’un travail de longue haleine, qui pourra être fait rapidement pour les applications déve-
loppées en interne, mais qui ne dépend pas de l’équipe de Dijon. Certaines fonctionnalités, qui
sont intimement liées à la procédure de connexion ou d’accès au serveur, seront toutefois mises
en place par Dijon, comme pour le verrouillage des stations.

Le serveur Scribe : quelles fonctions ?

9
Le serveur Scribe, pourquoi faire ?
 Ces fonctionnalités sont amenées à se développer par l’intégration d’outils externes comme ESU4,
et grâce aux remontées d’expériences des académies volontaires.

Quatrième rôle : un serveur Web

Scribe fait tourner le serveur Web Apache, d’une part pour des raisons liées aux applications —
certaines applications pédagogiques sont développées pour fonctionner en mode Web, afin d’évi-
ter tout problème d’incompatibilité — et d’autre part pour servir d’hébergement pour un Intranet
éventuel.

Cinquième rôle : un espace de travail collaboratif

Dans cette optique, le système SPIP, un système de développement simplifié de site Web, a
été intégré dans Scribe. Il offre des fonctionnalités de publication et de gestion de contenu à la
portée des élèves, et est utilisé avec succès dans de nombreux établissements. Scribe offre cette
fonctionnalité sans perte de performance, un serveur Web étant déjà intégré au serveur Scribe.
Reproduction interdite.

Le serveur Scribe : quelles fonctions ?

10
Le serveur Scribe, pourquoi faire ?
 1.2 : Les technologies de Scribe

Le système de déploiement Eole

Il se déploie en conformité avec le système Eole
L’administration courante se fait par EAD
Le serveur de fichiers Samba
Exim et Sympa pour la messagerie

Cups pour la gestion des imprimantes

Le système de déploiement Eole

Il se déploie en conformité avec le système Eole

Le serveur utilise la procédure Eole standardisée. Cette procédure, sur laquelle nous reviendrons,
peut se faire soit par le biais d’un serveur Zephir, soit par la création d’un fichier de configuration
autonome en répondant à un questionnaire.

L’installation dans l’établissement se limite à l’installation depuis un CD-ROM, puis à l’application

de la configuration contenue dans le fichier généré au préalable. L’installation de Scribe, en lui-
même, est extrêmement rapide.

L’essentiel du paramétrage, dépendant de chaque établissement, consistera à créer les listes

d’utilisateurs et de leurs droits, ainsi qu’à paramétrer les stations clientes.

L’administration courante se fait par EAD

Comme tous les éléments Eole, l’administration de base peut se faire de l’établissement au moyen
d’une interface Web accessible sans connaissances informatiques avancées préalables. Cette in-
terface est destinée à permettre un premier diagnostic, à réaliser les opérations courantes d’admi-
nistration du serveur, et toutes les opérations que le personnel de l’établissement peut être amené
à effectuer dans le cadre du fonctionnement normal du système.

Pour les fonctionnalités les plus avancées, il est possible de prendre la main à distance sur le
serveur, et d’avoir tous les droits d’administration, là où l’interface Web est conçue pour ne pas
permettre de causer des dégâts irréparable, même si elle était manipulée par un néophyte. Pour
le personnel informatique, l’accès en SSH avec tous les droits reste une solution envisageable.

Le serveur de fichiers Samba

Reproduction interdite.

Pour le partage de fichier, la gestion des utilisateurs et de leur droits, le logiciel Samba, déjà
présent dans Horus notamment, est utilisé. Il permet une interopérabilité avec le minimum d’effort
avec les stations.

Il permet aussi de réutiliser les méthodes de configurations mises en place sur le serveur Horus,
et déjà connues généralement.

Le serveur Scribe : quelles fonctions ?

11
Les technologies de Scribe
 Exim et Sympa pour la messagerie
Le logiciel Exim est un des logiciels libres capables de gérer le courrier électronique. Contraire-
ment aux logiciels-mastodontes, comme Postfix ou Sendmail, il est très adapté, par sa configu-
ration simple, à l’utilisation de sites terminaux du courrier électroniques, qui ne réalisent pas de
relais complexes ou de filtrages évolués. Il est de plus capable d’interagir avec l’annuaire LDAP
pour la gestion des comptes.

Le logiciel Sympa (système de multipostage automatique) est utilisé pour la gestion des listes de
diffusion, lui aussi reposant sur l’annuaire LDAP.

Cups pour la gestion des imprimantes

Le partage des imprimantes, soit connectées au serveur, soit accessible par un réseau local, se
fait avec le logiciel CUPS, entièrement configuré par un site Web. Cette interface permet le rempla-
cement des imprimantes, ou l’intégration d’une batterie d’imprimante, sans faire nécessairement
appel à l’assistance aux établissements.
Reproduction interdite.

Le serveur Scribe : quelles fonctions ?

12
Les technologies de Scribe
 1.3 : Le déploiement de Scribe : les points à considérer

Un système peu gourmand en ressources

La migration des données est possible

Il faut s’assurer au préalable de la compatibilité

Un système peu gourmand en ressources

Toutes ces fonctionnalités sont hébergées en utilisant très peu de ressources processeur, et le
seul critère à retenir par rapport aux serveurs commercialisés actuellement et celui de l’espace
disque, notamment si le choix du SCSI est retenu. En effet, le partage ou l’acheminement du cour-
rier ne nécessitent que peu de ressources. Le seul traitement intensif que le serveur doit réaliser
est la connexion de tous les utilisateurs simultanément au début des cours, et les processeurs
modernes sont largement capables de supporter cette charge.

Pour accélérer le traitement, la mémoire vive sera mise à contribution, aussi déconseille-t-on
moins de 512 Mo sur les serveurs pour de bonnes performances. Tout dépend, en fait, du nombre
d’utilisateurs simultanément connectés.

La migration des données est possible

Le serveur Scribe de l’ensemble des outils clients Samba, qui permettent à un serveur Linux
d’accéder à des partages Windows. On pourra donc, moyennant une manipulation des droits
pour attribuer les fichiers à leur propriétaire sur le serveur, transférer des données existantes d’un
serveur Microsoft Windows 2000 vers le serveur Scribe simplement en se connectant en tant
qu’administrateur et en copiant l’intégralité des répertoires. Le déploiement d’un serveur Scribe
peut donc être totalement transparent pour les utilisateurs, si la migration des stations clientes se
fait durant une période de vacances.

Il faut s’assurer au préalable de la compatibilité

Lorsque le rôle de contrôleur de domaine, et donc de contrôleur de l’authentification des utilisa-
teurs sur les postes de travail, est dévolu au serveur Scribe, certaines fonctionnalités en place,
notamment celles liées au verrouillage des stations clientes par l’exécution d’un script de démar-
rage particulier, risquent de ne plus fonctionner : Scribe se substitue au serveur qui offrait cette
Reproduction interdite.

fonctionnalité antérieurement.

Pour éviter les mauvaises surprises, il est indispensable d’anticiper, et de recenser toutes les
fonctions offertes par le contrôleur de domaine à remplacer. L’équipe Eole fait de son mieux pour
offrir un système complet, mais ne peut connaître toutes les applications utilisées sur les serveurs
pédagogiques. La plupart d’entre elles sont accessibles par des partages et continueront donc

Le serveur Scribe : quelles fonctions ?

13
Le déploiement de Scribe : les points à considérer
 à fonctionner. Certaines nécessitent, en revanche, d’agir depuis le contrôleur de domaine. Pour
ces dernières, l’équipe Eole tente de proposer des solutions équivalentes, mais ne peut connaître
l’ensemble des besoins potentiels.

Dans la plupart des cas, les applications sont simplement hébergées sur le serveur, et non pas
exécutées. Certains programmes disposent d’une partie serveur (BCDI...) et ne peuvent donc pas
s’exécuter sur Scribe, mais ils sont très minoritaires.
Reproduction interdite.

Le serveur Scribe : quelles fonctions ?

14
Le déploiement de Scribe : les points à considérer
 1.4 : Dimensionnement d’un serveur Scribe

Les besoins en disque

Il s’agit de la ressource la plus précieuse d’un Scribe

Le serveur peut tenir compte de plusieurs disques

Les besoins en mémoire
Les besoins en puissance processeur

Les besoins en disque

Il s’agit de la ressource la plus précieuse d’un Scribe

Le serveur Scribe a besoin d’espace disque pour conserver les documents des utilisateurs. Les
besoins pour les parties systèmes sont des plus restreintes, et le contenu de /usr loge dans
moins de 2 Go. C’est donc entièrement aux documents que sera dévolu l’espace disque, qu’ils
soient relatifs aux sites Web hebergés sur l’Intranet, aux boîtes aux lettres des utilisateurs, ou
aux documents personnels. On ne saurait fixer de limite supérieure, et des statistiques faites
sur des comptes personnels universitaires, fixant une limite haute, montre que l’on peut fixer un
minimum utilisable de 50 Mo par utilisateur. On aura tendance à craindre que l’espace disque ne
soit consacré essentiellement au stockage de mp3 ou de divX, mais il faut se rappeler qu’avec le
développement des liaisons rapides, il n’est pas rare de trouver des documents PDF de plusieurs
Mo, et que le cache du navigateur aura tendance à occuper un espace non négligeable s’il est
conservé dans le répertoire personnel de l’élève (ce que la sécurité du système recommande).

L’installation d’un Scribe nécessite au minimum 12 Go d’espace disque, mais une telle valeur
est largement insuffisante compte tenu des besoins habituellement constatés dans les établisse-
ments. C’est une valeur minimale pour l’installeur automatique.

En tout état de cause, les disques actuels permettent de disposer de grandes capacités pour un
prix réduit, et les élèves tentés d’abuser pourront se voir opposer un quota d’espace disque à
respecter.

Le serveur peut tenir compte de plusieurs disques

S’il est commun d’utiliser deux disques, l’un pour le système, l’autre pour la conservation des
sauvegardes, c’est notammant car chaque partition doit être entièrement contenue sur un disque.
Si l’on peut découper une partition en plusieurs partitions, la découpe doit se faire de manière à
s’intégrer aisément dans l’arborescence, et on aura du mal à dédoubler la partition contenant les
Reproduction interdite.

répertoires des utilisateurs, qui représente l’essentiel de l’occupation disque. Il est donc préférable
de prévoir large lors du dimensionnement initial du serveur, et d’affecter un disque complet à la
partition des utilisateurs.

Le serveur Scribe : quelles fonctions ?

15
Dimensionnement d’un serveur Scribe
 Les besoins en mémoire
Le serveur ne saurait fonctionner efficacement s’il devait manquer de mémoire. Contrairement à
ce qui se passe avec un serveur Horus, le serveur Scribe recevra de nombreuses connexions
simultanées d’utilisateurs manipulant de gros fichiers, et devra donc pouvoir en conserver des
copies en mémoire, en plus de ce qui est nécessaire au fonctionnement du service Samba et du
reste des applications.

Chaque copie du processus Samba va consommer environ 0,5 Mo par utilisateur connecté simul-
tanément qu’il soit actif ou inactif. A cela viendront s’ajouter 128 Mo pour le système Linux, et la
taille des fichiers manipulés par les utilisateurs actifs (qui sont généralement moins nombreux que
les utilisateurs connectés). En fonction des besoins (bureautique ou traitement d’images, les exi-
geances des applications sont très différentes...) on devra déterminer le dimensionnement idéal
du serveur Samba, sachant que le minimum nécessaire correspond aux chiffres cités plus haut.
En l’absence de statistiques sur les habitudes des utilisateurs élèves, on considère dans un en-
vironnement bureautique pur qu’un minimum de 512 Mo est adapté à 100 utilisateurs, et qu’1 Go
est suffisant jusqu’à 500 utilisateurs.

Les besoins en puissance processeur

Le processeur est encore une fois la ressource la plus abondante sur le serveur. Il ne sera sollicité
que relativement ponctuellement sur le serveur Scribe, pour piloter les accès disques essentielle-
ment, les processus étant peu gourmands en puissance de calcul. Les applications restant exécu-
tées sur les stations, il n’est pas nécessaire de prévoir le processeur en fonction des programmes
installés.

On pourra noter à titre indicatif qu’un Pentium 133 est capable de gérer cent connexions simulta-
nées à un serveur Samba, et que le goulet d’étranglement sera donc certainement lié aux lenteurs
d’authentification ou à un manque de mémoire. Lorsque le serveur Scribe est amené à se substi-
tuer à un serveur Windows fonctionnel, on pourra partir sur une machine similaire pour l’héberger.
Reproduction interdite.

Le serveur Scribe : quelles fonctions ?

16
Dimensionnement d’un serveur Scribe
2. Installation
d’un système
Scribe
 2.1 : Considérations matérielles

Le système Linux reconnaît la plupart du matériel récent

Le matériel reconnu par Scribe
Il peut être utile d’installer plusieurs disques
Cela implique un partitionnement manuel

Le système Linux reconnaît la plupart du matériel récent

Par le passé, le système Linux a acquis une réputation, souvent erronée, de ne pas supporter un
grand nombre de matériels. De nos jours, ce préjugé n’est plus valable, et ce d’autant moins que
les périphériques les plus délicats à prendre en charge, les cartes graphiques — qui évoluent très
rapidement et dont le fonctionnement interne est souvent un secret de fabrication — ne sont pas
nécessaires au bon fonctionnement des modules Eole.

En effet, seule une interface texte, ou une interface via des pages Web, est disponible sur la
machine. Comme il n’est normalement pas nécessaire d’intervenir directement sur le système,
une interface utilisateur semble superflue.

On pourra donc raisonnablement installer le système sur tout type de matériel répondant aux
spécifications énoncées ci-après. En cas de doute, on pourra consulter les nombreuses listes de
matériel supporté par Linux, notamment à l’URL suivante :

http://www.tldp.org/HOWTO/Hardware-HOWTO/

Il s’agit d’une base de données recensant les différents types de matériels supportés par Linux.

Le matériel reconnu par Scribe

Le serveur Scribe doit s’installer à partir de la dernière version du CD-ROM disponible, d’une
part pour éviter d’avoir à télécharger des mises à jour volumineuses, d’autre part pour bénéficier,
durant l’installation, du meilleur support du matériel disponible. Lorsque l’équipe Eole intègre de
nouveaux pilotes dans Scribe, elle génère alors une nouvelle image du CD-ROM, car par défi-
nition, si un matériel vital n’est pas supporté depuis le CD, il sera impossible d’installer puis de
mettre à jour pour en tenir compte.
Reproduction interdite.

L’équipe Eole compte mettre en place prochainement une base de connaissance recensant les
types de matériel supporté, à commencer par les serveurs des marchés nationaux, qui sont les
plus susceptibles d’être utilisés dans l’immédiat. Ce besoin se faisant ressentir de manière de
plus en plus pressante lorsque les réseaux pédagogiques font l’objet de dotations directes des
collectivités territoriales, une liste du matériel supporté fait partie des priorités.

Installation d’un système Scribe

18
Considérations matérielles
 Il peut être utile d’installer plusieurs disques
De la panoplie Eole, le serveur Scribe est le plus susceptible de profiter de plusieurs disques, que
ce soit configurés en RAID matériel, totalement transparent pour le système Linux, ou simple-
ment montés à différents points de l’arborescence, tant pour des raisons de performances que de
fiabilité.

Cela implique un partitionnement manuel

La méthode d’automatisation du partitionnement offre de bons résultats pour un partitionnement

sur un seul disque, mais risque d’obtenir des résultats aberrants avec plus d’un disque, du fait
de l’impossibilité de considérer l’ensemble de l’espace disque disponible comme un tout unique.
Les partitions devant rester cantonnées sur un même disque, on risque d’obtenir des résultats
étranges si une série de partitions moins utiles est affectée sur un disque, et que toutes les parti-
tions utiles se disputent l’espace disque du premier.

L’installation d’un serveur multidisque doit donc se faire en mode pro, qui permet un partition-
nement personnalisé. On veillera à respecter les consignes données durant la formation Tronc
commun, en sachant que les partitions importantes pour Scribe sont :
la partition /home qui héberge les dossier des utilisateurs, et qui doit être formatée en
XFS pour supporter les ACL ;
la partition /var/spool qui contient les files d’attente d’impression et de courrier électro-
nique ;
la partition /var/lib qui contient l’annuaire ;
la partition /var/www qui contient le site Web ;
la partition /var/log qui contient les traces de connexion des utilisateurs.

Comme on le voit, le serveur Scribe a un partitionnement complexe. Si l’on ne souhaite pas mettre
en fonctionnement une tâche précise, comme l’hébergement d’un Web interne, il est néanmoins
recommandé de prévoir l’espace disque correspondant : d’une part cela permet d’éviter qu’une
partition située plus haut dans l’arborescence ne soit remplie par inadvertance, d’autre part, cela
permettra d’activer la fonctionnalité à l’avenir sans avoir à réinstaller le serveur.

La partition /home reste la plus importante, en taille. Elle va héberger toutes les données des
utilisateurs. Pour pouvoir fonctionner correctement, deux options sont indispensables : le forma-
tage en XFS, un système de fichiers qui prend en charge les ACL indispensables à la gestion des
droits Windows sur les fichiers, ainsi que l’ajout des options usrquota et grpquota, si l’on veut
pouvoir activer la gestion des quotas de disque sur cette partition.
Reproduction interdite.

Installation d’un système Scribe

19
Considérations matérielles
 2.2 : Aperçu de la méthode d’installation au niveau académique

L’installation initiale
Installation du système
Saisie des paramètres de configuration généraux de l’académie

La configuration des paramètres spécifiques au serveur

Application des paramètres à la machine locale

Les installations suivantes
Installation du système
Personnalisation de la configuration

Importation du fichier de configuration

Application de la configuration

L’installation initiale
L’installation initiale est celle de la machine maîtresse, sur laquelle se fait la configuration des
paramètres académiques. Tous les autres systèmes seront des réplicats de celui-ci, accélérant
encore le processus d’installation.

Installation du système

La première étape consiste à installer le système directement à partir du CD. L’installeur est censé
procéder de la manière la plus automatique qui soit : il va détecter le matériel et imposer un
certain nombre de choix par défaut correspondants, notamment pour la création de partitions sur
le disque, et pour la création des comptes utilisateurs initiaux. À la fin de l’installation, le système
redémarre.
Note
Attention, l’installation va détruire, comme annoncé au démarrage, l’ensemble des
données présentes sur le disque.

L’installation recopie l’ensemble des logiciels nécessaires sur le disque, mais ne crée à ce moment
aucune configuration : cette étape a seulement pour objectif d’installer un squelette de système.

Cette étape étant entièrement automatisée, peu d’erreurs peuvent avoir lieu. La compatibilité du
matériel avec EOLE — et la gravure correcte des disques — risquent d’être les deux seules
sources d’erreur.

Saisie des paramètres de configuration généraux de l’académie

L’ensemble des services et des programmes du système est configuré à partir d’un fichier de
modèles. Il n’est donc pas nécessaire, pour une utilisation courante du serveur Scribe, d’avoir de
quelconques connaissances du système Linux : il suffit de répondre aux questions du script de
Reproduction interdite.

configuration, qui va déduire la configuration la plus adaptée au cas décrit.

Pour exécuter ce script, il faut d’abord se connecter au système. L’interface d’accueil est textuelle.
Il faut d’abord saisir l’identifiant root lorsque le système demande le login:. Le compte root
est celui de l’administrateur du système. Il permet de tout faire sur le système, et notamment
la plupart des opérations d’administration. Son mot de passe ne doit être connu que des ser-
vices académiques, et pas des correspondants techniques. Toutes leurs interventions se feront

Installation d’un système Scribe

Aperçu de la méthode d’installation au niveau 20
académique
 au moyen de l’interface EAD.

Le password initial de l’administrateur est Eole. Nous verrons comment le changer par la suite.
Il n’y a pas de retour écran lorsque l’on tape le mot de passe pour se connecter. Si tout s’est bien
passé, on accède à une ligne de commande du type

eole:˜#

Il faut alors exécuter la commande ./gen_dico. Il s’agit du script de configuration, qui va poser
les questions sur les paramètres de configuration propre à l’académie. Ce script va générer le
modèle de configuration adapté, appelé zephir.eol.

Le script de génération du dictionnaire permet de fournir les renseignements valables pour toute
l’académie. Il est inutile de répondre correctement, par exemple, aux questions portant sur les
adresses IP, puisqu’elles sont spécifiques à chaque établissement. En revanche, la partie géné-
rique, telle que le cache-père de l’académie ou le nom du serveur contenant les mises à jour de
RPM, peuvent être fournis une fois pour toutes.

Le script ./gen_dico n’a aucun effet sur la configuration du système : il sert seulement à définir
des choix par défaut pour l’étape suivante.

Le script demande les informations suivantes :

les paramètres réseau du serveur (adresse IP, nom de domaine du réseau pédagogique,
informations nécessaires pour le routage, comme la passerelle de sortie...) ;

les paramètres NetBIOS du serveur, dont le nom sous lequel il apparaîtra dans le réseau
local, et le nom du domaine SMB qu’on veut qu’il contrôle ;
les paramètres nécessaires pour configurer l’annuaire LDAP, comme le nom de l’académie
et le numéro RNE, qui servent de branche de base pour l’annuaire dans l’optique d’un
annuaire académique unifié ;
les serveurs que Scribe doit interroger pour naviguer sur Internet (DNS et mandataire
Web) ;
les noms des serveurs de mise à jour et de référence à utiliser ;
les noms des serveurs de temps, qui permettent de garder le serveur Scribe à l’heure ;

le choix de la présentation des montages (sous différentes lettres ou sous une seule
lettre) ;
l’adresse d’un réseau autorisé à se connecter au serveur pour le téléadministrer.

Toutes ces informations permettent de paramétrer les différents programmes tournant sur le ser-
veur Scribe. On veillera notamment à s’assurer que les paramètres comme le nom de l’académie
(ac-qqchose) n’est pas le nom DNS académique (ac-qqchose.fr) et que le numéro RNE saisi
est valide : aucune vérification n’est faite sur ce numéro, qui va être utilisé dans la construction de
l’annuaire. En cas d’erreur, tout fonctionnera jusqu’à ce que serveur doive être réinstancié com-
plètement : si l’on saisit, à cette occasion, le numéro RNE correct, les sauvegardes de l’annuaire
ne fonctionneront plus.

Le serveur utilisé pour la mise à jour devrait être, idéalement, un serveur situé dans l’académie,
Reproduction interdite.

pour éviter de surcharger les serveurs de Dijon et pour laisser aux responsables informatiques
locaux un délais pour valider les mises à jour. Il est préférable de disposer d’une maquette d’éta-
blissement mise à jour sur Dijon, afin de pouvoir tester tous les choix locaux, et une fois que tout
est satisfaisant, de mettre à jour un miroir local du site dijonnais, miroir utilisé par les établisse-
ments. On évite ainsi, en cas de mise à jour défaillante à Dijon, des pannes en cascade dans
l’ensemble des établissements installés.

Installation d’un système Scribe

Aperçu de la méthode d’installation au niveau 21
académique
 Le serveur de référence n’est pas utilisé dans les procédures courantes de l’EAD. Elle ne sert que
pour forcer la synchronisation des applications installées avec un serveur. On l’utilisera notamment
lorsque l’on suspecte un piratage, vu que cette commande réinstalle l’ensemble des paquets,
écrasant ainsi les paquets corrompus. On pourra aussi s’en servir en cas d’effacement accidentel
d’un paquet, à la main, sur le serveur. La procédure de mise à jour ne met à jour que les paquets
installés, et la réinstallation risque d’être problématique. Le script ControlRPM-Net permet de
résoudre ce problème, en utilisant le serveur de référence comme cible.

Le serveur autorisé à se connecter pour la téléadministration va dépendre des configurations

réseau adoptées dans l’établissement, et notamment de la présence d’un Amon, de la possibilité
d’accéder en télémaintenance au serveur Scribe, etc.

La configuration des paramètres spécifiques au serveur

Une fois le serveur initial configuré, tous les serveurs Scribe de l’académie le seront à partir
d’un fichier de configuration comportant l’intégralité des informations, à savoir les informations
académiques générales, et les informations spécifiques.

Pour générer le fichier eol contenant toutes ces informations, il faut, sur une machine où le
dictionnaire a déjà été initialisé, exécuter le script ./gen_config.

Il commence par demander un identifiant de l’établissement, qui va lui servir à baptiser le fichier
eol. Il repose ensuite toutes les questions vues dans la génération du dictionnaire, en reprenant
les choix par défaut qui auront été saisis.

Application des paramètres à la machine locale

Le programme instance_scribe se charge de lire un fichier eol et de configurer tous les

paramètres du système en fonction des données qu’il contient. Pour ce faire, on exécute :

./instance_scribe mon_etab.eol

L’application de la configuration va avoir plusieurs conséquences. Lors de la première installation,

elle va forcer le changement de plusieurs mot de passe. Celui de root en premier lieu, pour éviter
de laisser le serveur ouvert à quiconque aurait lu le site officiel Eole, puis il va forcer l’attribution
d’un mot de passe pour l’utilisateur scribe qui permet une administration locale limitée en ligne
de commande. Enfin, le script demande s’il faut écraser générer l’annuaire LDAP de base, qui sert
de squelette pour l’insertion des comptes utilisateurs à partir de GEP.

Les installations suivantes

Installation du système

Cette opération se déroule comme lors de l’installation de la machine maîtresse. Il n’y a pas
d’opération particulière à effectuer.

On pourra toutefois souhaiter un partitionnement différent du partitionnement par défaut. Dans

ce cas, il est nécessaire de réaliser l’installation en mode pro pour redimensionner les partitions
correctement. Cette méthode est nécessaire lorsque l’on utilise plus d’un disque sur le serveur,
pour éviter des disproportions dans les partitions. On pourra notamment veiller à séparer, dans le
partitionnement, les journaux du système (qu’il est indispensable de conserver) et les zones de
Reproduction interdite.

données personnelles (/home) et applicatives (comme /var/www).

Personnalisation de la configuration

Il faut d’abord exécuter la commande ./gen_config sur la machine maîtresse, et répondre

aux questions du script. Il va créer un modèle de configuration adapté, portant le nom
établissement.eol.

Installation d’un système Scribe

Aperçu de la méthode d’installation au niveau 22
académique
 Importation du fichier de configuration

Le fichier de configuration initial peut être transféré par disquette. Pour cela, il faut suivre le proto-
cole suivant :
Insérer une disquette dans le lecteur ;
Taper mount /dev/fd0 sur le maître ;
Copier le fichier .eol dans le répertoire /mnt/floppy ;
Démonter la partition :umount /dev/fd0

On procède à l’opération inverse sur le serveur-fils.

La machine peut alors être livrée dans l’établissement de destination, où elle sera reliée aux
différentes zones (Internet, pédagogique, administrative). Lors de la phase d’installation, il peut
être utile de repérer à quelles cartes réseaux correspondent les différentes adresses, afin de
brancher correctement la machine.

Application de la configuration

Il faut alors démarrer la machine, se connecter en tant que root, et lancer la commande :

./instance_scribe établissement.eol

On pourra alors redémarrer la machine pour s’assurer que les différentes modifications ont bien
été prises en compte, et que tous les services ont notamment été redémarrés.

On pourra alors se reconnecter en tant que root, pour réaliser deux opérations :
exécuter le script ./diagnose.sh qui effectuera une série de tests assurant le bon fonc-
tionnement du serveur ;
modifier le mot de passe de root, en utilisant la commande passwd. Elle demande
d’abord de saisir l’ancien mot de passe, puis le nouveau, à deux reprises pour éviter les
désagréments liés à une erreur de frappe lors de la saisie du mot de passe.
Reproduction interdite.

Installation d’un système Scribe

Aperçu de la méthode d’installation au niveau 23
académique
 2.3 : Les opérations à effectuer dans les établissements

L’inscription des stations dans le domaine

L’importation des bases GEP dans l’annuaire LDAP

L’inscription des stations dans le domaine

Le serveur Scribe doit être le contrôleur de domaine des stations du réseau pédagogique. Il faut
donc configurer ces stations pour qu’elles n’utilisent plus de comptes locaux, ou leur ancien contrô-
leur de domaine selon les cas, mais le serveur Scribe pour déterminer si un utilisateur peut se
connecter. Cette opération doit être faite par un administrateur de la station.

Lors de l’inscription de la station dans le domaine, elles établissent avec le contrôleur une relation
de confiance et échangent des certificats leur permettant de se reconnaître mutuellement. La
reconnaissance n’est pas basée sur le nom du domaine, mais sur un mot de passe déterminé lors
de l’inscription. En conséquence, on ne peut pas simplement remplacer un contrôleur existant
par un serveur Scribe et espérer que tout fonctionne. Même si les stations fonctionnaient déjà en
mode domaine, elles doivent subir à nouveau la procédure d’inscription.

Dans ce dernier cas, elles doivent d’abord être reconfigurées en mode autonome (groupe de
travail) pour briser l’association avec l’ancien domaine, et ce même s’il porte le même nom, puis
être réinscrites dans le domaine. L’opération se déroule de la même façon que pour une première
inscription.

L’importation des bases GEP dans l’annuaire LDAP

Les comptes utilisateurs des professeurs et des élèves peuvent être créés soit manuellement,
soit, et c’est le cas général, en important les bases GEP existantes. Le détail de l’opération sera
vu plus loin, mais cela signifie qu’il faut prévoir, lors de l’installation, de se doter de la base de
l’établissement. L’annuaire LDAP contient la liste des utilisateurs, et accomplit les formalités d’au-
thentification dans le domaine.

Il est important que le déploiement du serveur Scribe s’accompagne d’une sensibilisation au chan-
gement du mot de passe par défaut qu’il va attribuer, tout particulièrement pour les comptes des
Reproduction interdite.

professeurs.

Installation d’un système Scribe

24
Les opérations à effectuer dans les établissements
3. Finalisation de
l’installation
avec l’EAD
 3.1 : Aperçu général de l’outil

L’accès se fait par le Web

La transaction est sécurisée
La connexion se fait sur le port 8501
Il faut accepter le certificat proposé par le serveur
L’accès à EAD est authentifié
La page d’accueil permet de savoir si tout fonctionne

La section centrale contient les dates des opérations importantes

La barre de droite est une barre de navigation

L’accès se fait par le Web

L’interface EAD permet l’administration du système au moyen d’un navigateur situé sur le réseau
pédagogique. La plupart des tâches courantes peuvent être effectuées au moyen de formulaires
et de boutons.

La transaction est sécurisée

Afin d’éviter l’interception des données, et donc la connaissance par un utilisateur du réseau pé-
dagogique de la configuration du pare-feu, ou des données d’authentification, l’ensemble des tran-
sactions est chiffré, en utilisant le protocole SSL. Il est donc nécessaire d’indiquer au navigateur
de se connecter en HTTPS.

La connexion se fait sur le port 8501

Les numéros de port des applications sont standardisés. Pour éviter un conflit avec le service
Web, qui fonctionne lui par défaut sur le port 80, et pour ne pas déroger aux normes d’Internet, le
site de configuration est placé sur le port 8501. L’URL d’accès complète est donc :

https://[ip-du-scribe]:8501

Note
Il est aussi possible d’utiliser le nom du serveur dans le réseau pédagogique. Tou-
tefois, en cas de problème sur le serveur DNS, ce nom ne sera pas accessible,
puisque c’est le serveur DNS qui fait l’équivalence entre noms et adresses IP. Il
est donc préférable d’utiliser l’adresse IP directement, même si c’est légèrement
plus contraignant. De manière générale, lorsque l’on fait le premier essai d’une
connexion à un serveur, et que l’on craint qu’un problème ne survienne, il est pré-
férable de tester en utilisant les adresses IP plutôt que les noms de machines, afin
Reproduction interdite.

d’éliminer un problème potentiel.

Il faut accepter le certificat proposé par le serveur

Lors de la première connexion depuis la station d’administration, le serveur va proposer un certi-

ficat SSL. Par défaut, les navigateurs n’acceptent de faire confiance qu’à quelques émetteurs, et
le projet EOLE n’en fait pas partie.

Finalisation de l’installation avec l’EAD

26
Aperçu général de l’outil
 Les navigateurs vont alors proposer de valider le certificat manuellement après un message
d’avertissement. Cette étape est normale, et doit être effectuée. En revanche, il est déconseillé
de l’accepter définitivement. En effet, le certificat est généré à l’installation du serveur, de manière
aléatoire. Si le navigateur a conservé une copie du certificat et l’a associée au serveur Scribe, en
cas de réinstallation, il faudra l’effacer manuellement du navigateur pour que ce dernier accepte
de se connecter à nouveau. Il est donc préférable de n’accepter que temporairement le certificat.

L’accès à EAD est authentifié

La connexion peut alors se poursuivre. Le serveur va vérifier que la connexion est bien faite par
un administrateur légitime, en demandant l’identifiant et le mot de passe correspondant.

Lors de la première connexion, l’identifiant est administrateur, et le mot de passe est admin
après l’installation. On accède alors à la page d’accueil. Le nom a été choisi afin de rester en
cohérence avec le serveur Horus.

La page d’accueil permet de savoir si tout fonctionne

La barre de gauche de la page d’accueil contient une série d’indicateurs colorés indiquant le bon
fonctionnement des services fournis par le serveur. Une loupiote verte indique que le service est
démarré. Elle ne peut toutefois rien dire sur son bon fonctionnement : le diagnostic se limite à
détecter la présence du service et son lien avec son port d’écoute standard.

Cette liste utilise les mêmes mécanismes que le script de vérification diagnose.sh que l’on
lance après l’installation.

L’indicateur réseau indique si l’interface a été correctement configurée. Elle ne teste pas l’accès
au voisinage réseau, ou au réseau Internet. En général, lorsque l’on peut visualiser cette loupiote,
par l’EAD, le réseau est opérationnel... L’onglet services distants permet de vérifier l’accès à
Internet depuis le Scribe, et donc notamment les possibilités de mise à jour.

Les autres indicateurs reflètent le bon démarrage sur le serveur des programmes chargés d’as-
surer les services correspondants.

La section centrale contient les dates des opérations importantes

Les opérations importantes que sont la mise à jour du serveur (qui peut affecter son fonction-
nement), la sauvegarde des données et l’extraction des élèves depuis une base GEP (qui doit
généralement être précédée d’une sauvegarde...) sont enregistrées par Scribe et affichées direc-
tement sur la page d’accueil, avec un lien vers le fichier texte contenant les messages d’erreur
éventuels

La barre de droite est une barre de navigation

La barre de droite sert à naviguer dans les pages de l’EAD et contient des liens vers les différents
outils. Cette interface varie en fonction du profil, certaines fonctionnalités étant dissimulées aux
utilisateurs qui n’y ont pas accès.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

27
Aperçu général de l’outil
 3.2 : Les différents profils de connexion à l’EAD

Le profil administrateur sert aux responsables techniques

Le profil professeur permet d’accéder aux fonctions pédagogiques

Le profil professeur principal ajoute des droits sur une classe

Le profil administrateur sert aux responsables techniques

Le profil administrateur donne accès à tous les éléments de l’interface. Il équivaut à l’interface en
ligne de commande pour les tâches d’administration et permet de surveiller le bon fonctionnement
du serveur, et de redémarrer les éléments problématiques, ainsi que de réaliser les tâches cou-
rantes (comme la gestion des utilisateurs, l’ajout d’une station dans le domaine, la gestion des
imprimantes, les sauvegardes...)

Le profil administrateur ouvre également les droits conférés à un professeur ou à un professeur

principal, ce qui permet de vérifier que les opérations se sont correctement déroulées.

Ce profil doit être distribué dans les établissements scolaires : il permet de faire, au moins, un
premier diagnostic en cas de problème. Les droits associés à ce profil sont suffisamment restreints
pour qu’aucune opération destructrice ne puisse être faite : aucun dommage durable ne surviendra
d’une fausse manipulation. Le seul risque concerne la destruction des groupes, qui reste l’attribut
de l’administrateur. Lorsqu’un groupe n’a plus lieu d’être (lié à un travail ponctuel, par exemple),
il peut le supprimer. Toutefois, cela n’entraînera pas de perte de données sur le serveur en lui-
même.

Le profil professeur permet d’accéder aux fonctions pédagogiques

Il s’agit du profil le plus restreint. Il permet aux professeurs d’utiliser leurs adresses de courrier
électronique, de s’inscrire dans des groupes de travail, et d’accéder aux fonctions liées à l’en-
seignement, comme la gestion des devoirs ou la surveillance des postes des élèves... Ce profil
ne correspond pas à un identifiant unique : chaque professeur disposera de son propre accès,
protégé par mot de passe, avec les droits associés à ce profil.

Cela implique, peut-être, de prévoir une sensibilisation des enseignants quant à la protection de
leur mot de passe, conditionnant l’accès à des données personnelles et confidentielles.
Reproduction interdite.

Le profil professeur principal ajoute des droits sur une classe

Le professeur principal est un compte de professeur normal, avec tous les droits associés à ce
profil, auquel s’ajoute les droits relatifs à la gestion des élèves de la classe dont il s’occupe plus
particulièrement. Là aussi, ce profil n’est pas unique, mais simplement une description des privi-
lèges qui peuvent être accordés à un utilisateurs nominatif.

Finalisation de l’installation avec l’EAD

28
Les différents profils de connexion à l’EAD
 Lors d’une importation de GEP, si le professeur principal est mentionné, cette information se re-
trouve automatiquement dans l’annuaire. Ultérieurement, l’affectation des privilèges de respon-
sable de classe se fait en éditant le profil du professeur.
Note
Il peut y avoir plusieurs responsables pour une même classe, mais un même indi-
vidu ne peut être responsable que d’une classe.

Ce professeur peut notamment modifier les préférences de élèves de la classe dont il est respon-
sable, notamment pour le courrier électronique, affecter des quotas, et créer des groupes de travail
dans lequel il peut inscrire ses élèves (et où les autres professeurs pourront s’inscrire d’eux-même
s’ils le souhaitent).
Reproduction interdite.

Finalisation de l’installation avec l’EAD

29
Les différents profils de connexion à l’EAD
 3.3 : Surveillance des ressources

Les informations sur le matériel

L’indication de la charge

Les volumes de données transmis par les différentes interfaces

La mémoire utilisée
Deux types de mémoire : la RAM et le fichier d’échange

L’occupation de la RAM n’est pas très importante

L’espace disque utilisé

Les informations sur le matériel

Le lien système permet d’accéder à une page regroupant des informations sur le matériel installé
et sur les ressources disponibles.

Ces informations peuvent permettre d’identifier l’origine d’un problème sur le serveur. Elles servent
à établir le premier diagnostic pour une intervention plus poussée, si le redémarrage du service
incriminé ne suffit pas.

Dans le cadre Information Matériel, on voit un descriptif du matériel détecté. On peut no-
tamment l’utiliser pour vérifier si les barrettes sont bien branchées, si les cartes réseaux sont
correctement reconnues... Il s’agit du pendant des informations que l’on trouve dans le répertoire
/proc sur le matériel.

L’indication de la charge
Le cadre Système contient des informations génériques sur le système : version du système
d’exploitation, adresse IP du serveur, durée écoulée depuis le dernier démarrage (utile pour dé-
tecter les redémarrages intempestifs)...

L’indicateur le plus utile est celui de la charge (Charge système), même si sa lecture n’est pas
évidente. On appelle charge la moyenne du nombre de processus en attente d’exécution sur un
temps donné. En général, elle est affichée sur trois durées : une minute, cinq minutes, et un quart
d’heure.

Lorsque la charge est inférieure à 1, cela signifie que sur la période considérée, il y a eu des
moments où aucune tâche n’était en attente d’exécution, et que le système était donc inactif.
Toutefois, si la charge est supérieure à 1, cela ne signifie pas forcément que la machine est sous-
dimensionnée. Elle était peut-être en train d’exécuter des tâches s’attendant l’une l’autre, ce qui
augmente artificiellement l’indicateur de charge.
Reproduction interdite.

Dans le cas du serveur Scribe, la charge ne devrait jamais être très élevée, car le processeur n’est
pas l’élément le plus sollicité du système. En effet, en dehors de la validation de l’authentification
des utilisateurs — ce qui n’est que ponctuel — la tâche la plus gourmande en ressources est le
partage de fichiers. Cette fonction nécessite de la mémoire et de l’espace disque, mais très peu
de puissance de calcul.

Finalisation de l’installation avec l’EAD

30
Surveillance des ressources
 Les volumes de données transmis par les différentes interfaces
Le cadre Réseau indique, interface par interface, les volumes envoyés et reçus. Il n’est pas pos-
sible d’en tirer des informations utiles sur le bon fonctionnement du serveur, les volumes n’étant
enregistrés que depuis le dernier démarrage. Ces chiffres n’ont pas une vocation statistique.

En revanche, le nombre d’erreurs de transmission est aussi indiqué. Ce chiffre devrait normale-
ment être nul ou très faible. Un grand nombre d’erreurs signale un problème de réseau : grand
nombre de collisions, problème de négociation half/full duplex ou 10/100 Mb/s avec un autre équi-
pement réseau...

La mémoire utilisée
Deux types de mémoire : la RAM et le fichier d’échange

Le cadre Utilisation Mémoire permet de connaître l’occupation des deux types de mémoire
utilisés : la mémoire physique, la RAM, et le swap, c’est à dire la partition spécialisée du disque
utilisée par le système pour suppléer au manque de mémoire de physique.

L’occupation de la RAM n’est pas très importante

La mémoire inutilisée est de la mémoire perdue. Partant de ce principe, le noyau Linux ne vide
la mémoire que lorsqu’il doit la réutiliser pour écrire des informations nouvelles. L’indicateur d’oc-
cupation de la mémoire commence donc bas pour grimper très vite un peu en dessous de 100%
dans un système normal. Ce taux d’occupation est normal, et ne doit pas inquiéter.

Lorsque la mémoire physique devient insuffisante, le système Linux commence à utiliser le swap.
Si la mémoire vive est suffisante, le fichier d’échange n’est normalement pas utilisé. Son taux
d’occupation doit donc généralement être proche de zéro.

Dans le cas de Scribe, l’occupation mémoire est importante car Samba conserve en mémoire les
fichiers récemment manipulés. L’accès aux fichiers sera donc plus rapide si la mémoire vive est
pléthorique : les fichiers les plus utilisés par chaque élève seront lus depuis la RAM plutôt que
depuis le disque.

L’espace disque utilisé

C’est surtout dans la partition de données des élèves que l’espace devra être surveillé. Tout
accroissement rapide dans les autres partitions sera un signe de dysfonctionnement ; en revanche,
il s’agit d’un fonctionnement normal pour les données des utilisateurs. On veillera donc à adapter
les quotas en fonction des vitesses de remplissage de la partition de données, afin d’assurer à
chacun un espace de travail suffisant.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

31
Surveillance des ressources
 3.4 : Gestion des services

Redémarrage des services

Redémarrage du système

Mise à jour du système

La mise à jour finalise l’installation du serveur

Redémarrage des services

Le lien services permet d’accéder à une page mentionnant les différents services du système, et
donnant la possibilité de les redémarrer. Lorsqu’un indicateur de la page d’accueil est au rouge, il
est recommandé de commencer par relancer le service correspondant afin de voir si le problème
subsiste.

Redémarrage du système
Cette page permet aussi de redémarrer et d’éteindre le système. Attention, le redémarrage ne
peut se faire que si le BIOS de la machine le supporte. En cas de problème, il faudra se rendre à
la machine pour la rallumer électriquement.

Une telle opération ne se fait généralement qu’en concertation avec les services académiques.
Le redémarrage d’un serveur sous Linux est en effet une opération qui n’est pas routinière.

Mise à jour du système

Le lien mise à jour permet de récupérer l’ensemble des mises à jour, qu’elles concernent le
système ou les applications. Les dernières versions des paquets sont téléchargées sur le site de
référence indiqué lors de la configuration. Ces versions ont été validées par l’équipe EOLE pour
fonctionner ensemble : il n’est donc pas nécessaire de procéder à une validation individuelle, ou
à des mises à jour intermédiaires. Les versions téléchargées sont ensuite installées en écrasant
les versions précédentes, laissant le système dans un état stable et à jour, indépendamment de
la version de départ.

Les seuls cas où la mise à jour peut s’avérer problématique concerne les mises à jour du noyau
(qui nécessitent un redémarrage de la machine) et les mises à jour touchant en profondeur l’ar-
chitecture de mise à jour et de gestion des versions. Il s’agit des mises à jour marquées par des
Reproduction interdite.

changement de numéro de version (comme entre 1.0 et 1.5). Ces mises à jour, rarissimes, ne
sont pas compatibles entre elles et ne seront pas effectuées automatiquement.

L’équipe d’EOLE avertit les académies utilisatrices à chaque nouvelle version sur
les listes de diffusion, et il est possible de suivre l’actualité en consultant le site
(http://eole.orion.education.fr/)

Finalisation de l’installation avec l’EAD

32
Gestion des services
 Chaque académie pourra disposer d’un serveur miroir répliquant les données présentes sur ce
serveur, afin d’accélérer le téléchargement, et de mettre à disposition des établissements d’éven-
tuelles modifications locales. Cette méthode est de loin préférable car elle désengorge le serveur
de Dijon et donne aux équipes académiques l’occasion de tester les mises à jour avant de les
déployer massivement dans les établissements. Il suffit pour cela de mettre à jour une machine
de test sur le site de Dijon, et si tout fonctionne correctement à lancer la réplication des mises à
jour sur le serveur académique.

Pour obtenir la procédure permettant de créer un serveur académique de réplication, il faut écrire
à l’équipe EOLE ([email protected]) pour obtenir notamment les mots de passe nécessaires à la
connexion rsync au serveur officiel.

La mise à jour finalise l’installation du serveur

Compte tenu de la stratégie de diffusion des mises à jour, qui ne s’accompagnent pas néces-
sairement de la création d’une nouvelle image ISO, il est possible que des modification soient
apportées à Scribe même si l’on réalise l’installation depuis la dernière version. En conséquence,
il n’est pas d’installation complète sans séance de mise à jour, pour s’assurer que les dernières
versions des applications sont bien installées.

Les mises à jour de sécurité, notamment, ne concernent souvent qu’un paquet de la distribution,
et doivent être diffusées rapidement pour se protéger contre une intrusion : ces mises à jour sont
mieux diffusées par Internet que par la création d’une nouvelle image ISO, qui laisserait l’ensemble
du parc existant vulnérable. Elles ne s’accompagnent donc pas systématiquement d’une nouvelle
image. En règle générale, une image est indispensable lorsqu’il faut appliquer une modification
aux opérations qui s’effectuent au démarrage, comme le partitionnement ou la prise en charge du
matériel, ou lorsque les modifications sont volumineuses, et seraient difficilement téléchargeables
dans les établissements non dotés d’ADSL.

La lettre de la version utilisée lors de l’installation est donc secondaire : dès la première mise
à jour, qui est une étape normale de l’installation, le serveur ne sera plus le reflet de la version
d’installation mais de la version du jour de la dernière mise à jour.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

33
Gestion des services
 3.5 : Déclencher les mises à jour

L’opération nécessite un arrêt des services

Les mises à jour peuvent être déclenchées immédiatement
L’opération peut se faire en différé
L’opération peut être entièrement automatisée

L’opération nécessite un arrêt des services

Même lorsque la mise à jour ne concerne pas le noyau, et ne nécessite pas de redémarrer le ser-
veur proprement dit, la réinstallation des programmes nécessite de les arrêter et de les relancer.
L’opération de mise à jour doit donc être planifiée pour éviter les pertes de données.

Les mises à jour peuvent être déclenchées immédiatement

La mise à jour immédiate est possible, et on l’emploit notamment après l’installation. Il s’agit de la
procédure normale : toute installation doit être suivie d’une mise à jour. En effet, toutes les mises
à jour ne sont pas suivies obligatoirement de la génération d’une nouvelle image de CD-ROM.
Les mises à jour minimes comme les corrections dans la documentation ou des changements
cosmétiques ne donnent pas lieu à une nouvelle version lettrée, qui correspondent à des états de
la distribution à un moment donné.

Ces images sur CD-ROM ne servent qu’à diffuser les mises à jour dans les établissements où
l’accès Internet ne permet pas d’effectuer facilement de gros téléchargements. En conséquence,
lorsque les mises à jours sont légères et ne nécessitent que de télécharger quelques fichiers, elles
ne sont diffusées que par le système de mise à jour en ligne. Dès lors, même un CD-ROM gravé
avec la dernière version figée est susceptible de ne pas contenir la dernière version de l’ensemble
du système. Une mise à jour s’impose donc en conclusion de l’installation. Cette opération peut
être faite immédiatement, en préalable à la mise en production du serveur.

Pour réaliser une mise à jour immédiate, on clique simplement sur le bouton correspondant dans
la page Services/Mise à jour

L’opération peut se faire en différé

Lorsque l’on souhaite faire une mise à jour dans le cadre d’une intervention de routine, ou à
Reproduction interdite.

l’initiative de l’établissement, il est possible de sélectionner une mise à jour différée, et de préciser
la durée devant s’écouler avant le début de l’opération. Il est recommandé de ne le faire que
lorsque les mises à jour ont été testées au préalable.

Finalisation de l’installation avec l’EAD

34
Déclencher les mises à jour
 L’opération peut être entièrement automatisée
Si l’on dispose d’un serveur de mise à jour académique, et que les mises à jour qui y sont publiées
ont été testées par les équipes d’assistance aux établissements, notamment pour prévenir tout
problème lié à des modifications spécifiques ou à un certain type de matériel présent seulement
dans l’académie, il est possible d’automatiser complètement la mise à jour. Cette opération est
déconseillée pour les serveurs se synchronisant avec le serveur de Dijon, car certaines mises
à jour génériques peuvent ne pas être correspondre à la politique de l’académie et générer des
incompatibilités.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

35
Déclencher les mises à jour
 3.6 : L’inscription des stations dans le domaine

Il s’agit de l’opération la plus longue durant l’installation

La procédure dépend du système d’exploitation utilisé

Windows 98
Windows XP ou 2000
Il reste possible d’utiliser le compte DomainAdmins

Il s’agit de l’opération la plus longue durant l’installation

Les stations de travail doivent accepter l’autorité du serveur pour l’authentification des utilisateurs.
Pour cela, elles doivent être configurées pour entrer dans le domaine qu’il contrôle, et échanger
avec lui un certain nombre d’informations cryptographiques permettant à la station de reconnaître
le serveur par la suite.

L’installation d’un serveur Scribe nécessite par conséquent de passer sur l’ensemble des stations
de travail pour les inscrire dans le domaine contrôlée par le serveur Scribe. Il n’est pas possible
d’utiliser simplement le même nom de domaine que pour un éventuel réseau NT préexistant. En
effet, Scribe ne serait pas reconnu comme un contrôleur légitime de ce domaine, et les stations ne
se connecteraient pas à lui. Il est impératif, si les stations sont déjà présentes dans un domaine,
de les en faire sortir pour les y réinscrire.

La procédure dépend du système d’exploitation utilisé

Windows 98

Les stations Windows 98 sont inscrites dans un domaine par le biais des propriétés de la carte
réseau. Il est nécessaire de les faire passer de leur domaine actuel en mode groupe de travail, puis
de redémarrer la station, puis de reconfigurer la station pour l’inscrire dans le nouveau domaine
(même s’il porte un nom identique à celui utilisé précédemment). La station va alors interroger le
réseau pour savoir si un serveur est contrôleur pour le domaine en question, et échanger avec lui
les informations nécessaires à son identification ultérieure.

Windows XP ou 2000
Note
Attention, seul Windows XP Pro supporte de fonctionner en domaine. La version
familiale est prévue pour les stations isolées, et ne fonctionne donc pas avec un
Reproduction interdite.

contrôleur de domaine. Il ne s’agit pas d’une limitation de Scribe

L’intégration d’une station XP dans le réseau nécessite une opération supplémentaire par rapport
à un Windows 98. En effet, seul un utilisateur privilégié peut enregistrer la station dans le domaine.
Il est donc normalement nécessaire de se connecter à la station, de l’inscrire dans le domaine et
de fournir à cette occasion l’identifiant et le mot de passe d’un utilisateur membre du groupe

Finalisation de l’installation avec l’EAD

36
L’inscription des stations dans le domaine
 DomainAdmins. Or, avec la version de Samba utilisée dans Scribe, les utilisateurs membres de
ce groupe disposent de tous les droits sur les partages réseau. Il n’est pas envisageable de laisser
autant de droits aux utilisateurs dans les établissements. Par conséquent, l’enregistrement doit se
faire manuellement, sur la station, en utilisant le login admin et le mot de passe associé.

Seul l’administrateur peut enregistrer une station dans le domaine. Pour cela, dans l’onglet sta-
tions, on peut ajouter et supprimer des stations. Cette opération crée un compte sans mot de
passe sur le serveur, compte qui sera utilisé par la suite pour la connexion au domaine. Ce compte
ne donne pas de privilèges particulier, et l’existence des comptes de station ne pose pas de pro-
blème de sécurité particulier.

Ce compte doit porter le nom Netbios de la station, ce qui implique de relever le nom des stations,
ou tout du moins leurs adresses IP, et d’utiliser la commande nmblookup pour connaître le nom
Netbios qui y est associé.

Une fois l’opération de création des comptes de station réalisée, il est possible d’inscrire la station
dans le domaine en se rendant dans l’onglet de paramétrage de la connexion, et en y saisissant
le nom du domaine. Après un redémarrage, la station ouvrira des sessions sur le domaine et non
plus par rapport à sa base d’utilisateurs locaux.

Il reste possible d’utiliser le compte DomainAdmins

Il est possible, comme sur Horus, d’utiliser un membre du groupe DomainAdmins pour l’ins-
cription des stations dans le domaine. Toutefois, il est très vivement déconseillé d’inscrire des
utilisateurs dans ce groupe sans savoir exactement ce que l’on fait.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

37
L’inscription des stations dans le domaine
 3.7 : Le rôle de l’annuaire LDAP

L’annuaire LDAP sert de support au contrôleur de domaine

L’annuaire LDAP fait partie des éléments sauvegardés

L’annuaire LDAP sert de support au contrôleur de domaine

Le serveur Scribe est architecturé autour d’un serveur LDAP. Celui-ci contient un descriptif de
l’ensemble des éléments auxquels le logiciel Samba, chargé du partage de fichiers, fait appel.

Les comptes des utilisateurs, tels qu’utilisés pour le partage de fichier, sont conservés dans cet
annuaire. Il est donc nécessaire d’intervenir sur l’annuaire lors de l’ajout d’un compte. Cette opé-
ration peut se faire par le biais de l’EAD.
Note
Il n’est pas conseillé d’altérer la structure de l’annuaire LDAP, même pour adapter le
serveur Scribe à d’autres besoins. Il est prévu que la structure évolue pour s’adap-
ter à un schéma national, et d’éventuelles modifications risqueraient de rendre le
serveur incompatible avec de futures mises à jour.

L’annuaire LDAP fait partie des éléments sauvegardés

L’annuaire LDAP contient notamment toutes les associations entre les utilisateurs, leurs groupes,
et les partages auxquels ils peuvent accéder. Lors de l’installation initiale, un annuaire minimal est
créé pour permettre aux services de démarrer. Mais il est nécessaire de le remplir et de l’adapter
à l’établissement.

Cette opération peut être partiellement automatisée, notamment par le biais de l’importation des
données issues de GEP.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

38
Le rôle de l’annuaire LDAP
 3.8 : Importation des comptes des utilisateurs

L’importation se fait en plusieurs temps

La récupération des bases élèves
La récupération des bases professeurs
L’intervention sur l’annuaire LDAP

L’importation se fait en plusieurs temps

Pour ne pas causer de problème, le système d’importation commence par lire l’ensemble des
fichiers contenant les bases, crée un script permettant de modifier l’annuaire LDAP et n’exécute
ce script qu’une fois l’opération terminée. En cas de corruption des bases, il n’y a donc pas de
risque que l’annuaire LDAP soit détruit. De plus, par défaut, les utilisateurs et les groupes existants
sont conservés, mais il est possible de faire une mise à jour, ce qui entraîne la destruction des
données.

La récupération des bases élèves

L’opération nécessite d’une part de fournir, par le biais du formulaire, l’emplacement des fichier
.dbf à importer, et des paramètres de configuration applicables à l’ensemble des élèves :

le quota à mettre en place ;

le type de mot de passe à créer ;
l’autorisation d’utiliser la messagerie externe.

Sur certains serveurs, on pourra décider de s’affranchir des quotas, et sélectionner pour ce faire la
valeur zéro. Chaque utilisateur ne sera limité que par l’espace disque de la partition de données.

Lorsque l’on demande à l’EAD de générer des mots de passe, il utilise un mot de passe aléatoire
par défaut, qu’il faut communiquer de manière sûre à l’utilisateur. Si l’on souhaite accélérer ce
processus, au prix d’une perte de sécurité, on peut sélectionner la date de naissance comme mot
de passe. Il est alors impératif de sensibiliser les utilisateurs à la nécessité de modifier ce mot de
passe.

Par défaut, les utilisateurs sont restreints à la messagerie interne à l’établissement. On peut déci-
der d’activer pour tous l’accès externe. Cette opération nécessite l’implication du chef d’établisse-
Reproduction interdite.

ment compte tenu des responsabilités qu’il doit prendre.

Finalisation de l’installation avec l’EAD

39
Importation des comptes des utilisateurs
 Note
L’opération peut être répétée pour plusieurs bases GEP ; comme nous l’avons dit,
l’opération n’est pas destructrice par défaut, et ne fait qu’ajouter des listes d’utili-
sateurs dans l’annuaire. Il est en revanche possible de modifier ce comportement
pour synchroniser la liste des élèves avec une nouvelle base GEP. Dans ce cas, on
sélectionne la suppression des comptes qui ne sont pas présents dans les bases.

La récupération des bases professeurs

La même opération est ensuite effectuée pour l’importation des bases GEP de professeurs. Il
est là encore extrêmement important d’être vigilant avec les mots de passe, d’autant plus que
l’interface pour professeur permet de récupérer des fichiers appartenant à des élèves.

Le rapport d’extraction indique, comme précédemment, le nombre d’entrées traitées et si tout s’est
passé correctement. Une fois cette opération effectuée, la procédure continue pour demander si
les changements doivent être effectués ou non.

L’intervention sur l’annuaire LDAP

Après confirmation, le système interrompt l’annuaire LDAP, rendant le système inutilisable, et les
comptes sont ajoutés à partir des extractions. Un rapport d’extraction est placé dans la page
d’accueil de l’EAD, ce qui permet de s’assurer que l’opération s’est passée correctement.
Reproduction interdite.

Finalisation de l’installation avec l’EAD

40
Importation des comptes des utilisateurs
 3.9 : Manipulation ponctuelle des utilisateurs

L’importation d’une base GEP n’est pas forcément pratique

Rechercher un utilisateur
Modifier un utilisateur
Les opérations courantes sont disponible depuis la page de recherche

L’identifiant est immuable

Les informations de contact
Les groupes d’un élève

Les groupes d’un professeur

Les quotas de disque

L’importation d’une base GEP n’est pas forcément pratique

Même s’il existe une option pour laisser en place les comptes existants, ce qui permet de réali-
ser une importation chaque année en n’effaçant pas par inadvertance les données d’utilisateurs
qui auraient disparu par erreur de la base, l’importation d’une base GEP n’est pas l’outil le plus
adapté pour gérer les modifications ponctuelles correspondant, par exemple, à la mutation d’un
professeur ou à la création d’un compte temporaire pour un intervenant.

Il est possible, par le biais de l’EAD de réaliser des opérations sur la base LDAP, comme l’ajout ou
la suppression d’un utilisateur, l’attribution de privilèges, et et la gestion de leurs quotas de disque
et d’impression. On accède à ces fonctions par le lien utilisateurs de l’EAD.

Rechercher un utilisateur
La page d’accueil permet d’afficher tous les utilisateurs, de sélectionner uniquement ceux d’un
domaine de messagerie (et non pas d’un domaine Windows, deux notions qui n’ont rien à voir),
c’est-à-dire les utilisateurs enregistrés dans sur le serveur pour le courrier local (donc, en pra-
tique, tous les utilisateurs déclarés) et ceux disposant du privilège d’échanger des courriers avec
l’extérieur, et faisant partie d’un domaine de messagerie externe.

Il est également possible de restreindre la recherche en fonction de l’initiale de l’utilisateur (géné-

ralement son nom s’il a été créé par le biais de l’importation d’une base GEP).

On peut également effectuer une recherche, en saisissant une partie du nom des utilisateurs
recherchés : l’interface affichera tous les utilisateurs dont l’identifiant contient la chaîne saisie. Il
n’est pas possible d’utiliser des expressions rationnelles pour la recherche.

Modifier un utilisateur
Reproduction interdite.

Les opérations courantes sont disponible depuis la page de recherche

Une fois l’utilisateur recherché affiché, on peut effectuer les opérations suivantes :
attribution d’un nouveau mot de passe ;
attribution ou privation du droit d’envoyer du courrier externe ;

Finalisation de l’installation avec l’EAD

41
Manipulation ponctuelle des utilisateurs
 suppression de l’utilisateur ;
modification de l’utilisateur.

Ce dernier choix, moins explicite, affiche la page permettant de modifier tous les paramètres de
l’utilisateur en question.
Note
La suppression d’un utilisateur détruit aussi son répertoire personnel et l’ensemble
des données qu’il contient. Sachant que le répertoire personnel peut contenir des
données privées, il est recommandé de s’assurer que l’utilisateur a réalisé une
copie personnelle de ses documents avant de l’effacer.

L’identifiant est immuable

L’identifiant de l’utilisateur sert pour déterminer trop d’éléments statiques du système (comme le
nom de son répertoire personnel) pour être aisément modifiable. Une fois l’utilisateur créé, son
identifiant ne pourra être changé. Tous les autres paramètres peuvent être modifiés librement.

Les informations de contact

Le nom et le prénom peuvent être modifiés par la suite. C’est particulièrement utile compte tenu de
l’importation des comptes depuis GEP. Cette base, conçue pour DOS, ne gère par les caractères
accentués, ce qui rend certains noms et prénoms illisibles. C’est irréparable dans l’identifiant (du
type prenom.nom), mais il est possible de repasser dans l’interface pour corriger le prénom et le
nom associés au compte.

L’adresse électronique de contact n’est pas forcément une adresse gérée par le serveur. Par
défaut, c’est celle-ci qui sera utilisée, et c’est d’ailleurs obligatoire dans le cas des utilisateurs
élèves, mais dans le cas des professeurs, une adresse académique ou externe pourra être utilisée.

Les groupes d’un élève

Un élève est automatiquement membre du groupe correspondant à sa classe. Il n’en change que
par l’option changement de classe. Il peut aussi être membre de plusieurs groupes de travails
créés manuellement. L’inscription dans ces groupes détermine les partages de fichiers auxquels
l’utilisateur aura accès en plus de son partage individuel.

Les groupes d’un professeur

Le professeur est automatiquement membre du groupe correspondant à l’équipe pédagogique de

chacune des classes auxquelles il enseigne, déterminé à partir de GEP. Il peut également être
membre de tous les groupes créés sur le serveur, que ce soit des groupes disciplinaires, des
groupes de travail, ou le groupe correspondant au statut de professeur principal d’une classe.

Comme pour les élèves, l’inscription dans un groupe correspond à des droits sur les partages de
fichiers additionnels.

Les quotas de disque

Par défaut, les quotas sont désactivés : tout nouvel utilisateur dispose d’un quota de 0, correspon-
dant à une valeur illimitée. On pourra volontairement attribuer une valeur non-nulle à un compte,
et cela activera la gestion des quotas. Lorsque l’utilisateur dépasse cette taille, en megaoctets, il
Reproduction interdite.

reçoit un avertissement et dispose de sept jours pour se mettre en conformité. S’il n’obtempère
pas, il ne pourra plus écrire au terme de l’ultimatum. Idem, s’il tente de dépasser le double la
valeur de son quota.

Finalisation de l’installation avec l’EAD

42
Manipulation ponctuelle des utilisateurs
4. Configuration
des imprimantes
avec CUPS
 4.1 : Présentation de CUPS

CUPS est un système de gestion d’imprimantes

Il sert à signaler à Linux la présence d’imprimantes

Il est livré avec un ensemble de pilotes

Cups peut utiliser directement les pilotes Windows

CUPS est un système de gestion d’imprimantes

Il sert à signaler à Linux la présence d’imprimantes

Cups est un système de gestion des impressions, piloté par une interface Web. Parmi les sys-
tèmes de gestion des impressions (lpr étant le plus courant), CUPS a été choisi en raison de sa
simplicité d’utilisation et de son intégration avec le monde Microsoft. Cups déclare en effet auto-
matiquement les imprimantes qu’il connaît dans Samba, en rajoutant des partages d’imprimante
correspondant. La configuration est alors très simple : il suffit de signaler à CUPS la présence des
imprimantes et les modalités d’accès (emplacement, pilote...) au moyen de l’interface Web pour
que les clients du domaines puissent accéder automatiquement aux impressions.

De plus, Cups est compatible avec le logiciel Pykota, qui sert à gérer les quotas d’impression des
utilisateurs.

Il est livré avec un ensemble de pilotes

Dans une optique d’un fonctionnement purement cantonné à un poste Linux, Cups est un outil de
gestion complet des imprimantes. Il est livré avec un certain nombre de filtres qui vont convertir les
fichiers qu’on envoit à l’impression en code compréhensible par l’imprimante. On pourra trouver
sur le site (http://www.linuxprinting.org) une base de données d’imprimantes suppor-
tées par Linux (et inversement, une liste de celles qui ne pourront pas fonctionner). Linux devenant
fréquent sur le marché des serveurs, il est de plus en plus courant que les fabricants de matériels
fournissent, sinon des pilotes, au moins des spécifications techniques suffisantes pour permettre
la rédaction d’un pilote par un développeur indépendant. Le nombre d’imprimante supportées ne
cesse de croître : c’est le cas pour toutes celles qui supportent les langages PS et PCL, ainsi
qu’un grand nombre d’imprimantes propriétaires. Toutefois, Linux ne prends pas en compte un
certain nombre d’imprimantes anciennes, que l’on peut rencontrer dans les établissements sco-
laires, ainsi que les imprimantes dont les fabricants ont décidé de dissimuler les spécifications
Reproduction interdite.

techniques. Si le matériel n’était pas pris en charge, il sera néanmoins possible d’utiliser le pilote
Windows.

Cups peut utiliser directement les pilotes Windows

Si daventure une imprimante n’était pas supportée, cela ne voudrait pas dire que le déploiement
du serveur Linux est impossible : en effet, Cups peut se contenter de servir d’aiguillage, sans inter-

Configuration des imprimantes avec CUPS

44
Présentation de CUPS
 préter les données qu’il reçoit des stations. Pour peu que les stations soient capables de générer
du code directement compréhensible par l’imprimante (c’est-à-dire qu’elles soient équipées du pi-
lote Windows adapté pour l’imprimante), Cups pourra transmettre directement le flux de données
sans l’altérer, et réussir ainsi à partager l’imprimante.

Cette technique est moins souple que la précédente, car elle impose d’installer sur les stations
les pilotes des imprimantes. Cet inconvénient peut toutefois être aisément contourné, Samba
étant capable, à l’instar des contrôleurs de domaine Microsoft, de distribuer le pilote idoine lors
de la configuration de l’imprimante. De sorte qu’il suffira d’installer le pilote Windows dans un
répertoire spécifique du serveur, et ce pilote sera automatiquement téléchargé et installé par le
client lorsqu’on lui déclarera l’imprimante partagée.

Ainsi, l’installation du serveur ne conduit pas à des incompatibilité avec le parc existant, mais
la procédure d’installation variera en fonction des cas. Si toutes les imprimantes partagées ont
supportées par Linux, il est plus rapide d’indiquer à Cups d’utiliser le pilote Linux. Dans le cas
contraire, ou dans le doute, l’utilisation du pilote Windows permettra la prise en charge du péri-
phérique, au prix d’une étape supplémentaire dans l’installation.
Reproduction interdite.

Configuration des imprimantes avec CUPS

45
Présentation de CUPS
 4.2 : Configuration d’une imprimante supportée par Linux

Connexion à CUPS
Procédure de déclaration d’une imprimante
Attribution d’un indentifiant à l’imprimante nouvelle
Configuration du type d’imprimante

Définition de l’emplacement logique de l’imprimante

Validation des paramètres

Connexion à CUPS
Cups utilise une interface Web, qui écoute sur le port 631. Pour s’y connecter, une authentifica-
tion est nécessaire. L’utilisateur scribe est capable de se connecter, il dispose du privilège de
configurer les nouvelles imprimantes. Comme il s’agit d’un compte utilisé dans l’établissement, le
responsable informatique de ce dernier n’est pas obligé de faire appel à l’assistance académique
lors de l’installation d’une nouvelle imprimante, ou de toute autre opération bénigne de ce type.

Si l’accès à la page d’accueil, qui ne contient que des liens et de la documentation, est permis
pour tous, l’accès aux pages de configuration nécessite d’être scribe.

Procédure de déclaration d’une imprimante

Attribution d’un indentifiant à l’imprimante nouvelle

Lorsque l’on choisit de créer une nouvelle imprimante, il est nécessaire de préciser tout d’abord
trois paramètres qui vont servir à l’identifier. C’est en quelque sorte la carte d’identité de l’impri-
mante. La première information est un nom, qui doit être unique sur le réseau. Attention, l’interface
tronque les noms trop longs à 15 caractères, ce qui peut engendrer des doublons malvenus. Cette
information sert en effet de nom Netbios pour le partage d’imprimante ; on veillera donc à respec-
ter les contraintes liées à un nom Netbios.

L’emplacement et la description sont deux types d’informations complémentaires qui servent à

savoir de quelle imprimante il s’agit, par son type et sa localisation, lorsque l’on lit directement le
fichier de configuration. Les informations que l’on saisit ici n’ont pas d’importance, si ce n’est pour
identifier ultérieurement l’imprimante concernée. Il est possible de saisir ce que l’on veut dans ces
champs.

Configuration du type d’imprimante

Reproduction interdite.

Les deux écrans suivants servent à indiquer le type d’imprimante, sa marque et son modèle, ce
qui va être déterminant pour la sélection du pilote d’impression correspondant. Cups propose
dans son menu une liste d’imprimante supportées par les filtres, classées par constructeur, ce qui
permet une recherche facilitée. Si l’on ne trouve pas le type idoine, il est toujours possible que le
pilote pour une imprimante très similaire fonctionne : on se reportera au site Web de Linux Printing
pour plus d’information. Parmi les types d’imprimantes, on trouvera notamment une imprimante

Configuration des imprimantes avec CUPS

Configuration d’une imprimante supportée par Linux 46
 dite raw, c’est-à-dire à laquelle il faut envoyer les inforamtions brutes, sans traitement préalable.
C’est le type que l’on choisira pour les imprimantes à gérer directement au niveau des stations.
C’est aussi le type que l’on choisira par défaut si l’on ne parvient pas à trouver d’informations sur
l’imprimante : elle aura très probablement été livrée avec des pilotes spécifiques pour Windows.

Définition de l’emplacement logique de l’imprimante

L’étape suivante consiste à indiquer à Cups comment accéder à l’imprimante. Pour peu que l’im-
primante soit directement connectée au serveur, son nom devrait être mentionné dans la liste (au
niveau des imprimantes connectées sur le port parallèle). Mais il est aussi possible de sélection-
ner des imprimantes USB, des imprimantes réseau (en précisant alors l’URL de connexion, de
la forme lpr://IP:port/chemin où chemin est le nom de la file d’attente spécifique de l’im-
primante (généralement, un / suffit, mais on se reportera à la documentation de l’imprimante).
On pourra aussi déclarer des imprimantes partagées : Cups identifie automatiquement toutes
les imprimantes partagées par d’autres serveurs cups sur le même réseau. Il est aussi possible
de repartager des imprimantes partagées par une station Microsoft au moyen du voisinage ré-
seau. Cela semble inutile, mais cette fonctionnalité est prévue pour s’interfacer avec un logiciel de
gestion des quotas d’impression. En effet, pour fonctionner, le logiciel doit surveiller le compteur
de page de chaque imprimante, et il doit donc être activé avant et après chaque impression (la
différence du compteur lui donnant le nombre de pages imprimées). Si des stations partagent
directement leur imprimante locale à destination de l’ensemble de leurs voisines, il sera possible
de contourner aisément le logiciel de quotas en envoyant directement les documents à cette im-
primante. Il est donc nécessaire de partager une imprimante Windows à destination du serveur,
puis de repartager cette imprimante, dans le cadre du domaine cette fois-ci.

Validation des paramètres

Cups offre une dernière chance de consulter l’ensemble des paramètres de l’imprimante, et pro-
cède à la création des fichiers nécessaires à son bon fonctionnement (notamment le répertoire
contenant la file d’attente des impressions). Toutefois, cette opération n’est pas suffisante : elle se
contente de finaliser la partie Linux de la configuration.

Pour que l’imprimante soit visible dans le domaine, il est nécessaire de :

redémarrer Cups, pour qu’il sauvegarde sous forme de fichier la configuration qui vient
d’être faite, et qui était juste là cantonnée à la mémoire vive ;
redémarrer Samba, ce qui permet à Samba de découvrir l’existante du nouveau partage
dans ses fichiers de configuration, et de le rendre disponible pour les stations du domaine ;

Se rendre sur les stations pour y configurer l’imprimante, en faisant une recherche dans
le domaine, et en sélectionnant l’imprimante partagée par le serveur.

Selon les cas, on devra soit associer un pilote Windows à l’imprimante, soit, dans le cas d’un pilote
Linux, sélectionner Annuler lorsque la procédure d’installation demande l’emplacement du pilote.
Dns ce cas, les fichiers seront envoyés sans traitement au serveur : c’est le pilote du serveur qui
se chargera de traduire le fichier en langage imprimante.
Reproduction interdite.

Configuration des imprimantes avec CUPS

Configuration d’une imprimante supportée par Linux 47
 4.3 : Prise en compte des quotas

Pykota est vu comme un pilote particulier

Déclaration d’une imprimante indépendante

Pykota est vu comme un pilote particulier

Pykota se comporte comme un pilote d’imprimante, c’est-à-dire comme un filtre : il reçoit les don-
nées en provenance d’une station, et les transmet à l’imprimante en effectuant cette conversion.
Cette conversion consiste à :
interroger l’imprimante pour connaître son compteur de pages ;

envoyer les données reçues à un autre filtre, un pilote d’impression, qui va générer des
données à transmettre à l’imprimante ;
interroger à nouveau l’imprimante et faire la différence entre la nouvelle valeur du comp-
teur de page et l’ancienne, pour connaître le nombre de pages imprimées.

Alternativement, Pykota peut compter les pages des documents PCL, PS... directement.

Comme l’imprimante n’est accessible que depuis le serveur, et que celui-ci ordonne les tâches
d’impression, il n’est pas possible qu’une impression parasite ne vienne s’intercaler entre les deux
vérifications de pages.

Pour qu’une imprimante supporte les quotas, il suffit de choisir une imprimante managed by Py-
kota, dans la liste des types d’imprimante, sachant qu’on trouve une version Pykota de chaque
mode d’accès à l’imprimante.

Note
Cette manipulation permet de demander à CUPS d’utiliser
Pykota en préalable aux impressions, pour le gestion du décompte des pages en-
voyées à l’imprimante. Cette opération ne suffit pas pour que les quotas soient mis
en place. En effet, Pykota ne stocke pas seul ses listes de pages imprimées, il
doit les relier d’une manière ou d’une autre à l’utilisateur qui a déclenché la tâche
Reproduction interdite.

d’impression, pour que cela puisse lui être décompté. Cette opération est vue plus
bas.

Déclaration d’une imprimante indépendante

Si l’on déclare une imprimante en direct, les impressions qui seront faites ne seront pas prises
en compte dans la gestion des quotas. Ce n’est pas forcément un bug : on peut imaginer que

Configuration des imprimantes avec CUPS

48
Prise en compte des quotas
 certains établissements ne souhaitent mettre des quotas que pour les imprimantes coûteuses, et
Reproduction interdite.
non pas pour toutes les imprimantes disponibles.

Configuration des imprimantes avec CUPS

49
Prise en compte des quotas
 4.4 : Publication d’un pilote Windows au moyen de Samba

Création d’un partage spécifique

Installation des fichiers de pilote

Prise en compte par les stations

Création d’un partage spécifique

Si les pilotes Windows de l’imprimante sont présents sur le serveur Samba, il n’est pas nécessaire
de les installer à la main. Les versions récentes de Windows peuvent directement télécharger le
pilote pour prendre en charge l’impression ; pour savoir si le serveur dispose d’un pilote, la station
l’interroge pour connaître le contenu de son partage print\$.

Ce partage existe dans le squelette de fichier smb.conf généré par l’annuaire. Pour que le té-
léchargement des pilotes puisse se faire, il faut que le partage print\$ soit lisible par tous les
utilisateurs et qu’ils puissent s’y connecter sans mot de passe. Le système se connectant automa-
tiquement, on ne pourra pas exiger une authentification pour l’accès à ce répertoire. Ce n’est pas
très gênant vu qu’il est destiné à contenir des données publiques. Pour rendre un partage acces-
sible sans protection, on utilise la directive guest ok = yes dans la configuration du partage.
On veillera à ce que le partage ne soit accessible qu’en lecture seule, pour éviter qu’il ne de-
vienne un dépotoir pour les utilisateurs. Seuls devront y écrire les utilisateurs autorisés à installer
des pilotes d’impression, les membres du groupe PrinterAdmins, par exemple.

Installation des fichiers de pilote

Les clients Windows, confrontés à une imprimante pour laquelle ils ne possèdent pas de pilote,
vont tenter de consulter le partage spécifique print\$ et de rechercher un pilote qui pourrait
s’appliquer. Ils utilisent un chemin d’accès codé en dur et qu’il est nécessaire de répliquer dans
le répertoire associé au partage. Pour les cas les plus courant, on devra au minimum créer un
répertoire W32X86 pour les machines Windows NT/2000/XP et WIN40 pour les clients 95/98.
Attention à positionner correctement les droits pour que les utilisateurs puissent lire le contenu de
ces répertoires...

Le déploiement des pilotes doit nécessairement se faire depuis une station. Une fois connecté au
domaine dans un compte membre du groupe PrinterAdmin, on peut naviguer dans l’arborescence
Reproduction interdite.

et tenter d’afficher les propriétés des imprimantes. Cela génère un message d’erreur que l’on doit
ignorer, et l’on peut ensuite installer un pilote pour l’imprimante correspondante (onglet Nouveau
pilote...). Grâce aux propriétés de partage, on peut installer sur le serveur des drivers pour
d’autres versions de Windows.

Configuration des imprimantes avec CUPS

Publication d’un pilote Windows au moyen de 50
Samba
 Prise en compte par les stations
Les stations peuvent désormais télécharger automatiquement sur les imprimantes ainsi configu-
rées : la première tentative d’impression s’accompagnera du téléchargement du pilote adapté.
Reproduction interdite.

Configuration des imprimantes avec CUPS

Publication d’un pilote Windows au moyen de 51
Samba
 4.5 : L’impression PDF

Cette imprimante permet d’obtenir un fichier PDF

L’impression PDF est configurée par défaut

Cette imprimante permet d’obtenir un fichier PDF

L’imprimante PDF est une imprimante virtuelle présente par défaut dans Samba. Elle permet de
générer des fichiers PDF à partir d’une station, et ce même lorsque l’application ne prend pas en
compte PDF comme format de sortie. Comme PDF est un format lisible par tous, il est recom-
mandé comme format d’échange de documents, et il est donc utile de pouvoir en générer depuis
toutes sortes d’applications.

Si l’application ne gère pas de sortie PDF directement, elle est généralement capable d’imprimer,
et Adobe fournit des pilotes d’impression PDF permettant de transformer les fichiers Windows en
fichiers PDF que l’on peut normalement envoyer directement vers une imprimane PDF.

L’imprimante PDF de Samba n’a pas d’imprimante matérielle comme sortie, mais dépose le fichier
tel quel dans le répertoire de l’utilisateur, et tente de l’avertir par un winmessage.

L’impression PDF est configurée par défaut

Il n’y a rien à faire pour bénéficier de l’impression PDF. Elle doit être configurée, sur la station,
comme une imprimante PostScript, de sorte que Windows lui enverra les instructions d’impres-
sions dans le langage PS, qui pourra être transformé en PDF par l’imprimante virtuelle. On pourra
aussi s’en servir, sans installer de driver particulier, comme d’un convertisseur Postscript vers
PDF.
Reproduction interdite.

Configuration des imprimantes avec CUPS

52
L’impression PDF
 4.6 : Gestion des impressions

Chaque utilisateur peut annuler ses propres tâches

Le groupe PrinterAdmins peut effacer tous les travaux

Les utilisateurs CUPS disposent de tous les droits

Chaque utilisateur peut annuler ses propres tâches

Les utilisateurs peuvent visualiser tous les travaux d’impression dans la file d’attente de Windows,
et peuvent annuler ceux dont ils sont propriétaires.

Le groupe PrinterAdmins peut effacer tous les travaux

Les membres de PrinterAdmins peuvent, eux, effacer tous les travaux en attente, depuis l’in-
terface Windows. Ils peuvent également modifier la priorité des tâches en cours.

Les utilisateurs CUPS disposent de tous les droits

Ces opérations sont également possibles depuis l’interface Web de CUPS, et l’administrateur de
CUPS peut annuler les tâches ou changer leur priorité comme il le souhaite. Il peut également
accéder au cache de CUPS. Ce dernier conserve en effet sur le disque la file d’attente des im-
pressions, mais n’efface pas immédiatement les travaux, de sorte qu’il est possible de les replacer
dans la file active et de disposer d’un duplicata. Comme il s’agit d’une fonctionnalité qui porte at-
teinte à la confidentialité des données, on veillera à ne pas donner le droit d’accès à l’interface de
CUPS à plus d’utilisateurs que nécessaire.
Reproduction interdite.

Configuration des imprimantes avec CUPS

53
Gestion des impressions
 4.7 : Prise en compte des quotas

Déclaration de l’imprimante dans Pykota

Déclaration dans l’annuaire LDAP
Manipulation des quotas

Déclaration de l’imprimante dans Pykota

Pour que Pykota prenne en compte une imprimante, il doit disposer d’une entrée correspondante
dans son fichier de configuration, lui indiquant notamment le nom de l’imprimante, afin de pou-
voir faire le lien entre les informations que lui transmet CUPS et l’imprimante elle-même. Cette
opération se fait manuellement, sans nécessiter l’édition du fichier de configuration :

pkprinters -a -D "description" nom_imprimante

Cette commande indique à Pykota qu’il doit gérer l’imprimante. Pour que le lien se fasse entre
Pykota et CUPS, il est nécessaire d’utiliser le même nom d’imprimante dans les deux logiciels.

Déclaration dans l’annuaire LDAP

L’annuaire LDAP a pour but de conserver toutes les informations disponibles sur les utilisateurs,
et notamment les quantités de pages imprimées. Pour cela, l’imprimante doit disposer, une fois
déclarée, de son entrée dans l’annuaire. Cette opération se fait manuellement.

Bien qu’il soit possible d’utiliser les commandes générique de Pykota, Scribe dispose d’un certain
nombre de commandes prenant en compte les cas courants.

Pour activer les quotas pour l’ensemble des élèves, on utilisera la commande printquota.py
-a. Cette commande ajoute l’objet nécessaire à la gestion des quotas dans le compte de tous
les utilisateurs existants. Cela signifie qu’il faudra l’exécuter à nouveau si l’on ajoute de nouveaux
élèves, l’année suivante par exemple. En cas d’ajout en cours d’année, on pourra limiter l’ajout à
un élève, par la commande edpykota -add user1.

Manipulation des quotas

Reproduction interdite.

Par défaut, les quotas sont initialisés à 0, ce qui correspond à une valeur infinie. Pour placer une
limite, on utilisera la commande printquota.py -s n, qui limite à n le nombre de copie par
élève. Pour placer une limite différente par classe, on pourra utiliser l’option -c nom_classe.

Pour réinitialiser les quotas, on utilisera l’option printquota -r. Cette commande repositionne
les compteurs de pages à zéro pour l’ensemble des utilisateurs, et l’on peut restreindre sa portée à
une classe, par exemple. Pour manipuler un seul utilisateur, on utilisera la commande edpykota,

Configuration des imprimantes avec CUPS

54
Prise en compte des quotas
 avec l’option -S n pour modifier son nombre de pages maximal, et -r pour réinitialiser son
nombre de pages consommées.
Note
Il est prévu que la gestion des quotas d’impression soit intégrée dans l’EAD à court
terme, à la manière de la gestion des quotas de disque.
Reproduction interdite.

Configuration des imprimantes avec CUPS

55
Prise en compte des quotas
5. Gestion des
sauvegardes
 5.1 : Les sauvegardes : que sauvegarder

La procédure automatisée sauvegarde l’essentiel

Les données des utilisateurs

Le contenu de l’annuaire
Les droits sur les fichiers
Les paramètres de configuration
Le coeur du système se trouve sur CD-ROM
La configuration des imprimantes est rapide

Les modifications locales sont conservées sur un serveur externe

Les partages spécifiques ne sont pas conservés

La procédure automatisée sauvegarde l’essentiel

Les données des utilisateurs

L’ensemble des données utilisateurs se trouve contenues dans la partition /home. On y trouve les
données des utilisateurs (chaque élève dispose d’un répertoire à son nom, contenant un répertoire
de travail et un sous-répertoire privé), les données des classes (des répertoires gérés par les
professeurs pour la publication de fichiers pédagogiques) et des groupes (des zones d’échanges
autour d’un thème).

L’opération de sauvegarde va se dérouler avec les droits root, et réaliser un fichier compressé
(.tgz) contenant l’ensemble des répertoires de données : le script de sauvegarde prend les
privilèges de root pour lire l’ensemble des répertoires, y compris les répertoires personnels.

Le contenu de l’annuaire

Lorsque le script génère le fichier archivant l’ensemble des fichiers et des répertoires, il conserve
l’indication du propriétaire. Mais il ne s’agit que d’un numéro identifiant ; le nom du propriétaire et
ses droits ne sont jamais conservés directement dans l’arborescence. Pour des raisons d’espace
initialement, ce sont les UID qui sont enregistrées.

Pour s’assurer que lors de la restauration, les fichiers seront bien attribués à leur propriétaire, il
est nécessaire de sauvegarder simultanément l’annuaire. Celui-ci contient la liste des utilisateurs
et leur identifiant numérique.

Le système de sauvegarde génère donc un fichier spécifique contenant l’annuaire LDAP, dans un
format textuel :annuaire.ldif

Les droits sur les fichiers

Enfin, il faut s’assurer que les droits que les propriétaires ont affecté à leurs fichiers seront bien
Reproduction interdite.

conservés après une restauration, afin d’éviter que des fichiers confidentiels ne deviennent lisibles
par inadvertance.

La commande de sauvegarde des fichiers enregistre bien les droits Unix de base, mais ne prends
pas en compte les droits étendus (ACL). Le script de sauvegarde enregistre donc dans un fi-
chier séparé l’ensemble des ACL affectant les fichier, et conserve le résultat dans un fichier

Gestion des sauvegardes

57
Les sauvegardes : que sauvegarder
 texte :acls.sauv.

Les paramètres de configuration

Les paramètres des applications Sympa et EVA (base de données) et la configuration du système
(config.eol) sont aussi sauvegardés.

Le coeur du système se trouve sur CD-ROM

Pour l’essentiel, il n’est pas nécessaire de sauvegarder le système, qui est constitué de pro-
grammes libres que l’on peut facilement retrouver. En cas d’incident majeur sur le serveur, la
procédure la plus simple consiste à réinstaller complètement à partir du CD-ROM, et à restaurer
la dernière sauvegarde avec les outils présents à la fin de l’installation. Conserver une copie des
fichiers système serait une perte de temps et d’espace disque.

La configuration des imprimantes est rapide

Seul bémol, la configuration des imprimantes n’est pas sauvegardée, mais il est rapide de resaisir
les paramètres d’accès aux imprimantes.

Les modifications locales sont conservées sur un serveur externe

Les autres fichiers de configuration ne sont pas conservés non plus, mais du fait du mécanisme
de génération des configuration à partir d’un système centralisé, il n’est pas utile de le faire. La
réinstallation d’un serveur passe par le téléchargement du fichier de configuration et par une
nouvelle instanciation. Il n’est pas nécessaire de saisir à nouveau ce qui a été fait, et il n’est donc
pas nécessaire de sauvegarder la configuration du serveur qui en résulte.

Les partages spécifiques ne sont pas conservés

Si des partages faisant l’objet d’une configuration particulière ont été créés, ils ne sont pas conser-
vés dans l’annuaires, mais dans le fichier servant à les générer. Ce fichier devra être recréé indé-
pendamment des sauvegardes.
Reproduction interdite.

Gestion des sauvegardes

58
Les sauvegardes : que sauvegarder
 5.2 : Les sauvegardes se déclenchent depuis l’EAD

L’interface est similaire à celle utilisée pour les MAJ

La sauvegarde interrompt le fonctionnement du service

Programmation des sauvegardes

Déclenchement immédiat
Déclenchement différé

L’interface est similaire à celle utilisée pour les MAJ

L’interface de programmation des sauvegardes dans le temps est similaire à celle utilisée pour les
mises à jour, exception faite de la programmation d’une sauvegarde récurrente automatisée.

La sauvegarde interrompt le fonctionnement du service

Durant toute l’opération de sauvegarde, le serveur est inutilisable : en effet, pour éviter d’enregis-
trer des fichiers en cours d’écriture, le système de sauvegarde commence par arrêter le partage
de fichiers et l’accès à l’annuaire. Tous les utilisateurs sont donc déconnectés pendant la durée de
la procédure. Cette opération pouvant être longue, en fonction de la quantité de données à sauve-
garder, il est recommandé de l’envisager la nuit ou durant les congés. Une sauvegarde régulière
pourra être programmée, sous réserve de disposer d’assez d’espace de stockage.

Programmation des sauvegardes

Déclenchement immédiat

Il est possible d’effectuer une sauvegarde immédiate. L’opération prend d’autant plus de temps
qu’il y a de données à sauvegarder. Comme l’EAD est arrêté durant la sauvegarde, il est normal
que l’interface ne semble plus répondre. Lorsque l’opération est terminée, un rapport est dispo-
nible sur la page d’accueil. Il ne signifie pas nécessairement que l’opération s’est correctement
terminée : il contient, le cas échéant, les messages d’erreurs générés par la sauvegarde. Si tout
s’est bien passé, il indique la date à laquelle la dernière sauvegarde a été effectuée.

La sauvegarde a déclenchement immédiat ne doit pas être effectuée lorsque les utilisateurs sont
connectés sur le serveur. Le client d’accès aux partages réseau est conçu pour supporter des
déconnexions ponctuelles, mais certaines applications, lancées depuis le serveur par un client,
peuvent avoir besoin d’accéder à différents fichiers et « planter » en cas de coupure en cours
Reproduction interdite.

d’utilisation. Il est donc important de prévenir les utilisateurs en vue des sauvegardes, surtout s’ils
ont des contraintes de temps pour terminer un travail.

Déclenchement différé

Il est également possible de choisir un déclenchement différé, en sélectionnant dans le menu la

durée avant l’opération. Cette option sert essentiellement à programmer une sauvegarde durant la

Gestion des sauvegardes

59
Les sauvegardes se déclenchent depuis l’EAD
 nuit, après des modifications importantes, sans risquer d’interrompre le service. Il n’est pas pos-
sible de programmer une heure précise de déclenchement, seule une liste de délais d’attente est
prévue. Cette fonction n’a pas pour objectif l’automatisation des sauvegardes, seulement d’éviter
de prolonger l’interruption de service après une opération.
Reproduction interdite.

Gestion des sauvegardes

60
Les sauvegardes se déclenchent depuis l’EAD
 5.3 : La sauvegarde sur support local

La sauvegarde se fait dans /var/sauvegardes

Le répertoire peut servir de point d’ancrage à d’autres supports

Il est possible de faire une sauvegarde plus durable

Il faut que le serveur soit équipé d’un lecteur de bande

Les sauvegardes sont programmées dans l’onglet bande

La sauvegarde se fait dans /var/sauvegardes

Le système de sauvegarde, par défaut, réalise des sauvegardes dites sur disque. Les fichiers
résultants de la sauvegarde sont placés dans un sous-répertoire appelé sauvegarde. S’il existe
déjà, il est déplacé (dans sauvegarde1), pour laisser la place au nouveau. On trouve donc
toujours la sauvegarde la plus récente dans le répertoire sauvegarde, et la plus ancienne dans
sauvegarde4.

Si l’espace disque le permet, le système conserve donc toujours cinq versions des sauvegardes
sur le disque : les sauvegardes plus anciennes sont effacées.

Le répertoire peut servir de point d’ancrage à d’autres supports

Le choix d’une sauvegarde sur le disque est justifié par deux raisons. Tout d’abord, il peut être utile
de conserver sur le disque, à titre de garde-fou, une copie des fichiers de travail des utilisateurs.
Si l’un d’entre eux efface par mégarde un de ses fichiers, il est ainsi possible de le récupérer
sans nécessiter de longues manipulations de bandes. Pour être pleinement utiles dans ce cas,
les sauvegardes doivent être fréquentes, faute de quoi beaucoup de travail pourrait être perdu,
d’où la possibilité de conserver cinq copies des données simultanément sur le disque : l’utilisateur
dispose d’un temps plus long pour détecter le problème et demander la restauration de son fichier.

Par ailleurs, le choix d’une sauvegarde dans un répertoire a été pensé dans la logique Unix. Ce ré-
pertoire ne pointe vers une zone du disque que par défaut, et cette association peut être changée,
soit par la commande mount, soit par modification du fichier /etc/fstab pour une modification
plus définitive. C’est par ce biais que les sauvegardes peuvent être faites sur des périphériques
USB ou sur des PC distants : le script automatisé ne fait que faire appel aux mécanismes de
montage classique.

Il est possible de faire une sauvegarde plus durable

Reproduction interdite.

Il faut que le serveur soit équipé d’un lecteur de bande

Pour réaliser des sauvegardes plus durables, il est nécessaire de disposer d’un lecteur de bande
dans la machine. Les lecteurs SCSI sont tous supportés, et pour les modèles plus rares, on pourra
se reporter au site du Hardware-HOWTO pour une liste du matériel pris en charge par Linux.

Gestion des sauvegardes

61
La sauvegarde sur support local
 La réalisation d’une sauvegarde sur bande nécessite un travail préalable : l’accès au lecteur de
bande se fait sous Linux au moyen d’une interface unique, quel que soit le type du périphérique,
mais le nom du fichier de périphérique est variable. Il faut donc signaler à l’EAD le nom du péri-
phérique à utiliser. Cette formalité permet aussi de sélectionner le lecteur de bande à utiliser.

Cette opération se fait dans l’onglet configuration, il n’est besoin de la faire qu’une fois.

Les sauvegardes sont programmées dans l’onglet bande

Le déclenchement de la sauvegarde, immédiate ou différée, se fait dans l’onglet bande, et l’in-

terface est identique à celle utlisée pour les sauvegardes sur disque.
Reproduction interdite.

Gestion des sauvegardes

62
La sauvegarde sur support local
 5.4 : La sauvegarde distante

La sauvegarde distante se fait une sur machine du réseau local

Création d’un partage adapté à la sauvegarde

Sous W98 : le partage doit être protégé par mot de passe

Sous XP, le partage doit être réservé à un utilisateur

Configuration de la sauvegarde dans l’EAD

La sauvegarde distante se fait une sur machine du réseau local

Contrairement aux sauvegardes locales, disque ou bande, qui sont effectuées directement sur
la machine, les sauvegardes distantes se font sur un partage (du voisinage réseau) mis à la
disposition du serveur par une station de travail.

La réalisation de ce type de sauvegarde nécessite deux étapes préalables : la création d’un par-
tage réseau sur la station de sauvegarde d’une part, et la configuration de la sauvegarde sur le
serveur lui-même, pour lui indiquer les paramètres d’accès à ce partage.

Le déclenchement de la sauvegarde utilise la même interface que pour les sauvegardes dites
locales.

Création d’un partage adapté à la sauvegarde

Sous W98 : le partage doit être protégé par mot de passe

Il est nécessaire que les modules Windows permettant l’accès au voisinage réseau et le partage
de fichiers soient installés sur le système. C’est le cas des installations par défaut, mais certaines
académies utilisant des images adaptées (ghost ou similaire) pour l’installation des postes peuvent
avoir désactivé ces fonctions.

Il faut créer un répertoire, et sélectionner dans le menu accessible par un clic droit l’option Par-
tager, puis préciser que le partage doit être accessible en lecture et en écriture, et qu’il doit
être protégé par un mot de passe. Comme la sauvegarde contient potentiellement des informa-
tions confidentielles, il ne faut pas qu’elles tombent entre de mauvaises mains. Pour éviter cela,
le partage ne doit pas être accessible à tous ; l’interface EAD ne devra pas servir à réaliser des
sauvegardes sur un partage public.

Sous XP, le partage doit être réservé à un utilisateur

Reproduction interdite.

Dans cette logique, XP offre de meilleures possibilités pour sécuriser l’accès au partage. Lorsque
l’on crée un partage, il est par défaut accessible en écriture. Dans l’onglet Sécurité, il faut désacti-
ver tous les droits, puis rechercher dans le domaine (options Avancé, Rechercher) un utilisateur
que l’on aura créé préalablement pour cela. On pourra ainsi créer un utilisateur sauvegarde dans
l’EAD préalablement à la configuration des sauvegardes, plutôt que d’utiliser des noms d’utilisa-

Gestion des sauvegardes

63
La sauvegarde distante
 teurs réels : on évite ainsi que le titulaire du compte ne puisse consulter, dans la sauvegarde, les
fichiers de ses collègues.

L’utilisateur autorisé devra avoir tous les droits sur le répertoire, sans cela, l’opération d’écriture
échouera.

Configuration de la sauvegarde dans l’EAD

Le formulaire de configuration est identique quel que soit le système d’exploitation qui héberge le
partage. Dans les deux cas, l’EAD demande trois informations :

l’emplacement du partage ;

le nom de l’utilisateur ;
le mot de passe de l’utilisateur.

L’emplacement correspond à l’adresse IP (ou au nom Netbios) de la machine, ainsi qu’au nom
sous lequel le répertoire est partagé (par défaut, le nom du répertoire, mais cela peut être changé
sur la station, lors de la création). Il est recommandé d’utiliser l’adresse IP dans la mesure du
possible, pour éviter les ralentissements liés à la résolution du nom.

Le nom de l’utilisateur et son mot de passe sont ceux de l’utilisateur du domaine, dans le cas d’un
partage XP. Dans le cas d’un partage 98, on remplira, dans ces deux cases, le mot de passe que
l’on a attribué au partage.
Reproduction interdite.

Gestion des sauvegardes

64
La sauvegarde distante
 5.5 : Vérifications et restauration

Les fichiers de sauvegarde

Procédure de restauration

Les fichiers de sauvegarde

Si la sauvegarde s’est correctement déroulée, le rapport indique que tout est OK. On devrait
normalement trouver un répertoire sauvegarde à l’emplacement de la sauvegarde, contenant
les sept fichiers correspondant aux types de données sauvegardées. On pourra en vérifier la date
pour s’assurer que tout s’est passé correctement.

Procédure de restauration
Contrairement à la sauvegarde, qui peut s’automatiser et se piloter depuis l’EAD, la procédure de
restauration reste manuelle. C’est essentiellement voulu : une sauvegarde ne peut jamais nuire,
alors qu’une restauration peut détruire, en les écrasant, de nombreuses heures de travail. Dans
ces conditions, mieux vaut réserver les procédures de restauration aux équipes académique : une
panne sur le serveur nécessitera de toute manière leur intervention.

La restauration se fait en plusieurs étapes, correspondant chacune à un fichier. L’ordre dans lequel
ces étapes ont lieu est important, car la bonne restauration des droits, par exemple, repose sur
la présence des utilisateurs dans l’annuaire, de même, l’application des droits sur les fichiers
nécessite leur présence. L’ordre des opérations est donc le suivant :
restauration de l’annuaire ;
restauration des fichiers ;
restauration des droits.
L’annuaire LDAP

Pour restaurer l’annuaire LDAP, on va supprimer l’annuaire existant — qu’il soit corrompu ou vide
du fait d’une réinstallation complète du système — et réimporter l’annuaire sauvegardé.
Reproduction interdite.

La première étape consiste donc à arrêter l’annuaire, et avec lui, par sécurité, l’ensemble des
services qui en dépendent. Ensuite, on efface les fichiers correspondant à l’annuaire (contenus
dans le répertoire /var/lib/ldap/) et on utilise la commande slapadd -l annuaire.ldif
pour réimporter l’annuaire. L’ensemble des fichiers du répertoire /var/lib/ldap doit être recréé
si la commande s’est correctement effectué.

Toutefois, puisque la restauration s’est faite en tant que root, les fichiers créés appartiennent à

Gestion des sauvegardes

65
Vérifications et restauration
 cet utilisateur. L’annuaire LDAP tournant sous son propre utilisateur, appelé ldap, il ne pourra
pas accéder à ces fichiers. Il faut donc en modifier le propriétaire avec la commande chown
ldap.ldap /var/lib/ldap/* avant de redémarrer l’annuaire.

Les données

Les données sont archivées au format tar, et leur extraction se fait avec la commande :

tar zxf monfichier.tgz -C /répertoire/ou/extraire

On fera la restauration dans le répertoire approprié en fonction du type de données sauvegardées.

Reproduction interdite.

Gestion des sauvegardes

66
Vérifications et restauration
6. La gestion des
droits avec
Samba
 6.1 : La gestion des droits : deux approches

L’approche Unix : celle des permissions d’accès

Les droits d’accès dépendent du fichier
Trois droits : lecture, écriture, exécution
Quelques droits étendus permettent l’héritage des droits
Les droits d’accès sous Microsoft Windows
Chaque fichier est associé à une ACL (access control list)
Le système semble plus souple

L’approche Unix : celle des permissions d’accès

Les droits d’accès dépendent du fichier

Dans le système utilisé par Linux, les droits d’accès à un fichier dépendent d’éléments liés à ce
fichier. Chaque fichier appartient à un utilisateur et à un groupe unique, et conserve des permis-
sions d’accès spécifique pour cet utilisateur et ce groupe particulier. Il conserve aussi une série de
permissions d’accès applicables à l’ensemble des utilisateurs qui ne disposent pas de privilèges
particuliers.

Seul le propriétaire d’un fichier — et l’administrateur du système — peuvent modifier les permis-
sions d’accès. On dispose d’une certaine souplesse, car un utilisateur peut être membre d’autant
de groupe qu’il souhaite, et donc accéder aux fichiers de son groupe. Cette approche a été adop-
tée dans l’optique d’un groupe de travail qui souhaite partager des fichiers. Il n’y a pas de raison
de limiter les accès entre membres d’un même groupe, qui disposent donc du même niveau de
privilège.

Le modèle de sécurité retenu s’occupe de restreindre les accès au système, et permet de partager
les fichiers : il n’a pas pour objectif de définir des droits personnalisés pour chacun des utilisateurs.

En plus de cette limitation, la gestion des droits perd en souplesse lorsqu’on sait que seul l’admi-
nistrateur peut créer de nouveaux groupe et y inscrire des utilisateurs. Il n’est donc pas possible
de partager un fichier avec un groupe spécifique, puisqu’il ne peut en créer de sa propre initiative.

Trois droits : lecture, écriture, exécution

L’essentiel des permissions d’accès sous Linux se gère en attribuant aux bénéficiaires (proprié-
taire, groupe, autres utilisateurs) trois droits principaux, dont les effets varient en fonction du fichier
bénéficiaire.

Un grand nombre d’aspects du système (ressources, périphériques, interfaces de communica-

Reproduction interdite.

tion...) sont représentés par des fichiers. Cette approche permet de proposer aux administrateurs
une méthode unifiée pour restreindre les accès. L’accès à la carte son correspond donc au droit
d’écrire sur le périphérique /dev/audio, droit qui peut être conféré au groupe auquel appartient
ce fichier. Pour déterminer qui peut jouer de la musique, l’administrateur n’a qu’à ajouter des noms
au groupe audio, une opération standard et habituelle.

La gestion des droits avec Samba

68
La gestion des droits : deux approches
 L’effet exact des droits varie en fonction du type de fichier : sur un lien, par exemple, les droits ne
sont pas pris en compte : seul les droits sur le fichier de destination sont utilisés. Tout le monde a
le droit de suivre un lien.

Sur un fichier normal, les droits se comprennent facilement : droit de lecture, d’écriture (c’est-à-
dire droit de modification, puisqu’une écriture du fichier consiste à le modifier), et droit d’exécution,
que ce soit pour un fichier binaire exécutable, qui est alors transmis au processeur, ou pour un
fichier textuel, qui est alors interprété comme une suite de commandes par le shell.

Sur un répertoire, le droit de lecture correspond au droit de lister le contenu, le droit d’écriture au
droit de créer ou d’effacer un fichier. La création d’un fichier est une opération qui dépend des
droits du répertoire : au moment de la création, le fichier n’a pas encore de droits qui permettent
de savoir si cette opération est possible ou non. Le droit d’exécution, qui n’a pas de sens immédiat
pour les répertoires, est recyclé pour devenir le droit de parcourir l’arborescence au travers de ce
répertoire. Un utilisateurs qui ne dispose pas du droit d’exécution sur le répertoire n’aura pas la
possibilité d’entrer dans ses sous-répertoires.

Quelques droits étendus permettent l’héritage des droits

Par défaut, chaque utilisateur choisit, par le biais de sa variable UMASK, les droits qui s’appliquent
par défaut aux fichiers qu’ils créent. Toutefois, cette méthode n’est pas forcément désirable dans
certains cas : notamment lorsque l’administrateur veut créer un espace d’échanges où tout le
monde peut écrire, comme dans le cas des répertoires /tmp. Dans ce cas, on ne veut pas for-
cément que les utilisateurs puissent éditer les fichiers d’autrui, sans les empêcher d’écrire des
fichiers, éventuellement en les écrasant. Cette possibilité est offerte par le sticky bit, un droit par-
ticulier du répertoire parent. Sur les fichiers, ce droit est ignoré (sous Linux tout du moins).

Les deux autres droits possibles sont l’héritage des permissions du propriétaire ou du groupe. On
les utilise souvent pour donner aux membres d’un groupe (ou à tous les utilisateurs du système)
le droit d’effectuer un certain nombre d’opérations avec les permissions d’accès du propriétaire
du programme. Un grand nombre de programmes d’administration fonctionnent ainsi : ils prennent
les droits de l’administrateur lorsqu’ils sont lancés par n’importe quel utilisateur, et déterminent,
en fonction de l’identité de la personne qui les exécute, s’ils doivent permettre de configurer un
paramètre ou simplement récupérer sa valeur et en informer l’utilisateur.

Sur les répertoires, les droits d’héritage des permissions attribuent d’office tous les fichiers créés
dans ces répertoires au propriétaire et/ou au groupe propriétaire du répertoire.

Les droits d’accès sous Microsoft Windows

Chaque fichier est associé à une ACL (access control list)

La gestion des droits peut être plus souple sous les systèmes Microsoft Windows récents. Les
droits possibles sont associés à chaque utilisateur et à chaque groupe au sein d’une liste de
contrôles d’accès.

Les droits sont individualisés : plutôt que de récupérer un même droit plusieurs fois, et de lui attri-
buer un sens différent selon le fichier récipiendaire — une économie justifiée, aux temps héroïques
de l’informatique, car elle permettait de n’affecter qu’un seul octet à la gestion des permissions
d’accès — les droits sont traités séparément. On retrouve toutefois les possibilités offertes par le
système de droits POSIX.
Reproduction interdite.

Dans ce système, chaque utilisateur, ou groupe d’utilisateurs, peut disposer d’un jeu de droits
spécifiques. Le propriétaire d’un fichier peut attribuer des droits à l’ensemble des groupes ou des
utilisateurs. Lorsqu’il y a une tentative d’accès, le système compile une liste de droits applicable
à l’utilisateur, en fonction des groupes auxquels il appartient, et détermine alors si l’opération est
permise.

La gestion des droits avec Samba

69
La gestion des droits : deux approches
 Le système semble plus souple

Ce système est plus souple, car il permet de gérer des droits utilisateur par utilisateur. Il nécessite
toutefois une meilleure connaissance du système par les utilisateurs qui attribuent des droits. Une
erreur peut vite se produire compte tenu de la multiplicité des choix offerts. Pour éviter de trop
embrouiller l’utilisateur, l’interface ne présente par défaut que les droits les plus courants (lecture,
exécution, modification, archives).

L’autre inconvénient du système, qui affecte malheureusement le serveur Samba, est lié à la
structure du système Microsoft Windows. Un certain nombre d’opérations courantes nécessite
des privilèges étendus, rendant nécessaire l’appartenance d’un certain nombre d’utilisateurs au
groupe DomainAdmins, ce qui diminue la sécurité globale.
Reproduction interdite.

La gestion des droits avec Samba

70
La gestion des droits : deux approches
 6.2 : Les différents niveaux de droits

L’accès aux fichiers est contrôlé de plusieurs manières

Les utilisateurs n’ont accès qu’à l’aspect Windows
L’administrateur peut changer les droits Unix des partages

L’accès aux fichiers est contrôlé de plusieurs manières

Lorsqu’un utilisateur distant tente d’effectuer une opération sur le disque, il est soumis à une série
de vérification à différents niveaux :
Samba vérifie que l’utilisateur est autorisé, d’après sa propre configuration, à effectuer
l’opération et sous quel nom d’utilisateur Unix cette opération doit être faite ;
Le système Linux vérifie que l’opération est possible en examinant les droits présents sur
le fichiers, droits qui peuvent être soit des droits Unix traditionnel, soit des droits étendus
(acl) ;
Le système vérifie que les attributs du fichier ou de la partition n’interdisent pas l’opération.

Les utilisateurs n’ont accès qu’à l’aspect Windows

Le résultat de l’opération dépend de la configuration à chacun de ces niveaux, ce qui offre une
grande souplesse dans la définition des restrictions d’accès sur les fichiers. Pour les utilisateurs, la
manipulation des droits des fichiers au moyen de leur explorateur intégré à Windows XP est aisée :
Samba assure la conversation des droits Windows vers les ACL Linux. Pour l’administrateur, la
gestion à plusieurs niveaux permet de garantir que certaines restrictions ne pourront pas être
contournées par les utilisateurs.

L’administrateur peut changer les droits Unix des partages

Lorsque l’on crée un nouveau partage depuis l’EAD, des droits minimaux sont positionnés pour
permettre aux utilisateurs du partage d’accéder sans problème au répertoire correspondant. Cer-
tains administrateurs peuvent vouloir positionner des droits particuliers pour modifier certains as-
pects du comportement du serveur.
Reproduction interdite.

La gestion des droits avec Samba

71
Les différents niveaux de droits
 6.3 : Manipulation des droits Unix

chmod change les permissions

Les permissions sont designées par des lettres

Elles peuvent être désignées par une valeur octale

Les droits spéciaux (SUID, SGID, sticky)

chown change le propriétaire

chmod change les permissions

Les droits Unix, tels qu’ils ont été définis lors de la création du partage ou du dépôt de chaque
fichier sur le serveur, sont manipulables fichier par fichier avec la commande :

chmod permissions fichier

Les permissions sont designées par des lettres

Il existe deux manières d’indiquer les permissions, soit en utilisant la notation numérique en octal,
soit sous la forme :

chmod [u,g,o] [+,-][r,w,x] fichier

Le premier jeu d’options indique le groupe dont il faut changer les droits :

u pour le propriétaire ;
g pour le groupe ;

o pour les autres.

Le deuxième jeu d’options indique s’il faut ajouter ou retirer les permission de lecture, d’écriture
ou d’exécution. Il est possible de modifier plusieurs droits d’une seule commande.

Le droit r correspond au droit de lecture d’un fichier, ou au droit de lister le contenu d’un répertoire.
Le droit w correspond au droit de modification d’un fichier, ou de création/supression des fichiers
à l’intérieur d’un répertoire. Le droit x correspond au droit d’exécuter un programme, ou au droit
de traverser un répertoire pour accéder aux sous-répertoire, indépendamment du droit d’en lister
le contenu.
Reproduction interdite.

Elles peuvent être désignées par une valeur octale

Lorsque l’on souhaite positionne des droits à une valeur précise plutôt qu’ajouter ou retirer un
droit, on gagnera en rapidité à préciser les droits avec la forme numérique. Dans cette forme, on
a les équivalences suivantes :
le droit de lecture vaut 4 ;

La gestion des droits avec Samba

72
Manipulation des droits Unix
 le droit d’écriture vaut 2 ;
le droit d’exécution vaut 1.
Les droits spéciaux (SUID, SGID, sticky)

Certains droits particuliers modifient l’interprétation des autres droits. Le droit SUID, symbolisé
par un s dans le triplé des droits associé à un utilisateur, permet d’exécuter un programme avec
l’identité du propriétaire du programme et non pas celle de la personne qui l’exécute réellement.
Le droit SGID se comporte de la même façon, mais il permet de fixer le groupe sous l’identité
duquel l’opération va être faite.

Ces deux droits ne concernent que les commandes Unix lancées sur le système Linux, ce qui est
donc d’une portée limitée dans un serveur de fichiers. En revanche, lorsqu’ils sont positionnés sur
des répertoires, ils forcent les fichiers créés à l’intérieur du répertoire à « hériter » du propriétaire
ou du groupe, et peuvent donc simplifier la gestion de certains problèmes par Samba.

Le droit t, ou sticky bit, permet de garder un programme en mémoire après son exécution — une
fonctionnalité inutile sous Linux puisqu’il s’agit de la façon standard de gérer la mémoire — mais
lorsqu’il est placé sur un répertoire, il y rend les fichiers plus durables. Par défaut, la suppression
d’un fichier est une opération d’écriture sur le répertoire, et ne nécessite pas de disposer de droits
particuliers sur le fichier à effacer. Si le droit t est positionné sur le répertoire, il faut pour effacer
un fichier disposer à la fois du droit d’écriture sur le répertoire et du droit de modification sur le
fichier.

chown change le propriétaire

La commande chown propriétaire.groupe fichier permet de changer le propriétaire (et,
éventuellement, le groupe d’appartenance) d’un fichier. Seul un membre d’un groupe peut placer
un fichier dans ce groupe ; seul l’administrateur peut changer le propriétaire d’un fichier. Il n’est
donc pas possible de « donner » un fichier à un autre utilisateur.
Reproduction interdite.

La gestion des droits avec Samba

73
Manipulation des droits Unix
 6.4 : Fonctionnement de Samba

Il y a plusieurs niveaux de contrôles d’accès

Samba est un utilisateur Unix
Le serveur utilise les ACL pour les partages

Il est possible d’imiter la gestion des ACL Microsoft Windows

Il y a plusieurs niveaux de contrôles d’accès

La gestion des contrôles d’accès dans le serveur de fichiers se fait à plusieurs niveaux : au niveau
de Samba, tout d’abord, qui détermine si l’utilisateur qui se connecte est bien autorisé à accéder
au partage qu’il souhaite. Au niveau de Linux, ensuite, qui valide, en fonction de son système de
permissions d’accès, l’opération demandée par l’utilisateur.

Les deux niveaux d’applications se superposent, et doivent être pris en considération ensemble.
Même si Samba autorise une opération, le système de fichier peut l’interdire par la suite.

La subtilité de la configuration de Samba réside dans la gestion de ces doubles listes. Toutefois,
l’essentiel de la configuration de Samba est transparente pour l’administrateur. Les interventions
système ne se font qu’au travers des scripts de configuration simplifiés.

Samba est un utilisateur Unix

Samba se comporte, du point de vue du noyau, comme un utilisateur du système, généralement
celui sous lequel le client s’est authentifié. Il est donc nécessaire de créer des comptes Unix
pour les différents utilisateurs Samba. Afin de simplifier la procédure, les comptes du système
sont conservés dans un annuaire LDAP, et la création d’utilisateurs peut se faire par le biais de
l’interface EAD.

Le serveur utilise les ACL pour les partages

Les ACL POSIX sont utilisées par Samba pour le système de fichiers destiné à contenir les par-
tages. Cela nécessite toutefois une intervention de plus bas niveau : lors de l’installation d’une
application qui nécessite des droits spécifiques, l’administrateur doit les positionner manuelle-
ment. Les détails de l’opération seront fournis avec chaque application. La décision en la matière
ne relève pas du projet EOLE, dont la mission se limite à la fourniture d’une infrastructure. Les
Reproduction interdite.

applications bien développées ne devraient pas imposer une telle intervention.

Il est possible d’imiter la gestion des ACL Microsoft Windows

Toute la souplesse du système d’ACL Windows peut être imitée par la gestion sous Linux, no-
tamment au niveau de l’intégration des postes clients. Si les utilisateurs décident de modifier les

La gestion des droits avec Samba

74
Fonctionnement de Samba
 permissions d’accès à leurs fichiers, ils peuvent le faire au moyen des outils Windows classiques,
et cela sera pris en compte au niveau du serveur. Pour l’installation des applications, l’administra-
teur n’a donc pas forcément besoin de connaître le détail des commandes Linux liées aux droits.

Ces commandes sont toutefois utiles dans le cadre de la maintenance et de l’administration à

distance : elles peuvent être utilisées au travers d’une connexion SSH, et ne nécessitent pas de
se trouver physiquement sur le réseau de l’établissement.
Reproduction interdite.

La gestion des droits avec Samba

75
Fonctionnement de Samba
 6.5 : Comment interpréter les ACL ?

Les ACL sont constituées de droits Unix

Les ACL sont constituées de droits Unix

Les ACL ne génèrent pas de nouveaux types de droits, la gestion multigroupes et multiutilisateurs
se fait uniquement en reprenant les droits Unix traditionnels, mais en offrant plus de souplesse
pour déterminer le jeu de droits qui s’applique. Plutôt que d’avoir trois groupes de droits prédéfinis,
on peut ajouter à ces droits, qui constituent l’ossature par défaut, des droits spécifiques pour un
groupe ou pour un utilisateur précis. Ces ajouts peuvent se faire depuis la station Windows XP
cliente, ou avec la commande setfacl.

setfacl -m u:utilisateur:rwx fichier

setfacl -m g:groupe:rwx fichier

Lorsque le système constate qu’un utilisateur tente d’accéder à un fichier et qu’il n’est ni le pro-
priétaire ni membre du groupe principal du fichier, il va regarder les droits additionnels positionnés
par les ACL pour tenter de déterminer s’il dispose de droits spécifiquement associés à l’utilisateur
ou, à défaut, de droits s’appliquant à un groupe dont fait partie l’utilisateur. Le système va faire la
synthèse de ces droits additionnels, pour déterminer les droits effectifs que l’utilisateur aura sur le
fichier.

En plus des ACL portant sur un utilisateur ou sur un groupe, il est possible de définir une ACL de
masque, qui définit l’ensemble des droits qui peuvent être ajoutés par le biais des ACL. On aura
donc un garde-fou en cas de fausse manipulation si l’on applique une ACL globale restreignant
l’ajout d’un droit d’écriture sur des fichiers sensibles.

Les ACL peuvent être héritées si l’on positionne sur un répertoire une ACL par défaut, qui s’ap-
pliquera à toutes les créations de fichiers présentes dans ce répertoire. Toutefois, pour faciliter la
gestion de l’héritage des ACL, il peut être plus facile d’utiliser les options correspondantes dans
Samba.
Reproduction interdite.

La gestion des droits avec Samba

76
Comment interpréter les ACL ?
 6.6 : Quelques recommandations sur les droits

Différencier les droits d’installation et d’utilisation

Toujours agir sur les droits des groupes

Ne pas hésiter à multiplier les groupes

Différencier les droits d’installation et d’utilisation

Lors de l’installation des applications, il est recommandé d’utiliser l’identifiant admin pour se
connecter au serveur, afin de limiter les risques d’erreur. C’est pour l’attribution des droits durant
la phase d’utilisation que vont se poser d’éventuels problèmes.

En théorie, chaque académie pouvant utiliser des logiciels différents, c’est à elles qu’incombe la
responsabilité de définir les ACL à utiliser. En pratique, pour les applications courantes, il est pos-
sible d’obtenir de l’aide sur les listes de diffusion. Attention, il ne s’agit que de recommandations ;
il est possible d’arriver au résultat voulu par d’autres méthodes, et l’équipe EOLE ne souhaite rien
imposer en matière d’applications, et d’autant plus qu’il s’agit d’applications privées.

Toujours agir sur les droits des groupes

Il peut être tentant lorsqu’on établit une maquette, d’utiliser la souplesse apportée par les ACL pour
positionner des droits spécifiques par utilisateur. C’est toutefois une voie sans issue : cela revien-
drait à devoir modifier les droits sur les applications à chaque changement d’utilisateur, à chaque
mutation... Positionner des droits sur les groupes est beaucoup plus durable : les droits restent
intacts, seuls les utilisateurs membres des groupes changent. Et la manipulation des groupes
peut se faire par le biais de l’EAD, au niveau de l’établissement, sans intervenir sur le système de
fichiers.

Ne pas hésiter à multiplier les groupes

On ne devra pas hésiter à créer un groupe pour chaque type de droits dont peut disposer un (ou
plusieurs) utilisateurs. La présence d’un grand nombre de groupes n’a aucun impact négatif sur
le serveur, et à trop vouloir rassembler, on risque de ne pas pouvoir revenir en arrière s’il apparaît
nécessaire ultérieurement de séparer deux droits qui étaient jusqu’à présent associé aux mêmes
ensembles d’utilisateurs.
Reproduction interdite.

Note
Il faut rester raisonnable, on ne devra pas créer un groupe par binôme...

La gestion des droits avec Samba

77
Quelques recommandations sur les droits
 6.7 : La réplication des droits

Valider les droits sur le serveur père

Sauvegarder les ACL

Valider les droits sur le serveur père

Lors de l’installation initiale des applications sur le serveur père, on peut avantageusement posi-
tionner les droits avec un client Windows connecté au serveur.
Note
Dans certains cas, il est nécessaire de redémarrer le client pour que les change-
ments de droits soient pris en compte. Il doit s’agir de la première mesure à prendre
en cas de comportement erratique d’un client.

En cas de problème, on va d’abord chercher à voir si les droits appliqués correspondent bien à ce
qui est positionné sur les fichier. Pour cela, la commande getfacl permet d’afficher la liste des
utilisateurs et les droits qui leurs sont associés. La commande getfacl -R permet d’afficher les
droits pour un répertoire et tous les fichiers et répertoires qu’il contient.

La commande retourne les droits associés aux trois groupes d’utilisateurs classiques Unix, ainsi
que toutes les ACL spécifiques. Ces trois utilisateurs sont :
le propriétaire du fichier ;
le groupe Unix auquel appartient le fichier ;

le reste des utilisateurs (ACL par défaut).

Les droits sont représentés par les symboles suivants :

r pour le droit de lecture ;
w pour le droit d’écriture ;
x pour le droit de traverser ou d’exécuter ;
Reproduction interdite.

En revanche, la commande getfacl n’indique pas les permissions liées à l’héritage des droits
(s) ni celles liées à la protection contre l’effacement des fichiers (t). Pour afficher ces droits, la
commande ls -l fichier.

Cette commande affiche un grand nombre d’indications sur le fichier : la liste des droits Unix (trois
groupes de trois droits : pour le propriétaire, le groupe et le reste des utilisateurs), le nombre de

La gestion des droits avec Samba

78
La réplication des droits
 liens pointant vers ce fichier, le nom du propriétaire et du groupe du fichier, la taille et la date de
dernière modification.

Cette commande affiche les droits particuliers, et permet de vérifier notamment que le droit t est
positionné sur l’ensemble des répertoires.

Sauvegarder les ACL

Si les applications peuvent être installées par une simple restauration des données sauvegardées
sur le serveur père, les ACL doivent être elles aussi repositionnées. La commande

getfacl -R /data > ma_liste_de_droits

permet de conserver l’ensemble des ACL de la partition data dans un fichier

ma_liste_de_droits.

Les permissions peuvent être appliquées à nouveau par la commande

setfacl --restore=ma_liste_de_droits

On peut donc transférer aisément les ACL d’un serveur père à l’ensemble des réplicats.
Reproduction interdite.

La gestion des droits avec Samba

79
La réplication des droits
 6.8 : Gestion avancée : la manipulation des partages

L’héritage des permissions et des ACL peut se configurer

On partira généralement d’une configuration fonctionnelle

Les modifications les plus courantes

Les directives inherit servent à modifier l’héritage des droits

On peut forcer le mode de création d’un fichier

L’exécution de scripts

L’héritage des permissions et des ACL peut se configurer

Le serveur génère la configuration de Samba à partir de l’annuaire LDAP, qui contient la défi-
nition des partages et des groupes qui leur sont associés. Lors de la création, par l’importation
GEP, d’une classe donnée, tous les groupes associés à cette classe sont ajoutés à l’annuaire,
et lors de la regénération des fichier de configuration, les partages correspondants sont ajoutés
dans le fichier /etc/samba/smb.conf directement utilisé par Samba. Il est toutefois possible
de contourner les choix par défaut issus de l’annuaire en imposant l’utilisation d’une configuration
manuelle pour un partage.

Lors de la génération du fichier smb.conf, le script examine le contenu du répertoire

/usr/share/eole/backend/conf/ pour déterminer s’il y a des partages disposant d’une
configuration spécifique. S’il trouve un fichier du nom de nom_du_partage.conf, il en tiendra
compte plutôt que d’utiliser les informations issues de l’annuaire.

On partira généralement d’une configuration fonctionnelle

Le fichier doit contenir une section Samba complète (l’ensemble des directives applicables au
partage et situées après la ligne [nom_du_partage] dans le fichier smb.conf. Plutôt que de
tout resaisir, on pourra copier le fichier smb.conf tel qu’il est et supprimer toutes les directives
non-pertinentes.

Les modifications les plus courantes

Les directives inherit servent à modifier l’héritage des droits

Par défaut dans Samba, les droits des nouveaux fichiers sont positionnés par la station cliente à
0644, et 0755 pour les nouveaux répertoires. Si l’on veut affecter un jeu de droits précis pour les
nouveaux fichiers, on peut configurer le partage pour que Samba, lors de la création du fichier ou
Reproduction interdite.

du répertoire nouveau, lui affecte les droits du répertoire dans lequel il se trouve.

Pour cela, on dispose de deux directives, inherit permisions et inherit acls, qui per-
mettent de transmettre aux fichiers les droits et les ACL présents sur un répertoire.

La gestion des droits avec Samba

80
Gestion avancée : la manipulation des partages
 On peut forcer le mode de création d’un fichier

Pour positionner d’office les droits des fichiers créés dans un partage donné, il faudra procéder en
plusieurs étapes. Tout d’abord, on va indiquer à Samba qu’on souhaite qu’il positionne nos droits
lors de la création d’un fichier. On utilise pour cela les directives :

force create mode = 0664

force directory mode = 0775

Ces directives ne suffisent pas, car Samba dispose d’un masque qu’il applique lors de la création
des fichiers et des répertoires. Ces masques sont explicitement repris dans la configuration de
Samba, mais effacer les lignes correspondantes ne suffit pas : ils ne sont que l’expression des
choix par défaut du serveur Samba. Pour explicitement supprimer les masques et obtenir nos
droits par défaut, on doit les positionner à une valeur nulle : aucun masque ne sera alors appliqué.
On pourra donc avoir :

create mask = 0000

directory mask = 0000

L’exécution de scripts

On peut vouloir faire exécuter par Samba des commandes avant et après chaque connexion de
l’utilisateur, notamment pour faire le ménage dans certains répertoires. Samba dispose de deux
instructions, root preexec et root postexec, qui associent un script qui sera exécuté avec
les droits de root avant et après chaque connexion de l’utlisateur. On devra préciser le chemin
complet du script à exécuter.

Samba dispose de bien d’autres options, mais l’on couvre avec ces quelques modifications les
besoins de modification les plus courants.
Reproduction interdite.

La gestion des droits avec Samba

81
Gestion avancée : la manipulation des partages
 Conception et réalisation
MSSC Éditions Pédagogiques
1a rue Pasteur,
67540 Ostwald