Errata24 » Historique » Version 25
Version 24 (Gwenael Remond, 02/07/2015 15:46) → Version 25/82 (Emmanuel GARETTE, 02/07/2015 15:51)
{{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 XML dans l'interface ERA (lancer @era@, puis @Fichier>Ouvrir@) Puis aller dans le menu @Bibliothèque>Services@ et éditer les services concernés par le tcpwrapper
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
Par exemple pour le service @ldap@ on renseigne la valeur 'slapd' qui est ce que l'on souhaite trouver dans le fichier hosts.allow au final.
N'oubliez pas de faire un reconfigure ensuite (ou bien un simple "service bastion restart")
h3. Implémenter un nouveau service avec tcpwrapper :
Pour prendre en compte le tcpwrapper, ça se passe au niveau des services dans ERA. 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. ERA va générer un fichier tcpwrapper, classiquement le fichier @/etc/hosts.allow@, mais remarquons que en mode conteneur autant de fichiers seront générés que de conteneurs.
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 XML 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 :
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 XML dans l'interface ERA (lancer @era@, puis @Fichier>Ouvrir@) Puis aller dans le menu @Bibliothèque>Services@ et éditer les services concernés par le tcpwrapper
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
Par exemple pour le service @ldap@ on renseigne la valeur 'slapd' qui est ce que l'on souhaite trouver dans le fichier hosts.allow au final.
N'oubliez pas de faire un reconfigure ensuite (ou bien un simple "service bastion restart")
h3. Implémenter un nouveau service avec tcpwrapper :
Pour prendre en compte le tcpwrapper, ça se passe au niveau des services dans ERA. 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. ERA va générer un fichier tcpwrapper, classiquement le fichier @/etc/hosts.allow@, mais remarquons que en mode conteneur autant de fichiers seront générés que de conteneurs.
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 XML 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 :