Préambule
Voici un HOW-TO rapide sur SIMPLE-CDD pour construire une ISO Debian personnalisée.
Simple-cdd est un outil de création de CD/DVD d’installation Debian, se basant sur debian-cd et preseed avec tout un ensemble de fonctionnalités. complémentaires.
NOTE: Pour tout support, faire un fil de discussion spécifique dans la catégorie Support Debian
Dans cette documentation, toutes commandes d’installation de paquets sont réalisées par root .
L’utilisation de la commande build-simple-cdd est réalisé dans le répertoire simple-cdd d’un utilisateur nommé (votre utilisateur).
root n’est pas nécessaire pour créer un CD/DVD avec simple-cdd.
Introduction
Simple-cdd est un outil utilisé pour créer un disque DebianInstaller fait sur mesure. C’est une enveloppe autour de debian-cd et des outils de création de miroir pour créer une image sur CD DebianInstaller.
Il prend une liste de paquets à installer, et utilise une présélection debconf (preseed) pour pré-configurer l’installation.
Il permet d’avoir plusieurs profils d’installation différents, et de gérer des scripts de pré-installation et de post-installation, permettant par exemple de gérer des éléments qui ne peuvent utiliser le preseed debconf.
Chaque profil est constitué d’un certain nombre de fichiers qui décrivent comment est réalisé le CD/DVD iso, mais aussi les actions qu’exécutera en automatique l’installateur. La construction de cette iso est réalisé par la fonction build-simple-cdd qui utilisera en paramètre le nom du profil, le fichier de configuration de simple-cdd et génèrera des logs et une iso.
build-simple-cdd
Une installation par l’installateur Debian se déroule de la façon suivante:
-
Chargement du système de l’installateur
-
Choix du profil
-
Execution du PREINST du profil ( profil.preinst )
-
Execution du PRESEED du profil ( profil.preseed )
-
Execution de early_command du PRESEED
-
Execution du reste du PRESEED
-
Execution de late_command du PRESEED
-
Execution du POSTINST du profil ( profil.postinst )
Préparation de simple-cdd
Tout d’abord il faut installer simple-cdd:
apt install simple-cdd
Pour fonctionner correctement simple-cdd nécessite un certain nombre de répertoire. Ces répertoires doivent exister sous peine d’échec de la commande build-simple-cdd.
Arborescence de travail
Simple-cdd est organisé autour des profils. L’architecture des répertoire de simple-cdd est simple. Elle est constituée d’un répertoire de projet, nommé à sa convenance, dans lequel il y un répertoire profiles. C’est ce répertoire qui contiendra les fichiers nécessaires aux différents profiles. Après la création du CD, un répertoire ./tmp y sera créé par l’outil, qui lui servira de répertoire de travail pour créer l’image ISO du CD qui sera lui mis dans un répertoire images créé par l’outil.
Les autres répertoires plus spécifiques comme des dépôts locaux, ou un répertoire pour des fichiers spécifiques que l’on veut voir figurer sur le CD peuvent aussi y être créés.
En dehors du répertoire ./profiles les autres répertoires sont nommé à la convenance de l’utilisateur. Mais par conventions, ils sont souvent nommés comme sur l’arborescence ci-dessus dans les documentations sur internet.
Vous pouvez aussi mettre dans votre répertoire de base des fichiers meta comme README.md, LICENSE, CONTRIBUTING.md, CHANGELOG.md, etc. Cependant, si vous voulez pouvoir les inclure dans l’ISO, il faudra passer par ./extras ou ./local_extras .
La création d’une iso se fait à l’aide de la commande build-simple-cdd telle que:
build-simple-cdd --conf simple-cdd.conf --profiles vmssrvstd,vmssrvstd2 --logfile ./logs/build-2023-05-13-1826.log --verbose --debug --dvd 2>/dev/null
Il est recommandé de prévoir un fichier de log afin de mieux vérifier par la suite en cas d’erreur avec l’option –logfile . Les options –verbose et –debug permettent plus d’affichage à l’écran et dans les logs.
Une option –conf est prévue pour utiliser un fichier de configuration spécifique. Attention, les commande qui s’y trouvent sont directement issues de debian-cd et peuvent mener à des erreurs si elles ne sont pas correctement définie.
Simple-cdd génère un miroir des paquets utilisés par l’installateur (ainsi que les fichiers que l’ont veut voir figurer sur le CD). Il est possible de ne faire que cette seule opération avec l’option –mirror-only qui ne créera pas l’image CD. A l’inverse, l’option –build-only ne fera que construire l’image CD sans générer le miroir.
L’option –profiles permet de spécifier le ou les profiles voulus (séparés par une virgule sans espace). Attention, l’ordre des noms de profiles dans l’option sera l’ordre dans lequel ils apparaitront dans la liste de sélection lors de l’installation.
Ensuite il vous faut créer les fichiers de votre/vos profil(s) qui seront tous stockés dans le sous-répertoire ./profiles.
Les Fichiers de profiles
Les fichiers de profils permettent de créer des personnalisations différentes sur une seule ISO. L’installateur exécutera toujours le profil par défaut qui s’appelle default . Il est possible de modifier ce profil par défaut dans le répertoire profiles avec les fichiers profiles dont le nom sera default ( default.preseed par exemple).
Chaque fichier de profil doit être nommé avec la convention suivante :
NOM_DU_PROFIL.typefichier
Pour un profile, il y a plusieurs fichiers qui sont à créer. Un seul est réellement nécessaire, les autres fichiers sont optionnels.
NOM_DU_PROFILE.downloads (optionnel)
Ce fichier permet de mettre à disposition sur le CD des paquets qui ne seront pas forcément utilisés lors de l’installation d’un profile. Sa fonction est de s’assurer que ces paquets seront toujours disponibles sur le CD et ne nécessite pas d’être téléchargés d’internet (pour une installation sans lien avec Internet).
Le fichier est constitué d’une liste de noms de paquets à raison d’un nom par ligne. Il ne faut pas faire figurer la version du paquet, cependant il est possible de faire figurer l’architecture ( :i386 par exemple). Cette règle concerne aussi les fichiers .packages , .excludes , .extras, .udebs .
NOM_DU_PROFILE.excludes (optionnel)
Comme son type le suggère, ce fichier permet d’exclure des paquets du CD. Ils n’y figureront donc pas quel que soit le besoin éventuel y compris les dépendances .
Le fichier est constitué d’une liste de noms de paquets à raison d’un nom par ligne.
NOM_DU_PROFILE.packages (optionnel)
Ce fichier indique les paquets qui devront être installés par l’installateur, comme par exemple un wrapper de pare-feu comme ufw ou shorewall , ou encore des outils tels que tree , nmap , mlocate , etc… Ils seront bien sur ajoutés à l’ISO (comme pour les paquets dans le fichier .downloads ).
Le fichier est constitué d’une liste de noms de paquets à raison d’un nom par ligne.
NOM_DU_PROFILE.preseed (obligatoire)
Ce fichier est le cœur du profil. Il définit les réponses apportées à l’installateur au cours de l’installation.
Ce fichier fournit à l’installateur les actions par défaut à réaliser et les valeurs de réponses. Ce fichier est fonction de la distribution utilisée. Des exemples peuvent être trouvés sur :
stable = https://www.debian.org/releases/stable/example-preseed.txt
bookworm = https://www.debian.org/releases/bookworm/example-preseed.txt
buster = https://www.debian.org/releases/buster/example-preseed.txt
jessie = https://www.debian.org/releases/jessie/example-preseed.txt
Main source = https://salsa.debian.org/debian/simple-cdd/blob/master/profiles/default.preseed
Ce fichier a une syntaxe particulière qui sera présenté dans un autre chapitre.
Tous les paramètres sont liés à debconf sont trouvable sur le site Debian preseeds - all the possibilities [1] pour Debian Jessie, Stretch, Buster, Bullseye et Bookworm.
NOM_DU_PROFILE.udebs (optionnel)
Ce fichier liste les paquets udebs de l’installateur Debian destinés à être utilisés lors de l’installation par anna . Il n’est pas destiné à reporter des paquets cibles. Certaines inclusions très utiles comme les firmwares peuvent s’y trouver (Ce qui n’est plus nécessaire depuis Bookworm où les firmwares sont intégrés à l’ISO standard).
Le fichier est constitué d’une liste de noms de paquets à raison d’un nom par ligne.
NOM_DU_PROFILE.postinst (optionnel)
C’est un script SHELL de post-installation exécuté après que le système soit installé (et après l’éventuelle late_command du fichier preseed ). Comme c’est un script SHELL, vous devez lui donner des permissions d’exécution:
$ chmod +x PROFILENAME.postinst
Le script devra être écrit comme si vous utilisiez celui-ci en étant sous le système d’exploitation (i.e: in-target) et non pas comme si vous étiez en ramdisk.
La commande preseed late_command est exécutée dans l’environnement de l’installateur alors que le fichier .postinst du profil est exécuté dans l’"environnement cible.
ATTENTION: Le script est exécuté dans l’environnement cible et non pas dans l’environnement de l’installateur. Par contre les commande preseed early_command et late_command est exécutée dans l’environnement de l’installateur.
Il est préférable de pas utiliser de sourcing. Chaque script (de chaque profil) devra être écrit de façon indépendante plutôt que de se sourcer les uns les autres.
Il est conseillé d’utiliser un script SHELL POSIX plutôt que qu’un script BASH pour maximiser la compatibilité, mais ce n’est pas obligatoire.
NOM_DU_PROFILE.preinst (optionnel)
C’est un fichier de script comme le fichier précédent. Il est exécuté avant l’installation, mais après la commande early_command du fichier preseed .
Note: Il est préférable d’utiliser ce fichier au lieu de la commande d-i preseed/early_command string qui est limitée dans ses fonctionnalités. le fichier est exécuté dans l’environnement du système installé; early_command est exécuté dans l’environnement d’installation. Il faut être sûr de l’environnement voulu pour les commandes.
NOM_DU_PROFILE.extras (optionnel)
Ce fichier liste les fichiers (/path/vers/fichier) que l’on veut inclure dans l’image ISO (un fichier tar.gz, CHANGELOG.md etc.). Lors de la construction de l’image ISO ils seront ajoutés. Ce fichier ne permet pas d’ajouter un répertoire, uniquement des fichiers nommés. Ces fichiers seront présents dans le sous répertoire ./simple-cdd de l’image ISO.
Le fichier est constitué d’une liste de fichier avec le chemin d’accès (qui doit être accessible lors de la commande build-simple-cdd), un par ligne.
Il y a la possibilité d’ajouter des répertoires à l’ISO moyennant une modification du fichier /usr/share/simple-cdd/tools/build/debian-cd . Nous verrons cette possibilité plus loin.
Fichiers de configuration
Vous pouvez utiliser un fichier de configuration spécifique pour chaque profil, auquel cas il sera nommé comme les fichiers de profils NOM_DU_PROFILE.conf , ou bien à votre convenance avec .conf comme extension. Dans le premier cas, il sera dans le répertoire .profiles . Dans l’autre cas, vous pouvez le mettre où vous voulez mais il est plus recommandé de les mettre dans un répertoire dédié ./confs.
Il est conseillé de mettre tous les paramètres communs à tous les profils dans un fichier de configuration général ./confs/<mon_fichier_de_conf>.conf , et ce qui est spécifique au profil dans un fichier de conf de profil dans le répertoire ./profiles.
Personnellement je n’utilise qu’un fichier général de configuration simple-cdd.conf dans le répertoire de base $HOME/simple-cdd.
Vous pouvez avoir plusieurs fichiers de configuration général pour différentes versions ou personnalisation de vos images ISO (un pour avoir des profils A et B, un autre pour C et D, etc…). Mais build-simple-cdd n’utilise qu’un seul fichier de configuration général.
Toutes les variables d’environnement ont un équivalent dans le fichier de configuration du profil.
Variables d’environnement
Déclaration de Distribution
Cette variable permet de déclarer la distribution sur laquelle vous voulez baser votre image ISO.
dist=« stable »
Variable d’environnement d’architecture ARCH
Cette variable sert à définir l’architecture de votre image ISO en utilisant le mécanisme normal d’export de variable d’environnement du shell. En cas d’architecture multiple, il faut utiliser ARCHES.
export ARCH=« amd64 »
ou
export ARCHES=« i386 amd64 »
Variables d’environnement CONTRIB, NON-FREE et NON-FREE-FIRMWARE (Bookworm)
Par défaut, Debian ne prend en compte que les paquets libres. Vous pourriez vouloir autoriser l’utilisation des paquets contrib, non-free et non-free-firmware (pour bookworm). Pour cela il faut utiliser les variables CONTRIB NONFREE. Pour sauvegarder ces variables, vous voudrez utiliser mirror_components` avec les mêmes valeurs :
mirror_components=« main contrib non-free non-free-firmware »
Créer ses propres variables d’environnement
Il est possible de créer ses propres variables d’environnement. Cela impliquera de créer aussi le code qui traitera ces variables.
Pour cela il faut modifier le fichier /usr/share/simple-cdd/tools/build/debian-cd .
Par exemple, le code ci-dessous défini la variable et le code associé permettant de copier tout le contenu d’un répertoire dans le répertoire /simple-cdd sur l’ISO; permettant ainsi de mettre à disposition de l’installatrion (fichier preinst et postinst) des ficheirs de configurations ou autres.
Définition dans simple-cdd.conf (deux dernières lignes):
# Include alternative splash image
export SPLASHPNG="$PWD/local_extras/conffiles-std/enedwaith-org-scdd.png"
# what components to be added to image
mirror_components="main contrib non-free non-free-firmware"
# Add local extras files
cd_extras="$PWD/local_extras"
Code dans debian-cd (à la suite de la ligne le paragraphe # FIXME existante):
echo "Copy extras cd files and directories"
if [ -d "$cd_extras" ]; then
echo "Copy all files from $cd_extras/. to $extras_dir/"
cp -a $cd_extras/. $extras_dir/
fi
L’arborescence de l’ISO se présente donc ainsi:
/media//cdrom0
├── boot
├── css
├── debian -> .
├── dists
├── doc
├── EFI
├── install
├── install.amd
├── isolinux
├── pics
├── pool
└── simple-cdd
Et dans / simple-cdd (avec un profil vmssrvcrypto2 ) les répertoires ainsi copiés conffiles-* :
/media/cdrom0/simple-cdd
├── conffiles-box **
├── conffiles-lxqt **
├── conffiles-std **
├── default.downloads
├── default.excludes
├── default.packages
├── default.preseed
├── default.udebs
├── simple-cdd.templates
├── vmssrvcrypto2.downloads
├── vmssrvcrypto2.extra
├── vmssrvcrypto2.packages
├── vmssrvcrypto2.postinst
├── vmssrvcrypto2.preseed
├── vmssrvcrypto2.udebs
├── vmssrvcrypto.downloads
Profiles et Auto Profiles
Vous déclarez ici la liste des profils que vous voulez inclure dans votre image ISO. Les variables profiles et auto_profiles doivent avoir les même valeurs. Les noms de profils sont séparés par un espace et tout doit figurer sur une seule ligne. Ces valeurs ne peuvent pas figurer dans un fichier de configuration spécifique à un profil NOM_DU_PROFILE.conf mais à un fichier de configuration générique.
profiles=« custom util »
auto_profiles=« custom util »
Spécifications serveur
Pour vous assurer que vous obtenez les paquets deb et udeb d’un serveur spécifique, vous pouvez déclarer le nom du serveur et laisser debian_mirror et rsync_debian faire le reste :
server=« ftp.fr.debian.org »
debian_mirror=« ftp://$server/debian/ »
rsync_debian_mirror="$server::debian"
Omettre les manuels et les notes de versions
Pour un build plus petit, vous pourriez vouloir omettre les notes de version et les manuels.
export OMIT_MANUAL=1
export OMIT_RELEASE_NOTES=1
Les paquets locaux
Cette variable indique le répertoire où seront placés les paquets personnalisés dans le dépôt.
local_packages="./local_packages"
NOTE: Vous devez cependant inclure vos paquets personnalisés dans le fichier de profil des paquets NOM_DU_PROFILE.packages pour qu’ils soient installés automatiquement.
Création de l’image ISO
Pour créer l’image iso, il suffit d’appeler la commande build-simple-cdd , par exemple:
$ build-simple-cdd --conf simple-cdd.conf --profiles vmssrvstd --logfile ./logs/build-2023-05-13-1826.log --verbose --debug --dvd 2>/dev/null
Exemples de fichiers
Introduction
Construction des profils
Pour mes profiles, j’ai fait le choix d’avoir les fichiers de profils suivants:
-
preseed, fichier à avoir au minimum
-
downloads, packages, extras, udebs
-
preinst, postinst
Quand le profil est avec un GUI, j’ai utilisé une configuration minimale de LXQT.
Partitionnement
Le partitionnement par défaut des profils de mes serveurs et mes machines utilisateurs de la façon suivante:
/boot/efi -250Mo-
/boot (lvm) -250Mo-
/ (lvm) -25% du volume group LVM-
/home (lvm) -5% du volume group LVM-
/var (lvm) -25% du volume group LVM-
/var/log (lvm) -10% du volume group LVM-
/var/log/audit (lvm) -10% du volume group LVM-
/var/tmp (lvm) -5% du volume group LVM-
/tmp (lvm) -5% du volume group LVM-
swap (lvm) deux fois la RAM limité à 4Go (qui sera éventuellement modifié suivant les besoins)
Le partitionnement est conçu pour aller jusque 10T avec une limite de base à 300Go (les disques inférieurs ou égaux à 300 Go sont donc partitionné à 100%).
Le choix du découpage est dû à des considération personnelles de sécurité et d’utilisation:
-
La racine est séparée de /boot, /var/, /home, /tmp
-
Les répertoires utilisateurs sont indépendant et ont des paramètres nodev, nosuid
-
/var est indépendant du fait des applications (web par exemple)
-
/var/log indépendant pour éviter que les logs ne sature tout le disque, et nodev, nosuid, noexec
-
/var/log/audit, idem /var/log pour auditd
-
/var/tmp répertoire de travail isolé avec nodev nosuid, mais avec exec (pour les scripts des packages)
-
/tmp idem /var/tmp mais avec droits exec car certains packages ne sont pas conforme quand à l’utilisation de l’espace temporaire, sinon il devrait être en noexec.
Pre-installation
Le script de pré-installation me sert à effacer le disque sur lequel je vais procéder à l’installation. j’ai souvent eu des erreurs avec le preseed sur la suppression de l’(ancien partionnement. La documentation de preseed étant très peu complète.
Post-installation
J’ai utilisé les recommandations de CIS Workshop dans mes fichiers de post-installation .postinst de mes profils.
Dans cette post-installation, je configure, j’installe ou je copie:
-
Le splash screen de grub
-
le fichier de conf de ulogd
-
securetty
-
le clavier FR pour le shell grub
-
La police Ringbearer pour grub (pour un usage futur)
-
Les fichiers LXQT du répertoire utilisateur si profil avec GUI
-
La configuration et les fichier de configuration réseau
-
La configuration motd avec neofetch et issue/issue.net
-
Le fichier fstab
-
Du hardening des process, ASLR et core dump
-
Activation en complain de apparmor
-
La configuration des logs. J’ai choisi de conserver rsyslog car plus facile à utiliser que journalctl
-
La configuration SSHD avec les options suivantes:
- Ensure permissions on /etc/ssh/sshd_config are configured
- Configure protocol and listen parameters
- Ensure permissions on SSH private host key files are configured
- Ensure permissions on SSH public host key files are configured
- Ensure SSH access is limited
- Ensure SSH access is limited
- Ensure SSH root login is disabled
- Ensure SSH HostbasedAuthentication is disabled
- Ensure SSH IgnoreRhosts is enabled
- Ensure SSH PermitEmptyPasswords is disabled
- Ensure SSH PermitUserEnvironment is disabled
- Ensure SSH X11 forwarding is disabled
- Ensure SSH AllowTcpForwarding is disabled
- Ensure only strong Ciphers are used
- Ensure only strong Key Exchange algorithms are used
- Ensure only strong MAC algorithms are used
- Ensure SSH warning banner is configured
- Ensure SSH MaxAuthTries is set to 4 or less
- Ensure SSH MaxStartups is configured
- Ensure SSH MaxSessions is set to 10 or less
- Ensure SSH LoginGraceTime is set to one minute or less
- Ensure SSH Idle Timeout Interval is configured
- La configuration de grub standard
- Autorisation de os-probe
- Splash screen
- Couleur d’arrière-plan
- Couleur du menu
- Taille de la console
- Activation apparmor et auditd
- La configuration de grub en disque chiffré (/boot est dans la partition chiffrée)
- Activer le cryptodisk
- Modifier le paramètre PBKDF en PBKDF2 au lieu de Argon seul pris en compte par l’installeur
- Installation de grub-efi
-
La configuration de l’heure avec un serveur NTP local (le parefeu bloque les tentative de synchro vers internet)
-
Configuration des users pour un mot de passe sur 30 jours avant locking (sauf root)
-
Configuration complète en automatique de shoewall.conf, shorewall, shorewall6 et shorewall-init
-
Installation de webmin (uniquemen pour une utilisation à la demandeet uniquement sur réseau local. L’application est desactivée par defaut.
-
Initialisation de aide
-
Préférence réseau en IPv4 devant IPv6
-
Configfuration et installation GeoIP
-
Desactivation de rsync
-
Construction de la base mlocate
-
Configuration du swap avec celui concernant l’installation (en cas de multi-boot de distribution linux)
-
Update de apt-file
-
Configuration vimrc
-
Configfurations sysctl
-
Configuration pam.d
-
Configuration bashrc et profile
-
Configfuration login_defs
-
Configuration auditd et des règles
-
Configuration chkboot
-
Configuration netdata
Preseed
Les fichiers pressed de mes profiles considèrent une installation sur un seul disque (mais il est facile d eles faire évoluer sur plusieurs disques).
J’utilise systématiquement LVM pour la facilité de gestion des tailles de volumes.
J’utilise la commande early_command pour installer des fichier udebs particulier, effacer les partitions existante du disque, la selection de l’interface réseau utilisée pour l’installation. L’installation utilise le DHCP, mais si celui-ci echoue, alors une configuration manuelle est utilisée.
Le système est installé en français mais on peut choisir la langue de l’interface de l’installateur.
Un hostname par defaut et un domaine DNS par defaut sont configurés.
Chargement automatique des firmware est activé (Bookworm).
Le miroir des dépôt est configfuré sur deb.debian.org. J’ai une version qui utilise un dépôt local sur un NAS.
L’utilisateur root et un utilisateur par défaut sont configurés. avec des mots de passe chiffrés dans le preseed.
L’horloge et le serveur de temps pour l’installateur sont définis.
Configuration du boot avec GPT, EFI et le cas échéant pour le chiffrement LUKS2:
- Utilisation de dm-crypt
- Cipher: Serpent
- Key hash: SHA256
- Key size: 256
- ivAlgorithm: ecb
Dans le cas d’un profil LVM over LUKS, les options d’installation grub seront paramétrée pour une installation sans grub. Celle-ci est alors ré&alisée par le script de post-installatrion. en effet, l’installateur Debian ne sait pas installer un système avec /boot chiffré (à cause de l’"option par defaut du PBKDF en Argon2i).
Les mises à jour du système sont configuré mais sans mises à jour en automatique.
Par défaut les tasksel installées est standard, desktop, print-server sont desactivées.
La commande late_command une partition temporaire est supprimée. En effet, la dernière partition créée par l’installateur utilise tout l’espace LVM disponible. Je créée donc une partition todelete pour corriger cela. C’est un bug/defaut de l’installateur.
Exemples de profils
Standard
vmssrvstd.downloads.txt (4,9 Ko)
vmssrvstd.extra.txt (275 Octets)
vmssrvstd.packages.txt (1,5 Ko)
vmssrvstd.postinst.txt (62,5 Ko)
vmssrvstd.preinst.txt (596 Octets)
vmssrvstd.preseed.txt (28,4 Ko)
vmssrvstd.udebs.txt (360 Octets)
Standard avec LXQT minimal
vmssrvstdlxqt.downloads.txt (5,6 Ko)
vmssrvstdlxqt.extra.txt (279 Octets)
vmssrvstdlxqt.packages.txt (2,9 Ko)
vmssrvstdlxqt.postinst.txt (62,9 Ko)
vmssrvstdlxqt.preinst.txt (600 Octets)
vmssrvstdlxqt.preseed.txt (28,4 Ko)
vmssrvstdlxqt.udebs.txt (364 Octets)
Chiffré LVM over LUKS
vmssrvcrypto.downloads.txt (4,9 Ko)
vmssrvcrypto.extra.txt (278 Octets)
vmssrvcrypto.packages.txt (1,6 Ko)
vmssrvcrypto.postinst.txt (63,6 Ko)
vmssrvcrypto.preinst.txt (599 Octets)
vmssrvcrypto.preseed.txt (29,5 Ko)
vmssrvcrypto.udebs.txt (363 Octets)
Chiffré LVM over LUKS avec LXQT minimal
vmssrvcryptolxqt.downloads.txt (5,6 Ko)
vmssrvcryptolxqt.extra.txt (282 Octets)
vmssrvcryptolxqt.packages.txt (3,0 Ko)
vmssrvcryptolxqt.postinst.txt (63,6 Ko)
vmssrvcryptolxqt.preinst.txt (603 Octets)
vmssrvcryptolxqt.preseed.txt (29,5 Ko)
vmssrvcryptolxqt.udebs.txt (367 Octets)
Customisation
Il est fastidieux de maintenir un nombre important de profils sur lesquels une modification identique est à réaliser. J’ai donc créé une architecture de ficheir et un script pour encapsuler build-debian-cdd.
./build-simple-cdd.sh
En premier lieu, afin de pouvoir gérer facilement des éléments communs à tous les fichiers j’ai créé un script spécifique qui encapsule build-simple-cdd . Je l’ai simplement appelé ./ build-simple-cdd.sh .
Ce script dispose des fonctionnalités portées par les options suivantes:
-h|–help : imprime l’aide.
-p|–profiles : Permet de spécifier la liste des profiles qui seront générés (nom des profiles séparés par une virgule sans espaces). si le profile est all alors tous les profils seront traités.
-g|–generate : Genère l’ISO finale.
-r|–rsync : Une synchronisation de sauvegarde de l’espace de travail est réalisée.
-d|–distant : La synchronisation est réalisée sur un serveur distant qui utilise par défaut un NAS au sein de mon réseau.
Default device //diskstation/homes
Default mount point /media/mounts/diskstation/homes (attention j’ai configuré mon utilisateurs pour pouvoir utiliser ce point de montages)
-m|–mount : Définit le point de montage à utiliser
-l|–local : La synchronisation se fera dans un répertoire local.
-f|–force-root : utilise l’option –force-root de build-simple-cdd . Utile uniquement si vous utilisez simple-cdd sous root .
Le fonctionnement de ce script est décrit dans le schéma suivant:
./build-simple-cdd.sh
Le script charge le fichier de configuration qui se trouve dans un répertoire spécifique ./conf.
Ce fichier de configuration décrit les fichiers de profils à créer avec les éléments à concaténer.
Pour chaque type de fichier de profil, il existe un répertoire _ dans lequel se trouve tous les bouts de fichiers nécessaire.
L’intérêt de ce procéder est de permettre facilement la réutilisation de bout de code (postinst, preinst) ou de bout de configuration (download, packages, preseed, etc…).
Ainsi, si par exemple vous ne modifiez que la partie partitionnement de votre fichier preseed , vous n’avez pas à modifier le ou les fichiers de profiles, vous modifiez simplement l’élément correspondant dans le répertoire _preseed . C’est très utile quand on manipule de nombreux profils, dont des pans entier sont communs.
Par exemple, j’ai décomposé les fichiers postints en plus de 30 sous éléments. La gestion de correctifs, des évolutions ou l’ajout de nouvelles fonctionnalités sont très simple, et la constitution d’un profile ne s’apparente plus qu’à un jeu de Lego.
Contenu du répertoier _postinst et des sous-éléments Postinst
Profiles Imbriqués
Les profiles imbriqués sont des profiles dont on peut demander l’installation simultanée. En clair, les fichiers de conf de chaque profiles sont pris en compte ensemble.
NOTE: Je vous conseille de ne pas utiliser deux profiles avec un fichier preseed.
Par contre pour l’ajout optionnel d’application c’est tout à fait envisageable. Cela concerne les autres fichiers tels que:
- .downloads
- .packages
- .preinst
- .postinst
- .extra
On peut ainsi avoir comme un système de packaging qui, au lieu d’être prédéfini dans ses versions et son contexte de packaging, permet de moduler entre profils d’installation du serveur de base et profils applicatifs. Cela évite de faire autant de profils serveurs que d’utilisations.
En fait, on peut ainsi avoir des installations à la carte.
Par exemple, on peut vouloir faire un serveur apache, pour cela:
- Profil 1 : le profile d’un serveur de base complet
- Profil 2: les fichiers liés à l’installation d’apache (.packages, .postinst)
C’est utilisable presque à l’infini. Pour un serveur XAMP:
- Profil d’installation d’un serveur de base
- Profil d’installation d’Apache (avec un postinst de configuration de base)
- Profil d’installation de MariaDB (avec le postinst pour la configuration de base)
- Profil d’installation de PHP (avec le postinst pour la configuration de base)
Vous voulez faire une installation pour une application particulière ou des besoins particuliers:
- Profil d’installation des paquets de PHP et de l’applicatoin, le tout avec le postinst qui s’occupe de la configuration.
Le potentiel d’utilisation est très large.
Cependant, en particulier pour les fichiers .preinst et .postinst, il faut impérativement faire les tests préalables à toute action (dans le script postinst) pour s’assurer qu’on n’interfère pas avec les fichiers postinst correspondant des autres profiles. Ce la nécessite donc d’être très méticuleux.
Dernière mise à jour: 05/03/2024
Ceres? j’utilise maxima 
