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 :
- Recenser la machine sur le LDAP
- Configurer la table de partitions
- Configurer le réseau sur la machine
- Installer les paquets essentiels
- Configurer la surveillance de la machine
- S'assurer que la machine est sauvegardée
- Outils annexes
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 simplement il suffit de se rendre sur le site admin
puis accéder à la page ajouter une machine
. Ensuite c'est très simple, il suffit de suivre
les instructions. 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) :
- expliquer la méthode pour faire sans table, cf : https://www.debian.org/releases/stable/amd64/apds03.html.fr / https://wiki.debian.org/fr/Debootstrap
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
.
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écéssaires.
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
:
allow-hotplug eth0
iface eth0 inet static
address 172.22.2.81
netmask 255.255.254.0 # /23
network 172.22.2.0 # VLAN Admin
broadcast 172.22.3.255 # Optionnal
gateway 172.22.3.254 # Optionnal, especially if another network is configured
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 172.22.2.230
dns-search adm.resel.fr
up ip route add 172.23.2.0/23 via 172.22.3.254 dev eth0 # Route vers Rennes
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 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/ jessie main contrib non-free
deb-src http://miroir.adm.resel.fr/debian/ jessie main contrib non-free
deb http://miroir.adm.resel.fr/debian/ jessie-updates main contrib non-free
deb-src http://miroir.adm.resel.fr/debian/ jessie-updates main contrib non-free
# Security
deb http://pegase.adm.resel.fr:9999/debian-security jessie/updates main contrib non-free
deb-src http://pegase.adm.resel.fr:9999/debian-security/ jessie/updates main contrib non-free
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 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
. Il faut modifier la variable server dans /etc/ntp.conf
:
server ntp.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
TODO: Tout ce qui suit c'est du charabia, si vous comprenez félicitations. Moi je ne comprends rien...
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.
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
.
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 BackpPC
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