Configuration d'un nouveau serveur au ResEl

Ce guide décrit toutes les étapes logicielles qui doivent être réalisées sur une nouvelle machine physique ou virtuelle. Il est suffisant, mais tous les services sont généralement décrits de manière plus complète dans les autres pages de ce wiki.

Cela va de soit, mais je vous conseille de parcourir ce guide une fois de haut en bas avant de configurer votre propre machine.

Ce guide décrit les étapes pour :

  1. Recenser la machine sur le LDAP
  2. Configurer la table de partitions
  3. Configurer le réseau sur la machine
  4. [A] Installer les paquets essentiels
  5. [A] Configurer la surveillance de la machine
  6. [A] S'assurer que la machine est sauvegardée
  7. [A] Outils annexes

Les étapes décrite avec [A] sont faisables automatiquement avec Ansible.

Avant de commencer

Bien qu'Ansible soit disponible pour réaliser la plupart de ces étapes, il est conseillé à tous les administrateurs de le faire eux-même au moins une fois. Rien ne remplace la pratique ;-)

Pour les machines virtuelles, il est recommandé d'utiliser les templates créés, et vérifiez bien que vous utilisez la dernière version du template Proxmox !

Avant l'installation assurez-vous de :

  • Penser à vous rendre dans le BIOS ou équivalent pour activer les options souhaitées, par exemple le RAID, l'hyperV...
  • Configurer l'IDRAC/ipmi si possible
  • Vérifier la configuration réseau, en particulier celle du Switch !
  • Avant d'installer un nouveau système sur machine physique, il convient de la tester : disques, mémoire...

Ajouter la machine au LDAP

Le LDAP est la base de données au ResEl permettant d'inventorier tout les serveurs actifs. Cette entrée est essentielle pour s'assurer que la machine est bien officielle.

Pour ajouter une machine il suffit de se rendre sur le site admin puis accéder à la page ajouter une machine. Attention à bien prendre des ip de libre (visible sur la page IPs disponibles) dans le bon VLAN.

Attention : il faut ajouter uniquement les 2 derniers octets des adresses IPv4, regardez les autres fiches pour voir comment c'est fait !

Table des partitions

Machine virtuelle

Pour les machines virtuelles il est recommandé de ne pas faire de table de partition, sauf dans de rares cas. Utilisez le gabarit Proxmox créé en cas de doute.

TODO (rédacteur) :

Machine physique

TODO (rédacteur) :

  • Configuration LVM machines physiques

Ressources

Réseau

Vous devez IMPÉRATIVEMENT configurer une IP fixe, pas de DHCP ! En effet, si un reboot accidentel survient à un moment où le serveur DHCP est indisponible (exemple : longue coupure de courant, les DNS qui tombent), l'interface ne sera pas configurée et le serveur sera ainsi injoignable.

Préparation

Si vous travaillez sur une machine virtuelle, vérifiez sur Proxmox que vous avez bien ajouté toutes les interfaces dont vous avez besoin, dont au moins 1 sur le VLAN admin. Choisissez de préférence une interface de type VirtIO sur le vmbr1.

warning par défaut Proxmox crée une interface de type Intel E1000 sur le vmbr1 il faut impérativement le changer, sinon ça ne fonctionnera pas.

Si vous travaillez sur une machine physique assurez-vous que vos ports Ethernet soient bien branchés, et que les switchs soient bien configurés pour faire passer les VLAN nécessaires.

Dans tous les cas, vérifiez bien que les mac soient sur la fiche de la machine dans le LDAP, et que les adresses ip ne soient pas utilisées pour autre chose.

Configuration

Sur la machine vous pouvez voir la liste des interfaces disponible en tapant la commande 

ip link

Choisissez-en une (ex. ici eth0) Ajoutez les lignes suivantes dans le fichier /etc/network/interfaces : *NOTE IMPORTANTE : * Debian 9 ne supporte pas les commentaires en fin de ligne dans ce fichier (ils sont autorisé uniquement sur une ligne complète). Pensez à ne pas les recopier. 

allow-hotplug eth0
iface eth0 inet static
        address 172.22.2.81

        # /23
        netmask 255.255.254.0

        # VLAN Admin
        network 172.22.2.0

        # Optionnal
        broadcast 172.22.3.255

        # Optionnal, especially if another network is configured
        gateway 172.22.3.254

        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 172.22.2.229
        dns-search adm.resel.fr

        # Route vers Rennes
        up ip route add 172.23.2.0/23 via 172.22.3.254 dev eth0
Sur le même modèle ajoutez les autres lignes pour les autres interfaces. N'oubliez pas qu'il faut une seule gateway pour toutes les interfaces qui sera la passerelle par défaut.

Pour les DNS, rien de plus simple, éditez le fichier /etc/resolv.conf : 

options timeout:1
search adm.resel.fr adm.rennes.resel.fr resel.fr rennes.resel.fr 
nameserver 172.22.2.229
nameserver 172.22.2.32
nameserver 172.23.2.229

Redémarrez le réseau, puis vérifiez que tout fonctionne : 

systemctl restart networking
ping pegase

Ressources

La suite avec Ansible

Ansible est un outil permettant d'automatiser de nombreuses tâches.

Avant de provisionner le serveur assurez vous bien de :

  • Avoir créé une fiche LDAP
  • Configuré les partitions et le réseau sur la machine
  • Avoir le paquet sudo installé sur la machine et un compte sudoer
  • Avoir SSH de configuré sur la machine

Rendez-vous sur Loustic puis modifiez le fichier /srv/playbooks/provision-servers.yml.

Modifiez la ligne 

- hosts: gargantua

Avec le nom de la machine que vous désirez provisionner. Vous pouvez si vous le désirez provisionner plusieurs machines en séparant les noms par des virgules 

- hosts: rescuerad, braum

Enfin lancez le playbook avec votre utilisateur local lcarr dans mon cas : 

ansible-playbook -kK /srv/playbooks/provision-server.yml
Faites un yes pour accepter le certificat du serveur que vous installez. puis patientez.

La suite sans Ansible

La gestion de paquets

Nous utilisons au ResEl Debian et nous sommes en 2017 donc nous utilisons la commande apt. Avant de pouvoir installer des paquets il faut s'assurer que les miroirs ResEl soient bien configurés. Vous avez lors du bootstrap de la machine déjà utilisé le miroir ResEl situé à l'adresse suivante : http://miroir.resel.fr/debian/.

Le playbook Ansible apt-full-conf.yml est normalement suffisant. Cependant, voici la configuration manuelle :

Miroir ResEl

La première étape est de configurer les miroirs. Ceux-ci permettent à la fois d'économiser de la bande passante en ne téléchargeant qu'une seule fois les données dans le réseau, mais aussi de pouvoir tout simplement d'accéder aux miroirs sur les réseaux qui n'ont pas internet (le VLAN admin par exemple).

Configurez les miroirs ResEl en modifiant votre fichier /etc/apt/source.list pour ressembler à ceci : 

deb http://miroir.adm.resel.fr/debian/ stretch main contrib non-free
deb-src http://miroir.adm.resel.fr/debian/ stretch main contrib non-free

deb http://miroir.adm.resel.fr/debian/ stretch-updates main contrib non-free
deb-src http://miroir.adm.resel.fr/debian/ stretch-updates main contrib non-free

# Security
deb http://pegase.adm.resel.fr:9999/debian-security stretch/updates main contrib non-free
deb-src http://pegase.adm.resel.fr:9999/debian-security/ stretch/updates main contrib non-free

warning Il faut bien vérifier que le tagname de la distro est le nom de code et pas le statut, jessie et non stable, pour éviter une mise à jour système malencontreuse aux périodes de freeze.

Proxy ResEl

Pour profiter des proxy ResEl créez un fichier /etc/apt/apt.conf.d/01reselproxy : 

Acquire::http::proxy::bugs.debian.org "http://pegase.adm.resel.fr:3128";
Acquire::https::proxy::bugs.debian.org "http://pegase.adm.resel.fr:3128";
Acquire::http::proxy::security.debian.org "http://pegase.adm.resel.fr:3128";
Acquire::https::proxy::security.debian.org "http://pegase.adm.resel.fr:3128";

Le proxy est volontairement configuré pour ne pas accéder à tous les sites, mais uniquement bugs.debian.org et security.debian.org. Si vous désirez ajouter d'autres sources, n'hésitez pas à les ajouter au proxy.

apt update

Vérifiez que tout fonctionne bien, et mettez à jour : 

apt update
apt upgrade

Pour la suite de ce guide, nous aurons besoin des paquets suivants : 

apt install apticron apt-listchanges apt-listbugs

Apticron

apticron s'occupe de vérifier régulièrement la disponibilité des mises à jour, et en informer une adresse par e-mail. Éditez le fichier /etc/apticron/apticron.conf : 

  EMAIL="update-debian@resel.fr"
  SYSTEM=" nom_de_la_machine : description de la machine "
Par exemple pour gitu : 
SYSTEM="Gitu : La machine de Gitlab"

Listchanges

Listchanges va informer par e-mail les administrateurs lorsqu'une mise à jour est effectuée. Éditez le fichier /etc/apt/listchanges.conf : 

  [apt]
  frontend=mail
  email_address=update-debian@resel.fr
  confirm=0
  save_seen=/var/lib/apt/listchanges.db
  which=both

Les paquets indispensables

Pour nous simplifier la vie, et harmoniser les paquets installés sur toutes les machines du ResEl, nous allons installer quelques paquets indispensables : 

apt install ssh sudo tmux vim emacs-nox postfix ntp ntpdate

Je vous propose quelques paquets très utiles, installez-les si vous pensez que c'est nécessaire. Cependant prenez note : chaque paquet installé en plus est une faille de sécurité potentielle en plus !

Git pour car on versionne nos configurations : 

apt install git

Des outils de compilation (ma maman m'a dit de ne jamais mettre un compilateur sur une machine de prod) : 

apt install build-essential linux-header linux-source patchutils

Quelques outils réseau (ma maman me faisait manger du savon quand je mettais des outils de réseau sur un serveur de prod): 

apt install tcpdump nmap dnsutils traceroute tcptraceroute arping vlan

ZSH parce que c'est bon pour la santé : 

apt install zsh

Configuration initiale

Après avoir installé les paquets importants, nous allons les configurer. Cette étape est très importante car c'est celle-ci qui nous permettra d'avoir une configuration homogène et sécurisée au ResEl.

Configuration de sshd

SSHD est le service permettant de se connecter à distance à une machine. Il est essentiel de bien le configurer pour éviter les intrusions dans le réseau.

Ce service est configuré avec l'aide du playbook Ansible deploy-ssh-keys.yml. Attention, il faut activer l'option configure_sshd: False dans le rôle sshd sur le serveur voulu.

Voici les options qui doivent apparaître impérativement dans /etc/ssh/sshd_config :

Protocol 2
ListenAddress <adresse ip de la patte d'admin vlan997>
PermitRootLogin no
StrictModes yes
PermitEmptyPasswords no
AllowGroups sshusers
Pour éviter que n'importe quel utilisateur puisse se connecter sur les machines, nous utilisons un groupe s'appellant sshusers. Seuls les utilisateurs de ce groupe peuvent se connecter à la machine. 
groupadd sshusers

Puis ajoutez les utilisateurs que vous désirez dans le groupe : 

adduser lcarr sshusers
adduser mrobin sshusers

Quelques liens

Configuration de sudo

sudo est la commande linux permettant de déléguer une commande à un autre utilisateur, typiquement root.

La configuration par défaut devrait suffire, simplement vérifiez que le groupe sudo est bien défini dans le visudo : 

visudo
Doit contenir : 
%sudo   ALL=(ALL:ALL) ALL

Configuration de la gestion du temps

Voir aussi : Le NTP au ResEl

Le client NTP (Network Time Protocol) permet aux différents pc du ResEl d'être à la même heure, ce qui est bien utile lorsqu'un problème survient et que l'on doit étudier les logs. On préfère installer un serveur de temps local sur chaque serveur, ce qui présente l'avantage d'une synchronisation continue.

Le serveur de temps du ResEl est disponible à l'adresse ntp[.adm|.adm-pub].resel.fr. Une fois le paquet ntp installé, il faut modifier la variable server dans /etc/ntp.conf : 

server ntp.adm.resel.fr iburst dynamic

Configuration de ZSH

ZSH est un super shell que l'on aime bien utiliser au ResEl. Vous pouvez mettre la configuration "ResEl" par défaut avec le playbook zsh.yml.

TODO (rédacteur) :

  • Détailler la configuration par défaut

Monitoring

Voir aussi : le monitoring au ResEl

Le monitoring est une partie essentielle de la configuration de la machine, ne la négligez pas.

Serveur de mail

Voir aussi : Gestions des mails machines

L'envoi de mails est la méthode la plus basique pour surveiller une machine. De nombreuses informations passent par les e-mails, c'est la méthode historique, et elle risque de rester la méthode principale pendant un moment.

Configuration initiale de postfix

En lançant un apt install postfix, une interface de configuration debconf se lance. S'il est déjà installé, utilisez dpkg-reconfigure postfix. Dans ce menu, il faut utiliser les flèches directionnelles et pour se déplacer, espace pour cocher une case, entrée pour valider une action.

Suivez les étapes : 1. Sélectionner Internet with smarthost, ok. 2. Choisir le system mail name : <nom de la machine>.adm.resel.fr, ok. 3. Ajout du relais pegase.adm.resel.fr.

Modification de main.cf

Il est maintenant nécessaire d'ajouter un alias pour transmettre les mails à @resel.fr au lieu de @<machine>.adm.resel.fr.

On va donc modifier le fichier indiqué /etc/postfix/main.cf. Normalement, dans le dernier bloc de texte, vous pouvez lire la ligne 

relayhost = pegase.adm.resel.fr

dans laquelle vous allez ajouter des crochets autours de pegase.adm.resel.fr pour éviter la résolution du MX. Vous obtiendrez :

relayhost = [pegase.adm.resel.fr]

Dans certains cas, on ne souhaite pas que le serveur postfix n'écoute pas sur tous les ports. En particulier si la machine à accès au vlan adm-pub, où un utilisateur pourrait spam la machine sur son serveur smtp (port 25). Il faut donc changer les interfaces d'écoute.

Dans main.cf, remplacez inet_interfaces = all par inet_interfaces = 172.22.2.x, avec l'ip de machine dans le vlan admin.

Modification des alias

pour rediriger les mails vers les @resel.fr, on va maintenant modifier le fichier contenant les alias /etc/alias Qui de base ressemble à ceci (pas besoin de s'attarder sur les vale urs attribuées par défaut). 

# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: tcantin
Avec cette configuration, tous les mails seront envoyés à tcantin@<machine>.adm.resel.fr (en remplaçant évidemment par le nom de la machine.

On va modifier le fichier de sorte que tous les messages soient plutôt envoyés à root@resel.fr, et les mails de sécurité vers security@resel.fr. De cette manière, on a envoie tous les mails des machines aux heureux inscrits à la mailing-liste de flood.

Finalement, le fichier va donc ressembler à ceci 

# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: security@resel.fr
root: root@resel.fr

Application des changements

Rechargez postifx.

/etc/init.d/postfix reload

Log des événements

Voir aussi : Monitoring/Syslog

Le ResEl utilise LogCheck pour surveiller l'activité sur le serveur. Installer syslog-ng (qui remplace rsyslog ou syslogd qui est installé par défaut), et dans /etc/syslog-ng/syslog-ng.conf.

Pour envoyer les logs vers veronica, comme indiqué à la fin du fichier de conf par défaut, créer un nouveau fichier dans /etc/syslog-ng/conf.d/. Appelez le veronica.conf par exemple (il faut obligatoirement terminer le nom de fichier par .conf pour qu'il soit pris en compte) et ajoutez-y les lignes suivantes:

#########################################
#   Envoi des logs au serveur de logs   #
#########################################

destination serveur_logs { udp("172.22.2.6" port(514)); };
log { 
        source(s_src); 
        destination(serveur_logs);
};

Puis relancer le service : 

sudo systemctl restart syslog-ng

TODO: Il y a un rsyslog sur 2-3 machines. Se décider, harmoniser.

Icinga2

Voir aussi : Monitoring/Icinga

Ajouter un fichier dans la configuration de Icinga2 sur le master eris, dans /etc/icinga2/zones.d/ et reload icinga2. 

sudo icinga2 daemon --validate
sudo systemctl restart icinga2

Munin

Voir aussi : Monitoring/Munin

Installer munin-node et munin-plugins-extra sur la machine.

sudo apt-get install  munin-node munin-plugins-extra
sudo ln -s /usr/share/munin/plugins/apt /etc/munin/plugins/apt

Dans le fichier de configuration /etc/munin/munin-node.conf, enlever l'écoute sur toutes les interfaces (host *), et à la place spécifier l'IP dans la zone admin et le port 4949. Il faut aussi permettre à Eris et DGSI de contacter la machine, donc ajouter (à adapter si la machine n'a pas d'interface dans le 997) : 

allow ^172\.22\.2\.158$
allow ^172\.22\.2\.87$

Ajouter ce qu'il faut grapher dans /etc/munin/plugins/ (typiquement, des symlinks vers /usr/share/munin/plugins -- attention, pour les interfaces réseaux par exemple le nom du lien est important).

À savoir vous pouvez configurer automatiquement les plugins en lancant la commande : 

munin-node-configure --shell --families=contrib,auto | sh -x

Attention à vérifier tout de même que la commande a bien configuré ce qu'il vous faut, et n'hésitez pas à ajouter les plugins qui manquent.

Sur DGSI, ajouter la machine à la liste de celles qu'il faut scanner, dans /etc/munin/munin.conf.

Attention, le plugin APT est (encore) buggué, voir le ticket résolu à ce sujet.

BackupPC

Voir sur BackupPC

S.M.A.R.T. (uniquement machines physiques)

Voir aussi Monitoring/S.M.A.R.T.

Les données S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) permettent aux disques durs et SSD de remonter de nombreux indicateurs sur leur durée de vie, leurs cycles de fonctionnement, leur usage,... Sur Linux, un programme permettant de récupérer ces informations est smartmontools : 

apt install smartmontools
Pour l'activer sur le disque /dev/sdX, lancer : 
smartctl --smart=on --offlineauto=on --saveauto=on /dev/sdX

Pour activer le daemon il faut décommenter "start_smartd=yes" dans /etc/default/smartmontools.

Il faut également éditer le fichier de configuration /etc/smartd.conf, commenter la ligne commençant par DEVICESCAN et ajouter une ligne par disque. On peut par exemple surveiller tous les attributs et programmer un test court par jour (à 05h) et un test long par semaine (le mardi à 05h, en faible affluence), en cas d'erreur un mail sera envoyé à root. 

/dev/sda -a -o on -S on -s (S/../.././05|L/../../6/05) -m root
/dev/sdb -a -o on -S on -s (S/../.././05|L/../../6/05) -m root

Onduleurs (uniquement machines physiques)

Voir aussi Monitoring/S.M.A.R.T.

Si la machine est une machine physique il faut qu'elle écoute un onduleur pour pouvoir s'éteindre en toute sécurité.

Il faut commencer par mettre le tableau des Onduleurs à jour et définir une priorité à la machine. Il faut ensuite installer apcupsd : 

apt-get install apcupsd
Puis le configurer :

Passer ISCONFIGURED à yes dans /etc/default/apcupsd Éditer le fichier de conf /etc/apcupsd/apcupsd.conf et changer les paramètres suivants : 

 UPSCABLE smart
 UPSTYPE net
 DEVICE 172.22.2.8  #L'IP du serveur correspondant à l'onduleur sur lequel la machine est branché

 BATTERYLEVEL 50 #Le niveau correspondant à la priorité de la machine
 MINUTES 6  #Le temps correspondant à la priorité de la machine

Relancer le daemon : sudo systemctl restart apcupsd

Tester la connexion : apcaccess

Félicitations, votre serveur à ce moment devrait être parfaitement fonctionnel et prêt à l'emploi.

TODO (rédacteur)

  • Mise en forme
  • Réorganisation (install paquets / config, séparation machine physique / virtuelle)
  • Débat rsyslog / syslog-ng (?) -> ELK (projet en cours)
  • Lien BackupPC