Configuration

L'établissement d'appartenance du serveur doit déjà exister dans la base des serveurs.

La procédure d'enregistrement est requise pour tous les serveurs à administrer avec Zéphir. Elle permet de créer les données nécessaires dans la base de données et de configurer la transmission sécurisée entre Zéphir et le serveur. L'enregistrement est effectué manuellement sur le module avec la commande enregistrement_zephir.

Une fois la procédure terminée, la configuration du module peut être effectuée depuis le serveur selon le mode autonome synchronisé ou depuis l’application Zéphir.

Sur l’application Zéphir, l’application de configuration du module est accessible depuis la page d’état du serveur via le lien modifier affiché dans la section Configuration du tableau,

Cette application de configuration du module se comporte de manière semblable à celle exécutée depuis le serveur lui-même à quelques détails près :

• certains calculs et contraintes nécessitant l’accès direct au serveur configuré sont désactivés ;

• la page de différences entre la configuration appliquée sur le module et la configuration associée au module dans l’application Zéphir n’est disponible que pour les modules à jour à partir de la version 2.8.1 et à condition qu’une première synchronisation ait été effectuée sans erreur.

• cette page de différences est simplifiée.

En cas de différences entre la configuration appliquée sur le module et la configuration associée au module dans l’application Zéphir, il est demandé à l’administrateur de choisir quelle version, globalement, servira comme base de configuration pour l’édition.

La configuration éditée via cette application de configuration du module intégrée à l’application Zéphir n’est pas directement synchronisée avec celle du serveur mais nécessite une action pour l’envoyer.

Pour désinscrire un serveur il faut exécuter la commande enregistrement_zephir et la désinscription est proposée.

root@eolebase:~# enregistrement_zephir 

  Procédure d'enregistrement sur le serveur Zéphir 

** Ce serveur est déjà enregistré sur le serveur Zéphir **

 - n°identifiant : 454

 - adresse de Zéphir : zephir.ac-test.fr 

1 -> Désinscrire ce serveur du serveur Zéphir

2 -> Relancer l'enregistrement

3 -> Ne rien faire

  Entrez le numéro de votre choix : 1

Désinscription auprès du serveur Zéphir terminée

root@eolebase:~#

root@eolebase:~# enregistrement_zephir 

  Procédure d'enregistrement sur le serveur Zéphir 


** Ce serveur est déjà enregistré sur le serveur Zéphir **

 - n°identifiant : 454
 - adresse de Zéphir : zephir.ac-test.fr 

1 -> Désinscrire ce serveur du serveur Zéphir
2 -> Relancer l'enregistrement
3 -> Ne rien faire

  Entrez le numéro de votre choix : 1

Désinscription auprès du serveur Zéphir terminée

root@eolebase:~#

Deux informations sont importantes pour l'établissement :

• l'Identifiant de l'établissement, qui doit être unique ;
• le Nom de l'établissement.

Ces informations sont notamment utiles pour Zéphir, les applications web locales, ....

Sur les modules fournissant un annuaire LDAP^[11] local, ces variables sont utilisées pour créer l'arborescence.

En premier lieu, il convient de configurer le nom DNS du serveur.

Cette information est découpée en 2 champs :

• le nom de la machine dans l'établissement ;
• le nom DNS du réseau local.

Le Nom de la machine est laissé à l'appréciation de l'administrateur.

Le Nom DNS du serveur utilise fréquemment des domaines de premier niveau du type .lan

C'est ce nom qui configurera le serveur DNS (sur un module Amon par exemple) comme zone de résolution par défaut. Il sera utilisé par les machines pour résoudre l'ensemble des adresses locales.

Rappel : les outils mDNS (Avahi, Bonjour, ... ) utilise la racine '.local'. Pour éviter les problèmes de DNS, nous vous déconseillons d'utiliser cette racine.

En deuxième lieu, il convient de configurer les noms de domaine de la machine.

Cette information est découpée en plusieurs champs :

• le nom du domaine privé utilisé à l'intérieur de l'établissement ;
• le nom de domaine académique et son suffixe.

Si le module doit utiliser un proxy pour accéder à Internet, il faut activer cette fonctionnalité en passant la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.

Il devient alors possible de saisir la configuration du serveur proxy :

• nom de domaine ou adresse IP du serveur proxy ;
• le port du proxy.

Par rapport au protocole HTTP^[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.

Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).

En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.

Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.

Un certificat HTTPS est émis par une autorité de certification^[13].

Let's Encrypt^[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.

À partir de la version 2.8.1, le module Amon est équipé d'une fonctionnalité d'interception du trafic HTTPS. Il est possible de déclarer son certificat racine servant à sur-signer les ressources servies par le protocole HTTPS et transitant par le proxy filtrant. Cette déclaration permet d'en automatiser l'intégration dans le magasin de certificats local.

Si la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet est passée à oui, la variable Le serveur mandataire intercepte les communications HTTPS est proposée et permet elle-même de faire apparaître deux variables permettant d’identifier le certificat racine employé par le proxy filtrant.

En passant la variable Le serveur mandataire intercepte les communications HTTPS à oui, il est possible de renseigner les variables suivantes en utilisant les données affichées par la commande diagnose sur le module Amon :

• Type d’empreinte du certificat racine du proxy : SHA256 (par défaut sur Amon 2.8.1)
• Empreinte du certificat racine du proxy : information donnée par le diagnose du serveur Amon dans le cas où celui-ci fait office de proxy filtrant

Cette configuration est nécessaire uniquement lorsque le module Amon est configuré pour l’interception des communications HTTPS.

La variable Adresse IP du serveur DNS donne la possibilité de saisir une ou plusieurs adresses IP du ou des serveur(s) de noms DNS^[3].

La variable Fuseau horaire du serveur vous permet de choisir votre fuseau horaire dans une liste conséquente de propositions.

Trois types de certificats peuvent être utilisés pour sécuriser les connexions avec TLS^[15] :

• autosigné : le certificat est généré localement et signé par une CA^[13] locale ;

• letsencrypt : le certificat est généré et signé par l'autorité Let's Encrypt^[14] ;

• manuel : le certificat est mis en place manuellement par l'administrateur. Pour ce faire, il faut disposer au préalable des certificats fournis par l'autorité de certification, si ce n'est pas encore le cas, le choix autosigné permet d'utiliser le serveur de façon non optimale. Le répertoire /etc/ssl/certs/ est recommandé pour placer les certificats.

Avant toute chose, il faut décider comment la carte réseau est configurée.

Pour cela, il existe trois possibilités : statique^[16], DHCP^[17] ou non géré.

Dans le cas de la configuration statique, il faut renseigner l'adresse IP, le masque et la passerelle.

La configuration DHCP ne nécessite aucun paramétrage particulier.

L'utilisation de la nouvelle valeur non gérée permet de déléguer la configuration réseau à cloud-init^[18] ou à un autre outil de contextualisation.

Par défaut les accès SSH^[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.

Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.

Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.

Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….

Les paramètres communs à renseigner sont les suivants :

• Nom de domaine de la messagerie de l'établissement (ex : monetab.ac-aca.fr), saisir un nom de domaine valide, par défaut un domaine privé est automatiquement créé avec le préfixe i-;

• Adresse électronique d'envoi pour le compte root, saisir l'adresse que l'on souhaite utiliser pour l'envoi de courriers électroniques depuis le compte root.

• Adresse électronique recevant les courriers électroniques à destination du compte root, permet de configurer une adresse pour recevoir les éventuels messages envoyés par le système.

La variable Passerelle SMTP, permet de saisir l'adresse IP ou le nom DNS de la passerelle SMTP à utiliser.

Deux informations sont importantes pour l'établissement :

• l'Identifiant de l'établissement, qui doit être unique ;
• le Nom de l'établissement.

Ces informations sont notamment utiles pour Zéphir, les applications web locales, ....

Sur les modules fournissant un annuaire LDAP^[11] local, ces variables sont utilisées pour créer l'arborescence.

En premier lieu, il convient de configurer le nom DNS du serveur.

Cette information est découpée en 2 champs :

• le nom de la machine dans l'établissement ;
• le nom DNS du réseau local.

Le Nom de la machine est laissé à l'appréciation de l'administrateur.

Le Nom DNS du serveur utilise fréquemment des domaines de premier niveau du type .lan

C'est ce nom qui configurera le serveur DNS (sur un module Amon par exemple) comme zone de résolution par défaut. Il sera utilisé par les machines pour résoudre l'ensemble des adresses locales.

Rappel : les outils mDNS (Avahi, Bonjour, ... ) utilise la racine '.local'. Pour éviter les problèmes de DNS, nous vous déconseillons d'utiliser cette racine.

En deuxième lieu, il convient de configurer les noms de domaine de la machine.

Cette information est découpée en plusieurs champs :

• le nom du domaine privé utilisé à l'intérieur de l'établissement ;
• le nom de domaine académique et son suffixe.

Un module EOLE peut avoir de 1 à 5 cartes réseau.

Suivant le module installé, un nombre d'interface est pré-paramétré. Il est possible d'en ajouter en sélectionnant la valeur du nombre total d'interfaces souhaitées dans le menu déroulant. Cela ajoute autant d'onglet Interface-n que le nombre d'interfaces à activer choisi.

Si le module doit utiliser un proxy pour accéder à Internet, il faut activer cette fonctionnalité en passant la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.

Il devient alors possible de saisir la configuration du serveur proxy :

• nom de domaine ou adresse IP du serveur proxy ;
• le port du proxy.

Par rapport au protocole HTTP^[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.

Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).

En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.

Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.

Un certificat HTTPS est émis par une autorité de certification^[13].

Let's Encrypt^[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.

À partir de la version 2.8.1, le module Amon est équipé d'une fonctionnalité d'interception du trafic HTTPS. Il est possible de déclarer son certificat racine servant à sur-signer les ressources servies par le protocole HTTPS et transitant par le proxy filtrant. Cette déclaration permet d'en automatiser l'intégration dans le magasin de certificats local.

Si la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet est passée à oui, la variable Le serveur mandataire intercepte les communications HTTPS est proposée et permet elle-même de faire apparaître deux variables permettant d’identifier le certificat racine employé par le proxy filtrant.

En passant la variable Le serveur mandataire intercepte les communications HTTPS à oui, il est possible de renseigner les variables suivantes en utilisant les données affichées par la commande diagnose sur le module Amon :

• Type d’empreinte du certificat racine du proxy : SHA256 (par défaut sur Amon 2.8.1)
• Empreinte du certificat racine du proxy : information donnée par le diagnose du serveur Amon dans le cas où celui-ci fait office de proxy filtrant

Cette configuration est nécessaire uniquement lorsque le module Amon est configuré pour l’interception des communications HTTPS.

La variable Adresse IP du serveur DNS donne la possibilité de saisir une ou plusieurs adresses IP du ou des serveur(s) de noms DNS^[3].

La variable Fuseau horaire du serveur vous permet de choisir votre fuseau horaire dans une liste conséquente de propositions.

Une liste de serveurs de temps (NTP^[4]) à utiliser est proposée par défaut.

Il est possible de modifier ces valeurs afin d'utiliser un serveur de temps personnalisé.

Trois types de certificats peuvent être utilisés pour sécuriser les connexions avec TLS^[15] :

• autosigné : le certificat est généré localement et signé par une CA^[13] locale ;

• letsencrypt : le certificat est généré et signé par l'autorité Let's Encrypt^[14] ;

• manuel : le certificat est mis en place manuellement par l'administrateur. Pour ce faire, il faut disposer au préalable des certificats fournis par l'autorité de certification, si ce n'est pas encore le cas, le choix autosigné permet d'utiliser le serveur de façon non optimale. Le répertoire /etc/ssl/certs/ est recommandé pour placer les certificats.

Il est possible de définir d'autres adresses pour le serveur de mise à jour EOLE que celles fournies par défaut, dans le cas où vous auriez, par exemple, un miroir des dépôts.

Avant toute chose, il faut décider comment la carte réseau est configurée.

Pour cela, il existe trois possibilités : statique^[16], DHCP^[17] ou non géré.

Dans le cas de la configuration statique, il faut renseigner l'adresse IP, le masque et la passerelle.

La configuration DHCP ne nécessite aucun paramétrage particulier.

L'utilisation de la nouvelle valeur non gérée permet de déléguer la configuration réseau à cloud-init^[18] ou à un autre outil de contextualisation.

Par défaut les accès SSH^[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.

Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.

Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.

Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….

EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.

Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.

Il est possible de configurer des VLAN^[22] (réseau local virtuel) sur une interface déterminée du module.

Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :

• le numéro du VLAN ;

• l'adresse IP de l'interface dans ce VLAN ;

• le masque de sous-réseau de l'interface dans ce VLAN.

Il est possible de configurer une passerelle particulière pour un VLAN de l'interface 0.

Même si le nom de l'onduleur n'a aucune conséquence, il est obligatoire de remplir cette valeur dans le champ Nom pour l'onduleur.

Il faut également choisir le nom du pilote de l'onduleur dans la liste déroulante Pilote de communication de l'onduleur et éventuellement préciser le Port de communication si l'onduleur n'est pas USB.

Les champs Numéro de série de l'onduleur, Productid de l'onduleur et Upstype de l'onduleur sont facultatifs si il n'y a pas de serveur esclave. Il n'est nécessaire d'indiquer ce numéro de série que dans le cas où le serveur dispose de plusieurs onduleurs et de serveurs esclaves.

À partir d'EOLE 2.7.2, les onduleurs utilisant une connexion SNMP^[23] (driver snmp-ups) sont gérés nativement et des variables supplémentaires apparaissent dans l'interface.

La configuration ci-dessous convient, par exemple, pour un onduleur NITRAM Cyberpower :

Si le driver snmp-ups est sélectionné, le paramétrage de la Fréquence d'interrogation de upsmon est également proposé mais en mode expert uniquement.

Si le serveur dispose de plusieurs alimentations, il est possible de les connecter chacune d'elle à un onduleur différent.

Il faut cliquer sur le bouton + Nom de l'onduleur pour ajouter la prise en charge d'un onduleur supplémentaire dans l'onglet Onduleur de l'interface de configuration du module.

Si les onduleurs sont du même modèle et de la même marque, il faut ajouter de quoi permettre au pilote NUT de les différencier.

Cette différenciation se fait par l'ajout d'une caractéristique unique propre à l'onduleur. Ces caractéristiques dépendent du pilote utilisé, la page de man du pilote vous indiquera lesquelles sont disponibles.

Exemple pour le pilote Solis :

# man solis

Afin de récupérer la valeur il faut :

• ne connecter qu'un seul des onduleurs ;
• le paramétrer comme indiqué dans la section précédente ;
• exécuter la commande : upsc <nomOnduleurDansGenConfig>@localhost|grep <nom_variable> ;
• débrancher l'onduleur ;
• brancher l'onduleur suivant ;
• redémarrer nut avec la commande : # service nut restart ;
• exécuter à nouveau la commande pour récupérer la valeur de la variable.

Une fois les numéros de série connus, il faut les spécifier dans les champ Numéro de série de l'onduleur de chaque onduleur.

Pour déclarer un serveur esclave, il faut passer la variable Autoriser des esclaves distants à se connecter à oui puis ajouter un utilisateur sur le serveur maître afin d'autoriser l'esclave a se connecter avec cet utilisateur.

Idéalement, il est préférable de créer un utilisateur différent par serveur même s'il est possible d'utiliser un unique utilisateur pour plusieurs esclaves. Pour configurer plusieurs utilisateurs il faut cliquer sur le bouton + Utilisateur de surveillance de l'onduleur.

Pour chaque utilisateur, il faut saisir :

• un Utilisateur de surveillance de l'onduleur ;

• un Mot de passe de surveillance de l'onduleur associé à l'utilisateur précédemment créé ;

• l'Adresse IP du réseau de l'esclave (cette valeur peut être une adresse réseau plutôt qu'une adresse IP) ;

• le Masque de l'IP du réseau de l'esclave (comprendre le masque du sous réseau de l'adresse IP de l'esclave)

Une fois qu'un serveur maître est configuré et fonctionnel, il est possible de configurer le ou les serveurs esclaves.

Pour configurer le module en tant qu'esclave, il faut activer le service dans l'onglet Services puis, dans l'onglet Onduleur, passer la variable Configuration sur un serveur maître à non.

Il faut ensuite saisir les paramètres de connexion à l'hôte distant :

• le Nom de l'onduleur distant (valeur renseignée sur le serveur maître) ;

• l'Hôte gérant l'onduleur (adresse IP ou nom d'hôte du serveur maître) ;

• l'Utilisateur de l'hôte distant (nom d'utilisateur de surveillance créé sur le serveur maître ) ;

• le Mot de passe de l'hôte distant (mot de passe de l'utilisateur de surveillance créé sur le serveur maître).

Pour rediriger le service EoleSSO (port 8443), il faut indiquer l'adresse IP ou le nom de domaine interne de la machine de destination (en général l'adresse IP ou le nom de domaine interne du module Scribe).

Afin d'être totalement fonctionnelle derrière un reverse proxy, l'application EOP nécessite des règles de redirection particulières (redirection du port 6080 pour l’observation VNC^[27]).

Pour rediriger l'application EOP, il faut indiquer l'adresse IP ou le nom de domaine interne de la machine de destination (en général l'adresse IP ou le nom de domaine interne du module Scribe).

Pour accéder de manière sécurisée à l'EAD d'un serveur depuis l'extérieur de l'établissement, il est recommandé :

• d'activer l'interface web de l'EAD du serveur interne sur un second port (4203 par défaut) dans l'onglet expert Ead-web de ce module ;
• d'activer la redirection sur le serveur faisant office de reverse proxy en configurant l'adresse IP ou le nom de domaine interne de la machine de destination et son port d'écoute.

Pour rediriger HTTP et HTTPS il est nécessaire de passer la variable Activer le reverse proxy Nginx pour le http/https à oui et de renseigner plus d'informations :

• le Nom de domaine ou IP à rediriger : le nom de domaine diffusé auprès des utilisateurs. Ce nom de domaine est celui qui permet d'accéder au module Amon ou AmonEcole ;

• Activer la redirection pour tous les sous-domaines : cette variable est disponible à partir de la version 2.6.2 d'EOLE, elle permet la prise en charge de tous les sous-domaines par le proxy inverse ;

• Demander un certificat à Let's Encrypt pour ce domaine ? : cette variable est disponible à partir de la version 2.6.2 d'EOLE si la redirection pour tous les sous-domaines n'est pas activé et que le certificat SSL est Let's Encrypt ;

• le Répertoire ou nom de la page à rediriger permet de rediriger un sous-répertoire vers une machine. La valeur par défaut est / ;

• l'IP ou domaine de destination (avec http:// ou https://) ou URI complète permet de saisir l'adresse IP (exemple : http://192.168.10.1), le nom de domaine (exemple : http://scribe.monetab.fr) ou l'URI^[28] (exemple : http://scribe.monetab.fr/webmail/) du serveur de destination hébergeant la ou les applications.

Il est possible de forcer l'utilisation du protocole HTTPS pour les requêtes utilisant le protocole HTTP de façon transparente. De cette manière, un utilisateur web se connectant à l'adresse http://monetab.fr sera automatiquement redirigé vers https://monetab.fr

Ainsi les communications sont automatiquement chiffrées protégeant la transmission de données sensibles (nom d'utilisateur, mot de passe, etc.).

Le proxy inverse peut être utilisé pour ne rediriger que le HTTPS en passant les valeurs Reverse proxy HTTP à non et Reverse proxy HTTPS à oui.

Il est possible d'ajouter plusieurs redirections en cliquant sur le bouton + Nom de domaine ou IP à rediriger.

Le reverse proxy permet de rediriger automatiquement les utilisateurs voulant accéder à une page particulière vers une autre page.

L'exemple ci-dessus illustre le remplacement de SquirrelMail par Roundcube : si l'utilisateur cherche à accéder à l'adresse http://etb1.ac-test.fr/squirrelmail/, la page se recharge automatiquement avec l'URL de la nouvelle messagerie : http://etb1.ac-test.fr/roundcube/.

Les paramètres communs à renseigner sont les suivants :

• Nom de domaine de la messagerie de l'établissement (ex : monetab.ac-aca.fr), saisir un nom de domaine valide, par défaut un domaine privé est automatiquement créé avec le préfixe i-;

• Adresse électronique d'envoi pour le compte root, saisir l'adresse que l'on souhaite utiliser pour l'envoi de courriers électroniques depuis le compte root.

• Adresse électronique recevant les courriers électroniques à destination du compte root, permet de configurer une adresse pour recevoir les éventuels messages envoyés par le système.

• Taille maximale d'un message à envoyer en Mo, indiquer la taille maximale des courrier électroniques qui seront envoyés par exim.

La variable Passerelle SMTP, permet de saisir l'adresse IP ou le nom DNS de la passerelle SMTP à utiliser.

Il est possible d'activer le support du TLS^[15] pour l'envoi de messages.

Si la passerelle SMTP^[30] accepte le TLS, il faut choisir le port en fonction de la prise en charge de la commande STARTTLS^[31].

Pour cela il suffit d'indiquer le port spécifique dans l'option Utilisation de TLS (SSL) par la passerelle SMTP il y a cinq possibilités.

1. non

2. port 25

3. port 465

4. port 587

5. port personnalisé

Le dernier choix permet à l'utilisateur de saisir un port différent de ceux proposés dans une nouvelle option appelée Port de la passerelle SMTP.

Dans le cas où la passerelle nécessiterait une authentification il est nécessaire de le signaler en passant la variable La passerelle requiert une authentification à oui.

Cette action affiche deux nouvelles variables :

Deux informations sont importantes pour l'établissement :

• l'Identifiant de l'établissement, qui doit être unique ;
• le Nom de l'établissement.

Ces informations sont notamment utiles pour Zéphir, les applications web locales, ....

Sur les modules fournissant un annuaire LDAP^[11] local, ces variables sont utilisées pour créer l'arborescence.

En premier lieu, il convient de configurer le nom DNS du serveur.

Cette information est découpée en 2 champs :

• le nom de la machine dans l'établissement ;
• le nom DNS du réseau local.

Le Nom de la machine est laissé à l'appréciation de l'administrateur.

Le Nom DNS du serveur utilise fréquemment des domaines de premier niveau du type .lan

C'est ce nom qui configurera le serveur DNS (sur un module Amon par exemple) comme zone de résolution par défaut. Il sera utilisé par les machines pour résoudre l'ensemble des adresses locales.

Rappel : les outils mDNS (Avahi, Bonjour, ... ) utilise la racine '.local'. Pour éviter les problèmes de DNS, nous vous déconseillons d'utiliser cette racine.

En deuxième lieu, il convient de configurer les noms de domaine de la machine.

Cette information est découpée en plusieurs champs :

• le nom du domaine privé utilisé à l'intérieur de l'établissement ;
• le nom de domaine académique et son suffixe.

Un module EOLE peut avoir de 1 à 5 cartes réseau.

Suivant le module installé, un nombre d'interface est pré-paramétré. Il est possible d'en ajouter en sélectionnant la valeur du nombre total d'interfaces souhaitées dans le menu déroulant. Cela ajoute autant d'onglet Interface-n que le nombre d'interfaces à activer choisi.

Si le module doit utiliser un proxy pour accéder à Internet, il faut activer cette fonctionnalité en passant la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet à oui.

Il devient alors possible de saisir la configuration du serveur proxy :

• nom de domaine ou adresse IP du serveur proxy ;
• le port du proxy.

Par rapport au protocole HTTP^[12], le protocole HTTPS permet de chiffrer la communication entre le navigateur du poste client et le serveur du site distant.

Dans ce cas, le serveur proxy ne journalise qu'une seule connexion vers le site distant (exemple : https://pcll.ac-dijon.fr) mais pas les différentes requêtes d'accès aux pages ou aux fichiers se trouvant sur ce serveur (exemple : https://pcll.ac-dijon.fr/eole/).

En HTTPS, le serveur Proxy ne peut pas filtrer le contenu des pages consultées ni scanner les fichiers téléchargés avec un antivirus.

Le déchiffrement HTTPS sur le serveur Proxy permet d'intercepter l'ensemble des requêtes et de les journaliser, de filtrer le contenu des pages visitées et de scanner les fichiers téléchargés.

Un certificat HTTPS est émis par une autorité de certification^[13].

Let's Encrypt^[14], par exemple, est une autorité de certification publique et connue des navigateurs ; son certificat racine est pré-installé dans les navigateurs et les systèmes d'exploitation.

À partir de la version 2.8.1, le module Amon est équipé d'une fonctionnalité d'interception du trafic HTTPS. Il est possible de déclarer son certificat racine servant à sur-signer les ressources servies par le protocole HTTPS et transitant par le proxy filtrant. Cette déclaration permet d'en automatiser l'intégration dans le magasin de certificats local.

Si la variable Utiliser un serveur mandataire (proxy) pour accéder à Internet est passée à oui, la variable Le serveur mandataire intercepte les communications HTTPS est proposée et permet elle-même de faire apparaître deux variables permettant d’identifier le certificat racine employé par le proxy filtrant.

En passant la variable Le serveur mandataire intercepte les communications HTTPS à oui, il est possible de renseigner les variables suivantes en utilisant les données affichées par la commande diagnose sur le module Amon :

• Type d’empreinte du certificat racine du proxy : SHA256 (par défaut sur Amon 2.8.1)
• Empreinte du certificat racine du proxy : information donnée par le diagnose du serveur Amon dans le cas où celui-ci fait office de proxy filtrant

Cette configuration est nécessaire uniquement lorsque le module Amon est configuré pour l’interception des communications HTTPS.

La variable Adresse IP du serveur DNS donne la possibilité de saisir une ou plusieurs adresses IP du ou des serveur(s) de noms DNS^[3].

La variable Fuseau horaire du serveur vous permet de choisir votre fuseau horaire dans une liste conséquente de propositions.

Une liste de serveurs de temps (NTP^[4]) à utiliser est proposée par défaut.

Il est possible de modifier ces valeurs afin d'utiliser un serveur de temps personnalisé.

Trois types de certificats peuvent être utilisés pour sécuriser les connexions avec TLS^[15] :

• autosigné : le certificat est généré localement et signé par une CA^[13] locale ;

• letsencrypt : le certificat est généré et signé par l'autorité Let's Encrypt^[14] ;

• manuel : le certificat est mis en place manuellement par l'administrateur. Pour ce faire, il faut disposer au préalable des certificats fournis par l'autorité de certification, si ce n'est pas encore le cas, le choix autosigné permet d'utiliser le serveur de façon non optimale. Le répertoire /etc/ssl/certs/ est recommandé pour placer les certificats.

Il est possible de définir d'autres adresses pour le serveur de mise à jour EOLE que celles fournies par défaut, dans le cas où vous auriez, par exemple, un miroir des dépôts.

• Activer l'auto-complétion étendue sur la console : l'auto-complétion facilite l'utilisation de la ligne de commande mais peut ralentir son affichage, elle est activée par défaut ;
• Temps d'inactivité avant déconnexion bash : si aucune activité n'est constatée sur la console utilisateur pendant cette durée (en secondes), sa session est automatiquement coupée, avec le message : attente de données expirée : déconnexion automatique. La valeur 0 permet de désactiver cette fonctionnalité.
• Activer le reboot sur ctrl-alt-suppr : si cette variable est passée à non, la séquence ctrl - alt - suppr est désactivée.
• Nuance du fond d’écran dans VIM : l’éditeur VIM peut utiliser différents thèmes pour la coloration syntaxique et adapter ceux-ci en fonction de la valeur de la couleur d’arrière-plan pour en améliorer la lisibilité. La variable prend une valeur parmi dark et light, permettant d’adapter la coloration syntaxique à un arrière-plan sombre et clair respectivement.

• Poids relatif de l'utilisation de la swap par rapport à la mémoire vive : Le swappiness est un paramètre du noyau Linux permettant de définir avec quelle sensibilité il va écrire dans la swap si la quantité de RAM à utiliser devient trop importante. Le système accepte des valeurs comprises entre 0 et 100. La valeur 0 empêchera au maximum le système d'utiliser la partition d'échange.

• Activer le service de génération de nombres aléatoires rng-tools : Le démon rngd agit comme une passerelle entre un vrai générateur de nombres aléatoires, matériel (TRNG), tel que ceux que l'on peut trouver dans les puces Intel/AMD/VIA et le pseudo-générateur de nombres aléatoires du noyau (PRNG).

EOLE propose un système de vérification des mots de passe évolué pour les utilisateurs système.

Un paramétrage par défaut est proposé mais il est possible d'adapter.

La complexité des mots de passe peut être réglée finement à l'aide des paramètres suivants :

• Taille minimum du mot de passe utilisant une seule classe de caractères ;
• Taille minimum du mot de passe utilisant deux classes de caractères ;
• Taille minimum du mot de passe utilisant trois classes de caractères ;
• Taille minimum du mot de passe utilisant quatre classes de caractères ;
• Taille maximale du mot de passe.

La valeur 0 permet de désactiver une classe de caractères.

Pour maîtriser correctement ce qui va être fait il faut consulter l'état du partitionnement avant de saisir les paramètres souhaités à l'aide de la commande df -h / et des commandes vgdisplay et lvdisplay.

root@eolebase:~# df -h

Sys. de fichiers              Taille Utilisé Dispo Uti% Monté sur

udev                            980M       0  980M   0% /dev

tmpfs                           200M    3,2M  197M   2% /run

/dev/mapper/eolebase--vg-root   9,1G    2,1G  6,5G  25% /

tmpfs                          1000M     28K 1000M   1% /dev/shm

tmpfs                           5,0M       0  5,0M   0% /run/lock

tmpfs                          1000M       0 1000M   0% /sys/fs/cgroup

/dev/sda1                       687M    107M  531M  17% /boot

/dev/mapper/eolebase--vg-tmp    1,8G    2,9M  1,7G   1% /tmp

tmpfs                           200M       0  200M   0% /run/user/0

root@eolebase:~#

root@eolebase:~# df -h
Sys. de fichiers              Taille Utilisé Dispo Uti% Monté sur
udev                            980M       0  980M   0% /dev
tmpfs                           200M    3,2M  197M   2% /run
/dev/mapper/eolebase--vg-root   9,1G    2,1G  6,5G  25% /
tmpfs                          1000M     28K 1000M   1% /dev/shm
tmpfs                           5,0M       0  5,0M   0% /run/lock
tmpfs                          1000M       0 1000M   0% /sys/fs/cgroup
/dev/sda1                       687M    107M  531M  17% /boot
/dev/mapper/eolebase--vg-tmp    1,8G    2,9M  1,7G   1% /tmp
tmpfs                           200M       0  200M   0% /run/user/0
root@eolebase:~#

root@scribe:~# vgdisplay 

  --- Volume group ---

  VG Name               scribe-vg

  System ID             

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  8

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                5

  Open LV               5

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               39,30 GiB

  PE Size               4,00 MiB

  Total PE              10060

  Alloc PE / Size       5550 / 21,68 GiB

  Free  PE / Size       4510 / 17,62 GiB

  VG UUID               ctPVcP-76Se-EpMp-FLO3-13aR-Ghg9-PdIdUW

root@scribe:~#

root@scribe:~# vgdisplay 
  --- Volume group ---
  VG Name               scribe-vg
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  8
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                5
  Open LV               5
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               39,30 GiB
  PE Size               4,00 MiB
  Total PE              10060
  Alloc PE / Size       5550 / 21,68 GiB
  Free  PE / Size       4510 / 17,62 GiB
  VG UUID               ctPVcP-76Se-EpMp-FLO3-13aR-Ghg9-PdIdUW
   
root@scribe:~#

root@scribe:~# lvdisplay

  --- Logical volume ---

  LV Path                /dev/scribe-vg/root

  LV Name                root

  VG Name                scribe-vg

  LV UUID                uN8emF-hD9j-eNwv-zdaC-mEeK-9XGe-uBu2OU

  LV Write Access        read/write

  LV Creation host, time scribe, 2017-10-05 18:37:11 +0200

  LV Status              available

  # open                 1

  LV Size                8,94 GiB

  Current LE             2288

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     256

  Block device           252:0

[...]

root@scribe:~# lvdisplay

  --- Logical volume ---
  LV Path                /dev/scribe-vg/root
  LV Name                root
  VG Name                scribe-vg
  LV UUID                uN8emF-hD9j-eNwv-zdaC-mEeK-9XGe-uBu2OU
  LV Write Access        read/write
  LV Creation host, time scribe, 2017-10-05 18:37:11 +0200
  LV Status              available
  # open                 1
  LV Size                8,94 GiB
  Current LE             2288
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

[...]

En plus d’être envoyés a Rsyslog^[34], la plupart des événements des applications sont également stockés dans des fichiers binaires par journald^[35].

Sur les modules EOLE, les journaux de référence sont ceux gérés via Rsyslog.

journald offre néanmoins d'autres modalités de recherche, utiles notamment pour l'analyse des incidents. Aussi, les modules mettent en place une configuration permettant de conserver une quantité restreinte de journaux binaires afin de limiter la place occupée mais néanmoins permettre de profiter de capacités d'interrogation étendues sur les journaux récents.

L’espace occupé par les journaux gérés par journald^[35] est configuré via deux variables disponibles en mode expert dans l’onglet Logs.

• Taille maximale du journal (Mo) : définit une limite de taille du journal en Mo.

• Objectif de nombre maximal de journaux à conserver : définit la cible du nombre de journaux à conserver, étant donné que seuls les journaux archivés peuvent être supprimés pour atteindre cet objectif.

La possibilité de centraliser des logs a été dissociée de la mise en place d'un serveur ZéphirLog^[36]. Cela rend possible un transfert croisé des journaux ou une centralisation.

Le support des logs centralisés peut être activé dans l'onglet Service en mode expert.

Cette activation affiche un nouvel onglet nommé Logs dans l'interface de configuration du module.

Les options de cet onglet sont réparties en plusieurs sections :

• la configuration de la réception des logs permet de spécifier les protocoles de communication entre des machines distantes émettrices identifiées par leur adresse IP et le poste configuré ;

• la configuration de l'envoi des logs permet de spécifier l'adresse de la machine distante réceptrice. Le protocole (TCP^[37] ou RELP^[38]) utilisé est contraint par l'activation ou non du chiffrement (TLS^[15]) ;

• la configuration des journaux à envoyer permet de sélectionner les journaux à envoyer ainsi que l'heure de début et de fin de transfert.

Si la réception des journaux est activée (Activer la réception des logs de machines distantes à oui), il faut activer au moins l'un des 3 protocoles de réception : RELP, UDP et TLS over TCP.

L'activation des protocoles ouvre les ports adéquats sur le module.

L'activation de l'envoi des journaux (Activer l'envoi des logs à une machine distante à oui) nécessite la saisie de l'adresse IP du serveur centralisateur de journaux.

Le protocole (TLS over TCP ou RELP) utilisé est contraint par l'activation ou non du chiffrement (TLS).

Si le protocole utilisé pour la réception ou l'envoi des journaux nécessite un chiffrement (TLS), il est possible de spécifier les chemins associés aux certificats utilisés par rsyslog.

Par défaut, les certificats du module sont utilisés et leur validité n'est pas vérifiée.

Si l'envoi des journaux est activé, il est possible d'envoyer tous les journaux ou de choisir les journaux à envoyer.

Il est également possible d'envoyer les journaux en temps réel ou en différé. L'heure de début et de fin (plage temporelle) de transfert des journaux est également paramétrable.

En plus d’être envoyés a Rsyslog, la plupart des événements des applications sont également stockés dans des fichiers binaires par journald.

Sur les modules EOLE, les journaux de référence sont ceux gérés via Rsyslog. journald offre néanmoins d’autres modalités de recherche, utile notamment pour l’analyse des incidents. Aussi, les modules mettent en place une configuration permettant de conserver une quantité restreinte de journaux binaires pour limiter la place occupée mais néanmoins permettre de profiter de capacités d’interrogation étendues sur les journaux récents.

Avant toute chose, il faut décider comment la carte réseau est configurée.

Pour cela, il existe trois possibilités : statique^[16], DHCP^[17] ou non géré.

Dans le cas de la configuration statique, il faut renseigner l'adresse IP, le masque et la passerelle.

La configuration DHCP ne nécessite aucun paramétrage particulier.

L'utilisation de la nouvelle valeur non gérée permet de déléguer la configuration réseau à cloud-init^[18] ou à un autre outil de contextualisation.

Par défaut les accès SSH^[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.

Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.

Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.

Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….

EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.

Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.

Il est possible de configurer des VLAN^[22] (réseau local virtuel) sur une interface déterminée du module.

Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :

• le numéro du VLAN ;

• l'adresse IP de l'interface dans ce VLAN ;

• le masque de sous-réseau de l'interface dans ce VLAN.

Il est possible de configurer une passerelle particulière pour un VLAN de l'interface 0.

À partir de la version EOLE 2.6.2, pour permettre à un frontend EAD^[26] distant de se connecter au serveur de commandes de l'EAD local, il faut l'autoriser explicitement pour chaque interface.

Par défaut, l'accès au backend est bloqué pour chaque interface.

En mode expert, il est possible de configurer l'interface en mode DHCP^[17].

Si l'interface est configurée avec un adressage statique^[16], il faut renseigner l'adresse IP et le masque de sous-réseau.

Par défaut les accès SSH^[19] et aux différentes interfaces d'administration (EAD, Adminer, CUPS, ARV... selon le module) sont bloqués.

Pour chaque interface réseau activée (onglets Interface-n), il est possible d'autoriser des adresses IP ou des adresses réseau à se connecter.

Les adresses autorisées à se connecter via SSH sont indépendantes de celles configurées pour accéder aux interfaces d'administration.

Il est possible d'autoriser plusieurs adresses en cliquant sur Adresse IP réseau autorisée pour….

EOLE supporte les alias sur les cartes réseau. Définir des alias IP consiste à affecter plus d'une adresse IP à une interface.

Pour cela, il faut activer le support des alias (Ajouter des IP alias sur l'interface à oui) et configurer l'adresse IP et le masque de sous-réseau.

Il est possible de configurer des VLAN^[22] (réseau local virtuel) sur une interface déterminée du module.

Pour cela, il faut activer le support des VLAN (Activer le support des VLAN sur l'interface à oui) puis ajouter un VLAN à l'aide du bouton + Numéro d'identifiant du VLAN et configurer l'ensemble des paramètres obligatoires :

• le numéro du VLAN ;

• l'adresse IP de l'interface dans ce VLAN ;

• le masque de sous réseau de l'interface dans ce VLAN.

À partir de la version EOLE 2.6.2, pour permettre à un frontend EAD^[26] distant de se connecter au serveur de commandes de l'EAD local, il faut l'autoriser explicitement pour chaque interface.

Par défaut, l'accès au backend est bloqué pour chaque interface.

Le support du pare-feu peut être désactivé en passant Activer le support du firewall à non.

La valeur par défaut de la variable Restreindre le ping aux réseaux autorisés pour administrer le serveur est à oui par défaut mais cette restriction peut être levée en passant la variable à non.

Sur les modules disposant de la fonctionnalité serveur de fichiers comme Scribe et Horus, cette restriction est déjà levée puisque la variable est par défaut à non.

Si la variable Activer le routage IPv4 entre les interfaces est à oui, alors le routage IPv4 est activé au niveau du noyau (/proc/sys/net/ipv4/ip_forward passe à 1)

Si la variable Journaliser les "martian sources" est à oui, tous les passages de paquets utilisant des adresses IP réservées à un usage particulier (http://tools.ietf.org/html/rfc5735) seront enregistrées dans les journaux.

Par défaut, l'anti-spoofing^[43] est activé sur l'interface-0 des modules EOLE.

Sur les serveurs ayant 2 interfaces réseau ou plus d'activées (cas par défaut sur les modules Amon, Sphynx et Hâpy), il est possible de demander l'activation de l'anti-spoofing sur les autres interfaces en passant la variable Activer l'anti-spoofing sur toutes les interfaces à oui.

Passer la variable Déclarer des noms d'hôtes supplémentaires à oui, permet de déclarer des noms d'hôtes qui seront ajoutés au fichier /etc/hosts.

Il est possible d'ajouter plusieurs hôtes supplémentaires en cliquant sur le bouton +Adresse IP de l'hôte.

Le champ Nom court de l'hôte est optionnel.

Ce bloc de paramètres permet d'ajouter, manuellement, des routes afin d'accéder à des adresses ou à des plages d'adresses par un chemin différent de celui par défaut (défini par le routeur par défaut).

Après avoir passé la variable Ajouter des routes statiques à oui il faut configurer les paramètres suivants :

• Adresse IP ou réseau à ajouter dans la table de routage : permet de définir l'adresse de sous-réseau (ou l'adresse de l'hôte) vers lequel le routage doit s'effectuer ;

• Masque de sous réseau : permet de définir le masque du réseau défini ci-dessus (s'il s'agit d'une machine seule, il faut mettre l'adresse du masque à 255.255.255.255) ;

• Adresse IP de la passerelle pour accéder à ce réseau : permet de renseigner l'adresse de la passerelle permettant d'accéder au sous-réseau ou à l'hôte défini ci-dessus.

• Interface réseau reliée à la passerelle : permet d'associer la route à une interface donnée ;

• Numéro d'identifiant du VLAN ou rien : permet d'associer une route à un VLAN ;

Les deux paramètres suivants apparaissent uniquement si le service eole-dns est installé sur le module :

• Autoriser ce réseau à utiliser les DNS du serveur : les postes du réseau cible peuvent interroger le service DNS du serveur ;

• Autoriser ce réseau à utiliser les DNS des zones forward additionnelles : les postes du réseau cible sont autorisés à interroger les DNS des zones de forward.

Le paramètre suivant apparaît uniquement si le réseau virtuel privé RVP est activé :

• Passer par le VPN pour accéder à ce réseau : ce réseau n'est pas un réseau local. C'est un réseau distant accessible par le VPN.

La variable Configurer manuellement le MTU permet d'activer ou non le path MTU discovery^[45] (paramètre : /proc/sys/net/ipv4/ip_no_pmtu_disc).

Cette option est à non par défaut (ip_no_pmtu_disc=0) ce qui est le fonctionnement normal.

Cette valeur peut poser problème, notamment avec le réseau virtuel privé (VPN), lorsque les paquets ICMP^[46] de type 3 (Destination Unreachable) / code 4 (Fragmentation Needed and Don't Fragment was Set) sont bloqués quelque part sur le réseau.

Il est possible de forcer une valeur de MTU^[45] pour chacune des interfaces activées dans l'interface de configuration du module.

Si le champ n'est pas renseigné, la valeur par défaut est utilisée (1500 octets pour un réseau de type Ethernet).

Les variables ipv4_neigh_default_gc_thresh1, ipv4_neigh_default_gc_thresh2 et ipv4_neigh_default_gc_thresh3 servent à gérer la façon dont la table ARP évolue :

• gc_thresh1 : seuil en-deçà duquel aucun recyclage des entrées de la table qui ne sont plus utilisées n'est effectué ;
• gc_thresh2 : seuil qui, s'il est dépassé depuis un certain temps (5 secondes par défaut), déclenche le recyclage des entrées de la table qui ne sont plus utilisées ;
• gc_thresh3 : seuil au-delà duquel le recyclage est immédiatement déclenché pour contenir la taille de la table.

Cette variable permet de définir le ou les domaines qui sont utilisés lorsque le module EOLE a besoin de tester son accès à Internet.

En pratique, seul l'accès au premier domaine déclaré est testé sauf dans le cas où il n'est pas accessible.

Les domaines définis sont utilisés dans les outils diagnose et dans l'agent Zéphir.

L'autorité de certification^[13] Let's Encrypt^[14] permet de mettre en place, gratuitement, des certificats dont la distribution et le renouvellement sont automatisés.

Vous pouvez à présent gérer des certificats Let's Encrypt pour des serveurs accessibles depuis Internet ou au travers d'un proxy inverse.

• Les trois premiers points concernent l'emplacement des fichiers/données gérés par le client Let's Encrypt qui peuvent êtres modifiés.

• Les point 4 et 5 sont utiles dans le cas où vous souhaitez spécifier un serveur Let's Encrypt spécifique.
• Les points 7 et 8 permettent de modifier les ports associés aux défis http-01 et TLS-SNI.
• Le point 9 permet de déclencher le renouvellement des certificats avant la fin de validité des certificats Let's Encrypt déjà acquis.

Le point 6 permet de spécifier le mode de fonctionnement de Let's Encrypt, soit :

• webroot

• standalone

Le choix du mode de vérification n’est pas anodin, et peut engendrer des effets de bord.

webroot : Obtenir un certificat en écrivant dans la racine d'un serveur web fonctionnel.

standalone : Obtenir un certificat en lançant un serveur web autonome (le port 80 doit être disponible)

Le type manuel vous permet d'utiliser le certificat de votre choix (en général, un certificat signé par une autorité tierce).

Pour que les services d'un module EOLE l'utilisent, il faut placer vos fichiers aux endroits définis au préalable dans la section Choix du certificat SSL de l'onglet Général.

Dans le cas d'un certificat signé par une autorité externe, il faut copier le certificat de la CA en question dans /etc/ssl/local_ca/ afin qu'il soit pris en compte automatiquement (non nécessaire pour les certificats de l'IGC nationale).

Pour appliquer les modifications, utiliser la commande reconfigure.

En mode autosigné le certificat est généré localement et signé par une autorité de certification^[13] locale.

Un certain nombre de certificats sont mis en place lors de la mise en œuvre d'un module EOLE :

• /etc/ssl/certs/ca_local.crt : autorité de certification propre au serveur (certificats auto-signés) ;
• /etc/ssl/private/ca.key : clef privée de la CA ci-dessus ;
• /etc/ssl/certs/ACInfraEducation.pem : contient les certificats de la chaîne de certification de l'Éducation nationale (igca/education/infrastructure) ;
• /etc/ssl/req/eole.p10 : requête de certificat au format pkcs10, ce fichier contient l'ensemble des informations nécessaires à la génération d'un certificat ;
• /etc/ssl/certs/eole.crt : certificat serveur signé par la CA locale, il est utilisé par les applications (apache, ead2, eole-sso, ...) ;
• /etc/ssl/private/eole.key : clé du certificat serveur ci-dessus.

Après génération de la CA locale, un fichier /etc/ssl/certs/ca.crt est créé qui regroupe les certificats suivants :

• ca_local.crt ;
• ACInfraEducation.pem ;
• tout certificat présent dans le répertoire /etc/ssl/local_ca.

Même si le nom de l'onduleur n'a aucune conséquence, il est obligatoire de remplir cette valeur dans le champ Nom pour l'onduleur.

Il faut également choisir le nom du pilote de l'onduleur dans la liste déroulante Pilote de communication de l'onduleur et éventuellement préciser le Port de communication si l'onduleur n'est pas USB.

Les champs Numéro de série de l'onduleur, Productid de l'onduleur et Upstype de l'onduleur sont facultatifs si il n'y a pas de serveur esclave. Il n'est nécessaire d'indiquer ce numéro de série que dans le cas où le serveur dispose de plusieurs onduleurs et de serveurs esclaves.

À partir d'EOLE 2.7.2, les onduleurs utilisant une connexion SNMP^[23] (driver snmp-ups) sont gérés nativement et des variables supplémentaires apparaissent dans l'interface.

La configuration ci-dessous convient, par exemple, pour un onduleur NITRAM Cyberpower :

Si le driver snmp-ups est sélectionné, le paramétrage de la Fréquence d'interrogation de upsmon est également proposé mais en mode expert uniquement.

Si le serveur dispose de plusieurs alimentations, il est possible de les connecter chacune d'elle à un onduleur différent.

Il faut cliquer sur le bouton + Nom de l'onduleur pour ajouter la prise en charge d'un onduleur supplémentaire dans l'onglet Onduleur de l'interface de configuration du module.

Si les onduleurs sont du même modèle et de la même marque, il faut ajouter de quoi permettre au pilote NUT de les différencier.

Cette différenciation se fait par l'ajout d'une caractéristique unique propre à l'onduleur. Ces caractéristiques dépendent du pilote utilisé, la page de man du pilote vous indiquera lesquelles sont disponibles.

Exemple pour le pilote Solis :

# man solis

Afin de récupérer la valeur il faut :

• ne connecter qu'un seul des onduleurs ;
• le paramétrer comme indiqué dans la section précédente ;
• exécuter la commande : upsc <nomOnduleurDansGenConfig>@localhost|grep <nom_variable> ;
• débrancher l'onduleur ;
• brancher l'onduleur suivant ;
• redémarrer nut avec la commande : # service nut restart ;
• exécuter à nouveau la commande pour récupérer la valeur de la variable.