Calendriers partages

Dans une organisation relativement décentralisée, l’utilisation de calendriers partagés permet un suivi, et une organisation facilitée.

Un échec, pour commencer

L’année dernière, j’ai déployé à Ohm Force un intranet sous Plone. Avec, entre autres, une solution de calendrier partagé basée sur Calendaring.

Sauf que ça n’a jamais marché, en particulier avec une gestion des fuseaux horaire, et Calendaring pétait les calendriers locaux, en décalant les événements d’une heure à chaque mise à jour sur le calendrier local. Suffisant pour énerver n’importe quel utilisateur, et être sûr qu’il n’utiliserait jamais l’outil.

Personne du coup n’a utilisé l’outil, et le suivi est parti dans les limbes.

Take two

Franck, le bien aimé chef de projet à Ohm Force, m’a demandé si je pouvais remettre en place une solution.

J’ai regardé Google Calendars, qui est sympathique, et tout et tout, mais pas hébergé chez nous. Et nous, on aime pas trop les trucs pas hébergés chez nous.

J’ai repris le cahier des charges à la base. Et finalement, tout ce qu’il faut, c’est un serveur WebDAV.

Et un serveur WebDAV, sur un serveur qui fait déjà tourner Subversion et un serveur LDAP, ça s’installe en quelques lignes :


<Directory /var/www/dav>
    Dav On
    #Options Indexes FollowSymLinks
    AllowOverride None
    order allow,deny
    allow from all
    AuthName "LDAP"
    AuthType Basic

    <Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK>

    Require valid-user
        <IfModule mod_auth_ldap.c>
         AuthLDAPURL ldap://localhost/ou=unit,dc=domain,dc=top
        </IfModule>
    </Limit>
</Directory>

Donc mon serveur webdav est accessible à sur l’url https://server/dav/. Oui, c’est du https, on est jamais trop prudent.

Les clients

Ils y a deux clients principaux utilisés à Ohm Force :

  • Sunbird : le client de la mozilla foundation, qui s’améliore toujours.

  • iCal : le client de Mac OS X. Limité, mais l’interface utilisateur est sympa, (et je l’utilise depuis qu’il est sorti, je n’ai pas prévu d’en changer🙂

  • un truc sous Linux dont le nom m’échappe.

Le cas iCal est intéressant car il ne fonctionne pas sur https.

De plus, iCal, dans sa version actuelle, (Leopard change apparamment tout ça), considère que le monde des calendriers est séparé en deux groupes :

  • Ceux qu’on publie (et à chaque modification, on écrase la version sur le webdav)

  • Ceux auxquels on est abonnés (ils sont en lecture seule sur le client).

Utiliser iCal sur un serveur https

La solution est stunnel, qui permet d’encrypter/décrypter des flux SSL.

Pour PPC

Vous pouvez utiliser ces instructions de configuration, la partie “Access with login, Tiger (10.4)”

Il faut éditer le fichier /etc/stunnel.rulink.conf, en changeant l’url sécurisée vers le site de Rutgers U vers votre partage WebDAV.

Toutefois, la dernière fois que j’avais utilisé le binaire, il n’était pas compilé pour Intel, uniquement pour PPC. Ca tourne, mais c’est pas optimal.

Pour Intel

J’ai crée un petit installeur qui permet d’installer le binaire. Le truc, c’est que le dev Mac n’est pas mon truc, et qu’il faut bricoler dans le terminal pour finaliser l’installation.

J’ai réalisé l’installeur pour Ohm Force, ce qui était facile, car le serveur de calendrier est le même pour tout le monde ; l’adresse du serveur est donc en dur.

Dans celui-ci, il faut modifier le fichier de conf après l’installation /etc/stunnel.ohmforce.com pour mettre la bonne URL, puis redémarrer le service avec sudo launchctl stop com.ohmforce.stunnel ; sudo launchctl start com.ohmforce.stunnel

Voilà l’image : HTTPS iCal.dmg.zip.

1 comment so far

  1. Evandro on

    Merci!


Comments are closed.

%d bloggers like this: