Ce document décrit comment installer et utiliser le package 'Horde configuré avec CAS'. Cet environnement peut être utilisé sur un système linux. |
Dates de modification | ||
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
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.
Ce package se configure grâce à deux fichiers :
conf/build.conf
conf/user.conf
Ce fichier permet de configurer les options du package. Les options sont les suivantes :
IMP_USE=1
INGO_USE=1
KRONOLITH_USE=1
MNEMO_USE=1
NAG_USE=1
TURBA_USE=1
CAS_USE=1
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
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/ ]
Ce fichier permet de configurer les différents produits contenus dans la package. Les options sont les suivantes :
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
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_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_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_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)
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 ]
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 :
extraire les produits choisis
les patcher
les configurer
Voici un exemple de séquence de construction :
./build.sh --clean ./build.sh --build ./build.sh --db ./build.sh --deploy
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.
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.
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.
updates/horde-3.X.X/config/conf.php => custom/horde-3.X.X/config/conf.php
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
custom/horde-3.X.X/imp-h3-4.X.X/mailbox.php
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.
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
Appliquer les requêtes SQL contenu dans : script/upgrade.sql
CAS : Le serveur HORDE doit être accessible en HTTP et en HTTPS depuis le serveur CAS.
CAS : Le serveur CAS doit être accessible en HTTP et en HTTPS depuis le serveur HORDE.
CAS : Le serveur CAS doit pouvoir ouvrir une connexion HTTPS vers HORDE, donc le certificat (ou l'autorité de certification) doit être chargé dans la JVM de CAS.
PEAR : le site web de horde propose un package PEAR tout prêt pour horde : http://ftp.horde.org/pub/pear/pear-1.3.tar.gz dézipper ce package est placer la variable php include_path en conséquence.
php_value include_path .:/home/www/TEST/pear
SESSION : HORDE est configuré de base pour utiliser des session filesystem, , veiller à bien positionner la variable php session.save_path
php_value include_path .:/home/www/TEST/pear
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.
Il existe un hook au sens horde afin de pouvoir restreindre l'accès à horde. Le fonctionnement est le suivant :
Authentification CAS
appel d'une méthode ("_cas_hook_authorisation") qui valide si la personne peut se connecter ou non.
Pour activer cette couche d'autorisation :
cp updates/horde-3.0.4/config/conf.php custom/horde-3.0.4/config/
modifier custom/horde-3.0.4/config/conf.php : $conf['auth']['params']['authorisation'] = true;
./build.sh --build
./build.sh --deploy
Pour adapter la fonction d'autorisation :
cp updates/horde-3.0.4/config/hooks.php custom/horde-3.0.4/config/
modifier custom/horde-3.0.4/config/hooks.php : changement le comportement de la fonction : _cas_hook_authorisation
./build.sh --build
./build.sh --deploy
Voir Exemple d'un fichier de configuration
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 :
MYHORDE_PATH = la racine HORDE de votre webmail horde
PACKHORDE_PATH = la racine horde du package ESUP
Procédure :
Télécharger le dernier package horde-esup
dezipper ce package on obtient ainsi PACKHORDE_PATH
copie de fichiers :
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/
appliquer le patch $PACKHORDE_PATH/patch/patch_conf_xml (sûrement a adapter)
appliquer le patch $PACKHORDE_PATH/patch/patch_imp (sûrement a adapter)
appliquer le patch $PACKHORDE_PATH/patch/patch_ingo (sûrement a adapter)
Une fois ces modifications faites, votre webmail peut fonctionner CAS reste la partie configuration :
connecter vous dans votre webmail
vous devez être administrateur et vous devez voir le menu "Adminsitration" (si ce n'est pas le cas vérifier le fichier horde/conf/conf.php partie $conf['auth']['admins'])
Allez dans Adminsitration => Configuration => Horde => Authentification
dans le menu 'What backend should we use for authenticating users to Horde?' choisissez 'CAS Authentication'
faite la configuration nécessaire.
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 :
connexion de l'utilisateur au webmail
authentification CAS
retour au webmail et récupération PT (PT-01-xxxxxxxxxxxxxxxxx)
ce PT est mis en session (webmail) comme mot de passe
lors du premier envoie de ce PT au niveau du serveur IMAP :
- saslauthd recoit ce PT
- ce PT n'est pas dans le cache SASL
- appel pam_cas et validation du PT au niveau du serveur CAS
- mise en cache de ce PT dans le cache SASL
pendant un certain temps les ouvertures IMAP utilisent ce PT (PT-01-xxxxxxxxxxxxxxxxx)
mais le cache sasl a une durée de vie (-t 3600 lors du lancement saslauthd)
Imp n'a pas conscience que le cache SASL a expiré donc il renvoie son PT (PT-01-xxxxxxxxxxxxxxxxx)
saslauthd recoit ce PT et :
- ce PT n'est pas dans le cache SASL
- appel pam_cas et tentative de validation du PT au niveau du serveur CAS
- ce PT a déjà été utilisé donc pam_cas refuse ce PT "authentication failure"
Imp reçoit donc une erreur lors de l'ouverture de la connexion IMAP
il redemande un PT (PT-02-xxxxxxxxxxxxxxxxx) au serveur CAS (il faut biensur que la session CAS soit encore valide)
il tente de réouvrir la connexion avec ce nouveau PT et là la connexion doit s'ouvrir correctement.
Le cache SASL comporte un erreur de logique dans sa gestion de cache vous trouverez les explication et la patch sur le thread suivant
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)