schroot.conf est un fichier texte codé en
UTF-8, décrivant les chroots utilisables avec schroot.
Les commentaires sont préfixés par un
caractère ‘#’
(“hash”) au début d'une ligne ou à la suite de
n'importe quel texte. Tout texte à la droite de
‘#’ est traité comme un
commentaire.
Le format de configuration est de type INI, découpé
en groupes de paires clé-valeur séparés par des noms de
section entre crochets.
Un chroot est défini comme un groupe de paires
clé-valeur qui débute par un nom entre crochets, seul sur une
ligne. Le fichier peut contenir plusieurs groupes définissant ainsi
plusieurs chroots.
La définition du chroot débute par son nom entre
crochets. Par exemple,
- [sid]
Le nom est sujet à certaines restrictions de
dénomination. Pour plus de détails, consultez la section
“Nom de Chroot” ci-dessous.
S'ensuivent plusieurs paires clé-valeur, une par
ligne :
- type=type
- The type of the chroot. Valid types are ‘plain’,
‘directory’, ‘file’, ‘loopback’,
‘block-device’, ‘btrfs-snapshot’,
‘zfs-snapshot’ and ‘lvm-snapshot’. If empty or
omitted, the default type is ‘plain’. Note that
‘plain’ chroots do not run setup scripts and mount
filesystems; ‘directory’ is recommended for normal use (see
“Plain and directory chroots”, below).
- description=description
- Une description courte du chroot. Elle peut être traduite en
différentes langues ; consultez la section
“Localisation” ci-dessous.
- priority=nombre
- Définir la priorité d'un chroot.
nombre est un entier positif indiquant si
une distribution est plus ancienne qu'une autre. Par exemple,
“oldstable” et “oldstable-security” peuvent
être ‘0’ alors que “stable” et
“stable-security” sont ‘1’,
“testing” est ‘2’ et “unstable”
est ‘3’. Les valeurs ne sont pas importantes, mais les
différences entre elles le sont. Cette option est
déconseillée et n'est plus utilisée par schroot, mais
il est encore permis de l'utiliser, elle deviendra obsolète et sera
retirée dans une prochaine version.
- message-verbosity=verbosité
- Définir la verbosité des messages affichés par
schroot lors de la mise en place, de l'exécution des commandes et
du nettoyage du chroot. Les paramètres valables sont
‘quiet’ (supprime la plupart des messages),
‘normal’ (par défaut) et ‘verbose’
(affiche tous les messages). Ce paramètre est écrasé
par les options --quiet et --verbose.
- users=utilisateur1,utilisateur2,…
- Une liste séparée par des virgules des utilisateurs qui sont
autorisés à accéder au chroot. Si vide ou omis, aucun
utilisateur ne sera autorisé à accéder au chroot
(sauf s'il appartient à un groupe spécifié dans
groups).
- groups=groupe1,groupe2,...
- Une liste séparée par des virgules des groupes qui sont
autorisés à accéder au chroot. Si vide ou omis, aucun
groupe d'utilisateurs ne sera autorisé à accéder au
chroot.
- root-users=utilisateur1,utilisateur2,...
- Une liste séparée par des virgules des utilisateurs qui sont
autorisés à devenir root dans le chroot sans mot de
passe. Si vide ou omis, aucun utilisateur ne sera autorisé
à devenir root sans mot de passe (mais si un utilisateur ou un
groupe auquel il appartient est dans users
ou groups, respectivement, il peut obtenir
un accès avec un mot de passe). Consultez la section
“Sécurité” ci-dessous.
- root-groups=groupe1,groupe2,...
- Une liste séparée par des virgules des groupes qui sont
autorisés à devenir root dans le chroot sans mot de
passe. Si vide ou omis, aucun utilisateur ne sera autorisé
à devenir root sans mot de passe (mais si un utilisateur ou un
groupe auquel il appartient est dans users
ou groups, respectivement, il peut obtenir
un accès avec un mot de passe). Consultez la section
“Sécurité” ci-dessous.
- aliases=alias1,alias2,...
- Une liste séparée par des virgules des alias (noms
alternatifs) pour ce chroot. Par exemple, un chroot, nommé
“sid”, peut avoir un alias ‘unstable’ pour des
raisons de commodité. Les alias sont sujets aux mêmes
restrictions que le nom du chroot lui-même.
- profile=répertoire
- script-config=nom-de-fichier
- Le comportement des scripts de mise en place des chroots peut être
personnalisé pour chaque chroot en définissant un profil de
configuration spécifique. Le nom du répertoire est relatif
à /etc/schroot. Le nom par défaut est
‘default’. Les fichiers de ce répertoire seront
recherchés par les scripts de mise en place dont le comportement
peut par conséquent être personnalisé en
sélectionnant le profil approprié. Les alternatives sont
‘minimal’ (pour une configuration minimale),
‘desktop’ (pour exécuter des programmes graphiques
dans un chroot, autorisant plus de fonctionnalités du
système hôte disponible dans le chroot) et
‘sbuild’ (pour utiliser le chroot pour la construction de
paquet Debian). D'autres paquets peuvent fournir des profils
supplémentaires. La valeur par défaut des clés
setup.config,
setup.copyfiles,
setup.fstab et
setup.nssdatabases est définie en
fonction de la configuration de
profile.
- Notez que la clé profile remplace
l'ancienne clé script-config. La
clé script-config est exactement la
même que profile, mais
“/config” y est ajoutée. Le nom de fichier par
défaut est ‘default/config’. Chacune de ces deux
clés peuvent être utilisées.
script-config sera prioritaire
(profile sera indéfini).
script-config est
déconseillée et sera retirée dans une prochaine
version. Notez que profile est
équivalent à script-config si
le fichier recherché par
script-config ne contient que les variables
standard fournies par schroot. Si des variables supplémentaires ou
des scripts shell sont ajoutés, veuillez également
définir setup.config qui permettra
à ces fichiers d'être toujours recherchés. Il est
recommandé de remplacer l'utilisation de fichiers recherchés
par des clés supplémentaires dans schroot.conf quand cela
est possible. Il sera toujours possible de rechercher des fichiers de
configuration supplémentaires en utilisant
setup.config.
- À noter pour les utilisateurs graphiques que le fichier fstab
desktop/fstab aura besoin d'une modification si vous utilisez
gdm3 ; veuillez consulter les commentaires dans ce fichier pour
plus d'information. La clé
preserve-environment doit être
définie à ‘true’ pour que l'environnement soit
préservé dans le chroot.
- Si aucun des profils de configuration fournis ci-dessus ne convient
à vos besoins, ils peuvent être édités pour
les personnaliser davantage et/ou copiés et utilisés en tant
que modèles pour de tous nouveaux profils.
- Notez que les différents profils ont des implications de
sécurité différentes ; consultez la section
“Sécurité” ci-dessous pour plus
d'informations.
- setup.config=nom-de-fichier
- Cette clé spécifie un fichier que les scripts de mise en
place vont rechercher quand ils seront exécutés. La valeur
par défaut est celle définie par
script-config. Le fichier est un script de
type Bourne shell, et par conséquent peut contenir tout code shell
valable, en plus des simples affectations de variable. Cela permet, par
exemple, d'adapter les comportements en fonction d'un type
spécifique ou nom de chroot. Notez que le script sera chargé
à chaque invocation des scripts de mise en place et doit
être idempotent.
- Toutes les configurations par défaut dans le fichier sont
maintenant définissables en utilisant les clés de
configuration dans schroot.conf, comme détaillé
ci-dessous. Les configurations existantes devront être
modifiées pour utiliser ces clés à la place de ce
fichier. Consultez schroot-script-config(5) pour plus de
détails. Ce type de fichier de configuration de script de mise en
place n'est plus fourni dans les profils standard, mais continuera
à être recherché s'il est présent et que cette
clé est définie.
- setup.copyfiles=nom-de-fichier
- Un fichier contenant une liste de fichiers à copier dans le chroot
(un fichier par ligne). Le fichier aura le même chemin absolu dans
le chroot.
- setup.fstab=nom-de-fichier
- Le fichier de la table des systèmes de fichiers à utiliser
pour monter les systèmes de fichiers dans le chroot. Le format de
ce fichier est le même que pour /etc/fstab, documenté
dans fstab(5). La seule différence est que le chemin du
point de montage fs_dir est relatif au chroot plutôt
qu'à la racine. Notez également que les points de montage
sont canonisés sur l'hôte, ce qui permet de s'assurer que
les liens symboliques absolus pointent à l'intérieur du
chroot. Cependant, les chemins complexes contenant des liens symboliques
multiples peuvent être incorrectement résolus. Il est
déconseillé d'utiliser les liens symboliques
imbriqués comme points de montage.
- setup.nssdatabases=nom-de-fichier
- Un fichier listant les bases de données du système à
copier dans le chroot. Les bases de données par défaut sont
‘passwd’, ‘shadow’, ‘group’ et
‘gshadow’. Les autres bases de données qui pourraient
être ajoutées incluent ‘services’,
‘protocols’, ‘networks’ et
‘hosts’. Les bases de données sont copiées en
utilisant getent(1) pour que toutes les sources de bases de
données listées dans /etc/nsswitch.conf soient
utilisées pour chaque base de données.
- setup.services=service1,service2,…
- Une liste des services à exécuter dans le chroot
séparés par des virgules. Ceux-ci seront
démarrés quand la session démarrera et
arrêtés quand la session se terminera.
- command-prefix=commande,option1,option2,...
- Une liste séparée par des virgules d'une commande et des
options de la commande. Cette commande et ses options seront
préfixées à toutes les commandes
exécutées dans le chroot. C'est utile pour ajouter des
commandes comme nice, ionice ou eatmydata pour toutes les commandes
exécutées dans le chroot. nice et ionice affecteront
l'ordonnancement CPU et I/O. eatmydata ignore les opérations fsync
sur le système de fichiers et est utile pour les chroots
d'instantané jetable où vous ne vous souciez pas des pertes
de données, mais désirez une grande vitesse.
- personality=persona
- Définir les personnalités (domaine d'exécution des
processus) à utiliser. Cette option est utile par exemple lors de
l'utilisation d'un chroot 32 bits sur un système
64 bits. Les options valables sous Linux sont ‘bsd’,
‘hpux’, ‘irix32’, ‘irix64’,
‘irixn32’, ‘iscr4’, ‘linux’,
‘linux32’, ‘linux_32bit’,
‘osf4’, ‘osr5’, ‘riscos’,
‘scorvr3’, ‘solaris’, ‘sunos’,
‘svr4’, ‘uw7’, ‘wysev386’ et
‘xenix’. La valeur par défaut est
‘linux’. Il y a aussi l'option spéciale
‘undefined’ (personnalité non définie). Pour
un chroot 32 bits sur un système 64 bits,
‘linux32’ est l'option requise. La seule option valable pour
les systèmes non Linux est ‘undefined’. La valeur par
défaut pour les systèmes non Linux est
‘undefined’.
- preserve-environment=true|false
- Par défaut, l'environnement ne sera pas préservé
à l'intérieur du chroot. À la place, un environnement
minimal sera utilisé. Définir à
true pour toujours préserver
l'environnement. C'est utile par exemple lors de l'exécution des
applications graphiques à l'intérieur du chroot qui ont
besoin de l'environnement pour fonctionner correctement. L'environnement
peut également être préservé en utilisant
l'option --preserve-environment.
- shell=shell
- Lors de l'exécution d'un interpréteur de commande de
connexion plusieurs interpréteurs de commandes potentiels seront
considérés dans cet ordre : la commande dans la
variable d'environnement SHELL (si l'option --preserve-environment
est utilisée ou si
preserve-environment est activé),
l'interpréteur de commandes de l'utilisateur dans la base de
données ‘passwd’, /bin/bash et finalement
/bin/sh. Ce paramètre écrase cette liste et utilisera
l'interpréteur de commandes spécifié. Il peut
être écrasé en utilisant l'option
--shell.
- environment-filter=regex
- L'environnement à définir dans le chroot sera filtré
dans le but d'enlever les variables d'environnement qui peuvent poser un
problème de sécurité. Toute variable d'environnement
qui correspondrait à l'expression régulière POSIX
étendue spécifiée sera supprimée avant
l'exécution de toute commande dans le chroot.
- Les variables d'environnement potentiellement dangereuses sont
retirées par sécurité par défaut en utilisant
l'expression régulière suivante :
“^(BASH_ENV|CDPATH|ENV|HOSTALIASES|IFS|KRB5_CONFIG|KRBCONFDIR|KRBTKFILE|KRB_CONF|LD_.*|LOCALDOMAIN|NLSPATH|PATH_LOCALE|RES_OPTIONS|TERMINFO|TERMINFO_DIRS|TERMPATH)$”.
Chroots « plain » et
« directory »
Les chroots de type ‘plain’ ou
‘directory’ sont des répertoires accessibles dans le
système de fichiers. Les deux types sont équivalents à
l'exception du fait que les chroots
« directory » exécutent les scripts de
mise en place tandis que les chroots « plain »
non. Par conséquent, les systèmes de fichiers comme
/proc ne sont pas montés dans les chroots
« plain » ; c'est la
responsabilité de l'administrateur de configurer manuellement ces
types de chroot alors que les chroots
« directory » sont automatiquement
configurés. De plus, les chroots
« directory » implémentent les options
des chroots union de systèmes de fichiers (consultez
“Options des chroots union de systèmes de
fichiers ci-dessous).
Ces types de chroot ont une option de configuration
supplémentaire (requise) :
- directory=répertoire
- Le répertoire contenant l'environnement de chroot. C'est là
où la racine sera déplacée lors de l'exécution
d'un interpréteur de commande de connexion ou d'une commande. Le
répertoire doit exister et être accessible en lecture et
exécution pour autoriser les utilisateurs à y
accéder. Notez que sur les systèmes Linux il sera
monté autre part pour être utilisé comme
chroot ; le répertoire pour les chroots
‘plain’ est monté avec l'option --rbind pour
mount(8), alors que pour les chroots ‘directory’
l'option --bind sera utilisée à la place pour que les
sous-montages ne soient pas conservés (ils doivent être
définis dans le fichier fstab comme dans le fichier
/etc/fstab de l'hôte).
Chroots « file »
Les chroots de type ‘file’ sont des fichiers sur le
système de fichiers courant contenant une archive des fichiers du
chroot. Ils implémentent les options des chroot source
(consultez “Options des chroots source”,
ci-dessous). Notez qu'un chroot source correspondant (de type
‘file’) sera créé pour chaque chroot de ce
type ; c'est pour un accès commode à l'archive source,
par exemple dans le but de mettre à jour. Les options
supplémentaires suivantes sont aussi
implémentées :
- file=nom-de-fichier
- Le fichier contenant l'environnement de chroot archivé (requis).
Cela doit être une archive tar, facultativement compressée
par gzip, bzip2, xz, lzop ou lz4. Les extensions de fichier
utilisées pour déterminer le type sont .tar,
.tar.gz, .tar.bz2, .tar.xz, .tar.lzop,
.tar.lz4, .tgz, .tbz, .txz, .tzo et
.tlz4. Ce fichier doit appartenir à l'utilisateur root et
être non inscriptible par les autres. Notez que les archives zip ne
sont plus gérées ; zip n'était capable
d'archiver ni les tubes nommés (« named
pipes ») ni les nœuds de périphériques
(« device nodes ») et n'était donc pas
adéquat pour archiver des chroots.
- location=chemin
- C'est le chemin du chroot à l'intérieur de l'archive.
Par exemple, si l'archive contient un chroot dans /squeeze, vous
devriez spécifier ici “/squeeze”. Si le chroot est la
seule chose à l'intérieur de l'archive, c'est-à-dire
si / est la racine du système de fichiers pour le chroot,
cette option doit être laissée vide ou omise
complètement.
Les chroots de type ‘loopback’ sont des
systèmes de fichiers disponibles comme des fichiers sur le disque,
accessibles par un montage loopback. Le fichier sera monté en
loopback et démonté à la demande. Les chroots loopback
implémentent les options de chroot montable et de chroot
d'union de systèmes de fichiers (consultez “Options
de chroot montable” et “Options de chroot
d'union de systèmes de fichiers”, ci-dessous) et
une option supplémentaire :
- file=nom-de-fichier
- C'est le nom du fichier contenant le système de fichiers, incluant
le chemin absolu. Par exemple, “/srv/chroot/sid”.
Les chroots de type ‘block-device’ sont des
systèmes de fichiers disponibles sur un périphérique
bloc non monté. Le périphérique sera monté et
démonté à la demande. Les chroots
périphériques bloc implémentent les options chroot
montable et chroot d'union de systèmes fichiers (consultez
“Options des chroots montables” et “Options
des chroots d'union de systèmes de fichiers”
ci-dessous) et une option supplémentaire :
- device=périphérique
- C'est le nom du périphérique contenant le
périphérique bloc, incluant le chemin absolu. Par exemple,
“/dev/sda5”.
Chroots d'instantanés Btrfs
Les chroots de type ‘btrfs-snapshot’ sont des
instantanés Btrfs créés à partir d'un
sous-volume Btrfs existant sur un système de fichiers Btrfs
monté. Un instantané sera créé à partir
de ce sous-volume source à la demande au démarrage d'une
session et l'instantané sera monté. À la fin de la
session, l'instantané sera démonté et supprimé.
Ce type de chroot implémente les options de chroots source
(consultez “Options de chroots source”
ci-dessous). Notez qu'un chroot source correspondant (de type
‘directory’) sera créé pour chaque chroot de ce
type ; c'est pour un accès commode au volume source. Les
options supplémentaires suivantes sont également
implémentées :
- btrfs-source-subvolume=répertoire
- Le répertoire contenant le sous-volume source.
- btrfs-snapshot-directory=répertoire
- Le répertoire dans lequel les instantanés du sous-volume
ci-dessus seront enregistrés.
Chroots of type ‘zfs-snapshot’ are a ZFS clone
created from an existing ZFS dataset. A snapshot and clone will be created
from this source subvolume on demand at the start of a session, and then the
clone will be mounted. At the end of the session, the clone will be
unmounted and the clone and snapshot will be deleted. This chroot type
implements the source chroot options (see “Source chroot
options”, below). Note that a corresponding source chroot (of
type ‘directory’) will be created for each chroot of this
type; this is for convenient access to the source volume. These additional
options are also implemented:
- zfs-dataset=dataset_name
- Name of the ZFS source dataset to use.
- zfs-snapshot-options=snapshot_options
- Snapshot options. These are additional options to pass to zfs
snapshot.
Chroots d'instantanés LVM
Les chroots de type ‘lvm-snapshot’ sont des
systèmes de fichiers disponibles sur un volume logique LVM (LV). Un
instantané LV sera créé à partir de ce LV
à la demande, ce dernier sera ensuite monté. À la fin
de la session, l'instantané LV sera démonté et
supprimé.
Les chroots d'instantanés LVM implémentent les
options des chroots sources (consultez “Options des
chroots source” ci-dessous) et toutes les options des
‘périphériques bloc’. Notez qu'un chroot source
correspondant (de type ‘block-device’) sera créé
pour chaque chroot de ce type ; c'est pour un accès commode au
périphérique source. L'option supplémentaire suivante
est également implémentée :
- lvm-snapshot-options=options_d'instantanés
- Options d'instantanés. Ce sont les options supplémentaires
à passer à lvcreate(8). Par exemple, “-L
2g” pour créer des instantanés de 2 GiB.
Note : le nom du LV (-n), les options des
instantanés (-s) et le chemin original du LV ne devraient
pas être spécifiés ici ; ils sont
définis automatiquement par schroot.
Les chroots de type ‘custom’ sont des types de
chroot spéciaux, utilisés pour implémenter de nouveaux
types de chroot gérés par aucun des types de chroot ci-dessus.
Cela peut être utile pour implémenter et tester un nouveau
type de chroot sans besoin d'écrire de code C++. Cependant, vous
devrez écrire vos propre scripts de mise en place pour effectuer la
mise en place, car par défaut ce type de chroot ne fait pas grand
chose. Vous aurez aussi besoin d'ajouter des clés
personnalisées à votre définition de chroot pour
être utilisées dans le script de mise en place ;
à la différence de la configuration des types de chroot
ci-dessus, aucune validation des options ne sera faite à moins que
vous ne le fassiez vous-même dans votre script de mise en place
personnalisé. Les options supplémentaires suivantes sont
également implémentées :
- custom-session-cloneable=true|false
- Définir si les sessions peuvent être clonées en
utilisant ce chroot ou non (activé par défaut).
- custom-session-purgeable=true|false
- Définir si les sessions peuvent être purgées en
utilisant ce chroot ou non (désactivé par
défaut).
- custom-source-cloneable=true|false
- Définir si les chroots source peuvent être clonés en
utilisant ce chroot ou non (désactivé par
défaut).
Les chroots de type ‘btrfs-snapshot’,
‘file’ et ‘lvm-snapshot’ implémentent les
chroots source. De plus, les types de chroot avec la prise en charge de
l'union activée implémentent les chroots source (consultez
“Options des chroots union de systèmes de
fichiers” ci-dessous). Ce sont des chroots qui créent
automatiquement une copie d'eux-mêmes avant utilisation et qui sont
en général gérés par des sessions. Ces chroots
fournissent en plus un chroot supplémentaire dans l'espace de noms
source:, pour permettre un accès commode aux données
d'origine (non-imagées) et aider à la maintenance du chroot.
Par exemple pour un chroot nommé wheezy
(chroot:wheezy), un chroot source source:wheezy correspondant
sera créé. Pour des questions de compatibilité avec des
versions plus anciennes de schroot qui ne prennent pas en charge les espaces
de noms, un chroot de même nom avec le suffixe -source
ajouté sera créé en plus (par exemple
wheezy-source en continuant l'exemple ci-dessus). Notez que ces noms
pour compatibilité seront retirés dans schroot 1.5.0, et par
conséquent l'utilisation de l'espace de noms source: est
préféré à la place de l'utilisation de la forme
avec le suffixe -source. Consultez schroot(1) pour plus de
détails.
Ces chroots fournissent les options supplémentaires
suivantes :
- source-clone=true|false
- Définir si le chroot source doit être cloné
automatiquement (créé) pour ce chroot. La valeur par
défaut est true pour cloner
automatiquement, mais si besoin le clonage peut être
désactivé en la définissant à
false. Si le clonage est
désactivé, le chroot source sera inaccessible.
- source-users=utilisateur1,utilisateur2,...
- Une liste séparée par des virgules des utilisateurs qui sont
autorisés à accéder au chroot source. Si vide ou
omis, aucun utilisateur ne sera autorisé à accéder au
chroot. Cela deviendra l'option users dans
le chroot source.
- source-groups=groupe1,groupe2,...
- Une liste séparée par des virgules des groupes qui sont
autorisés à accéder au chroot source. Si vide ou
omis, aucun utilisateur ne sera autorisé à accéder au
chroot. Cela deviendra l'option groups dans
le chroot source.
- source-root-users=utilisateur1,utilisateur2,...
- Une liste séparée par des virgules des utilisateurs qui sont
autorisés à devenir root dans le chroot source sans mot
de passe. Si vide ou omis, aucun utilisateur ne sera autorisé
à devenir root sans mot de passe (mais si un utilisateur est dans
users, il peut obtenir un accès avec
un mot de passe). Cela deviendra l'option
root-users dans le chroot source. Consultez
la section “Sécurité” ci-dessous.
- source-root-groups=groupe1,groupe2,...
- Une liste séparée par des virgules des groupes qui sont
autorisés à devenir root dans le chroot source sans mot
de passe. Si vide ou omis, aucun utilisateur ne sera autorisé
à devenir root sans mot de passe (mais si un groupe auquel
appartient l'utilisateur est dans groups,
il peut obtenir cet accès avec un mot de passe). Cela deviendra
l'option root-groups dans le chroot source.
Consultez la section “Sécurité”
ci-dessous.
Les chroots de type ‘block-device’,
‘loopback’ et ‘lvm-snapshot’ implémentent
le montage de périphérique. Ce sont des chroots qui ont besoin
de monter un périphérique pour pouvoir accéder au
chroot. Ces chroot fournissent les options supplémentaires
suivantes :
- mount-options=options
- Les options de montage pour le périphérique bloc. Ce sont
des options supplémentaires à passer à
mount(8). Par exemple, “-o
atime,sync,user_xattr”.
- location=chemin
- C'est le chemin vers le chroot à l'intérieur du
système de fichiers sur le périphérique. Par exemple,
si le système de fichiers contient un chroot dans
/chroot/sid, vous spécifieriez ici
“/chroot/sid”. Si le chroot est la seule chose sur le
système de fichiers, c'est-à-dire que / est la racine
du système de fichiers pour le chroot, cette option doit
être laissée vide ou omise entièrement.
Les chroots de type ‘block-device’,
‘directory’ et ‘loopback’ permettent, lors de la
création d'une session utilisant les unions de systèmes de
fichiers, de superposer sur le système de fichiers d'origine un
répertoire séparé inscriptible. Le système de
fichiers d'origine est en lecture seule ; toute modification faite au
système de fichiers dans le dossier inscriptible superposé
laisse le système de fichiers d'origine inchangé. Une union
permet à plusieurs sessions d'accéder et faire des changements
simultanément sur un unique chroot, en gardant les changements de
manière privée à chaque session. Pour activer cette
caractéristique, définissez
union-type à n'importe quelle valeur
gérée. Dès lors, le chroot sera également un
chroot source, qui fournira des options supplémentaires
(consultez “Options des chroots source”
ci-dessus). Toutes les entrées sont optionnelles.
- union-type=type
- Définir le type d'union de systèmes de fichiers. Pour le
moment les systèmes de fichiers pris en charge sont
‘aufs’, ‘overlayfs’, ‘overlay’
(à partir de Linux 4.0+) et ‘unionfs’. La
valeur par défaut est ‘none’ qui désactive
cette caractéristique.
- union-mount-options=options
- Options de montage des unions de systèmes de fichiers
(configuration des branches), utilisées pour monter l'union de
systèmes de fichiers spécifiés avec
union-type. Cela remplacera la chaîne de caractères
complète “-o” pour les montages et autorise la
création d'unions de systèmes de fichiers complexes. Notez
que ‘aufs’, ‘overlayfs’ et
‘unionfs’ prennent en charge différentes options de
montage. Note : Il est possible d'utiliser les variables
“${CHROOT_UNION_OVERLAY_DIRECTORY}” et
“${CHROOT_UNION_UNDERLAY_DIRECTORY}” pour se
référer respectivement au répertoire de surcouche de
session inscriptible et au répertoire en lecture seule sous-jacent
qui forment l'union. Consultez schroot-setup(5) pour une liste
complète des variables.
- union-overlay-directory=répertoire
- Spécifier le répertoire où les répertoires de
la surcouche inscriptible pour la session seront créés. Par
défaut, il s'agit de
‘/var/lib/schroot/union/overlay’.
- union-underlay-directory=répertoire
- Spécifier le répertoire où les répertoires de
la sous-couche en lecture seule seront créés. Par
défaut, il s'agit de
‘/var/lib/schroot/union/underlay’.
En plus de la configuration des clés listées
ci-dessus, il est possible d'ajouter des clés personnalisées.
Ces clés seront utilisées pour ajouter des variables
d'environnement supplémentaires à l'environnement
d'exécution des scripts de mise en place. La seule restriction est
que le nom des clés doit contenir uniquement des caractères
alphanumériques ou des traits d'union, doit commencer par un
caractère de l'alphabet et contenir au moins un point.
C'est-à-dire qu'il doit correspondre à l'expression
régulière étendue
“^([a-z][a-z0-9]*\.)+[a-z][a-z0-9-]*$”.
Par exemple :
debian.apt-update=true
debian.distribution=unstable
Définira les variables d'environnement
suivantes :
DEBIAN_APT_UPDATE=true
DEBIAN_DISTRIBUTION=unstable
Notez que c'est une erreur d'utiliser différents noms de
clé définissant la même variable d'environnement en
mélangeant des points et des traits d'union.
Les clés de configuration personnalisées peuvent
également être modifiées lors de l'exécution en
utilisant l'option --option. Cependant, pour des raisons de
sécurité, seules les clés sélectionnées
peuvent être modifiées. Ces clés sont
spécifiées en utilisant les options suivantes :
- user-modifiable-keys=clé1,clé2,..
- Définir les clés que l'utilisateur peut modifier en
utilisant --option.
- root-modifiable-keys=clé1,clé2,..
- Définir les clés que le superutilisateur peut modifier en
utilisant --option. Notez que le superutilisateur peut utiliser les
clés définies dans
user-modifiable-keys en plus des
clés définies ici.
Quelques clés peuvent être traduites dans plusieurs
langues. C'est effectué en ajoutant le nom local entre crochets
après le nom de la clé. Par exemple :
description[en_GB]=Traduction anglaise britannique
Cela traduira la clé
description pour la locale en_GB.
description[fr]=Traduction française
Cela traduira la clé
description pour toutes les locales
françaises.