Distribution EOLE

{{toc}}

h1. Errata 2.4

_Cette page recense des problèmes affectant les versions EOLE 2.4.0 et/ou 2.4.1 corrigés dans des versions d'EOLE supérieures mais qui ne le seront pas sur ces versions d'EOLE._

h2. Problème de restauration complète du serveur sans serveur Zéphir

Deux problèmes existent dans la procédure de restauration complète du serveur sans Zéphir :

- il est nécessaire de créer deux fichiers avant de configurer le point de montage de bacula et de restaurer le catalogue ;

- il est nécessaire de redémarrer creoled après la configuration du point de montage.

Par exemple pour un montage USB :

<pre>

# /usr/share/eole/sbin/baculaconfig.py -s usb --usb_path=/dev/vdb1

# /usr/share/eole/sbin/bacularestore.py --catalog amonecole-dir

</pre>

La procédure est :

<pre>

# touch /etc/bacula/include-options.conf /etc/bacula/bacula-restore.conf

# /usr/share/eole/sbin/baculaconfig.py -s usb --usb_path=/dev/vdb1

# service creoled restart

# /usr/share/eole/sbin/bacularestore.py --catalog amonecole-dir

</pre>

Ce problème est résolu dans la version 2.4.1.

h2. Il n'est pas possible d'accéder au serveur SSH alors qu'il est autorisé dans l'interface de configuration

Un problème existe dans la version 2.4.0 empêchant l'accès au SSH alors qu'il est bien autorisé dans l'interface de configuration.

Le fichier hosts.allow, dans certain cas, n'est pas généré correctement.

Pour corriger le problème, il faut utiliser le patch suivant :

"Patch":https://dev-eole.ac-dijon.fr/attachments/download/1164/hosts.allow.patch

Ce fichier est à placé dans le répertoire /usr/share/eole/creole/patch/ ou dans la variante.

Puis exécuter la commande reconfigure.

L'accès SSH devrait être à nouveau possible.

Ce problème est résolu dans la version 2.4.1.

h2. MySQL ne fonctionne plus après l'exécution du script "script_gfcMysql_v3.sh" sur le module Horus

Le script */usr/share/minedu/scripts/script_gfcMysql_v3.sh* ne fonctionne pas complètement sur EOLE 2.4.0. Le chemin vers *mysql_pwd.py* n'est pas actualisé.

De plus *apparmor* empêche l'exécution de *MySQL* quand le répertoire des bases */var/lib/mysql* devient un lien symbolique. Il faut indiquer à *apparmor* le véritable chemin.

Ce problème est résolu dans la version 2.4.1.

h2. Erreur au démarrage de Nginx :

Si vous avez du type :

<pre>

Restarting nginx: nginx: [warn] conflicting server name "xxxxxxxxxxxxxx" on 0.0.0.0:80, ignored

nginx: [warn] conflicting server name "xxxxxxxxxxxxxx" on 0.0.0.0:443, ignored

</pre>

Cela arrive si vous avez définit plusieurs URL pour un même domaine dans la configuration du reverse proxy.

Pour corriger le problème, il faut utiliser le patch suivant :

"Patch":https://dev-eole.ac-dijon.fr/attachments/download/1229/nginx.default.patch

Ce problème est résolu dans la version 2.4.1.

h2. eole-nfs : Ouverture du port 111 en UDP :

Le port 111 est ouvert en TCP mais pas en UDP à l'activation du service NFS.

Pour corriger le problème, il faut ajouter le dictionnaire suivant :

"Dictionnaire":https://dev-eole.ac-dijon.fr/attachments/download/1304/00_nfsudp.xml

Ce problème est résolu dans la version 2.4.2.

h2. Erreur de nom DNS de la zone accessible via ce serveur web parent :

L'accès au proxy père n'est pas forcement fonctionnel. Si vous avez les erreurs suivantes au démarrage de Squid :

<pre>

# /etc/init.d/squid3 restart * Restarting Squid HTTP Proxy 3.x squid3 * Waiting... * ... * ... * ... * ... * ... * ... [ OK ]

2015/06/23 15:49:14| strtokFile: xxxxxxxx not found

2015/06/23 15:49:14| Warning: empty ACL: acl intradom0 dstdomain "xxxxxxxx" 

</pre>

Il faut ajouter le patch suivant :

"Patch":https://dev-eole.ac-dijon.fr/attachments/download/1306/common-squid1.conf.patch

Ce problème est résolu dans la version 2.4.2.

h2. Tcpwrapper bloque injustement l'accès au serveur :

Il n'est pas possible de se connecter sur des services protégés par tcpwrapper.

Par exemple dans les logs de SSH nous avons :

<pre>

/var/log/rsyslod/local/sshd/sshd.err.log :

Jun 30 08:59:09 xxxx sshd[18288]: warning: /etc/hosts.allow, line 1: missing newline or line too long

Jun 30 08:59:09 xxxx sshd[18288]: warning: /etc/hosts.allow, line 1: all the subsequent rules will be ignored

Jun 30 08:59:13 xxxx sshd[18289]: warning: /etc/hosts.allow, line 1: missing newline or line too long

Jun 30 08:59:13 xxxx sshd[18289]: warning: /etc/hosts.allow, line 1: all the subsequent rules will be ignored

</pre>

Une ligne avec beaucoup d'espace est présent au début du fichier. Cette ligne est considéré comme anormalement longue.

Pour corriger il faut utiliser le patch suivant :

"Patch":https://dev-eole.ac-dijon.fr/attachments/download/1310/hosts.allow.patch

Ce problème a été introduit dans la version 2.4.1 et est résolu dans la version 2.4.2.

h2. Le fichier @/etc/hosts.allow@ est vide sur un module avec ERA (TcpWrapper) :

h3. Migration des modèles ERA en 2.4.1 :

Pour résoudre le problème, il s'agit de rajouter dans l'interface ERA un attribut tcpwrapper aux objets de type service qui sont concernés par le tcpwrapper:

Ouvrir votre modèles ERA dans l'interface (lancer @era@, puis @Fichier>Ouvrir@). Puis aller dans le menu @Bibliothèque>Services@ et éditer les services concernés par le tcpwrapper.

Il suffit de renseigner le nom tcpwrapper du service (le nom tel qu'il doit apparaître dans le fichier hosts.allow) et le tcpwrapper sera pris en compte dès qu'une directive utilisant ce service sera créée. 

Les services concernés sont par défaut :

* pour le service "service d'annuaire" il faut mettre "slapd" ;

* pour le service "service ldaps" il faut mettre "slapd" ;

* pour le service "Accès aux serveurs TFTP" il faut mettre "in.tftpd" ;

* pour le service "ssh" il faut mettre "sshd".

N'oubliez pas de faire un reconfigure ensuite.

Plus d'information dans la doc ERA sur les services, paragraphe "implémenter un service avec tcpwrapper" :

http://eole.ac-dijon.fr/documentations/2.4/beta/partielles/ERA/co/2-Services.html

h3. Migration des modèles ERA en 2.4.2 et plus : 

Il faut migrer les modèles ERA personnalisés (pas ceux fournis en natif par le paquet ERA).

En effet, il y a eu des changements dans la DTD du format XML interne à l'application ERA : la version XML 2.42.

Un script de migration est fourni pour passer en 2.42, il suffit d'ouvrir le modèle ERA concerné dans l'interface ERA (faire un @Fichier>Ouvrir@), puis faire un @Fichier>Enregistrer@ et une fenêtre de type popup apparaît au moment de l'enregistrement pour proposer la mise à jour du modèle.

h2. Le routage manuel (MANUAL_ROUTES) n'est pas désactivable au niveau d'exim

Quelle que soit la configuration choisie, les lignes suivantes sont toujours présentes dans la configuration.

<pre>

# Routes manuelles EAD

MANUAL_ROUTES = /etc/mail/routes

</pre>

Pour corriger le problème, il faut utiliser le patch suivant :

"Patch":https://dev-eole.ac-dijon.fr/attachments/download/1313/exim-vars.conf.patch

Ce problème est résolu dans la version 2.4.2.

h2. Récapitulatif de tous les dictionnaires, templates et paches :