La page du petit FreeBSD

Précédent Suivant

2. Projet d'interface de
configuration unifiée
L'idée de ce projet est de remplacer l'approche de configuration
actuelle, à base de procédures, et de donner la possibilité de modifier le
comportement du système via une hiérarchie bien définie de
paramètres. L'un des objectifs est aussi de fournir un modèle orienté
objet de la gestion et de la structure du système d'exploitation au lieu
du modèle procédural actuel (et inconsistant) système/service
démarrage/arrêt.
Ce projet implique entre autres de:
 Fournir une vision cohérente du système et de ses sous-
systèmes fonctionnels comme un ensemble d'objets reliés
entre eux et possédant certaines propriétés.
 Fournir une approche globale de l'interface utilisateur,
soit en ligne de commande, soit graphique.
 Gérer les ressources système et les sous-systèmes. Cela
inclut de gérer les interdépendances statiques et
dynamiques entre les sous-systèmes et la possibilité
d'augmenter/diminuer les capacités des sous-systèmes à
la volée.
C'est un travail en cours. - Je suis conscient que des parties y
sont manquantes ou mal placées. Adressez-moi s'il vous plaît
vos commentaires et les modifications qui vous paraissent
utiles, soit directement, ou mieux à la liste de diffusion pour les
systèmes FreeBSD embarqués <freebsd-small@FreeBSD.ORG>.
Toute personne qui peut m'aider à la conception et à
l'implémentation est la bienvenue.

2.1. Interface de configuration unifiée

 Commençons par définir les termes suivants:
o Base de gestion - la structure
contenant les données de
configuration et d'autres
informations sous une forme
définie. Ce sera très probablement
un arbre (avec d'éventuels liens
entre branches ou d'autres
mécanismes pour représenter les
interdépendances) - la façon de la
stocker reste à discuter.
 o Interface utilisateur - la méthode
(ou agent) de présentation des
données de la base de gestion de
sorte qu'elles puissent être
consultées et modifiées par les
utilisateurs autorisés.
o Moniteur système - le processus
effectuant les tâches de
configuration et de contrôle,
interagissant d'une part avec la base
de gestion et d'autre part avec les
ressources système et les sous-
systèmes, et aussi directement avec
l'utilisateur (servant ainsi d'interface
utilisateur), ou transmettant des
requêtes à un autre processus
agissant comme interface
utilisateur.
o Sous-système - un ``paquetage''
comprenant des programmes, des
informations de configuration, et de
quoi installer, désinstaller, démarrer
et arrêter, formant un ensemble
fournissant un service particulier
pour le compte du système. Chaque
sous-système est vu comme un
objet ayant des propriétés
particulières, susceptible de générer
des événements, répondre à des
requêtes générales communes à
tous les sous-systèmes, et fournir
des services particuliers aux autres
sous-systèmes.
 Une des approches possibles pour enregistrer
l'information de gestion est d'utiliser le cadre déjà
existant connu sous le nom de MIB, tel que défini
pas les RFCs applicables.
Cette approche a plusieurs avantages: c'est le
travail mûrement réfléchi de nombreuses
personnes et équipes expérimentées, elle a déjà
prouvé son utilité, elle est largement acceptée et
utilisée, elle est facilement extensible, elle peut
représenter des objets assez compliqués, etc.
Elle a aussi ses limites: e.g., il n'y a pas de
mécanisme standard de représentation des
événements et des objets indirectement liés entre
eux, elle tend à engendrer des arbres profonds et
étroits qui impliquent de parcourir plusieurs
niveaux pour modifier des paramètres d'usage
courant, elle ne dit rien des dépendances
mutuelles entre objets et paramètres (sauf pour
les relations père-fils-frère) et des séquences de
définition requises pour ces paramètres, etc.
Ces problèmes ne sont pas directement abordés
par les standards, et les implémentations
effectives (celles que je connais) doivent ajouter
ces mécanismes ``en coulisse'', de sorte que leur
fonctionnement n'est ni trivial ni facilement
accessible (et encore moins modifiable).
Si donc c'est ce que nous décidons d'utiliser, nous
devrons résoudre d'une façon ou d'une autre ces
questions. Le point suivant présente une approche
possible de ce dilemme.
Dans ce qui suit, le terme ``objet'' représente un
sous-système fonctionnel, un service système par
exemple, généralement fourni par un processus
spécifique (ou, un jeu de paramètres système
globaux, auquel cas le moniteur système est le
service lui-même).
Chaque objet de la base de gestion peut être
représenté par les propriétés suivantes:
o Son état interne, constitué
probablement de plusieurs
paramètres et des fonctions
actuellement actives, mais
représenté, pour le reste du
système, par un jeu de variables
d'état commun à tous les objets.
o Un espace temporaire pour de
nouvelles valeurs des paramètres,
qui sont fournies par les autres
sous-systèmes, où elles attendent
d'être prises en compte.
o Définitions de l'automate d'états
finis, décrivant les changements
d'état en fonction des événements
reçus.
o Liste des événements qu'il peut
envoyer et recevoir.
o Liste des dépendances vis-à-vis de
l'état et des services d'autres objets.
o Liste des requêtes qu'il peut traiter.
 o Liste des paramètres qu'il peut
accepter ou fournir et de leurs
plages de valeurs.
Quelques mots à propos du démarrage: les
programmes de démarrage doivent
vérifier que les dépendances peuvent être
exprimées linéairement, sous forme de
liste ordonnée. Si ce n'est pas possible, ils
doivent détecter à l'exécution les
éventuels interblocages et agir comme
arbitres entre les différentes parties (ou
signaler l'erreur). En cas de dépendance
non satisfaite vis-à-vis d'un sous-système
manquant, le moniteur système agira de
façon appropriée comme décrit plus bas
(au paragraphe sur le traitement des
requêtes).
L'ensemble d'états symboliques peut
comprendre les états suivants, définissant
l'état interne actuel de l'objet (tel que
décrit par l'automate d'états finis):

Nom Signification
INIT Le sous-système s'initialise, chargeant
éventuellement les données et binaires
nécessaires depuis un support permanent.
CHECK Tests de cohérence de nouvelles valeurs de
paramètres fournies.
READY Prêt à exécuter sa fonction principale, mais
non encore actif.
START Tâches de démarrage (liées à sa fonction
principale par opposition à INIT qui se
rapporte à son initialisation).
RUN Phase principale (actif).
IDLE En attente d'événement extérieur.
BUSY Le sous-système est occupé (soit à une
tâche de haute priorité, soit simplement
bloqué) et ne peut être interrompu sauf par
un redémarrage complet.
ERROR L'objet est mal configuré ou présente des
dysfonctionnements.
(autre ...) (autre ...)

L'ensemble des actions possibles peut

comprendre les actions suivantes:
Nom Signification
LIST_EV_REQ Obtenir la liste des
événements que peut générer
le sous-système.
LIST_ACT_REQ Obtenir les listes des actions
auxquelles peut répondre le
sous-système.
GET_DEF_REQ Obtenir la définition d'un
paramètre donné (les
arguments, la plage de
valeur).
SET_REQ Affecter une valeur à un
paramètre donné (cette valeur
ne pourra être utilisée
qu'après un COMMIT_REQ).
GET_REQ Obtenir la valeur actuelle
d'un paramètre donné.
COMMIT_REQ Rendre effectives les
modifications des paramètres
courants définies par la
dernière transaction.
ROLLBACK_REQ Annuler le dernier
COMMIT_REQ (revenir à
l'état antérieur).
INIT_REQ Effectuer les tâches
d'initialisation.
START_REQ Commencer à effectuer sa
fonction principale.
STOP_REQ Arrêter l'exécution de sa
fonction principale.
RESTART_REQ Redémarrage, éventuellement
forcé.
NOTIFY_REQ Me prévenir de tout
changement de votre état.
UPGRADE_REQ Mise à jour du sous-
système - cela peut inclure
télécharger ce qu'il faut du
réseau vers un espace de
stockage permanent. Le
processus de mise à jour
devra être transactionnel, et
sauvegarder la version
précédente en cas de
DOWNGRADE_REQ.
DOWNGRADE_REQ Retour à la version antérieure
Nom Signification
sauvegardée du sous-système.
UNINSTALL_REQ Désinstallation complète du
sous-système - libérant
éventuellement l'espace de
stockage permanent occupé.
(autre ...) (autre ...)

(Chaque requête inclut l'identification de

son origine et les habilitations de
l'émetteur.)
L'ensemble des événements que peuvent
générer les sous-systèmes peut inclure ce
qui suit:

Nom Signification
EV_ACK Acquittement de la dernière
opération.
EV_NACK Non-acquittement de la dernière
opération.
EV_CHANGE Notification de modification
(comprenant le nom du paramètre
modifié et/ou le changement d'état de
l'automate).
EV_DEP Signale la dépendance vis-à-vis d'un
autre sous-système - demande si le
service existe. Il devra probablement
y avoir deux types de dépendances:
souple (le sous-système peut toujours
fonctionner même si la dépendance
n'est pas résolue) et stricte
(l'existence et le fonctionnement
correct de l'autre sous-système sont
nécessaires à la fonction).
(autre ...) (autre ...)

L'un des attributs d'un événement peut

être un indicateur précisant si cet
événement a un destinataire unique ou est
diffusé. Dans le cas d'une destination
précise, il ne devra être transmis qu'à
celle-ci. Les événements diffusés sont
transmis à tous les sous-systèmes.
Le moniteur système traitera ces
événements et les transmettra aux sous-
systèmes enregistrés appropriés. D'une
façon générale, si un sous-système dépend
 d'un autre, il recevra tous les événements
émis par cet autre sous-système.
Au cas où un sous-système manque, et où
le moniteur système reçoit des
événements signalant la dépendance d'un
autre sous-système vis-à-vis du premier,
le moniteur devra soit installer les
composants nécessaires (depuis l'espace
de stockage permanent ou le réseau), soit
envoyer un EV_NACK au second sous-
système. Il est du ressort de ce dernier de
gérer cette situation en fonction du type
de dépendance (i.e. ``souple'' ou
``stricte'').
Dans l'idéal, le moniteur système
disposera des sous-programmes
nécessaires à la présentation des données
de gestion sous forme lisible, de sorte
qu'elles soient facilement archivées,
sauvegardées et restaurées en cas
d'incohérence.
 Les interfaces utilisateur sont encore aujourd'hui
une autre histoire: j'en ai vu qui suivaient
simplement les MIB standard, les menus se
composant de numéros OID (``Object Identifier'')
et d'un champ DESCRIPTION. Selon ma propre
expérience, elles sont (tout juste) acceptables,
parce que vue l'étendue et la profondeur des
arbres MIB habituels, il faut descendre et
remonter plusieurs niveaux pour modifier des
paramètres interdépendants (d'après le protocole).
Une interface utilisateur plus acceptable
rassemblerait les données dépendantes dans des
entrées de menu communes, sans se préoccuper
de leur situation dans l'arbre MIB.
Un objectif valable serait de créer une telle
interface utilisateur, qui puisse vous guider dans
les tâches de configuration les plus courantes,
tout en laissant la possibilité d'une utilisation
rapide et sans contrainte aux utilisateurs
confirmés. Cela peut être réalisé par des
``assistants'' de configuration, ou une utilisation
intensive de propositions anticipées, ou des
raccourcis pour les commandes avec auto-
complétion, etc.
 La base de gestion devra être facilement
exportable via des protocoles standard, tels que
SNMP ou LDAP.
La plupart des implémentations que je connaisse
(sinon toutes) d'agents pour ces protocoles sont
(contrairement à leur nom) assez lourdes - leur
utilisation devra donc être optionnelle, ou
remplacée par un autre protocole léger ou un
agent mandataire s'exécutant sur une autre
machine. Un exemple d'un tel agent mandataire
est l'implémentation existante de UCD-SNMP qui
suit en grande partie l'arborescence de sysctl(3),
l'exportant simplement comme partie des
arborescences MIB.
Il peut aussi valoir la peine d'envisager d'utiliser
d'autres protocoles comme DHCP (et BOOTP) ou
le Service Location Protocol - ``protocole de
localisation de service'' - (SLP - RFC 2165) pour
une intégration facile aux ressources du réseau
local, une configuration initiale aisée et la
localisation des interlocuteurs.
Toutes les opérations effectuées par le moniteur
système devront être transactionnelles, i.e. il
devra être possible de soumettre un ensemble de
modifications en un seule entité logique et de
s'assurer qu'elles soient toutes appliquées ou pas
du tout. Cela inclut aussi la possibilité
d'interrompre le processus pendant son
déroulement.
Cela signifie probablement que chaque objet
(sous-système) doit mémoriser non seulement sa
configuration courante, mais aussi la nouvelle
configuration transmise telle qu'elle sera
appliquée si la transaction réussit.
Il devra y avoir contrôle de validité des valeurs et
des autorisations, sur la base duquel les
opérations seront soit soumises, soit refusées.
 Quelques notes sur les implémentations possibles
d'un moniteur système:
o Supposons que toutes les
informations de configuration
soient lues au démarrage par un
``démon'' spécialisé (ce pourrait être
aussi une partie de init(8)), qui
serve ensuite d'agent de
communication pour toutes les
informations de configuration, que
 ce soit des demandes de
modification, de démarrage ou
d'arrêt, ou des notifications de
modification.
o L'information de configuration est
enregistrée soit dans une base de
données binaires, soit dans une
hiérarchie de répertoires
reproduisant la hiérarchie des
éléments de la configuration.
Chaque programme de niveau
utilisateur responsable d'une tâche
(comme le ``démon'' de routage,
inetd, etc.), soit a la possibilité de
communiquer avec l'agent de
configuration, soit est recompilé
pour y inclure des mécanismes qui
se substituent aux fichiers de
configuration et événements (tels
les signaux de relecture de la
configuration) nécessaires.
Cela signifie probablement que
certains sous-programmes de la libc
devront être remplacés, parce qu'ils
supposent que la configuration est
lue dans des fichiers disque donnés.
Etant donné que chaque sous-
système de ce type doit
implémenter certaines opérations
communes à tous, comme installer,
désinstaller, démarrer, arrêter, etc.,
nous pourrions utiliser le système
des ``paquetages'' existant (avec
quelques modifications mineures)
pour atteindre facilement une partie
des objectifs (i.e.
installer/désinstaller/mettre à
jour/annuler une mise à
jour/arrêter/démarrer).
o Chaque sous-système obtient du
moniteur système ses informations
de configuration initiales, et
s'enregistre auprès de ce dernier de
façon à recevoir les événements de
configuration, tels que les
demandes de relecture, à fournir les
données de configuration effectives,
 les codes retour, à réagir aux
signaux, redémarrages, etc.
o Le moniteur système agit comme
point de rencontre pour tous les
producteurs et consommateurs
d'événements et de données de
configuration. Il doit maintenir une
table des sous-systèmes enregistrés,
des événements qu'ils peuvent
émettre, des événements qu'ils
souhaitent recevoir, etc. Il transmet,
en se basant sur cette table, les
informations voulues aux sous-
systèmes appropriés.
o L'interface utilisateur n'est qu'un
des clients du moniteur système,
bien que disposant de privilèges
particuliers.
o Une des fonctions importantes du
moniteur système, lorsqu'un objet
(sous-système) s'enregistre pour
recevoir certains événements, est de
s'assurer que ces événements
peuvent être générés. Cela pour
éviter que des sous-systèmes
attendent des événements qui
viennent d'autres sous-systèmes
manquants. Voyez plus haut ce qui
a été dit des dépendances mutuelles.
Note : C'est une approche
possible - centralisée. Il vaut la peine
d'envisager une autre approche,
distribuée, dans laquelle chaque objet
(sous-système) envoie et reçoit des
informations de points de rencontre
propres à chaque autre objet. Cela
élimine (ou réduit considérablement) le
rôle du moniteur système qui est l'unique
maillon faible de l'architecture
centralisée.

2.2.
Voici ma première proposition de hiérarchie pour l'interface
utilisateur:
 Configuration système
1. Périphérique et fichier de
démarrage
Nom du périphérique de démarrage
(éventuellement réseau) et du noyau
a. (Enumération des
périphériques
disponibles)
i. (Enumé
ration
des
fichiers
disponi
bles)
2. Fichier de configuration
Gestion du fichier de
configuration - chargement et
sauvegarde, local ou éloigné (si
applicable).
a. Charger / enregistrer
i. Source /
destinati
on
(Enumé
ration
des
espaces
de
stockag
e,
éventuel
lement
sur le
réseau)
b. Edition directe (mode
expert)
3. Sous-systèmes
a. Gestion des modules
Gestion des pilotes
matériel optionnels et
protocoles
i. (Enumé
ration
des
 modules
chargés
dynami
quemen
t
disponi
bles)
A. C
h
a
r
g
e
r

d
é
c
h
a
r
g
e
r

é
t
a
t
b. Gestion des
``paquetages''
Gestion des services
système de base et
optionnels
i. (Enumé
ration
des
``paquet
ages''
localem
ent
disponi
bles)
 A. D
é
m
a
r
r
e
r

a
r
r
ê
t
e
r

é
t
a
t

c
o
n
f
i
g
u
r
e
r
c. Source par défaut
pour les ``paquetages''
des services
Où récupérer
automatiquement les
``paquetages''
manquants
i. (Enumé
ration
des
supports
 disponi
bles)
(Disque
s locaux
ou sur
le
réseau,
ftp,
http)
4. Gestion des ressources
a. Occupation mémoire
Cette entrée pointe
sur un sous-arbre, qui
permet de définir
diverses limites de
ressources pour les
sous-systèmes, les
services et les
processus
b. Occupation de
l'espace de stockage
(Des choses comme
l'espace libre
minimum sur les
périphériques de
stockage permanent)
c. Priorités des tâches
Cela n'inclut pas que
les tâches actives,
mais aussi celles qui
pourraient être
démarrées
i. Lister /
modifie
r
5. Console système
6. Console virtuelle (si applicable)
7. Date système / fuseau horaire
8. Bannière
9. Ouverture de session
a. Session locale
b. Session à distance
 Configuration réseau
1. Nom de machine et domaine
2. Interfaces
a. (Enumération des
interfaces physiques)
(Enumération des
interfaces virtuelles,
si applicable)
(Options de création
des interfaces
virtuelles, si
applicable)
i. Options
de
l'interfa
ce
(vitesse,
dispositi
f,
encapsu
lation,
descript
ion,
etc.)
ii. ARP
iii. Pont
iv. IP
A. A
d
r
e
s
s
e

m
a
s
q
u
e

d
 e

r
é
s
e
a
u

a
l
i
a
s
v. IPX
vi. AppleT
alk
3. Options de protocole
a. IP, UDP, TCP, ARP,
IPX, ATM...
(Enumération des
protocoles
disponibles)
i. (Enumé
ration
des
options
propres
aux
protocol
es,
tailles
des
tampons
,
algorith
mes,
tables
ARP,
etc.)
A. L
i
s
t
e
r

a
j
o
u
t
e
r

s
u
p
p
r
i
m
e
r

m
o
d
i
f
i
e
r

d
é
f
i
n
i
r

(
s
i

a
 p
p
l
i
c
a
b
l
e
)
4. Routes
a. Liste
b. Statiques
i. Ajouter
/
supprim
er /
lister
A. (
d
é
f
i
n
i
t
i
o
n

d
e

r
o
u
t
e
)
c. Dynamiques
i. (Enumé
ration
des
protocol
es de
routage
dynami
 que
disponi
bles)
A. A
j
o
u
t
e
r

s
u
p
p
r
i
m
e
r

l
i
s
t
e
r
I. (
d
éf
in
it
io
n
d
e
r
o
ut
e)
5. Services réseau
a. DNS
i. Hôtes
 A. A
j
o
u
t
e
r

s
u
p
p
r
i
m
e
r

l
i
s
t
e
r
I. (
D
éf
in
it
io
n
s
d'
h
ôt
e
s)
ii. Solveur
s
A. A
j
o
u
t
e
 r

s
u
p
p
r
i
m
e
r

l
i
s
t
e
r
I. (
A
d
re
ss
e
s
d'
h
ôt
e
s)
iii. Configu
ration
du
serveur
DNS
local
b. PPP
i. Serveur
ii. Client
c. NFS
i. Serveur
ii. Client
d. NIS
e. DHCP
i. Ajouter
/
supprim
er /
réserver
/ lister
A. (
D
é
f
i
n
i
t
i
o
n
s

d
'
a
d
r
e
s
s
e
s

I
P
)
f. SNMP
i. Version
de
protocol
e
ii. Envoyer
les
signaux 
- trap - 
à ...
 iii. Liste de
contrôle
d'accès
(C'est
soit le
système
complet
de liste
de
contrôle
d'accès
dans le
cas de
SNMPv
2, soit la
chaîne
de
caractèr
es
définiss
ant la
commu
nauté
avec
SNMPv
1)
g. Impression
i. Locale /
à
distance
A. I
m
p
r
i
m
a
n
t
e
s
I. A
jo
ut
er
/
m
o
 di
fi
er
/
s
u
p
p
ri
m
er
/
li
st
er
B. F
i
l
e
s

d
'
a
t
t
e
n
t
e
I. P
ri
o
ri
té
/
s
u
p
p
ri
m
er
/
li
st
er
h. Services SMB
 i. Traduction d'adresses
réseau (NAT)
j. Filtres de paquets
k. Gestionnaire de bande
passante
l. NTP
m. Accès distant
 Gestion des utilisateurs
1. Comptes utilisateur
a. Ajouter / supprimer /
modifier / lister
i. Nom /
mot de
passe /
liste de
contrôle
d'accès
2. Profils utilisateur
a. Ajouter / supprimer /
modifier / lister
i. Nom /
prototyp
e/
définitio
n
A. N
o
m
I. L
is
te
d
e
re
st
ri
ct
io
n
s
d
e
c
 o
m
m
a
n
d
e
s
II. L
is
te
d
e
re
st
ri
ct
io
n
s
d'
a
c
c
è
s
III. L
is
te
d
e
re
st
ri
ct
io
n
s
d
e
re
ss
o
u
rc
e
s
IV. L
is
 te
d
e
re
st
ri
ct
io
n
s
d
e
te
m
p
s
C
P
U
V. M
ét
h
o
d
e
d'
a
ut
h
e
nt
if
ic
at
io
n
1. Mots de pas
Unix
2. S/Key
3. Kerberos
4. Radius
5. TACACS
 Autres services
1. Tâches ``cron''
 Systèmes de fichiers
 1. Local / à distance
a. (Enumération des
systèmes de fichiers
disponibles)
i. Système
s de
fichiers
/ point
de
montag
e/
options
b. Partition de
pagination / fichier de
pagination
i. Créer /
mettre
en
service
 Environnement
1. Définir / supprimer / lister
 Etat du système
1. (Enumération des variables d'état)
 Diagnostics
1. Débogage
a. (Enumération des
sous-systèmes de la
hiérarchie qui peuvent
fournir des
informations de
débogage)
i. Définir /
réinitiali
ser /
niveau
2. Messages système
3. ping / traceroute / rtquery
Adressez s'il vous plaît vos commentaires à Andrzej
Bialecki <abial@freebsd.org>.

Précédent Sommaire Suivant

La page du petit FreeBSD   TinyWare - Logiciels de taille
réduite
This, and other documents, can be downloaded from
ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
For questions about FreeBSD, read the documentation before contacting
<questions@FreeBSD.org>.
For questions about this documentation, e-mail <doc@FreeBSD.org>.