On a vu au travers de ce billet https://www.mytinydc.com/index.php/2018/09/13/pine64-rock64-bootp-pxe/, comment démarrer une unité sans carte SD, uniquement par le réseau et au moyen du protocole Bootp.
Nous allons voir maintenant, comment installer le système d’exploitation Debian, de manière automatisée. Cette procédure permet de provisionner un nouveau serveur en moins de 4 minutes…
Que peut-on automatiser ?
L’installation du système Debian
Le serveur NFS, disposera d’une image disque, dont le contenu devra être être disposé sur la carte SD du nouveau serveur, et après démarrage “Bootp”. Intervention humaine nécessaire, ou pas…
La configuration de certains services
Les configurations suivantes sont identiques pour tous les serveurs du Datacenter :
- Le paramétrage du service Email (exim4)
- les paramètres régionaux “locales”
- leur emplacement géographique, qui détermine leur fuseau horaire de production (tzdata)
- les paramètres du détecteur d’intrusion OSSEC,
- les paramètres minimum des sondes cliente du monitoring
- …
Les autorisations de connexions réseaux
Pour administrer, ou exécuter certains services, vous devez installer quelques clés SSH, permettant aux différents acteurs, parfaitement identifiés de s’y connecter et effectuer des tâches. Liste des acteurs :
- le serveur de Backup (sauvegarde/restauration)
- le serveur d’administration du Datacenter (Datacenter manager - DCIM)
- …
Méthodes d’automatisation
Toutes les points pré-cités sont facilement automatisables. On pourra utiliser ces différentes techniques :
- Système de copie de templates. Il s’agit de modèles de configurations créés par l’administrateur
- copie d’une clé publique (id_rsa.pub), clairement identifiée vers un fichier “.ssh/authorized_keys”
- installer des paquets Debian supplémentaires, à partir des dépôts officiels ou bien à partir de paquets disponibles sur le réseau local (dpkg -i)
- reconfiguration de paquets selon des paramètres précis
- ….
Pour réaliser ces opérations, après avoir été clairement énoncées, vous pourrez choisir d’utiliser “Ansible”, “Puppet”, “Chef”,…
Dans mon cas, j’ai développé un outil “mytinydc-automation” (voir le billet), qui permet d’écrire des pseudo-scripts en Bash (appelés automates).
Et n’oubliez surtout pas de documenter ce processus.
État du nouveau serveur après un démarrage au travers du réseau
Nous avons vu qu’il est possible de discriminer les démarrages Bootp selon le type de plateforme (X86, ARM).
Une plateforme “amd64” n’utilise pas les mêmes fichiers binaires qu’un serveur de type “arm64” ou bien “armhf”. Par conséquent la configuration Bootp, diffère selon la plateforme. Ce qui est sûr, c’est qu’une fois démarrés, ces serveurs “causent” tous ce langage commun : “bash”, intégré dans toutes les distributions Linux.
C’est donc à partir de ce langage que je vais construire le moteur qui va permettre l’installation d’un système Debian sur un unité vierge. Les tests que j’ai effectué ont démontrés que les unités Raspberry Pi3 et Rock64 disposent d’un lecteur intégré de carte SD dit “hotplug”.
Démarrez ces types d’unités par le réseau, connectez-vous par SSH, lisez en continu le fichier “/var/log/syslog”, insérer une carte SD, vous disposerez des signaux indiquant la prise en compte par le Kernel de cette carte SD.
A partir de maintenant on peut installer n’importe quoi sur cette dernière puis redémarrer le serveur, qui cette fois, redémarrera sur sa carte SD et non plus par le réseau.
Ce qui nous amène à comprendre : L’unité dispose d’une carte SD bootable, le serveur démarre à partir de cette dernière. Dans le cadre d’une carte SD vierge, le serveur démarrera sur le réseau. Il est donc tout à fait possible de démarrer un serveur par le réseau avec une carte SD insérée, et vierge.
Spécifications (exemple)
- Le futur serveur doit être préparé pour démarrer à partir de sa carte réseau
- Le Datacenter doit permettre un amorçage de cette nouvelle unité par le réseau (configuration du service DHCP/Bootp)
- Le serveur démarré par le réseau utilise le système disposé sur le serveur NFS.
- Le serveur NFS disposera de l’image système Debian et relative au type de plateforme du nouveau serveur.
- L’installation ne peut démarrer que si la carte SD est détectée comme insérée.
- L’installation généra un mot de passe fort, pour y accéder par SSH, une fois le serveur installé.
- Les automates sont disponibles, au choix, sur le serveur NFS ou bien sur le serveur de gestion du Datacenter (préféré)
- L’installation pourra être exécutée, au choix, à partir de la console du serveur démarré par le réseau, ou bien à partir du serveur de gestion du Datacenter (préféré)
- Le serveur de backup ainsi que le serveur de gestion du Datacenter auront un accès SSH au nouveau serveur, une fois installé. J’utilise Backuppc pour les sauvegardes et MytinyDC-IM pour la gestion du Datacenter. Par conséquent, les clé ssh publiques des compte “backuppc” et “mytinydcim” devront disposer d’un accès SSH au nouveau serveur, après installation d’un système Debian sur sa carte SD.
- Le service OSSEC sera installé et paramétré à partir d’un template (modèle).
- Le service de monitoring Prometheus sera installé et paramétré à partir d’un template (node_exporter au minumum).
- La configuration du firewall autorisera l’utilisation des services OSSEC et Prometheus.
Procédure d’installation pas à pas
Démarrage de l’unité sur le réseau
Vous devez vous assurer que l’unité est correctement démarrée par le réseau. Son système d’exploitation est hébergé sur le serveur NFS. Par conséquent toutes actions directes sur les fichiers du serveur NFS, auront un impact sur le comportement de l’unité démarrée par le réseau.
Automate - Accès root
L’automate d’installation doit avoir un accès “root” via SSH, à l’unité démarrée par le réseau. Insérez le contenu de la clé publique de l’automate (.ssh/idrsa.pub) dans le fichier /root/.ssh/authorized_keys situé sur le serveur NFS et pour la plateforme considérée. En effet le serveur NFS pourra être système d’exploitation pour différents types de plateformes. Dans mon cas, je dispose des répertoires “/nfs/boot/rock64*” pour les unités de type “Rock64 - arm64” et “*/nfs/boot/rpi_” pour les unités de type “Raspberry PI - armhf”.
Effectuez un test de connexion SSH, à partir du compte utilisé pour lancer les automates, au compte “root” du serveur démarré par le réseau.
Installation d’un système Debian sur la carte SD
Insérez une carte SD dans la nouvelle, unité. Attention, les données disponibles sur cette carte, seront supprimées de manière irréversible.
L’image d’un système vierge, il s’agit d’une image système disponible pour votre distribution dans leur version officielle. Téléchargez l’image correspondant à votre distribution et à votre plateforme. Et disposez la dans le répertoire “/images” du système de fichier NFS. Ex : /nfs/boot/rock64/images ou /nfs/boot/rpi/images …
Donnez lui un nom générique en conservant le nom de la distribution ainsi que sa version (très important pour historiser les images installées). Conservez toujours les images installées, ceci peut permettre dans le futur d’évaluer les risques d’une “infection” détectée tardivement. Vous pourrez ainsi réinstaller l’image et voir l’impact de cette infection sur votre Datacenter. N’installez jamais d’image “exotiques” uniquement les images officielles.
Création de l’automate d’installation de l’image
Procédure :
- Détection de la disponibilité de la carte SD
- Détection de l’image à installer. J’installe toujours l’image la plus récente, découverte sur le système de fichier NFS.
- Écriture de l’image sur la carte SD
- Contrôle d’écriture.
Détection de la disponibilité de la carte SD
L’automate à l’aide d’une commande simple devra détecter la présence d’une carte SD dans l’appareil. Les cartes SD sont nommées “/dev/mmcblk[Enumérateur]” (ex : /dev/mmcblk0 ou /dev/mmcblk1 etc… par le kernel. Certaines unité démarrent à 0 (Raspberry PI) ou 1 (Rock64). Par conséquent je vais rechercher les deux cas, et utilisant la commande “partprobe”, qui renverra le code 0 pour “trouvé” ou le code 1 pour “non trouvé”:
Détection de l’image à installer
Les images de systèmes officiels devront être téléchargées et compressées au format zip, puis copiées dans le répertoire “images” du répertoire NFS correspondant à l’architecture de l’unité démarrée par le réseau. Ex : /nfs/boot/rock64/images ou /nfs/boot/rpi/images …
Écriture de l’image sur la carte SD
Cette fonction va permettre de décompresser l’image disque, sur la carte SD. Utilisation des commandes unzip et dd dans un pipeline.
Contrôle d’écriture
Un contrôle au moyen de l’outil “partprobe” permettra de détecter la présence de partitions et leur type. Préambule au “chroot” qui sera exécuté dans la partition principale afin d’y ajouter les paquets nécessaires, les clés SSH, etc…
L’automate permettant l’installation d’image
Ce pseudo-script (automate) devra être exécuté par la commande “mytinydc-automation.sh” (voir le projet sur notre GitLab)
L’automate est nommé “provisionserver” et disposé comme suit :
/opt/mytinydc/automates/provisionserver
|___> script.mtya
# script.mtya
#cette function prend le préfixe des devices de type SDCARD ex: /dev/mmc...
function probesdcard {
export SDCARDDEV=""
# Probing if media ok
DEVICENUMS="0 1 2"
for num in $DEVICENUMS;do
/sbin/partprobe -d -s $1$num >/dev/null 2>/dev/null #DONTCATCH
ERR=$?
if [ "$ERR" = "0" ];then
SDCARDDEV=$1$num
break;
fi
done
if [ "$SDCARDDEV" = "" ];then
echo "[ERR] - La carte SD est introuvable"
# fin on ne peut aller plus loin
exit 1
fi
echo "[*] Carte SD détectée : $SDCARDDEV"
} #DONTCATCH
#Cette fonction prend le chemin disposant des images
#Chemin absolu par rapport au système de fichier NFS monté ex : /images
function setimage {
IMAGE=""
if [ "$1" = "" ];then
echo "Vous devez spécifier la valeur du chemin des images en paramètre"
exit 1
else
#trié sur "la plus récente"
CDIR=`ls -t $1/*.zip` #DONTCATCH
if [ "$CDIR" = "" ];then
echo "Le répertoire des images $1 est vide"
exit 1
fi
for file in $CDIR
do
if [ -f $file ];then
IMAGE=$file
break
fi
done
fi
echo "[*] Image détéctée : $IMAGE"
export IMAGE
} #DONTCATCH
# Fonction permettant d’écrire l'image sur la carte SD, opération irréversible
# Prend en paramètres : Chemin complet de l'image, destination
function copyImage {
echo "[*] Ecriture de l'image $1 vers $2"
# On va avoir besoin de unzip
apt-cache show unzip > /dev/null 2>/dev/null #DONTCATCH
if [ "$?" = "1" ];then
apt-get -y install unzip
fi
BS="bs=1M"
# dd affiche la progression et le rapport sur STDERR redirect vers STDOUT
unzip -p $1 |dd of=$2 $BS status=progress 2>&1
echo "[*] La copie s'est bien déroulée : OK"
echo "[*] Rafraichissement de la table de partition"
/sbin/partprobe $2
} #DONTCATCH
# Fonction permettant de detecter la partition système de la carte SD
# Parametre : device SDCARD
function getsystempartition {
export PARTITION=`fdisk -l $1 | grep " 83" | awk '{print $1;exit}'`
if [ "$PARTITION" = "" ];then
echo "[ERR] La partition systeme installé sur la carte SD n'a pas été trouvée (type de partition 83)"
exit 1
fi
}
# Fonction de montage SDCARD
# Parametres : device - point de montage
function mountSdcard {
mount|grep $1 #DONTCATCH
if [ "$?" = "1" ];then
echo "[*] Mounting $1 on $2"
mount $1 $2
fi
echo "[*] $1 Mounted on $2"
}
# Fonction de démontage SDCARD
# Parametre : device
function umountSdcard {
echo "[*] Unmounting $1"
umount $1
echo "[*] $1 Unmounted"
}
# Préparation du kit pour le chroot
function chrootkitmount {
# Mount necessary for chroot
for fs in $1;do
echo "[*] chroot montage $DEVICECHROOT sur $2/$fs"
mount --bind /$fs $2/$fs >/dev/null 2>/dev/null #DONTCATCH
done
}
# Démontage du kit chroot
function chrootkitumount {
# Mount necessary for chroot
for fs in $1;do
echo "[*] chroot demontage $2/$fs"
umount $2/$fs >/dev/null 2>/dev/null #DONTCATCH
done
}
# Variable obligatoire
#CHECK WRITETOSDCARD
probesdcard "/dev/mmcblk"
setimage "/images"
if [[ "$WRITETOSDCARD" = "Y" ]];then
copyImage $IMAGE $SDCARDDEV
fi
Exécution de l’automate
A cette étape le serveur est démarré par le réseau et accessible via SSH. A partir du serveur automate, exécutez :
/opt/mytinydc/sbin/mytinydc-automation.sh provisionserveur raspi5 WRITETOSDCARD="Y"
**raspi5 dans mon exemple est le nom DNS du serveur démarré par le réseau
Paramétrage du nouveau serveur
Nous allons passer aux paramétrages basiques du serveur.
Cette opération va s’exécuter dans un “chroot”. Pour accomplir cette opération nous aurons besoin d’un shell qui comportera les opérations à réaliser, auquel je vais passer les paramètres nécessaires :
- HOSTNAME (nom hôte du serveur),
- PASSWORDROOT (mot de passe root),
- PASSWORDMAINUSER (mot de passe utilisateur principal “pi”),
- TIMEZONE (zone fuseau horaire),
- LOCALE (définition de locale “en fr etc..”,
- LOCALEENCODE (encodage par défaut “iso8859, etc”).
Je vais écrire un deuxième automate chargé d’exécuter toute la procédure.
La procédure consiste à changer le nom hôte du serveur final, attribuer un mot de passe “root”, et un mot de passe à l’utilisateur principal (dépend des distributions).
Pour les Raspberry PI et la distribution Raspbian, l’utilisateur “pi” est créé implicitement.
Puis on passera à la configuration du fuseau horaire de production du serveur et de ses “locales”.
J’installe aussi les clés publiques SSH des serveurs ayant autorité (ex : serveur de sauvegarde).
Ces dernières seront disposées dans le répertoire “ressources/sshkeys” de l’automate.
L’automate est nommé “setupserver” et disposé comme suit :
/opt/mytinydc/automates/setupserver
|___> script.mtya
|___> ressources
|________> actionschrooted.sh
|________________> sshkeys
|________________> sshkeybackuppc
Fichier ressource
Il s’agit du shell qui sera exécuté en mode “chroot”.
L’automate doit envoyer ce fichier sur le serveur final afin que le shell exécuté via SSH par l’automate puisse l’atteindre et l’exécuter dans l’environnement du nouveau serveur.
Ce fichier est à disposer dans le répertoire “ressources” de l’automate.
Fichier : “ressources/actionschrooted.sh”
#!/bin/bash
# @author DHENRY (@MytinyDC.com)
# @licence CC BY-NC-ND 4.0
# Project (c)MytinyDC.com
#executed in chroot environmnent
if [ "$1" = "" ];then
echo "[ERR] Merci de fournir le hostname (ex: raspi14)"
exit 1
fi
if [ "$2" = "" ];then
echo "[ERR] Merci de fournir le mot de passe root"
exit 1
fi
if [ "$3" = "" ];then
echo "[ERR] Merci de fournir le mot de passe utilisateur principale (utilisateur pi)"
exit 1
fi
echo "[*] Contrôle si mode chroot ?"
RES=$(ls -di /)
if [ "$RES" = "2 /" ]
then
echo " Chroot : OK"
else
echo "[ERR] Vous devez être dans un environnement chrooté pour continuer"
exit 1
fi
HOSTNAME=$1
PASSWORDROOT=$2
PASSWORDMAINUSER=$3
TIMEZONE=$4
LOCALE=$5
LOCALEENCODE=$6
# Set hostname
echo $HOSTNAME > /etc/hostname
# set root password to new install
echo "[*] Réglage mot de passe root - Le nouveau mot de passe root est : [ $PASSWORDROOT ]"
$(echo root:$PASSWORDROOT | chpasswd )
#For pi only
PI=$(getent passwd pi)
if [ "$PI" != "" ];then
echo "[*] Pour des raison de sécurité, changement du mot de passe de l'utilisateur pi"
$(echo pi:$PASSWORDMAINUSER| chpasswd )
fi
############
# Disable nodm on rock64 - no problem with pi command will just answer an error
echo "[*] Desactivation de l'environnement Desktop"
systemctl disable nodm >/dev/nul 2>&1
#source : https://serverfault.com/questions/362903/how-do-you-set-a-locale-non-interactively-on-debian-ubuntu/689947#689947
echo "[*] Réglage locales"
sed -i -e 's/# $LOCALE $LOCALEENCODE/$LOCALE $LOCALEENCODE/' /etc/locale.gen
echo 'LANG="$LOCALE"'>/etc/default/locale
dpkg-reconfigure --frontend=noninteractive locales 2>&1
update-locale LANG=$LOCALE
############
#TIMEZONE is set in config.sh
#source : https://stackoverflow.com/questions/8671308/non-interactive-method-for-dpkg-reconfigure-tzdata#8671492
echo "[*] Réglage fuseau horaire $TIMEZONE"
# unlink
rm /etc/timezone >/dev/null 2>&1
ln -fs /usr/share/zoneinfo/$TIMEZONE /etc/localtime
dpkg-reconfigure -f noninteractive tzdata 2>&1
############
# Expand filesystem to the entire disk Raspberry - Automatically done on Rock64 with armbian distro
if [ -f "/usr/bin/raspi-config" ];then
echo "[*] Ask to Expand filesystem to the next reboot"
raspi-config --expand-rootfs > /dev/null 2>&1
if [ "$?" != "0" ];then
echo "[ERR] La demande d'expansion du FS root n'a pas aboutie"
echo " au prochain reboot exécutez, connecté root :"
echo " raspi-config --expand-rootfs"
echo " reboot"
fi
fi
### activer SSH (Buster)
echo "[*] Activation ssh"
systemctl enable ssh
## Autoriser la connexion root via ssh (décommentez les deux lignes si vous n'utilisez pas de clés publiques sinon impossibilité de se connecter après installation)
#echo "[*] Autoriser les connexions root"
#sed -i "s/#PermitRootLogin prohibit-password/PermitRootLogin yes/" /etc/ssh/sshd_config
# Désactivation autologin
echo "[*] Desactivation autologin sur PI"
sed -i -E "s/(^ExecStart=.*autolo.*)/ExecStart=-\/sbin\/agetty --noclear %I xterm-256color/" /etc/systemd/system/getty@tty1.service.d/autologin.conf 2>&1
Automate de paramétrage
Ce script présente de nombreuses commandes sans interception d’erreurs (#DONTCATCH). Ceci est un choix technique, les erreurs remonteront systématiquement dans le rapport, il est important d’aller jusqu’au bout pour permettre de rejouer ce même script en cas d’erreurs. La séquence est complexe pour intercepter les erreur et revenir en arrière.
# script.mtya
#cette function prend le préfixe des devices de type SDCARD ex: /dev/mmc...
function probesdcard {
export SDCARDDEV=""
# Probing if media ok
DEVICENUMS="0 1 2"
for num in $DEVICENUMS;do
/sbin/partprobe -d -s $1$num >/dev/null 2>/dev/null #DONTCATCH
ERR=$?
if [ "$ERR" = "0" ];then
SDCARDDEV=$1$num
break;
fi
done
if [ "$SDCARDDEV" = "" ];then
echo "[ERR] - La carte SD est introuvable"
# fin on ne peut aller plus loin
exit 1
fi
echo "[*] Carte SD détectée : $SDCARDDEV"
}
# Fonction permettant de detecter la partition système de la carte SD
# Parametre : device SDCARD
function getsystempartition {
export PARTITION=`fdisk -l $1 | grep " 83" | awk '{print $1;exit}'`
if [ "$PARTITION" = "" ];then
echo "[ERR] La partition système installée sur la carte SD n'a pas été trouvée (type de partition 83)"
exit 1
fi
}
# Fonction de montage SDCARD
# Parametres : device - point de montage
function mountSdcard {
mount|grep $1 #DONTCATCH
if [ "$?" = "1" ];then
echo "[*] Mounting $1 on $2"
mount $1 $2
fi
echo "[*] $1 Mounted on $2"
}
# Fonction de démontage SDCARD
# Parametre : device
function umountSdcard {
echo "[*] Unmounting $1"
umount $1
echo "[*] $1 Unmounted"
}
# Préparation du kit pour le chroot
function chrootkitmount {
# Mount necessary for chroot
for fs in $1;do
echo "[*] chroot montage $DEVICECHROOT sur $2/$fs"
mount --bind /$fs $2/$fs >/dev/null 2>/dev/null #DONTCATCH
done
}
# Démontage du kit chroot
function chrootkitumount {
# Mount necessary for chroot
for fs in $1;do
echo "[*] chroot demontage $2/$fs"
umount $2/$fs >/dev/null 2>/dev/null #DONTCATCH
done
}
# Génération avec apg de deux mot de passe
function genpassword {
if [ ! -f "/usr/bin/apg" ];then
echo "[*] Installation du paquet DEBIAN : apt - générateur aléatoire de mot de passe"
apt-get -y install apg > /dev/null 2>/dev/null
fi
# Get apg password root and mainuser (pi)
echo "[*] Génération des mots de passe (root et utilisateur principal)"
export PASSWORDROOT=$(apg -n 1 -m 15 -x 18)
export PASSWORDMAINUSER=$(apg -n 1 -m 15 -x 18)
}
# Variables obligatoires
#CHECK HOSTNAME
#CHECK TIMEZONE
#Exemple: TIMEZONE="Asia/Kolkata"
#CHECK LOCALE
#Exemple: LOCALE="en_GB.UTF-8"
#CHECK LOCALEENCODE
#Exemple: LOCALEENCODE="UTF-8"
#RESS actionschrooted.sh /tmp/actionschrooted.sh
#RESS sshkeys/sshkeybackuppc /tmp/sshkeybackuppc
EXECCHROOT="/tmp/actionschrooted.sh"
probesdcard "/dev/mmcblk"
getsystempartition "$SDCARDDEV"
genpassword #DONTCATCH
MOUNTPOINT="/mnt"
DEVICESCHROOT="dev sys proc run"
mountSdcard "$PARTITION" "$MOUNTPOINT" #DONTCATCH
chrootkitumount "$DEVICESCHROOT" "$MOUNTPOINT" #DONTCATCH
cp "$EXECCHROOT" "$MOUNTPOINT/$EXECCHROOT" #DONTCATCH
chrootkitmount "$DEVICESCHROOT" "$MOUNTPOINT" #DONTCATCH
chroot $MOUNTPOINT/. /bin/bash -c "/bin/bash \"$EXECCHROOT\" \"$HOSTNAME\" \"$PASSWORDROOT\" \"$PASSWORDMAINUSER\" \"$TIMEZONE\" \"$LOCALE\" \"$LOCALEENCODE\"" #DONTCATCH
chrootkitumount "$DEVICESCHROOT" "$MOUNTPOINT" #DONTCATCH
rm "$EXECCHROOT" #DONTCATCH
rm "$MOUNTPOINT/$EXECCHROOT" #DONTCATCH
### Installation des clés ssh sur root
mdkir -p $MOUNTPOINT/root/.ssh >/dev/null 2>&1 #DONTCATCH
AUTHKEYS="$MOUNTPOINT/root/.ssh/autorized_keys"
cat /tmp/sshkeybackuppc > $AUTHKEYS
umountSdcard "$PARTITION" #DONTCATCH
## Fin prêt au reboot
Exécution de l’automate
A cette étape le serveur est toujours démarré par le réseau. A partir du serveur automate, exécutez :
/opt/mytinydc/sbin/mytinydc-automation.sh setupserver raspi5 HOSTNAME="raspi5" TIMEZONE="Asia/Kolkata" LOCALE="en_GB.UTF-8" LOCALEENCODE="UTF-8"
Le serveur est maintenant prêt à être rebooté pour un démarrage autonome sur sa carte SD. Si vous enchaînez les automates, cela prend moins de 4 minutes. Il vous reste à installer les applications nécessaires à son intégration dans le Datacenter. Cette opération sera réalisée par des automates. Le mot de passe d’accès “root” est fourni dans le rapport d’installation, je conseille de le changer à la première connexion.
Redémarrage
Après redémarrage le serveur sera joignable par son ip ou son nom hôte avec le compte “root” ou à partir des unités ayant autorité sur ce serveur (dans le cas précité, seul le serveur de backup a autorité), via échange de clés SSH.
Aller plus loin
Cette démonstration présente les aspects pratiques de l’automatisation, à partir d’un cas concret. Les distributions sont livrées avec des paquets inutiles dans le cadre de votre utilisation, par exemple l’interface graphique. Pour désinstaller l’ensemble graphique : apt-get -y remove x11-common; apt-get -y autoremove. Cette commande désinstalle tout ce qui concerne l’interface graphique, ses dépendances et les logiciels dépendant de ce paquet. Vous pouvez créer plusieurs automates permettant l’installation automatisée de services nécessaires à la production…
Licence de ce document : Creative Commons (CC BY-NC-ND 4.0)
CETTE DOCUMENTATION EST LIVRÉE “EN L’ÉTAT”, SANS GARANTIE D’AUCUNE SORTE ET DISTRIBUÉE DANS UN BUT ÉDUCATIF EXCLUSIVEMENT. L’AUTEUR, CONTRIBUTEURS DE CETTE DOCUMENTATION OU ©MYTINYDC.COM NE SAURAIENT EN AUCUN CAS ÊTRE TENUS RESPONSABLES DES DOMMAGES DIRECTS OU INDIRECTS POUVANT RÉSULTER DE L’APPLICATION DES PROCÉDURES MISES EN ŒUVRE DANS CETTE DOCUMENTATION, OU DE LA MAUVAISE INTERPRÉTATION DE CE DOCUMENT.