Installation de Kali Linux en preseed

Les programmes d’installation Debian et Kali Linux sont très modulaires. De façon basique, ils exécutent les scripts qu’on leur fournit les uns après les autres. Chacun de ces scripts font référence à debconf qui interagit avec l’utilisateur afin de stocker les paramètres d’installation. De ce fait, l’installeur peut être automatisé au travers du mécanisme standard preseed de debconf, fonction qui fournit des réponses systématiques aux questions posées lors de la phase d’installation.

RAPPEL : preseed permet d’automatiser les questions posées par DebianInstaller en remplissant les réponses au sein de la base de données debconf.

Il existe de multiples façons de prédéfinir les réponses à l’intention du programme d’installation. Chaque méthode a ses avantages et ses inconvénients. La façon dont l’opération de preseed se fait détermine les questions présentées :

avec des paramètres de boot
avec un fichier preseed dans l’image initrd
avec un fichier preseed intégré au démarrage du media
avec un fichier preseed chargé depuis le réseau

Dans ce dernier cas, il suffit de préparer le fichier preseed et de le présenter à l’installeur via un serveur web en ajoutant le paramètre de démarrage : preseed/url=http://server/preseed.cfg (ou en utilisant un alias).

ATTENTION : en, utilisant cette méthode, le réseau doit alors être configuré en premier. Cela signifie que les questions relatives au réseau pour debconf (nom d’hôte et nom de domaine, langage et pays) ne peuvent être paramétrées via preseed.

Dans le cas de l’intégration du fchier preseed à l’image ISO, il faut préparer celle-ci et la reconstituer pour ajouter le fichier au bon emplacement : /cdrom/preseed.cfg. Le plus simple est encore d’intégrer ce fichier à l’image initrd en décompressant le fichier initrd et en le modifiant pour ajouter le fichier preseed, puis recomposer l’image initrd.

Un fichier preseed est un fichier texte contenant sur chaque ligne les réponses aux questions posées par l’agent debconf. Une ligne est découpée en quatre champs séparés par des espaces ou des tabulations :

le premier champ indique le propriétaire de la question (d-i pour installer).
le second champ contient l’identifiant de la question posée.
le troisième champ liste le type de la question.
le quatrième champ contient la valeur de la réponse souhaitée.

REMARQUE : le quatrième champ doit être séparé du précédent avec un espace simple. Tout caractère additionnel est considéré comme faisant partie de la valeur.

La façon la plus simple de constituer un fichier preseed est d’installer le système une première fois manuellement. Puis, la commande ci-dessous fournit alors les réponses à fournir à l’installeur :

# debconf -get-selections --installer

On peut obtenir des réponses des autres packages que l’installeur, en utilisant l’option debconf-get-selections. Maintenant, une solution alternative plus sûre consiste à rédiger le fichier preseed manuellement, en démarrant à l’aide d’un exemple préconçu et en consultant la documentation Debian. En pratiquant ainsi, seules les questions où les réponses par défaut ont besoin d’être surchargées peuvent être présélectionnées.

En fournissant l’option priority=critical boot on précise alors à debconf de ne tenir compte que des questions critiques et d’utiliser les réponses par défaut pour les autres.

Exemple : fichier preseed :

### Localization

# Preseeding only locale sets language, country and locale.

# The values can also be preseeded individually for greater flexibility.

d-i debian-installer/language string en
d-i debian-installer/country string DE
d-i debian-installer/locale string en_US.UTF-8

# Keyboard selection.

d-i console-keymaps-at/keymap select fr
d-i keyboard-configuration/xkb-keymap select fr

# netcfg will choose an interface that has link if possible. This makes it
# skip displaying a list if there is more than one interface.

d-i netcfg/choose_interface select auto

# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.

d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain

# Disable that annoying WEP key dialog.

d-i netcfg/wireless_wep string

### Mirror settings

# If you select ftp, the mirror/country string does not need to be set.

d-i mirror/country string manual
d-i mirror/http/hostname string mirror.mymirror.fr
d-i mirror/http/directory string /debian/packages/
d-i mirror/http/proxy string

### Account setup

# Skip creation of a root account (normal user account will be able to
# use sudo).

d-i passwd/root-login boolean true

# Root password, either in clear text

d-i passwd/root-password password <Password>
d-i passwd/root-password-again password <Password>

# To create a normal user account.

d-i passwd/user-fullname string phil
d-i passwd/username string philpwd

# Normal user's password, either in clear text

d-i passwd/user-password password philpwd
d-i passwd/user-password-again password philpwd

### Clock and time zone setup
# Controls whether or not the hardware clock is set to UTC.

d-i clock-setup/utc boolean true

# You may set this to any valid setting for $TZ; see the contents of
# /usr/share/zoneinfo/ for valid values.

d-i time/zone string Europe/Paris

# Controls whether to use NTP to set the clock during the install

d-i clock-setup/ntp boolean true

# Alternatively, you may specify a disk to partition. If the system has only
# one disk the installer will default to using that, but otherwise the device
# name must be given in traditional, non-devfs format (so e.g. /dev/hda or
# /dev/sda, and not e.g. /dev/discs/disc0/disc).
# For example, to use the first SCSI/SATA hard disk:
#d-i partman-auto/disk string /dev/sda
# In addition, you'll need to specify the method to use.
# The presently available methods are:
# - regular: use the usual partition types for your architecture
# - lvm:     use LVM to partition the disk
# - crypto:  use LVM within an encrypted partition

d-i partman-auto/method string regular

# If one of the disks that are going to be automatically partitioned
# contains an old LVM configuration, the user will normally receive a
# warning. This can be preseeded away...

d-i partman-lvm/device_remove_lvm boolean true

# The same applies to pre-existing software RAID array:

d-i partman-md/device_remove_md boolean true

# And the same goes for the confirmation to write the lvm partitions.

d-i partman-lvm/confirm boolean true

# You can choose one of the three predefined partitioning recipes:
# - atomic: all files in one partition
# - home:   separate /home partition
# - multi:  separate /home, /usr, /var, and /tmp partitions

d-i partman-auto/choose_recipe select atomic

# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.

d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

# This makes partman automatically partition without confirmation.

d-i partman-md/confirm boolean true
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

### Package selection

tasksel tasksel/first multiselect standard, ssh-server

# Individual additional packages to install
#d-i pkgsel/include string openssh-server build-essential
# Whether to upgrade packages after debootstrap.
# Allowed values: none, safe-upgrade, full-upgrade

d-i pkgsel/upgrade select safe-upgrade

# Some versions of the installer can report back on what software you have
# installed, and what software you use. The default is not to report back,
# but sending reports helps the project determine what software is most
# popular and include it on CDs.

popularity-contest popularity-contest/participate boolean false

# Avoid that last message about the install being complete.

d-i finish-install/reboot_in_progress note

# This command is run just before the install finishes, but when there is
# still a usable /target directory. You can chroot to /target and use it
# directly, or use the apt-install and in-target commands to easily install
# packages and run commands in the target system.

d-i preseed/late_command string apt-install puppet vim sudo tmux curl git
d-i grub-installer/only_debian boolean true

D'ailleurs, la modularité de Kali Linux n’a pratiquement aucune limite. En effet, on peut facilement constituer sa propre image personnalisée de Kali Linux. Les images officielles sont constituées à l’aide de live-build qui est un ensemble de scripts, autorisant la totale automatisation et personnalisation de l’ensemble des pans de la création de l’image ISO de Kali Linux. La suite live-build utilise une structure arborescente de répertoires en entrée, afin de préparer la configuration. Cette dernière est stockée avec quelques scripts additionnels d’aide dans un dépôt git. On utilise ce dépôt comme image personnalisée de construction. Parmi ces images personnalisées les plus connues, on peut citer :

En premier lieu il faut installer les packages nécessaires et extraire le dépôt git avec la configuration live-build :

# apt install curl git live-build
# git clone git://git.kali.org/live-build-config.git
# cd live-build-config

Puis, on peut d’ores et déjà créer et mettre à jour (sans modification quelconque) l’image ISO Kali, uniquement en exécutant :

# ./build.sh --verbose

Lorsque cela est terminé on découvre alors une nouvelle image ISO dans le répertoire images du répertoire de travail précédemment créé. Avec l’option --variant, il est possible de configurer un gestionnaire de fenêtre différent de gnome :

# ./build.sh --variant kde --verbose

Lorsqu'on l’exécute, live-build installe les packages listés dans les fichiers *.list.chroot du répertoire package-lists. Or, la configuration par défaut dispose du fichier kali.list.chroot au sein de ce même répertoire, ce qui décrit l’intégralité des packages de la distribution kali-linux-full. Mais, il est possible de commenter l’utilisation de ce méta-package afin d’en utiliser un autre de notre choix ou d’inclure une liste précise de packages. On peut bien sûr combiner les deux approches en démarrant un méta-package différent et en ajoutant des packages supplémentaires de notre choix.

Pour inclure des packages personnalisés, il faut le faire dans l’image en plaçant les fichiers .deb dans le répertoire packages.chroot. Par exemple, pour personnaliser une image gnome de Kali Linux, on devra positionner les packages personnalisés dans kali-config/config-gnome/packages.chroot.

Les méta-packages ne sont rien d’autres que des packages vides dont le seul rôle est de définir les dépendances sur les autres packages. Cela permet alors d’installer des groupes de packages que l’on désire installer ensemble. Le package source kali-meta construit ainsi tous les méta-packages fournis par Kali Linux :

kali-linux: le méta-package de base poussé par les autres méta-packages.
kali-linux-full: le méta-package par défaut de l’installation Kali Linux.
kali-linux-all: le méta-package de tous les méta-packages et des autres packages.
kali-linux-sdr: les outils des ondes radio et du sans-fil.
kali-linux-gpu: les outils concernant les plateformes GPU.
kali-linux-wireless: les outils d’analyse et de gestion des plateformes sans-fil.
kali-linux-web: les outils fondamentaux pour les applications web.
kali-linux-forensic : les outils d’analyse informatique légale.
kali-linux-voip : les outils pour les plateformes utilisant la voix sur IP.
kali-linux-pwtools : les outils de crackage de mot de passe.
kali-linux-rfid : les outils pour l’utilisation de RFID.

On peut alors composer avec ces méta-packages lorsque l’on créée une liste de package personnalisée pour live-build. La liste complète des méta-packages est disponible sur l’adresse web tools.kali.org.

Chapitre Précédent

Retour au Module

Chapitre Suivant

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio

Vous pourrez aussi aimer