Configuration d'un nouveau serveur au ResEl

Avant de commencer

Ce guide décrit toutes les étapes qui doivent être réalisées au niveau software sur une nouvelle machine physique ou une machine virtuelle. Il se veut suffisant à lui même, mais tous les services sont généralement décrits de manière plus complète dans d'autres pages de ce wiki.

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 !

Quelques points en plus à considérer avant l'installation :

  • Avant d'installer un nouveau système sur machine physique, il convient de la tester : disques, mémoire...
  • 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érifiez la configuration réseau, en particulier celle du switch !

Ajouter la machine au LDAP

Se rendre sur le site admin et dans le menu "ajouter une machine". C'est très simple, il suffit de suivre les étapes :)

Table des partitions

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

TODO : machines physiques (LVM principalement)

Réseau

Configuration en ip fixe IMPÉRATIVE, pas de DHCP ! En effet, si un reboot accidentel survient à un moment où le serveur dhcp est indisponible (exemple : longue coupure de courant), l'interface ne sera pas configurée et le serveur sera ainsi injoignable. Dans le /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

Les paquets indispensables

Il faut pouvoir se connecter à distance sur la machine et permettre à certaines personnes autorisées de pouvoir passer root, et pouvoir laisser un programme tourner, même déconnecté (utile en cas de compilation, ou si on perd la connexion de façon accidentelle) : 

apt-get install ssh sudo tmux vim postfix ntp ntpdate

Au ResEl, on versionne les configurations : 

apt-get install git

Enfin, très fortement dépendant de la machine à mettre en place ou des besoins ponctuels, quelques utilitaires pour la gestion du réseau, ou la compilation : 

apt-get install tcpdump nmap dnsutils traceroute tcptraceroute arping vlan
apt-get install build-essential linux-header linux-source git patchutils
[TODO: vérifier le nom des paquets]

Configuration de sshd

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
Et bien sûr, créer le groupe sshusers et ajouter les administrateurs humains dans le groupe sshusers.

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. Il faut modifier la variable server dans /etc/ntp.conf : 

server ntp.resel.fr iburst dynamic
[TODO: Second serveur de temps ?]

Monitoring

Voir aussi : le monitoring au ResEl

Serveur de mail

Voir aussi : Gestions des mails machines

Il faut dans tous les cas configurer le serveur mail, afin de faire suivre les mails donnant le résultat des commandes programmées (crontab), etc. Les écrans debconf de exim4 ou postfix permettent de configurer facilement un serveur qui se contente d'envoyer des mails, il s'agit d'un « smarthost ». Les mails sont à faire suivre au serveur de courrier du ResEl. Le serveur SMTP ne doit pas écouter sur l'interface eth0, ce n'est pas nécessaire. En éditant /etc/aliases, les mails destinés au root local sont généralement transmis à root@.resel.fr.

Exemple pour Postfix : internet with smarthost, avec un relais pegase.adm.resel.fr et l'envoi des mails root locaux à root@…, ainsi que les mails de security vers security@…. Il convient de modifier /etc/postfix/main.cf et mettre en crochets [pegase.adm.maisel.enst-bretagne.fr] pour éviter d'utiliser la résolution du MX.

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, ajouter le paragraphe suivant à la fin du fichier pour envoyer les logs vers veronica :

#########################################
#   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.

Mises à jour

Installer apticron, apt-listchanges et apt-listbugs.

  • apticron, éditer le fichier /etc/apticron/apticron.conf, 
      EMAIL="update-debian@resel.fr"
  SYSTEM=" nom_de_la_machine : description de la machine "
    Exemple pour gitu :

SYSTEM="Gitu : La machine de Gitlab"

  • Listchanges, éditer 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
  • sources.list : Indiquer à la machine où aller chercher ses mises à jour. Pour Debian, le ResEl dispose de son propre miroir : 
deb ftp://miroir.resel.fr/debian jessie main
deb-src ftp://miroir.resel.fr/debian jessie main

deb ftp://miroir.resel.fr/debian jessie-updates main
deb-src ftp://miroir.resel.fr/debian jessie-updates main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

BackupPC

TODO

S.M.A.R.T.

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-get 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

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

Normalement 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