> Zarafa avait deux inconvénients majeurs [...]
> un découplage restreint (quoique meilleur que - disons - Zimbra) : il est son propre serveur de stockage
Je suis d'accord avec ça. Pour avoir subit Zarafa en production, stocker les mails en bdd
- est vraiment une fausse bonne idée, il faut des énormes serveurs pour tenir la charge qu'un simple imap sur maildir peux encaisser sans efforts, c'est frappant. peut-être à cause du maintient des indexes, des contraintes d'intégrité, des méthodes d'accès (passer par un intérpreteur et query planner sql), ou de la concurence/des verroux ...
- rends les migrations/changements/adaptations/réparations à chaud difficiles ; ça fait perdre énormement de souplesse et de possibilité de rattraper les boulettes, par rapport à un format de stockage de mail classique où l'on peux manipuler les mails directement avec des outils courants ou quelques lignes de script, déplacer/répartir quelques mailboxes sur un autre serveur, faire des backups incrémentaux et restaurer mail par mail, remplacer un deamon IMAP ou LDA qui ne convient pas/plus, etc.
- Situation dans leur cas aggravée par le choix d'une structure de bdd collant au plus près (sans trop d'abstraction quoi) aux contraintes de MAPI, ce qui la rends assez imbitables (avec des colonnes contenant des champs de bits, les mails décomposés en "properties" et splittés sur x rows, etc). Schéma non documenté, bien sûr.
Cette différence d'approche (Zarafa monolithique et SOGo "intégrable") est aussi sensible en ce qui concerne les choix de protocoles d'accès privilégiés.
Dans le cas de Zarafa, on a pour protocole principal (celui de l'extension Outlook avec laquelle ils font leur beurre) une popotte maison (des requètes MAPI encapsulées dans du SOAP), et en guise de complément du pauvre un peu délaissé,des backends IMAP et iCal-over-http (oui oui, même pas du CalDAV) très frustres et probablement très peu utilisés (c'est ce que je déduit du fait qu'elles sont archi buggués). Ok, et de l'ActiveSync via Z-Push (j'ai pas testé, ça marche bien ?). Le filtrage/tris coté serveur n'est accessible que par le proto de leur client Outlook lourd (inaccessible depuis les autres clients, bye bye thunderbird), idem pour les carnets d'adresse. Pensez-y : si vous migrez hors de Zarafa, vous perdez les règles de tris et les contacts (et quelques mails si vous subissez autant de bugs que moi avec leur passerelle IMAP)...
A l'opposé, SOGo semble avoir un parti pris sans concession pour les protocoles standards, ce qui rejoint ton constat au sujet de sa capacité d'"intégration" (avec d'autres softs). Le support CalDAV est impec, les tris sont en Sieve (tout frais, mes platres), les contacts accessibles en CardDAV (déjà !) et/ou GroupDAV, le mail est délégué au serveur IMAP de son choix (qui saura surement gérer ça mieux q'un group/bloat-ware) sans réinvention d'un proto de mail-over-la-roue... sans parler des contributions à Thunderbird/Lightning (justement en vue d'améliorer le support des protocoles standards, et aussi de donner acces aux infos de disponibilité/freebusy, etc...). L'extension Outlook suggérée (Zideone, en béta qui fait peur) se contente elle-même d'ajouter à l'infâme le support des standards qu'il aurait toujours du avoir, ce qui peut aussi le rendre utile pour communiquer avec les groupware concurents. C'est l'opposé du vendor lock-in.
Par contre, un avantage à mes yeux en faveur de Zarafa, c'est qu'il ne fait pas tout pour faire peur à l'admin : les dépendances sont limités, c'est tout en C++ pas trop jojo mais "devinable" sinon lisible, les fichiers de conf sont dans /etc (et ont une syntaxe bateau), les logs dans syslog, les libs dans /usr/lib, les données statiques dans /usr/share, ça se compile bien (./configure ; make ; make install), ils fournissent des packages très propres en i386 & amd64 pour beaucoup de distros (et c'est facile de les refaire soi même). Bref, si vous avez installé quasi n'importe quel logiciel serveur du monde libre récement, d'apache à postfix ou exim en passant par postgresql ou mysql ou dovecot ou bind ou openldap..., vous ne serez pas dépaysés.
Tandis que coté SOGo, tout semble fait la façon la plus gratuitement originale possible (par rapport à ce avec quoi les admins sont généralement habitués à travailler). Tellement bizarre pour moi que j'ai renoncé de ce fait à l'utiliser en prod (à la place de l'autre zouave) de peur de ne pouvoir le comprendre, diagnostiquer, réparer, maintenir, reconfigurer ou upgrader, et malgré ses indéniables charmes (fonctionalités, souplesse et standards surtout). Codé en Objective-C (cool, mais du coup je crains qu'il n'y ai pas bcp de monde qui envoi des patchs, et donc que les bugs restent là), reposant sur une large tripotée de libs obscures et interdépendantes (et pas présentes sous debian, centos, fedora ni ubuntu) qui viennent d'un projet semblant à l'abandon (opengroupware), et qui sont stockées dans des dépots mercurial (yo, encore un truc à apprendre), et qu'il faut patcher (les libs, vous suivez ?) spécialement pour le SOGo ; dépendance forte à GNUstep (t'a déjà mis ça sur un serveur non Apple ou NeXT cher confrère ?), y compris pour le stockage de la conf (à mort la Linux Standard Base) et aussi pour son format. Quand tu a réussi à le compiler une fois (et make-installé des trucs qui vont se coller dans les coins les plus improbable du système, fait des ldconfigs à tour de bras pour que ça passe), puis mis en prod, je pense que tu espère ne jamais avoir à l'upgrader. Dommage. Quelqu'un a-t-il osé l'utiliser en prod parmis vous ?
[^] # Re: SoGo ou l'ouverture et les standards ouverts
Posté par herodiade . En réponse à la dépêche Nouvelle version de Mozilla Lightning et SOGo. Évalué à 2.
> un découplage restreint (quoique meilleur que - disons - Zimbra) : il est son propre serveur de stockage
Je suis d'accord avec ça. Pour avoir subit Zarafa en production, stocker les mails en bdd
- est vraiment une fausse bonne idée, il faut des énormes serveurs pour tenir la charge qu'un simple imap sur maildir peux encaisser sans efforts, c'est frappant. peut-être à cause du maintient des indexes, des contraintes d'intégrité, des méthodes d'accès (passer par un intérpreteur et query planner sql), ou de la concurence/des verroux ...
- rends les migrations/changements/adaptations/réparations à chaud difficiles ; ça fait perdre énormement de souplesse et de possibilité de rattraper les boulettes, par rapport à un format de stockage de mail classique où l'on peux manipuler les mails directement avec des outils courants ou quelques lignes de script, déplacer/répartir quelques mailboxes sur un autre serveur, faire des backups incrémentaux et restaurer mail par mail, remplacer un deamon IMAP ou LDA qui ne convient pas/plus, etc.
- Situation dans leur cas aggravée par le choix d'une structure de bdd collant au plus près (sans trop d'abstraction quoi) aux contraintes de MAPI, ce qui la rends assez imbitables (avec des colonnes contenant des champs de bits, les mails décomposés en "properties" et splittés sur x rows, etc). Schéma non documenté, bien sûr.
Cette différence d'approche (Zarafa monolithique et SOGo "intégrable") est aussi sensible en ce qui concerne les choix de protocoles d'accès privilégiés.
Dans le cas de Zarafa, on a pour protocole principal (celui de l'extension Outlook avec laquelle ils font leur beurre) une popotte maison (des requètes MAPI encapsulées dans du SOAP), et en guise de complément du pauvre un peu délaissé,des backends IMAP et iCal-over-http (oui oui, même pas du CalDAV) très frustres et probablement très peu utilisés (c'est ce que je déduit du fait qu'elles sont archi buggués). Ok, et de l'ActiveSync via Z-Push (j'ai pas testé, ça marche bien ?). Le filtrage/tris coté serveur n'est accessible que par le proto de leur client Outlook lourd (inaccessible depuis les autres clients, bye bye thunderbird), idem pour les carnets d'adresse. Pensez-y : si vous migrez hors de Zarafa, vous perdez les règles de tris et les contacts (et quelques mails si vous subissez autant de bugs que moi avec leur passerelle IMAP)...
A l'opposé, SOGo semble avoir un parti pris sans concession pour les protocoles standards, ce qui rejoint ton constat au sujet de sa capacité d'"intégration" (avec d'autres softs). Le support CalDAV est impec, les tris sont en Sieve (tout frais, mes platres), les contacts accessibles en CardDAV (déjà !) et/ou GroupDAV, le mail est délégué au serveur IMAP de son choix (qui saura surement gérer ça mieux q'un group/bloat-ware) sans réinvention d'un proto de mail-over-la-roue... sans parler des contributions à Thunderbird/Lightning (justement en vue d'améliorer le support des protocoles standards, et aussi de donner acces aux infos de disponibilité/freebusy, etc...). L'extension Outlook suggérée (Zideone, en béta qui fait peur) se contente elle-même d'ajouter à l'infâme le support des standards qu'il aurait toujours du avoir, ce qui peut aussi le rendre utile pour communiquer avec les groupware concurents. C'est l'opposé du vendor lock-in.
Par contre, un avantage à mes yeux en faveur de Zarafa, c'est qu'il ne fait pas tout pour faire peur à l'admin : les dépendances sont limités, c'est tout en C++ pas trop jojo mais "devinable" sinon lisible, les fichiers de conf sont dans /etc (et ont une syntaxe bateau), les logs dans syslog, les libs dans /usr/lib, les données statiques dans /usr/share, ça se compile bien (./configure ; make ; make install), ils fournissent des packages très propres en i386 & amd64 pour beaucoup de distros (et c'est facile de les refaire soi même). Bref, si vous avez installé quasi n'importe quel logiciel serveur du monde libre récement, d'apache à postfix ou exim en passant par postgresql ou mysql ou dovecot ou bind ou openldap..., vous ne serez pas dépaysés.
Tandis que coté SOGo, tout semble fait la façon la plus gratuitement originale possible (par rapport à ce avec quoi les admins sont généralement habitués à travailler). Tellement bizarre pour moi que j'ai renoncé de ce fait à l'utiliser en prod (à la place de l'autre zouave) de peur de ne pouvoir le comprendre, diagnostiquer, réparer, maintenir, reconfigurer ou upgrader, et malgré ses indéniables charmes (fonctionalités, souplesse et standards surtout). Codé en Objective-C (cool, mais du coup je crains qu'il n'y ai pas bcp de monde qui envoi des patchs, et donc que les bugs restent là), reposant sur une large tripotée de libs obscures et interdépendantes (et pas présentes sous debian, centos, fedora ni ubuntu) qui viennent d'un projet semblant à l'abandon (opengroupware), et qui sont stockées dans des dépots mercurial (yo, encore un truc à apprendre), et qu'il faut patcher (les libs, vous suivez ?) spécialement pour le SOGo ; dépendance forte à GNUstep (t'a déjà mis ça sur un serveur non Apple ou NeXT cher confrère ?), y compris pour le stockage de la conf (à mort la Linux Standard Base) et aussi pour son format. Quand tu a réussi à le compiler une fois (et make-installé des trucs qui vont se coller dans les coins les plus improbable du système, fait des ldconfigs à tour de bras pour que ça passe), puis mis en prod, je pense que tu espère ne jamais avoir à l'upgrader. Dommage. Quelqu'un a-t-il osé l'utiliser en prod parmis vous ?