Installations automatisées de nouveaux serveurs (provision de serveurs)

Installations automatisées de nouveaux serveurs (provision de serveurs)

25 juillet 2019 Admin système Support 0

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ée, 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 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 “bootera” sur la 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/id_rsa.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ée 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é “/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ème officiels devront être téléchargée et compressées au format zip, puis copié 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 a 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 documentCreative 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.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

8 + 1 =

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.