Package de Horde esup

Ce document décrit comment installer et utiliser le package 'Horde configuré avec CAS'. Cet environnement peut être utilisé sur un système linux.


Julien  Marchal 
Université Nancy 2

Dates de modification
Revision 1.0.0 19 avril 2004 Création de la documentation
Revision 1.1.1 22 avril 2004 ajout des configurations de LOG
Revision 1.1.2 17 aôut 2004 modification du package 2.2.5
Revision 1.1.3 25 aôut 2004 ajout de la partie test
Revision 1.2.0 26 juillet 2005 nouveau package 3.04 + FAQ
Revision 1.2.1 29 juillet 2005 FAQ couche authorisation
Revision 1.2.2 16 août 2005 Ajout du chmod
Revision 1.2.3 31 août 2005 FAQ CASification Horde
Revision 1.3.0 12 septembre 2005 Externalisation de la FAQ
Revision 1.3.1 12 septembre 2005 Ajout du préambule
Revision 1.3.2 15 avril 2006 Adaptation nouveau package
Revision 2.0 20 Juin 2006 Passage en docbook + réintégration FAQ
1. Pré-requis
2. Préambule
3. Configuration
3.1. conf/build.conf
3.2. conf/user.conf
4. Installation
5. Personnalisations
5.1. Exemple du "thèmes"
5.2. Exemple d'un fichier de configuration
5.3. Exemple d'un script php modifié
6. Test
7. UPGRADE 3.0.X vers 3.1.1
8. FAQ
8.1. Quels sont les prérequis pour utiliser HORDE ?
8.2. Doit on accéder à HORDE en https ?
8.3. Comment utiliser la couche autorisation d'accès a horde ?
8.4. Adapter un fichier de configuration de horde ?
8.5. Comment ajouter uniquement la CASification à Horde ?
8.6. Pam_cas et "authentication failure"
8.7. Traduction

1. Pré-requis

Important

La base de données doit exister et les tables ne seront créées (par le package) que pour les bases de type mysql, pour les autres une création manuelle est nécessaire (voir $PRODUITS/scripts/db) Un client mysql doit être présent et accessible via "/usr/bin/mysql" Un script d'upgrade de la base de données est fournit.

2. Préambule

Le package fournit par esup permet une installation rapide de Horde. En aucun cas il ne permet une configuration complète de Horde. Vous devez affiner les paramètres de Horde et de ses applications par rapport a votre SI et au comportement que vous souhaitez. Les numéros de versions écrite dans ce document sont amené a changer, donc adapter les exemples.

3. Configuration

Ce package se configure grâce à deux fichiers :

Des fichiers build.sample.conf et user.sample sont fournit dans le répertoire conf/

3.1. conf/build.conf

Ce fichier permet de configurer les options du package. Les options sont les suivantes :

choisir les applications à déployer entre IMP, INGO, KRONOLITH, MNEMO, NAG, TURBA, et CAS (valuer à 0 ou 1) par défaut :

IMP_USE=1

INGO_USE=1

KRONOLITH_USE=1

MNEMO_USE=1

NAG_USE=1

TURBA_USE=1

CAS_USE=1

paramétrer les versions de produit utilisées, ce package se base sur les versions suivantes :

HORDE_VER=3.X.X

IMP_VER=h3-4.X.X

INGO_VER=h3-1.X.X

KRONOLITH_VER=h3-2.X.X

MNEMO_VER=h3-2.X.X

NAG_VER=h3-2.X.X

TURBA_VER=h3-2.X.X

CAS_VER=2.X

paramétrer les noms des dossiers utilisés par le package :

BUILD_DIR : répertoire où le package va se construire [ build ]

SOURCE_DIR: répertoire contenant les sources (en tar.gz) des différents produits [ source ]

PATCH_DIR : répertoire contenant les patchs à appliquer aux produits [ patch ]

PERSO_DIR : répertoire contenant les personnalisations [ custom ]

UPDATES_DIR : répertoire contenant les updates du package sur horde[ updates ]

DEPLOY_DIR : : répertoire où va être installé horde et les différents produits [ /home/www/ ]

3.2. conf/user.conf

Ce fichier permet de configurer les différents produits contenus dans la package. Les options sont les suivantes :

Base de données (HORDE, IMP, TURBA, KRONOLITH):

DB_TYPE : type de la base [ mysql ]

DB_HOST : nom d'hôte hébergeant la base

DB_PORT : port de connexion à mysql [ 3306 ]

DB_USERNAME : username pour la connexion à la base

DB_PASS : mot de passe pour la connexion à la base

DB_NAME : nom de la base de données

Messagerie (IMP, CAS) :

SMTPHOST : nom d'hôte hébergeant le SMTP [ mail.univ.fr ]

MAIL_SERVER_NAME : nom d'hôte hébergeant le serveur IMAP [ mail.univ.fr]

MAIL_SERVER_PORT : port IMAP à utiliser [ 143 ]

MAIL_DOMAIN : domaine de messagerie [ univ-nancy2.fr ]

MAIL_PROTO : protocole a utiliser pour les connexion imap [ imap/notls ]

Ldap (TURBA):

LDAP_HOST: nom d'hôte hébergeant le service LDAP [ ldap.univ.fr ]

LDAP_PORT: port LDAP à utiliser [ 389 ]

LDAP_BASEDN : basedn LDAP à utiliser [ dc=univ,dc=fr ]

LDAP_BINDDN : dn pour la connexion LDAP (laissez vide en anonyme)

LDAP_BINDPASS : mot de passe pour la connexion LDAP (laissez vide en anonyme)

LDAP_UID_KEY : nom du paramètre contenant l'identifiant de l'utilisateur [uid ]

CAS (CAS, IMP):

CAS_HOST : nom d'hôte hébergeant le service CAS [ auth.univ.fr ]

CAS_PORT: port HTTPS à utiliser pour le CAS [ 443 ]

CAS_PATH : URI pour le serveur CAS [ ]

CAS_PROXY : URL du récepteur CAS proxy [ https://webmail.univ.fr/casProxy.php ]

CAS_LOGOUT : autorise le logout CAS lors du logout horde [ true ]

LOG

LOG_LEVEL : niveau de log (par défaut E_ERROR, possibilité de php E_INFO,E_ALL,etc..)

LOG_FILE : fichier de log (/tmp/horde.log)

DIVERS (HORDE):

ADMIN_USERS : administrateur de horde [ ('admin') ]

URL_HORDE : URI de horde sur le serveur [ / ]

KRONOLITH_REMINDER : adresse mail a utiliser pour les rappels de rendez-vous [ rappel@univ.fr ]

4. Installation

Avant toutes choses il faut faire un :

find . -name "*.sh" -exec chmod u+x '{}' \;
cp conf/build.sample.conf conf/build.conf
cp conf/user.sample.conf conf/user.conf

Une fois les deux fichiers de configuration préparés, il faut utiliser le script build.sh. Ce script reçoit un paramètre d'action qui peut être :

--build : va construire les produits dans le répertoire BUILD_DIR. Cette action va :

extraire les produits choisis

les patcher

les configurer

--db : va créer les tables dans la base de données (UNIQUEMENT MYSQL)

--clean : va nettoyer le BUILD_DIR

--deploy : va copier le contenu du BUILD_DIR dans le DEPLOY_DIR

--undeploy : va supprimer le DEPLOY_DIR (demande de confirmation)

Voici un exemple de séquence de construction :

./build.sh --clean
./build.sh --build
./build.sh --db
./build.sh --deploy

5. Personnalisations

Ce package va vous permettre d'inclure des personnalisations de configuration ou des patch "maisons". Le répertoire PERSO_DIR [ custom ] vous permet de placer des fichiers avec la même arborescence que celle de production. Ces fichiers seront copiés lors de la commande --build. Ces fichiers seront soumis aux remplacements réguliers que le package opère afin de configurer horde.

5.1. Exemple du "thèmes"

Dans le package par défaut vous trouverez un thème esup. Ce thème est constitué de plusieurs fichiers qui se trouvent dans le répertoire : custom/horde-3.0.4/themes/esup/ Ces fichiers seront recopiés lors du build.

5.2. Exemple d'un fichier de configuration

Les fichiers de configurations qui sont impactés par la configuration du packaging se trouvent dans le répertoire updates.

Important

Ne modifier pas directement ces fichiers dans updates.

reproduisez l'arborescence que vous trouverez dans updates dans le répertoire custom :

updates/horde-3.X.X/config/conf.php => custom/horde-3.X.X/config/conf.php

adaptez votre fichier custom/horde-3.X.X/config/conf.php en prenant garde de conserver les TAG de remplacement (ex :'__DB_HOST__';)

./build.sh --build

./build.sh --deploy

Votre fichier custom/horde-3.X.X/config/conf.php sera présent en production avec vos adaptations et les remplacements fait par le package. Dans le cas d'un fichier de configuration qui est absent du répertoire updates cela reviens a modifier un script php

5.3. Exemple d'un script php modifié

reproduisez l'arborescence que vous trouverez dans votre répertoire de production dans le répertoire custom :

custom/horde-3.X.X/imp-h3-4.X.X/mailbox.php

adaptez votre fichier custom/horde-3.X.X/imp-h3-4.X.X/mailbox.php

./build.sh --build

./build.sh --deploy

NB : prenez garde à bien utiliser les noms complets des répertoires ( horde-3.X.X ) et pas les liens symboliques. Cela sera plus facile pour vous lors d'une mise à jour de package.

6. Test

La distribution de horde inclus un script de test. Ce script vous permet de voir les extensions php manquantes, les librairies pear nécessaires, etc ... Il est accessible uniquement par http dans : http://your.server.fr/URL_HORDE/test.php

7. UPGRADE 3.0.X vers 3.1.1

Appliquer les requêtes SQL contenu dans : script/upgrade.sql

8. FAQ

8.1. Quels sont les prérequis pour utiliser HORDE ?

php_value include_path .:/home/www/TEST/pear
php_value include_path .:/home/www/TEST/pear

8.2. Doit on accéder à HORDE en https ?

Non cela n'est pas nécessaire dans le cas où vous utiliser CAS, les échanges de mot de passe étant sécurisé par le CAS vous pouvez utiliser uniquement du HTTP.

8.3. Comment utiliser la couche autorisation d'accès a horde ?

Il existe un hook au sens horde afin de pouvoir restreindre l'accès à horde. Le fonctionnement est le suivant :

Pour activer cette couche d'autorisation :

Pour adapter la fonction d'autorisation :

8.4. Adapter un fichier de configuration de horde ?

Voir Exemple d'un fichier de configuration

8.5. Comment ajouter uniquement la CASification à Horde ?

Il n'existe pas de package contenant uniquement la CASification de Horde. Aucune garantie sur le fonctionnement de cette procédure ne peut être donnée. Si vous disposez d'un webmail horde déjà en place et si vous voulez ajouter la couche CAS procéder comme suit : Soit :

Procédure :

cp $PACKHORDE_PATH/cas-2.1/cas.php $MYHORDE_PATH/horde/lib/Horde/Auth/
cp $PACKHORDE_PATH/cas-2.1/casProxy.php $MYHORDE_PATH/horde/
mkdir $MYHORDE_PATH/horde/lib/CAS
cp $PACKHORDE_PATH/cas-2.1/phpCAS/* $MYHORDE_PATH/horde/lib/CAS/

Une fois ces modifications faites, votre webmail peut fonctionner CAS reste la partie configuration :

8.6. Pam_cas et "authentication failure"

Il arrive régulièrement d'avoir des messages d'erreur du coté serveur de messagerie de ce type :

PAM_cas[00000]: authentication failure
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
 <cas:authenticationFailure code='INVALID_TICKET'>
   ticket 'PT-XX-xxxxxxxxxxxxxxxxx' not recognized
 </cas:authenticationFailure>
</cas:serviceResponse>
PAM_cas[00000]: for requestGET /cas/proxyValidate?ticket=PT-XX-xxxxxxxxxxxxxxxxx&service=imap://mail.univ.fr HTTP/1.0
PAM_cas[00000]: authentication failure for user 'identifiant' : bad CAS ticket. PT=PT-XX-xxxxxxxxxxxxxxxxx
saslauthd[00000]: pam_ldap: error trying to bind as user "uid=identifiant,ou=People,dc=univ,dc=fr" (Invalid credentials)

Ce message est lié a l'expiration du cache du PT dans SASL. Voici ce qui ce passe :

Le cache SASL comporte un erreur de logique dans sa gestion de cache vous trouverez les explication et la patch sur le thread suivant

8.7. Traduction

Chaque application gère ses traductions ; le framework Horde s'appuie sur le système des gettext pour assurer le multi-linguisme. Chaque applications possède un répertoire po/. Ce dossier po/ contient des fichiers du style fr_FR.po. Ces fichier .po contiennent les traductions de chaines de caractères. Ces fichiers nécessitent d'être compilés. Au niveau de Horde, et des applications, pour faire appel à une traduction on utilise l'instruction gettext suivante _("Hello") qui, si tout va bien, renvoie "Bonjour" (en français fr_FR). Exmple de contenu de fichier fr_FR.po :

msgid "24 hours"
msgstr "24 heures"

msgid "Contents of '%s'"
msgstr "Contenu de '%s'"

Pour mettre à jour une traduction horde fournit un utilistaire HORDE_DIR/po/translation.php

Tout d'abord mettez jour ajour votre fichier .po (HORDE_DIR/imp/po/fr_FR.po

PHP_BIN_DIR/php -n -d include_path=HORDE_DIR/lib:PAER_DIR HORDE_DIR/po/translation.php make -m imp -l fr_FR

Vous pouvez vous référrer au fichier HORDE_DIR/po/README pour plus d'information

Après cette procédure, il est conseillé de relancer apache (un graceful suffit)