Différences entre versions de « SOGo »

Version actuelle datée du 24 décembre 2010 à 19:53

SOGo (Scalable OpenGroupware.org) est un logiciel de groupe de travail (groupware) libre, proposant les fonctions de calendrier, répertoire d'adresses, et de webmail. Il est dérivé de OpenGroupware.org, lui-même basé sur SOPE (Skyrix Object Publishing Environment).

Il propose trois modes d'accès aux données:

une interface web ayant recours à AJAX,
via les protocoles GroupDAV, CardDAV et CalDAV permettant un accès par un client lourd (comme Thunderbird/Lightning par exemple),
la synchronisation avec les assistants personnels via Funambol

Cet article présente une installation du groupware sous Debian Lenny (à quelques adaptations près, il pourra aussi être utile pour une installation sur d'autres distributions). L'installation se réfère à la version 1.3.4 (avec peut-être certains extraits de la 1.3.2) et est utilisée par des utilisateurs de plusieurs nom de domaines.

L'installation a été effectuée en grande partie en suivant la documentation fournie sur le site de SOGo. Référez-vous au PDF Installation and Configuration Guide disponible sur cette page pour plus de détails.

Installation des paquets

La société montréalaise Inverse qui maintient SOGo propose des paquets sur leur dépôt debian. Pour l'utiliser, vous devrez donc ajouter leur dépôt à votre liste de dépôts, par exemple en ajoutant la ligne suivante à votre fichier /etc/apt/sources.list:

deb http://inverse.ca/debian lenny lenny

Il suffit ensuite d'installer le paquet sogo qui installera les dépendances nécessaires. Notez que les paquets n'étant pas signés, vous devrez continuer explicitement leur installation en répondant Oui à l'avertissement du gestionnaire de paquets:

 sogo:~# aptitude install sogo
 Lecture des listes de paquets... Fait
 Construction de l'arbre des dépendances       
 Lecture des informations d'état... Fait
 Lecture de l'information d'état étendu      
 Initialisation de l'état des paquets... Fait
 Lecture des descriptions de tâches... Fait  
 Les NOUVEAUX paquets suivants vont être installés : 
   autotools-dev{a} gnustep-base-common{a} gnustep-base-runtime{a} gnustep-common{a} gnustep-make{a} libavahi-client3{a} libavahi-common-data{a} libavahi-common3{a} 
   libavahi-compat-libdnssd1{a} libdbus-1-3{a} libffcall1{a} libgnustep-base1.16{a} libldap-2.4-2{a} libmemcached2{a} libmysqlclient15off{a} libobjc2{a} libsope-appserver4.9{a} 
   libsope-core4.9{a} libsope-gdl1-4.9{a} libsope-ldap4.9{a} libsope-mime4.9{a} libsope-xml4.9{a} libxml2{a} libxslt1.1{a} mysql-common{a} perl{a} perl-modules{a} sgml-base{a} 
   sogo sope4.9-gdl1-mysql{a} sope4.9-libxmlsaxdriver{a} tmpreaper{a} xml-core{a} 
 Les paquets suivants sont RECOMMANDÉS mais ne seront pas installés :
   dbus libnss-mdns memcached mysql-server mysql-server-5.0 
 0 paquets mis à jour, 33 nouvellement installés, 0 à enlever et 0 non mis à jour.
 Il est nécessaire de télécharger 18,2Mo d'archives. Après dépaquetage, 65,6Mo seront utilisés.
 Voulez-vous continuer ? [Y/n/?] 
 ATTENTION : des versions non certifiées des paquets suivants vont
 être installées.
 
 Des paquets non certifiés peuvent compromettre la sécurité de votre
 système. Vous ne devriez les installer que si vous êtes certain
 que c'est bien votre intention.
 
   libsope-core4.9 libsope-gdl1-4.9 libsope-mime4.9 sope4.9-gdl1-mysql libsope-ldap4.9 libsope-xml4.9 sogo libsope-appserver4.9 libmemcached2 sope4.9-libxmlsaxdriver 
 
 Voulez-vous ignorer cet avertissement et continuer quand même ?
 Pour continuer, entrer « Oui ». Pour interrompre l'installation, entrer « Non » : Oui

Attention: il vous faut ensuite installer le paquet correspondant à la base de données que vous souhaitez utiliser, sinon SOGo ne fonctionnera pas et affichera l'erreur suivante dans ses logs:

EOAdaptor: cannot find adaptor bundle: 'PostgreSQL'

SOGo supporte les SGBD PostgreSQL, MySQL, et Oracle. En fonction de votre choix, vous devrez donc installer les paquets sope4.9-gdl1-postgresql, sope4.9-gdl1-mysql, ou sope4.9-gdl1-oracle. Pour mon installation de test, j'avais fait le choix de PostgreSQL (l'installation de production se base sur MySQL):

aptitude install sope4.9-gdl1-postgresql

Configuration de SOGo

SOGo utilise le système de base de données de configuration du projet GNUStep, qui implémente une sorte de base de registres.

Cette configuration sera utilsé par l'utilisateur système sogo qui a été créé à l'installation des paquets. La commande defaults permet la manipulation de la configuration, qui est dans le fichier ~/GNUstep/Defaults/.GNUstepDefaults. Elle est donc différente pour chaque utilisateur. Ici, l'application fonctionnant sous le compte sogo, il faudra bien veiller à exécuter les appels à defaults sous l'utilisateur sogo.

On passe donc sous le compte sogo

su - sogo

ou bien

sudo -u sogo -i

Paramètres de base

On commence par la définition de paramètres de base. Reportez-vous au PDF pour connaître les fuseaux horaires disponibles et la signification de toutes ces options.

# Langue par défaut
defaults write sogod SOGoLanguage "French"
# Envoi d'un mail aux participants d'un rendez-vous
defaults write sogod SOGoAppointmentsSendMailNotifications NO
# Envoi d'un mail lors de la création d'un carnet d'adresse ou un agenda
defaults write sogod SOGoFoldersSendEMailNotifications NO
# Envoi d'un mail aux personnes concernées par le changement d'ACL d'un agenda
# ou d'un carnet d'adresses.
defaults write sogod SOGoACLsSendEMailNotifications NO

Une option SOGoMailDomain détermine le domaine utilisé par défaut, d'après la documentation, pour « construire la liste des adresse email valides pour les utilisateurs ». Je n'ai pas trouvé à quoi ça correspond exactement, et je ne l'utilise pas dans ma configuration. Mes noms d'utilisateurs sont les adresses électronique complètes.

Si votre serveur IMAP utilise les adresses électroniques comme identifiants, mais que vous voulez utiliser des noms d'utilisateur différents sous SOGo, vous devriez pouvoir le faire grâce à la clef de configuration « SOGoForceIMAPLoginWithEmail » qui permet d'utiliser l'adresse électronique principale d'un utilisateur au lieu de son nom d'utilisateur pour se connecter au serveur IMAP.

SOGo supporte normalement la configuration de plusieurs domaines ayant chacun leur source d'authentification (disjointe), leur serveur mail, et d'autres options particulières, comme le montre un exemple donné dans le guide d'installation, mais je n'ai pas réussi à activer cette fonctionnalité: lors de mes tests, seul le premier domaine configuré était fonctionnel, et les utilisateurs de l'autre domaine ne pouvaient pas se connecter. Reportez-vous au guide d'installation si vous avez besoin de cette fonctionnalité.

Serveur SMTP

On précise le serveur SMTP que SOGo pourra utiliser

defaults write sogod SOGoMailingMechanism smtp
defaults write sogod SOGoSMTPServer smtp.cliss21.com

Serveur IMAP

Ici on précise le serveur IMAP à utiliser. Notez que SOGo utilise le mot de passe de l'utilisateur pour se connecter à ce serveur IMAP. Il faut donc que le serveur IMAP et SOGo partagent la même source d'authentification ou bien veiller à ce que que les mots de passe soient toujours identiques.

defaults write sogod SOGoIMAPServer localhost
defaults write sogod SOGoDraftsFolderName INBOX.Drafts
defaults write sogod SOGoSentFolderName INBOX.Sent
defaults write sogod SOGoTrashFolderName INBOX.Trash

La base de données

Base PostgreSQL

Le guide d'installation fournit les commandes de la base de données via les appels aux commandes système createuser et createdb. Personnellement, je préfère me connecter à la base de données et effectuer les requêtes moi-même. Pour vous connecter à la base de données, sous Debian, par défaut il faut effectuer la commande suivante:

su - postgres -c psql template1

puis créer l'utilisateur et la base de données:

CREATE USER sogo PASSWORD 'sogo';
CREATE DATABASE sogo OWNER sogo;

Notez que l'utilisateur PostgreSQL doit avoir le droit de créer des tables. Ici, l'utilisateur sogo aura tous les droits sur la base de données. Assurez-vous que votre serveur postgresql permet bien l'authentification par mot de passe depuis le serveur SOGo. Sous Debian, c'est normalement déjà le cas, mais pour les autres distributions, vous devrez peut-être ajouter une ligne telle que celle-ci au fichier pg_hba.conf de votre configuration PostgreSQL (sous debian c'est /etc/postgresql/8.3/main/pg_hba.conf, sous RedHat ça doit être /var/lib/pgsql/data/pg_hba.conf)

On définit ensuite la base de données utilisée par SOGo. Les tables seront créées automatiquement au redémarrage de SOGo.

defaults write sogod SOGoProfileURL 'postgresql://sogo:sogo@bdd1:5432/sogo/sogo_user_profile'
defaults write sogod OCSFolderInfoURL 'postgresql://sogo:sogo@bdd1:5432/sogo/sogo_folder_info'

Base MySQL

Pour créer la base de données, j'ai utilisé les requêtes suivantes:

mysql> CREATE DATABASE sogo DEFAULT CHARSET UTF8;
mysql> GRANT ALL ON sogo.* TO sogo@localhost IDENTIFIED BY '*********';

Assurez-vous que l'utilisateur MySQL « sogo » a bien les permissions nécessaires à la création de nouvelles tables. Non seulement c'est SOGO qui va créer les tables au premier démarrage (assurez-vous que c'est bien le cas, il le mentionne dans son fichier de log), mais SOGo crée également plusieurs tables pour chaque utilisateur (notamment pour y conserver leurs carnets d'adresses).

On désigne dans la configuration la base de données utilisée par SOGo avec les clefs suivantes:

defaults write sogod SOGoProfileURL 'mysql://sogo:********@localhost/sogo/sogo_user_profile'
defaults write sogod OCSFolderInfoURL 'mysql://sogo:********@localhost/sogo/sogo_folder_info'
defaults write sogod OCSEMailAlarmsFolderURL 'mysql://sogo:********@localhost/sogo/sogo_alarms_folder'

OCSEMailAlarmsFolderURL n'est nécessaire que si vous activez les rappels par courriel (voir la section sur ces rappels, plus bas dans ce document).

Source d'authentification des utilisateurs

La source d'authentification pour SOGo peut être un annuaire LDAP, une base de données d'un SGBD supporté, ou un serveur CAS (Central Authentication Service).

Je ne traiterai ici que de l'authentification par proxy (que je n'ai pas pu valider entièrement) et l'authentification par base de données, que j'utilise.

Authentification sur le Proxy web

L'authentification SOGo peut théoriquement s'appuyer sur l'authentification faite par le proxy web installé en frontal (ce qui permet de supporter toutes les authentifications supportées par les modules apache, notamment Kerberos par WebAuth, etc.).

Pour cela, positionner une clef SOGoTrustProxyAuthentication à YES:

defaults write sogod SOGoTrustProxyAuthentication YES

Puis configurez l'authentification apache dans le fichier /etc/apache2/conf.d/SOGo.conf (ceci dépend du type d'authentification que vous désirez, et n'a rien de spécifique à SOGo), et décommenter la ligne suivante pour configurer la variable x-webobjects-remote-host dans l'environnement Apache en y affectant la valeur de la variable d'environnement REMOTE_USER :

## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
#  RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"

Cette authentification pose cependant le problème du mot de passe utilisé pour lire les messages de l'utilisateur sur le compte IMAP. Si vous fournissez une source d'authentification (voir les sections suivantes) avec un mot de passe en clair, SOGo sera peut-être assez intelligent pour y récupèrer le mot de passe, ou bien, comme je l'ai lu dans des commentaires sur le web, vous devrez configurer un accès au serveur IMAP sans authentification, réservé à SOGo.

Je n'ai cependant pas testé cette fonctionnalité car je n'ai jamais réussi à faire accepter l'authentification du Proxy à SOGo, malgré l'option SOGoTrustProxyAuthentication: SOGo s'obstinait à afficher une page blanche avec un mot indiquant que l'authentification n'était pas reconnue.

Authentification par base de données

Authentification par une table PostgreSQL

Pour authentifier les utilisateurs de SOGo sur une base de données, il suffit que la table ou vue désignée comme source d'authentification dispose des champs définis c_uid, c_name, c_password, c_cn, et mail.

Pour mes tests, j'ai simplement créé une table PostgreSQL dans la même base que SOGo, avec la définition suivante:

CREATE TABLE sogo_user (
   c_uid character varying NOT NULL,
   c_name character varying,
   c_password character varying,
   c_cn character varying,
   mail character varying
);
ALTER TABLE public.sogo_user OWNER TO sogo;
ALTER TABLE ONLY sogo_user ADD CONSTRAINT sogo_user_pkey PRIMARY KEY (c_uid);

J'ai ensuite créé manuellement quelques utilisateurs en insérant des données dans ma table d'authentification sogo_user:

INSERT INTO sogo_user VALUES ('sogo','SOGo Administrator',md5('azerty'),'SOGo Administrator','tech@-NOSPAM-cliss21.com');
INSERT INTO sogo_user VALUES ('herschel','Herschel Krusfoski ',md5('monmotdepasse'),'Herschel Krustofski','herschel@-NOSPAM-cliss21.com');

Ce n'est ici qu'une source d'authentification à but de test. En production, nous nous basons sur une vue MySQL.

On insère dans la base de configuration les identifiants d'accès à cette base:

defaults write sogod SOGoUserSources '({
type = "sql";
id = "directory";
viewURL = "postgresql://sogo:sogo@bdd1/sogo/sogo_user";
canAuthenticate = YES;
isAddressBook = YES;
userPasswordAlgorithm = md5;
displayName = "Carnet d'adresses général (lecture seule)";
})'

isAddressBook = YES et displayName permettent d'utiliser cette source d'authentification comme carnet d'adresse en lecture seul. Nous ne l'utilisons en fait pas car cela exposerait les adresses de l'ensemble des comptes de messagerie électronique du serveur, ce qui n'est pas acceptable (ce n'est pas la seule chose que nous avons dû désactiver pour ne pas exposer tous les comptes du serveur: voir la section à ce propos plus bas dans ce document).

L'idéal aurait été de disposer d'une source d'authentification par domaine dans une configuration multi-domaine, qui permettrait de l'utiliser sans risque comme carnet d'adresse. Malheureusement, comme on l'a vu, je n'ai pas réussi à faire fonctionner la configuration multi-domaine.

Plusieurs bases de données (ou annuaire LDAP) devraient pouvoir être utilisés comme source de données en les ajoutant à la liste qu'est SOGoUserSources, séparés par des virgules, par exemple (je l'écris au conditionnel car je ne l'ai pas testé: n'ayant pas eu de succès avec la configuration multi-domaines, il est possible que cette fonctionnalité pose également problème):

defaults write sogod SOGoUserSources '({
   /* source 1 */
},
{
   /* source 2 */
})'

Authentification par une vue MySQL

En production, nous avions besoin d'authentifier les utilisateurs à une base MySQL existante (utilisée par postfix). Nous utilisons donc une vue MySQL qui exporte les données nécessaires avec les noms de colonnes nécessaires à SOGo. Pour le rôle des différents champs demandés par SOGo, reportez-vous au guide d'installation (dans l'exemple d'authentification SQL):

CREATE VIEW sogo_auth_view AS
       SELECT  username AS c_uid,
               username AS c_name,
               password AS c_password,
               username AS c_cn,
               username AS mail,
               name AS displayName
       FROM mailbox
       WHERE active=1;

Sans oublier de définir les droits adéquats pour l'accès à la vue et à la table:

GRANT SELECT ON postfix.sogo_auth_view TO sogo_auth@localhost;
GRANT SELECT ON postfix.mailbox TO 'solog_auth'@'localhost';

Et voici la source d'authentification correspondante définie dans SOGo (la base de données s'appelle postfix):

defaults write sogod SOGoUserSources '({
    type = "sql";
    id = "directory";
    viewURL = "mysql://sogo_auth:********@bdd1/postfix/sogo_auth_view";
    canAuthenticate = YES;
    isAddressBook = NO;
    userPasswordAlgorithm = md5;
})'

Ce n'est cependant pas exactement la configuration que nous avons adopté car SOGo ne supporte que deux formats de mots de passe: en clair ou sous format md5; et notre base d'utilisateurs possède des mots de passe sous format crypt-md5...

Pour contourner le problème, nous avons dû mettre en place une page de login imitant celle de SOGo qui authentifie les utilisateurs sur notre base de données existante, et stocke le mot de passe sous forme md5 dans une table annexe utilisée par la vue pour remplacer le mot de passe d'origine. En cas de succès, l'utilisateur est alors redirigé vers SOGo de façon transparente (ce qui n'est pas facilité par l'utilisation intensive d'Ajax par cette page...) via une authentification normale.

Ce contournement fonctionne, mais, étant très spécifique à notre environnement, nous ne le détaillons pas ici. Si vous souhaitiez en savoir plus, n'hésitez pas à contacter l'équipe de Cliss XXI.

Rappels par mail

Si vous souhaitez que l'utilisateur puisse recevoir des alarmes par mail avant ses rendez-vous notés dans son agenda, vous devez définir une table dans la configuration de SOGo (qui sera créée automatiquement) via l'option OCSEMailAlarmsFolderURL (déjà mentionnée plus haut), et activer l'option SOGOEnableEMailAlarms:

defaults wrire sogod SOGOEnableEMailAlarms YES
defaults write sogod OCSEMailAlarmsFolderURL 'mysql://sogo:********@localhost/sogo/sogo_alarms_folder'

Vous devrez ensuite paramétrer un job cron sur votre serveur pour exécuter chaque minute la commande /usr/sbin/sogo-ealarms-notify. Voici un exemple de fichier que vous pourrez placer par exemple dans /etc/cron.d/sogo:

# SOGo rappels par email
* *     * * *   sogo    /usr/sbin/sogo-ealarms-notify

Configuration du serveur web

SOGo dispose de son propre daemon, qui reçoit par défaut ses requêtes sur le port 20000. Pour servir les fichiers images, CSS et autres, il faut installer un serveur HTTP en frontal qui servira de proxy aux requêtes princiaples, relayées vers le port 20000. SOGo recommande le serveur NGinx, mais je me suis lâchement contenté d'Apache.

Les paquets debian de SOGo installent sa configuration apache dans le fichier /etc/apache2/conf.d/SOGo.conf. Vous devrez l'adapter pour modifier les lignes suivantes:

 RequestHeader set "x-webobjects-server-port" "443"
 RequestHeader set "x-webobjects-server-name" "sogo"
 RequestHeader set "x-webobjects-server-url" "https://sogo.cliss21.com"

Notez que si vous précisez une adresse en HTTPS comme URL du serveur, vous devrez activer et configurer mod_ssl pour votre serveur apache.

La configuration SOGo nécessite mod_proxy et mod_headers. On configurera également l'accès par https si ce n'est déjà fait. Sous debian, l'activation d'un module se fait simplement avec la commande a2enmod et celle d'un vhost par a2ensite. Adaptez les commandes à votre distribution.

# activation des modules proxy et headers
a2enmod proxy_http # ceci active aussi mod_proxy dont dépent mod_proxy_http
a2enmod headers
# activation du module ssl et de la configuration par défaut pour un accès par https
a2enmod ssl
a2ensite default-ssl
# redémarage du serveur pour prendre en compte ces modifications
invoke-rc.d apache2 restart

Exposition de tous les comptes de messagerie du serveur

Comme je l'ai mentionné plus haut, si on définit la source d'authentification comme carnet d'adresse en lecture seule, tous les utilisateurs de la source d'authentification seront révélés à vos utilisateurs de SOGo. On peut s'en prévenir en n'activant pas de carnet d'adresse global.

Une autre fonctionnalité révèle également l'ensemble des utilisateurs de votre installation SOGo: il s'agit de l'abonnement à un carnet d'adresses. Cette fonctionnalité est accessible à tous les utilisateurs authentifiés de SOGo depuis leurs pages de gestion des carnets d'adresses, via un bouton « s'abonner à un carnet d'adresse ».

Ce bouton ouvre une page permettant la recherche d'un carnet d'adresse partagé par un autre utilisateur. Même les utilisateurs ne partageant aucun carnet sont affichés dans le résultats d'une recherche, et une recherche avec le modif « . » affiche l'ensemble des utilisateurs.

Ceci n'est pas acceptable dans un environnement ISP, et il est regrettable que SOGo ne dispose pas de fonctionnalité pour limiter cette exposition.

En attendant une éventuelle correction, nous avons pu désactiver cette fonctionnalité en supprimant le bouton y donnant accès dans le modèle de la page de gestion des carnets d'adresses, et en interdisant l'accès à l'URL permettant la recherche d'un carnet d'adresses partagé au niveau de la configuration du serveur web.

La modification du modèle de la page SOGo est la suivante:

--- /usr/lib/GNUstep/SOGo/Templates/ContactsUI/UIxContactFoldersView.wox        2010-12-24 17:53:02.000000000 +0000
+++ /usr/lib/GNUstep/SOGo/Templates/ContactsUI/UIxContactFoldersView.wox.orig   2010-12-24 17:53:21.000000000 +0000
@@ -101,10 +101,10 @@
             
           </a>
                  <a href="#" class="smallToolbarButton">
-            
+                         
                  </a>
           <a href="#" class="smallToolbarButton">

Attention: si l'on commente toute la base <a></a> du lien, d'autres fonctionnalités de la gestion des carnets d'adresse ne fonctionnent plus. Supprimer le contenu du lien suffit (au prix d'une petite partie invisible mais cliquable sur la page, entre les deux autres liens).

Pour interdire l'accès à l'URL de recherche des cartes d'adresses partagés, nous avons ajouté la directive suivante dans la configuration Apache:

<LocationMatch "/SOGo/so/.*/Contacts/userFolders">
    Order allow,deny
    Allow from none
</LocationMatch>

Lancement de SOGo

Après cette configuration, il faut redémarrer le daemon sogo (de même qu'après chaque modification du fichier .GNUstepDefaults):

/etc/init.d/sogo restart

Fichier de log

SOGo écrit une certaines quantité d'information dans son fichier de log /var/log/sogo/sogo.log. Il est possible d'activer les logs de certains composants à l'aide de clefs de configurations figurant dans la FAQ de SOGo.

Accès à l'interface web

Il ne vous reste plus qu'à vous connecter à SOGo. L'interface web est disponible à l'adresse désignant le serveur sur lequel vous avez installé SOGo, suivi de /SOGo (respectez la casse, ou bien modifiez '/etc/apache2/conf.d/SOGo.conf si vous souhaitez utiliser un autre nom).

Accès via un client lourd

SOGo permet la synchronisation de ses donées avec un client lourd tel que Thunderbird ou Outlook. Pour Thunderbird, il faut lui installer l'extention Lightning modifiée par inverse (Inverse travaille avec Mozilla pour intégrer les modifications nécessaires à la branche principale), ainsi que deux extensions spécifiques: sogo-connector et sogo-integrator.

Référez-vous au document « SOGo Mozilla Thunderbird Configuration.pdf » disponible dans la partie documentation du site de SOGo.

Préparation des extensions Thunderbird

Ces extensions sont prévues pour être déployées au niveau d'une organisation, et un script de mise à jour automatique des extensions est fourni. Elles sont téléchargeable sur le site de SOGo, dans la partie « frontend »: http://www.sogo.nu/fr/downloads/frontends.html

Avant d'installer les extensions, il est nécessaire de modifier l'extention sogo-integrator pour préciser l'URL du script de mise à jour des extenstions, dont semble dérivée l'url de l'installation SOGo (il ne semble malheureusement pas possible de préciser une autre url, mais je n'ai pas encore vérifié dans les sources). Pour ça, suivez la procédure suivante:

désarchiver le .xpi (avec zip ou jar);
modifier le fichier chrome/content/extensions.rdf pour y mettre une URL qui pointe sur votre serveur dans l'attribut isi:updateURL de la balise Seq. Par exemple:

  <Seq about="http://inverse.ca/sogo-integrator/extensions"
       isi:updateURL="https://sogo.cliss21.com/plugins/updates.php?plugin=%ITEM_ID%&version=%ITEM_VERSION%&platform=%PLATFORM%">

recréer l'archive .xpi (toujours avec zip ou jar).

Pour pouvez alors installer les extensions dans thunderbird.

Notez qu'une limitation actuelle de ces extensions impose que le premier compte utilisé par Thunderbird soit configuré avec les mêmes login et mot de passe que ceux de l'utilisateur dans SOGo.

Mise en place du script de mise à jour des extensions

Les sources de SOGo comprennent un répertoire Scripts dans lequel se trouve un script « updates.php » que vous devrez installer dans un répertoire de votre serveur web hébergeant SOGo, et qui permettra aux client Thunderbird de mettre à jour les extensions SOGo automatiquement.

Avant de le mettre en place, adaptez l'URL dans la balise em:updateLink pour pointer vers votre répertoire de téléchargement des extensions.

À la mise en place et à chaque nouvelle version des extensions, vous devrez modifier le fichier pour préciser les numéros de version et les fichiers correspondant pour chacune des trois extensions. Pour ne plus proposer de mise à jour d'une extention, sans pour autant que les autres clients ne la désinstalle, précisez « disabled » comme numéro de version.

En cas de problème

Si votre installation ne fonctionne pas, voici quelques points à vérifier:

vérifiez éventuellement les fichiers de logs de votre serveur web, mais surtout le fichier de logs de sogo /var/log/sogo/sogo.log.
vérifiez que le daemon sogo écoute bien sur le port 20000 (il ne s'est jamais arrêté inopinément, mais on peut vérifier qu'il a bien été lancé):

$ netstat -let | grep 20000 && echo "ok, un daemon écoute bien sur le port 20000"
tcp        0      0 *:20000                 *:*                     LISTEN      sogo       8085182    
ok, un daemon écoute bien sur le port 20000

Si ce n'est pas le cas, tentez de redémarrer le daemon:

/etc/init.d/sogo restart

Plus d'information

Pour plus d'information, vous pourrez consulter les sites suivantes:

le site officiel de SOGo, qui propose son téléchargement, ainsi que celui des extentions Thunderbird et Lightning;
la documentation officielle de SOGo (également sur son site officiel), incluant trois guides en anglais :
- SOGo - Installation and Configuration Guide (PDF)
- Mozilla Thunderbird - Installation and Configuration (PDF)
- Mobile devices - Installation and Configuration (PDF)