Well I won’t discuss yet another time about some CMS’ popularity. I’ve been told that using Google Trends to evaluate the popularity of something wasn’t a good idea. So evaluating it through job trends should be a bad idea as well, especially when as a developper you try to find your way out of the economic crisis.

Far more interesting and comforting, the Python Job Trend is unarguably growing – which is something very good. Zope is not the only « Python killer app » anymore.

Oh, and when you talk about python web frameworks, you can’t omit Django nor Pylons. Which leads to this very interesting graph below :

So, what we can learn is that :

• Zope opportunities are dramatically decreasing
• There are more Django opportunities than Pylons opportunities
• Django’s interest is growing significantly !

The rise of Plone

I started working with Zope in 2000, and I was immediately impressed by its strengh. Dude, that was nine years ago. I even wrote some books about it, as it lacked documentation by this time. Plone was brought to my eyes in mid-2002  by my old-time friend Kamon Ayeva. Then I began working heavily with Plone as a developper and contributed a few modules.

Plone 1.0 came out in 2003 and had a tremedous effect on the rising sun of CMSes in Planet Earth. Wow. Such a wonderful package, and as was said by Mike Sugarbaker in OSCON 2002 :

I won’t do the complete rundown of all the « competing » open source content management frameworks. I’ll cut to the chase : the winner is Plone. The package with the most tools, the most professionalism, the most traction, and above all, the most buzz.

Then went great times. Big companies joined the boat, small companies arised (especially here in France) and started to organize. Pilot Systems and Ingeniweb were the two major competitors in France for Plone, but many other small businesses joined in. Pilot and Ingeniweb both had prestigious customers, such as large industrial companies, banks, etc. Plone was a success for, IMHO, the following reasons :

• Open-source : openness was becoming a strong trend back in 2003 ; as such, many companies started to turn to open source software providing a professionnal service.
• Technology advance : Plone was one of the rare serious (open-source) CMSes by these times and provided in an integrated package some powerful features it was difficult to find somewhere else : MS-Office indexing, LDAP integration, components architecture, SEO, Cache efficiency.
• The big CMS time : by this time, there were not so many widely used CMS software. My grandmother wasn’t aware of Internet Power (well, in fact she was dead). Blogs were run by techies and were not as popular as in 2006. We were in year 2 before S.B…

We gained marketshare over big CMS companies such as Documentum. Even CA showed a strong interest in Plone and contributed to the Plone Foundation creation.

Then we missed something.

2006/2007 : Maturity

By 2006 I stopped developping with Plone and became more into python teams management and commercial activites. Plone was easy to sell for us at Ingeniweb : we had a tremendous experience on what customers needed as an added value from the « out-of-the-box » product. In fact, most customers always wanted the same things over the out-of-the-box product :

• Plone essentially as an intranet ;
• LDAP integration ;
• Nice user interface / skin design ;
• Powerful search engine indexing MSWord / PDF documents ;
• Workgroups ;
• Large file storage (which required additional products because it was inefficient in ZODB).

That’s the time I should have noticed something were becoming wrong. Although we had a great experience of those custom installation, and although customers needs were often the same, we always had to do custom installations each and every time, which involved a lot and a lot code to do.

Plone was there a mature product we had very good time working with, but my teams started complaining about the refactoring maniacs in Plone and the updates-that-break-everything trend. I didn’t pay too much attention.

Oh, and by the way, the last sign of life we get from CA’s Plone-based Brightstor Document Management is somewhere in 2005. But we had great successes in deploying large intranets. Wow.

Plone’s future was promising : it was said by those times that Plone would gain an enormous benefit from using Zope 3 instead if Zope 2 (Zope 3 was talked about since at least 2002). Performance was also something to improve.

2008 : Missing the step

In 2008 I started to think we should find alternatives to Plone. We began loosing some contracts, and with time I think the reasons were simple.

CMS were widely spread in 2008. In 2003 it was a niche market but in 2008 many companies, small or big, offered those services, and the price-to-pay for a CMS decreased dramatically. That’s something we didn’t figure out at this time.

Plone was state-of-the art back in 2003, and as it was then widely accepted that it was based on a not-well-known language and ran on a less-than-well-known platform (Zope). I won’t argue about the strengh of Python (which I love) and Zope 2 (which is now too anti-MVC for me to keep it as a viable solution for my projects). But, hell, we were in 2008 and LAMP solutions were widely accepted even by large organizations. Although it was an advantage 5 years before, edge technology made Plone harder to sell. Many people involved in Plone didn’t understand that and there were some big fights in my company against PHP. PHP was shit. PHP was brainfuck. PHP was hell. Python was THE rule, Python was for Internet what C’s been for Unix. Yeah… but sometimes, to sell to the masses, you have to listen to them just a tiny bit – and we missed that. Which major hoster provided a Zope / Plone hosting service ? None. Which hoster provided a PHP hosting offer ? All of them (even at Ingeniweb we had some PHP stuff running ! But, hush, that’s a secret).

One of the major inconvenience of using an edge technology was that it was difficult to find developpers. Plus, when you’d find a Python programmer, you’d have to train him to Zope, then train him to Plone. And it is impossible for people with average developpment skills to program Plone. The learn curve is tedious (have you noticed how the Plone Conf 2009 logo looks like a Plone learning curve, by the way ? even the falldown is there !). But it’s difficult having people who masterize both programming and HTML/CSS integration. Hence the failure : we had a lot of programmers, writing PROGRAMS instead of WEB SITES. And when you look at Plone as it is today, you notice it’s really the major error for it : Plone people are programmers, not web people. Remember the early success of Plone ? Limi was an UI guy, not a programmer. We’ve lost that. Now, Plone people code because they love to code. In my company, doing a roll-down menu was a pain for all the guys. No one seemed to be able to build a site that was working with IE6.

Also, using an edge platform, Plone was very dependant of it. The future of Zope became at one point linked to the future of Plone (Paul Everitt saying that Plone was the « killer app » of Zope). But when you look at the Zope history, you cry… Zope 3 was full of promises, it was Zope 2 advantages without Zope 2’s defaults. And Zope 3.0 came out in fall 2004. In late 2009, Plone is still using Zope 2.x !  When I think about Five, things become more funny. Five is Zope 2 + Zope 3 : a way to use Zope 3 features with Zope 2 architecture. Plone architecture is a layer cake, with criptic pathes everywhere. It’s so layered that there are so many ways to do just one thing… Wait, that reminds me of a language Python programmers love to hate ! So, when you think about our programmer, he has to master :

• Python (of course)
• Zope 2
• The concepts of Zope 3
• Five’s way of integrating Zope 2 into Zope 3
• Plone 3.x
• Plone 2.x because many things are still done the Plone 2 way instead of the Plone 3 way

Now, do you understand the learning curve ? And do you understand that there’s not too much room for HTML/CSS advanced skills ? How much time must a newbee spend to become a Plone 3 master ? Plone’s architecture evolution is the exact contrary of Python’s way of evolving. Well, hopefully, some people understood that and started adding a new layer (once more) to integrate great Python concepts : eggs and so on. So you have now to master one more layer, distutils, to install a simple product into Plone. Nuxeo understood this back in 2006 when they decided rewriting their ECM suite from Zope to Java. We laughed at them by this time, thinking they would never succeed, but they did – and they did it well. We though Zope was the ultimate web framework. Instead, Zope was becoming older and older. Zope 3 promises remain unfulfilled by this day.

When I started writing this article, I drawed a simple timeline to explain why I were leaving Plone. Here it is. I didn’t invent anything, it comes from the official release timeline.

Ok, now do you notice something special ? Yes : no major feature added since mid-2007 (that is, the prehistoric times). By no means people stopped working on Plone core ! They did. They refactored some code, leading developpers to learn new layers as well as old layers. Then they refactored more, developpers had more to learn. Then they refactored more, loosing interest from everybody. Developpers are now fed up with this refactormania.

Then, last but maybe most important thing : as a specific designed product, with a nearly underground framework, Plone ignored competition. Both « buzz » and features became more important with other products such as Drupal, Joomla! or eZ-Publish. Yeaaaah, I know, those products are full of defaults and Plone is nearly perfect – no kidding, I was considered as a fucking bastard when I tried to introduce Plone alternatives in my company. But still. Look at cruel, raw facts. See this drawing there :

Can you see this blue line hitting the ground? That’s Plone’s popularity. And, if you wonder, yes : Plone’s popularity is decreasing.

Wait ! There’s even more fun stuff. See that ? Plone is now as (un)popular as SPIP. What a shame.

Today : thank you and goodbye, guys !

As of today, Plone is seen by many as a black box with magic inside. Sometimes the magic works and it’s nice, sometimes it doesn’t and you have to spend several years in Harry Zopper’s sorcerer school to understand why it doesn’t work and how to fix it.

Plone is full of « proprietary » (I mean, not widely spread nor supported) software. Zope. ZODB. Even Kupu, the visual editor, is poorly spread (plus has a stupid name). Python is the only great thing about Plone as of today.

No matter how you put it, Zope is slow. Can’t believe me ? Click this and have a coffee.

Plone’s future is pityful. Look at this great news item from Pilot Systems. Want to know what’s the future of Plone ?

• Refactoring, refactoring, refactoring ;
• Getting rid of the past errors (Kupu => TinyMCE – at last !)
• Getting the modernity train (new skin, blob support – at last)
• Some more stuff to learn (tiles / deco, dexterity vs. archetypes, Chameleon, Queryplan, …)

Were are the new features ? Hidden.

Where are the solutions to the learning curve problem ? Hidden, as well ;)

For all there reasons, I’m not part of the game anymore.

I’ve used Drupal, eZ and Joomla! and I’ve found that those communities were well-organized. I’ve also found that :

• Installing a product could be as simple as untaring a file ;
• Deploying a site didn’t require to know 8 frameworks ;
• Designing a skin was as simple as integrating HTML+CSS into a set of files (Delivrance is such a big joke by the way) ;
• There was ONE WAY to do things well, and this way was obivous ;
• There were many quality extensions to those products.

I’ll miss Plone for edge Intranet projects with important security requirements.

I’ll still be using Python for other projects – you can’t quit Python as easily :)

I’ll still keep in touch with Plone companies such as Ingeniwebalterwaysolutions or Pilot Systems with respect. Those two last years, Pilot did a far better job than Ingeniweb at promoting Plone – and it’s important they did it. But it’s funny to see that both companies are now moving towards different directions beyond Plone. Just like, back in 2006, Nuxeo waved away from Zope.

I’ll miss 2006’s Plone strength, but you can’t always rely on the past. Many CMSs has been (and are still) moving fast, but Plone stayed immobile, just re-re-re-painting blinds.

Mais dès que l’on rentre dans les subtilités, et en particulier dans la configuration multi-sites, se pose parfois un vrai problème : l’écran blanc de la mort. Concrètement : vous voulez configurer Drupal, vous accédez à l’URL de votre site depuis un navigateur, et là, tel Steevy Boulay devant son autobiographie, une page strictement blanche, strictement vide, zéro octet, rien.

En général, ce symptôme est dû à un problème de sécurité dans les répertoires de Drupal, mais reste à trouver quoi et où. Rien sur la page, rien dans les logs, ça ne simplifie pas.

Aussi, pour trouver l’origine du problème, il existe une astuce. Éditez le fichier index.php à la racine de votre htdocs de Drupal et ajoutez les lignes suivantes (en gras) au début du fichier :

<?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
// $Id: index.php,v 1.94 2007/12/26...

Et là, les erreurs devraient s’afficher, de façon beaucoup plus explicite, sur la page HTML. Pensez évidemment à supprimer ces lignes après avoir donné les droits de lecture sur le fichier settings.php (un grand classique)…

Ce module permet d’intégrer Alfresco à Drupal. Plutôt que de servir de backend à la totalité du contenu de Drupal, Alfresco se comporte comme une médiathèque : on ajoute, dans Drupal, un objet « Alfresco Item », qui va pointer vers le contenu d’origine d’Alfresco.

On dispose également d’un champ « Alfresco node » sur chaque contenu, ce qui permet de référencer au sein d’un contenu quelconque un node Alfresco. Hyper pratique pour faire des références vers une base documentaire !

Quelques remarques :

• Un node d’Alfresco ne peut être référencé que par un et un seul Alfresco Item dans Drupal.
• Un utilitaire permet de faire un « bulk import » d’une arborescence Alfresco dans Drupal (sous forme de références évidemment). Hélas, quand un nouveau contenu est créé côté Alfresco, l’Alfresco Item n’est pas rajouté côté Drupal, ce qui limite un peu cette fonctionnalité.
• Aucune écriture n’a lieu de Drupal vers Alfresco. Il n’est pas possible d’éditer le contenu Alfresco depuis Drupal, donc (fort dommage, mais c’est la vie).
• Drupal se comporte comme un proxy envers Alfresco (pas de possibilité de transmettre l’authentification Drupal vers Alfresco, donc), mais au moment du téléchargement d’un document l’utilisateur accède à Alfresco – avec les credentials du proxy. On ne voit jamais l’URL en clair. Du coup, à moins de s’astreindre à n’utiliser que le compte « guest » pour publier sur Internet, il y a de vrais risques d’exposer par inadvertance des documents qui ne devraient pas l’être.

La bonne nouvelle,  c’est que l’on peut utiliser conjointement Drupal et Alfresco dans les cas suivants :

• Pour gérer la documentation d’un projet : la « vie » du projet (Blog, Wiki, Forum, …) est localisée dans Drupal tandis que la partie « Documentation » est gérée par Alfresco avec Workflows, Versionning et compagnie.
• Pour créer un site Internet qui pointerait vers de la documentation « officielle ». Exemple, un site institutionnel qui met à disposition des usagers des procédures : les procédures sont gérées par Alfresco mais référencées par Internet.
• Etc…

C’est plutôt rassurant car, pour être honnête, les capacités d’Alfresco « out of the box » en tant que CMS (notamment avec Share) sont des années derrière celles de Drupal. Une bonne initiative, donc, et nous espérons que le module sera amélioré pour gérer des liens plus étroits avec Alfresco (authentification partagée, et, pourquoi pas, possibilité d’écrire depuis Drupal vers Alfresco !).

Prérequis

Avant d’installer Alfresco, il faut préparer les éléments suivants :

• Disposer d’une Debian Etch (ça va mieux en le disant :)), connectée à Internet. Nous partons du principe que la machine est vierge et que vous n’avez rien installé dessus.
• Télécharger la version d’Alfresco Labs disponible sur le Wiki d’Alfresco et placez-la dans votre répertoire personnel (~/)
• Prendre un papier et un stylo pour noter les paramètres qui seront utiles au moment de l’installation.

Voici les paramètres que nous allons utiliser le long de ce guide :

• DB_HOST : La machine sur laquelle se trouve votre base de données PostgreSQL
• DB_USER : L’utilisateur qui se connecte à la base Postgres ( »alfresco » par défaut)
• DB_NAME : Le nom de la base de données qui hébergera les données d’Alfresco ( »alfresco » semble être un choix raisonnable)
• DB_PASSWORD : Son mot de passe ( »toto » dans notre cas)
• DATA_PATH : Le chemin dans lequel vous allez stocker les données d’Alfresco. Nous utiliserons /var/lib/alfresco.
• TOMCAT_HOST : La machine sur laquelle nous allons installer Alfresco / Tomcat
• TOMCAT_PORT : Le port sur lequel Tomcat va tourner (8080 par défaut sous Debian)

Remarque : Pour des raisons de convenance personnelle, j’utilise sudo plutôt que de me connecter avec le compte root de la machine. Je vous invite à faire de même, mais c’est un point de détail. Je considère dans ce guide que toutes les manipulations, sauf avis contraires, sont effectuées avec le compte root.

Mise à jour des paquets

Les paquets dont nous avons besoin pour l’installation ne sont pas tous disponibles lors d’une installation par défaut de Debian Etch. Éditez donc le fichier /etc/apt/sources.list pour ajouter la possibilité de télécharger des packets pas Open-Source :

deb http://ftp.fr.debian.org/debian/ etch main non-free
deb http://security.debian.org/ etch/updates main contrib non-free

Puis mettez à jour la liste des paquets :

apt-get update

Base de données

Alfresco peut fonctionner avec un grand nombre de bases de données. La documentation officielle insiste sur MySQL, nous allons donc, par esprit de contradiction, nous intéresser à Postgres. Nous installerons la version 7.4, mais, à ma connaissance, le processus est strictement le même pour l’installation de la 8.1, qui marche tout aussi bien avec Alfresco.

Si vous disposez déjà d’une instance de Postgres sur la même machine ou sur une autre, connectez-vous sur cette machine et ignorez la ligne suivante.

apt-get install postgresql-7.4

Il faut maintenant créer un utilisateur et une base de données pour héberger les données d’Alfresco. Rappel : Si vous utilisez une autre installation de Postgres, ces manipulations doivent être effectuées depuis l’autre machine.

su - postgres

postgres:~$ createuser alfresco
Le nouvel utilisateur a-t'il le droit de créer des bases de données ? (o/n) n
Le nouvel utilisateur a-t'il le droit de créer des utilisateurs ? (o/n) n
CREATE USER
postgres:~$ createdb -O alfresco -E UNICODE alfresco
CREATE DATABASE
postgres:~$ psql -d alfresco -c "ALTER USER alfresco WITH PASSWORD 'toto'"


ALTER USER

N’oubliez pas évidemment de remplacer « toto » ci-dessus par le mot de passe que vous souhaitez réellement utiliser.

Il faut maintenant préciser que la base Postgres pourra être accédée au travers du réseau. Dans /etc/postgres/7.4/main/postgresql.conf, positionnez la ligne suivante :

tcpip_socket = true

Installation de Tomcat

Nous pouvons maintenant installer le JDK de Java et Tomcat.

apt-get install sun-java6-jdk
apt-get install tomcat5.5
/etc/init.d/tomcat5.5 stop # Pour gagner du temps à l'installation 

Décompressez le .tar.gz d’Alfresco Labs dans un répertoire temporaire et installez Alfresco et Alfresco Share.

cd /tmp
tar -xzvf ~/alfresco-labs-war-3Stable.tar.gz
cp /tmp/alfresco.war /var/lib/tomcat5.5/webapps
cp /tmp/share.war /var/lib/tomcat5.5/webapps
/etc/init.d/tomcat5.5 start

À partir de ce moment, Alfresco est installé. Le plus dur reste à faire : configurer Alfresco, Alfresco Share et tous les éléments sans lesquels vous ne parviendrez pas à le faire fonctionner.

Pour vérifier que tout s’est bien passé, regardez si les répertoires « alfresco » et « share » ont été créés dans /var/lib/tomcat5.5/webapps au moment du démarrage de Tomcat.

Configuration d’Alfresco

Configuration de la base de données

Avant de nous attaquer à la configuration de la base de données, il faut déjà installer le driver Postgres pour Java. C’est relativement simple.

apt-get install libpg-java

Fichiers de configuration d’Alfresco

Les fichiers de configuration d’Alfresco ne sont pas déployés lors du démarrage de Tomcat. Il faut donc le faire à la main.

mkdir /var/lib/tomcat5.5/shared/classes/alfresco
cp -r /tmp/extensions/* /var/lib/tomcat5.5/shared/classes/alfresco
chown -R tomcat55:nogroup /var/lib/tomcat5.5/shared/classes/alfresco

Il va maintenant falloir éditer les fichiers de configuration pour faire fonctionner correctement Alfresco. Éditez le fichier /var/lib/tomcat5.5/shared/classes/alfresco/extension/custom-repository.properties et éditez / modifiez le lignes suivantes (attention, lisez attentivement le fichier pour ne pas doubler les lignes) :

dir.root=/var/lib/alfresco
db.username=alfresco
db.password=toto
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://localhost:5432/alfresco

Replacez « localhost » par DB_HOST et « alfresco » par DB_NAME s’il y a lieu. Vérifiez que le numéro du port de Postgres est correct (c’est bien 5432 par défaut).

Certaines des lignes ci-dessus étaient commentées (précédées par « # ») : dé-commentez-les. Commentez la partie « Derby connexion ». Seules les lignes mentionnées ci-dessus doivent être non commentées !

Dans le même répertoire, éditez custom-hibernate-dialect.properties. Commentez tout le fichier sauf les deux lignes suivantes (elles se trouvent normalement à la toute fin du fichier) :

hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
hibernate.query.substitutions=true TRUE, false FALSE

Il faut penser à modifier le fichier /var/lib/tomcat5.5/webapps/alfresco/WEB-INF/classes/log4j.properties pour assurer un log correct des opérations d’Alfresco :

log4j.appender.File.File=/var/log/alfresco/alfresco.log



Et bien sûr créez le répertoire adequat :

mkdir /var/log/alfresco
chown tomcat55:nogroup /var/log/alfresco

Création du répertoire de données

Créez le répertoire DATA_PATH :

mkdir /var/lib/alfresco
chown tomcat55:nogroup /var/lib/alfresco 

Configuration des options de démarrage de Tomcat

Les options de démarrage de Tomcat ne permettent pas de faire fonctionner correctement Alfresco. Il faut donc modifier /etc/init.d/tomcat5.5 et modifier les lignes suivantes pour débrayer le Security Manager de Tomcat et pour augmenter la mémoire mise à disposition du Alfresco :

TOMCAT5_SECURITY=no
# ...
        CATALINA_OPTS="-Djava.awt.headless=true -Xmx1024M -XX:MaxPermSize=256m"
# ... 

Les valeurs de gestion de la mémoire doivent être en tous les cas inférieures à la mémoire physique disponible sur votre machine (sinon tomcat va swapper sans arrêt et Alfresco sera inutilisable). L’option « MaxPermSize » permet d’éviter certaines erreurs de mémoire que j’ai pu rencontrer en faisant cohabiter Alfresco et Jira.

Installation des programmes additionnels

En théorie, Alfresco devrait fonctionner comme cela. Mais pour en profiter pleinement, il faut installer les programmes et librairies sur lesquels il se base notamment pour effectuer des conversions de documents.

apt-get install imagemagick
apt-get install xfvb xfonts-base

(TODO : ÉCRIRE LA PROCÉDURE POUR pdf2swf ET POUR Open-Office)

Il faut indiquer à Alfresco où se trouvent ces programmes. Éditez /var/lib/tomcat5.5/webapps/alfresco/WEB-INF/classes/alfresco/repository.properties :

dir.root=/var/lib/alfresco
img.root=/usr
img.dyn=${img.root}/lib
img.exe=${img.root}/bin/convert
swf.exe=./bin/pdf2swf

On en profite pour modifier une autre option dans ce fichier qui permet de reconstruire automatiquement l’index en cas d’erreur :

index.recovery.mode=AUTO

Test de l’interface

Vous pouvez maintenant vous connecter avec votre navigateur : http://localhost:TOMCAT_PORT/alfresco

L’accès par défaut est admin/admin ; Changez-le immédiatement !

CIFS

Pour configurer les protocoles additionnels tels que CIFS/SMB (qui permettent un accès au repository Alfresco comme s’il s’agissait d’un filesystem) ou FTP, éditez le fichier suivant :

Comme Tomcat s’exécute avec un utilisateur non privilégié, vous ne pouvez pas utiliser le port standard (445) pour faire tourner votre serveur CIFS. Il faut, à la place, décommenter les lignes suivantes dans /var/lib/tomcat5.5/webapps/alfresco/WEB-INF/classes/alfresco/file-servers.xml :

<tcpipSMB port="1445" platforms="linux,solaris,macosx"/> 
<netBIOSSMB sessionPort="1139" namePort="1137" datagramPort="1138" platforms="linux,solaris,macosx"/>

Pour accéder au serveur, utilisez depuis Windows : \\server:1445\Alfresco. Il ne reste plus qu’à « mapper » le port 445 vers le port 1445 (avec iptables par exemple) pour se débarrasser du « :1445″ dans la chaîne de connexion – mais c’est une autre histoire.

Configuration Alfresco Share

Pour configurer Alfresco Share, il faut simplement indiquer à Share un moyen de communiquer avec Alfresco : il faut renseigner le nom d’hôte (localhost dans notre cas) et surtout le numéro du port sur lequel se font les échanges avec Alfresco. Éditez le fichier /var/lib/tomcat5.5/webapps/share/WEB-INF/classes/alfresco$ sudo vi webscript-framework-config.xml et remplacez toutes les instances de 8080 par le numéro du port sur lequel Tomcat tourne (en général : 8080 ou 8180, c’est le premier par défaut sous Debian, de mémoire).

Vous vous connectez ensuite à Alfresco Share par l’URL suivante :

http://localhost:ALFRESCO_PORT/share

Et maintenant ?

Et voilà, Alfresco est installé !

Ce guide est légèrement incomplet (manque la partie OpenOffice et PDF2SWF) et il me reste quelques problèmes techniques à résoudre (problème du port de CIFS), mais cela devrait vous mettre le pied à l’étrier.

N’hésitez pas à me dire si vous remarquez des erreurs dans ce guide ou souhaitez préciser certains points.

Bonne installation !

Référence

Voici une liste de liens utiles, pour référence ou pour aller plus loin :

• La documentation officielle de l’installation d’Alfresco sous Debian Etch
• Téléchargement d’Alfresco