planet.evolix.org

En réponse à la faille critique DSA-1571 parue aujourd'hui :

Voici un résumé rapide de certaines opérations urgentes à effectuer ( liste non exhaustive ).
Pour plus d'informations vous pouvez consulter la page dédiée sur wiki.debian.org.

Mettre à jour le système

aptitude update && aptitude upgrade

Regénerer la clé du serveur OpenSSH

ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
/etc/init.d/ssh restart

Regénerer vos propres clés

A faire sur un système à jour bien sur.

Supprimer les clés utilisateurs impactées

Un script fourni par Debian permet de les détecter : http://security.debian.org/project/extra/dowkd.
Attention l'auteur signale que celui-ci peut donner des faux positifs ou des faux négatifs.

Ensuite vous pouvez lancer par exemple :

for i in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do perl ./dowkd.pl file $i; done

Regénerer vos certificats SSL

Pour votre serveur mail, web, VPN,...

J'ai eu récemment à installer la bibliothèque tomcat-native à la demande d'un client d'Evolix.
N'étant pas expert Java/Tomcat je sais juste ce que la page officielle décrit : gain de performance,
une meilleure génération des ID de sessions et certaines fonctionnalités de monitoring.

De plus cela fait disparaitre le message suivant au démarrage de Tomcat :
catalina_2008-04-18.log:INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.5.0...

Voici une copie brute de mes notes d'installation sur un système Debian Etch :

 $ cd $HOME/tmp
 $ sudo aptitude install libapr1-dev autoconf
 $ wget http://tomcat.heanet.ie/native/1.1.9/source/tomcat-native-1.1.9-src.tar.gz
 $ tar zxvf tomcat-native-1.1.9-src.tar.gz
 $ cd tomcat-native-1.1.9-src/jni/native/
 $ apt-get source libapr1
 $ sh buildconf --with-apr=./apr-1.2.7/
 $ ./configure --with-apr=/usr/bin/apr-config --with-ssl=/usr/include/openssl --with-java-home=/usr/lib/jvm/java-1.5.0-sun
 $ make
 $ sudo cp .libs/libtcnative-1.so.0.1.3 /usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/i386/libtcnative-1.so
 $ sudo /etc/init.d/tomcat5.5 restart

Note : l'installation d'une version <1.1.4 avec la version de Tomcat de Debian Etch provoque un message d'erreur.

Il ne me reste plus qu'à en faire un package afin de pouvoir installer ça proprement.

J'ai rencontré quelques soucis ces jours-ci après des mises à jour de ports FreeBSD. J'ai utilisé comme à mon habitude la commande portupgrade -arRe.

• J'avais modifié le script /usr/local/etc/rc.d/milter-greylist afin que milter-greylist s'exécute en tant qu'utilisateur postfix (et non pas mailnull comme c'est le cas par défaut). Cela permet notamment que la socket qu'il crée puisse être utilisable par postfix. J'ai été étonné de voir que la mise à jour a écrasé ce script et a donc rendu le milter indisponible (rien de bien grave, quelques spams reçus avant rétablissement de la situation). Je pensais, peut-être naïvement, qu'un fichier dans /usr/local/etc ne pouvait pas être écrasé sans avertissement.

• Dans le même genre une mise à jour de Roundcube a écrasé ses fichiers de configuration présents dans /usr/local/www/roundcube/config. Conséquences un peu plus graves : webmail indisponible.

Reste à trouver comment cela aurait pu être évité.

Comme vous pouvez facilement le voir j'ai fait le choix du moteur de blog Chronicle.

Etant tout à fait novice dans l'univers du blogging j'avais tout d'abord installé Wordpress, qui a l'air très bien, mais que j'ai jugé finalement trop lourd : base MySQL et beaucoup de code PHP.

Je me suis alors orienté vers Blosxom, qui a l'énorme avantage de stocker ses données dans de simples fichiers texte. Parfait pour un adepte de Subversion comme moi.

Néanmoins quelques soucis m'ont poussé à l'abandonner, notamment le fait que celui-ci se base sur la date de dernière modification des fichiers pour déterminer la date d'une entrée de blog, ce qui ne me convient pas. Je suis certain qu'il existe un plugin (Blosxom étant particulièrement modulaire) pour remédier à cela mais je ne l'ai pas trouvé en temps voulu malheureusement.

Finalement je suis tombé ce matin même sur chronicle, qui est très simple, permet de spécifier quelques meta-informations dans le fichier de données, et gère de base les quelques fonctionnalités indispensables qu'il me fallait. Je n'ai rencontré pour l'instant que quelques petites soucis : il n'est à priori pas internationalisable (un peu génant pour les dates), et ne permet pas de spécifier un encodage pour le plugin Textile que j'utilise (et je suis totalement converti à l'UTF-8). Il ne me reste donc plus qu'à faire remonter quelques patch à l'auteur.

De toute manière rien n'est figé et il me suffira de quelques lignes de perl pour passer à un autre moteur si celui-ci ne me convient plus !

Debian a son wget, FreeBSD son fetch, et j'ai cru pendant longtemps que le seul moyen simple de récupérer un fichier via HTTP à partir d'un système de base OpenBSD était d'utiliser lynx.

Ce qui n'était pas très pratique car cela force de passer par un mode interactif (sauf option appropriée, mais j'avoue n'avoir jamais pris le temps de parcourir toute la page de man).

J'apprend aujourd'hui que l'outil ftp d'OpenBSD, comme son nom ne l'indique pas, gère aussi HTTP et HTTPS !

Exemple : ftp http://openbsd.org/index.html

Et bien voila, c'est fait, j'ai ouvert mon blog.

Je traiterais ici principalement des sujets techniques auquels je suis confronté lors des projets
professionnels auquels je participe au sein de la société Evolix, ou de mes projets personnels/associatifs
au sein de l'association Oopss.org.

Si vous avez suivi les liens ci-dessus vous avez normalement compris que les thèmes abordés seront principalement liés au Logiciel Libre et à l'administration système et réseau.

A bientôt !

PFW est un frontend web pour PF (OpenBSD Packet Filter). Voici un petit patch indispensable pour permettre d’éditer correctement les règles de NAT (version 0.7.8). D’autres patches suivront peut-être car de nouveaux bugs nous ont déjà été reportés.

Cette présentation a eu lieu le 17 Avril dernier devant un auditoire d’une cinquantaine de personnes à la pépinière hébergée par Capgemini au Roy d’Espagne.
À noter que des personnes de la Ville de Marseille étaient présentes dans le cadre de leur réflexion de migration vers le Libre qui a débuté par un appel d’offre pour l’aide à la migration sous OOo (OpenOffice.org)

En tant que vice-président de l’association Libertis, j’ai pu présenter le Cluster et réaliser en 30 minutes une introduction au Libre.

Vous trouverez les slides sous FDL ici :

Slides du 170408 by Sdubois

Un nouvel exemple de migration (après [0],[1] et [2]) qui concerne cette fois un serveur de messagerie (Postfix/Courier-IMAP/OpenLDAP/Amavis/SpamAssassin/Horde) et d’un intranet (Apache/PHP/MySQL) pour plusieurs centaines d’utilisateurs. La migration a duré environ 3 heures (pizzas comprises) sans accroc majeur mais avec un bon nombre de remarques plus ou moins importantes :

- Les Release Notes dispensent de bons conseils : Backup any data, inform users in advance, etc. J’ajoute que je préconise de prévoir une période d’arrêt des services d’au moins une heure avec quelques heures de marge au cas où (dans pas mal de cas, cela peut correspondre à prévoir cela un soir et se réserver la possibilité de passer la nuit dessus !). Je dis bien que je conseille d’arrêter les services (par exemple, mettre en place des règles de firewall les rendant inaccessibles) : en effet prenons l’exemple d’un service SMTP, il est nécessaire de bien vérifier que le système mis-à-jour est fonctionnel avant d’autoriser à nouveau les mails entrants (car si un problème survient, on risque de perdre des mails). Bien sûr, si aucun arrêt n’est possible, une infrastructure permettant une tolérance de panne est sûrement place et l’arrêt des services sur une machine ne posera pas de problème.

- J’utilise en général un noyau Linux patché grsec sur les serveurs mail ou web. Et avant une mise-à-jour majeure, j’ai pris l’habitude redémarrer sur un noyau non-grsec, à savoir celui par défaut… sauf quand il ne contenait pas les pilotes du controleur RAID/SCSI. À retenir :-)
Toujours au sujet du noyau, après quelques installations/désinstallations de noyaux, le paquet module-init-tools a disparu, d’où d’inquiétants messages QM_MODULES: Function not implemented. Solution triviale : aptitude install module-init-tools.

- J’ai perdu mon périphérique /dev/megadev0 (correspondant au controleur RAID/SCSI) que j’ai du recréé via mknod /dev/megadev0 c 253 0 pour avoir un monitoring fonctionnel.

- Un problème de conflit entre les paquets libfam0 et libfam0c102 s’est posé, empêchant d’ailleurs de préparer la mise-à-jour avec un aptitude -d dist-upgrade pour télécharger d’avance tous les paquets à mettre à jour (j’ai finalement du le faire en précisant les paquets manuellement). Pour forcer la résolution de ce conflit : aptitude install libfam0.

- J’ai obtenu l’erreur suivante pendant la mise-à-jour : E: Internal Error, Could not perform immediate configuration (2) on debian-archive-keyring Ack! Something bad happened while installing packages. Pour la résoudre : aptitude install debian-archive-keyring.

- Parlons Apache/PHP/MySQL. En ce qui concerne la migration d’Apache, aucun problème. Pour MySQL 4 vers 5, rien à noter non plus mis à part de bien conserver les mots de passe compatibles avec la v4 (old_passwords=1) comme nous le propose debconf. Enfin pour PHP, je suis resté (pour le moment) sur la version 4 car l’Intranet tourne sous Typo3 et le module calendrier en place semble être incompatible avec PHP5. J’ai eu par contre une activation “surprise” du module eaccelerator dans le php.ini : PHP Warning: Unknown(): Unable to load dynamic library ‘/usr/lib/php4/20050606+lfs/eaccelerator.so’ - /usr/lib/php4/20050606+lfs/eaccelerator.so: cannot open shared object file: No such file or directory in Unknown on line 0

- Pour SpamAssassin, mettre à jour les require_version des règles sur mesure ! Et quelques adaptations mineures (ok_languages, use_dcc plus valables).

- Quelques petits coups de pioche à mettre :

freshclam: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied

Solution : execstack -c /usr/lib/libgmp.so.3.3.3

Uncaught exception from user code: Can’t load ‘/usr/lib/perl5/auto/Quota/Quota.so’ for module Quota: /usr/lib/perl5/auto/Quota/Quota.so: cannot enable executable stack as shared object requires: Permission denied at /usr/lib/perl/5.8/DynaLoader.pm line 225, <DATA> line 225. at ./add.pl line 26

Solution : execstack -c /usr/lib/perl5/auto/Quota/Quota.so

- Pour garder Vim en tant qu’éditeur par défaut (aucun troll n’est caché dans ce point…), ne pas oublier le fameux update-alternatives –config editor

- Pour Courier-LDAP, la syntaxe a apparemment changé :
authdaemond: You need to specify a ldap server in config file
authdaemond: authldaplib: error in LDAP configuration file, aborting

Il faut désormais préciser LDAP_URI (LDAP_SERVER et LDAP_PORT ne sont plus valables) :

#LDAP_SERVER 127.0.0.1
#LDAP_PORT 389 LDAP_URI ldap://127.0.0.1

- Postfix 2.3 génère maintenant par défaut des DSN (Delivery Status Notifications) qui peuvent s’avérer gênantes avec les demandes de confirmation de lecture d’Outlook. Pour désactiver les DSN, ajouter dans le main.cf : smtpd_discard_ehlo_keywords = silent-discard, dsn

Voilà, ce fut donc loin de passer comme une lettre à la poste, mais ça ne fut pas un calvaire non plus. Les services ont été réactivés en temps et en heure, et aucun soucis majeur ne s’est produit dans les jours suivants. Au serveur suivant !

Il n’est pas aisé de maintenir un serveur LAMP car les mises-à-jour majeures du système nécessitent un travail important de vérification (et correction) de toutes les applications web. Et cela s’avère carrément impossible dans le cadre d’un serveur LAMP mutualisé où l’on ne peut pas imposer à tous une migration à un instant défini. La seule alternative viable est de mettre en place un second serveur permettant aux webmasters d’avoir deux comptes en parallèle et ainsi de réaliser une migration en douceur.

C’est donc ce cas de figure qui se pose le serveur web-mutu zidane.evolix.net (Debian 3.1, Apache 2.0.54, PHP 4.3.10, MySQL 4.0.24) qui a désormais une espérance de vie très limitée. Tous les hébergés restants sont donc priés de migrer vers hosting.evolix.net (Debian 4.0, Apache 2.2.3, PHP 5.2.0, MySQL 5.0.32) où un compte leur a été créé. Voici un petit concentré des détails techniques sur lesquels il est nécessaire de se concentrer pour cette migration :

• Migration PHP 4.3 vers PHP 5.2 : vous pouvez consulter les pages suivantes 4.x->5.0, 5.0->5.1 et 5.1->5.2 pour voir les évolutions (nouvelles fonctionnalités, incompatibilités, etc.).
• Migration MySQL 4.0 vers 5.0 : vous pouvez consulter les pages suivantes : 4.0->4.1 et 4.1->5.0.
• Charset ISO8859-1 VS UTF8 : il faut prendre garde aux problèmes d’encodage de caractères. Il est désormais conseillé d’utiliser du full-UTF8 (encodage des fichiers, stockage MySQL, content-type des pages HTML, etc.). Notez que MySQL5 offre la possibilité de stocker ses bases en UTF8, mais cela peut poser des problèmes avec certaines web-applications (des problèmes ont été constatés avec Wordpress, Dotclear) et cela peut nécessiter de convertir votre base. Si les commandes “SET NAMES”, “SET CHARACTER”, etc. vous sont iconnues, reportez vous à la documention MYSQL sur l’internationalisation/localisation.
  
• Pour la gestion des droits, le serveur web d’hosting.evolix.net tourne avec un groupe commun avec votre utilisateur. Vous devez donc vous assurer que vos fichiers sont en lecture pour le groupe pour qu’ils puissent être lus par le serveur web, et en écriture si le serveur web doit écrire dedans.
• En ce qui concerne les modules PEAR, seuls des modules de base sont installés sur le nouveau serveur (Archive_Tar, Console_Getopt, Log, Net_Sieve). Sur demande, nous pourrons installer certains modules supplémentaires ou alors il faudra envisager une installation locale.
• Au niveau DNS, vous avez la possibilité de forcer le pointage vers le nouveau serveur afin de vérifier que tout fonctionne correctement avant de réaliser la bascule réelle de votre site. Si vous souhaitez une bascule rapide en minimisant les délais de propagation DNS, vous pouvez réduire le TTL juste avant le changement effectif (mettez le à 1 heure par exemple, ce qui donnera un délai moyen de 15 minutes pour vos visiteurs).
• Au niveau des statistiques Awstats, vos anciennes statistiques peuvent être récupérées. Il suffit de nous demander de les transférer quelques minutes avant le changement effectif de DNS.

N’hésitez pas à nous contacter par mail ou via le canal IRC #evolix sur Freenode.

Après les épisodes [0] et [1], voici la mise-à-jour d’un poste de travail mono-utilisateur KDE/Mozilla/OpenOffice, en place depuis 2 ans environ dans une association. Les remarques concernant la migration sont les suivantes :

- Au niveau de la mise-à-jour complète des paquets (le dist-upgrade), il a été nécessaire de forcer la mise-à-jour de KDE. En effet, aptitude install kde a permis la désinstallation des paquets libhal0 et dbus-1 spécifiques à Sarge.

- Il a été nécessaire de récupérer manuellement la clé GPG pour authentifier les paquets avec aptitude.

- Au niveau de KDE, les icônes sur le bureau ont été désorganisés (tous rassemblés en haut à gauche) et l’application KGPG était lancée par défaut (à désactiver car non utilisée dans ce cas précis).

Bref, surtout des détails. Aucun soucis au niveau de Firefox->Iceweasel et Thunderbird->Icedove (le plus gênant était le changement des… icônes), au niveau d’OpenOffice v1->v2, CUPS, GAIM, etc. La conclusion de cette mise-à-jour a été : « C’est réparti pour 2 ans de stabilité ! » Qui a dit que Debian n’était pas prêt pour le poste de travail en environnement professionnel ?

Plusieurs services (Apache, Tomcat, etc.) dépendent de variables d’environnement, notamment des variables LC_*/LANG*. Il faut donc prendre garde à la façon dont on (re)lance un service. Par exemple, sous Debian, un apache(2)ctl start ne revient pas au même qu’utiliser un “wrapper” comme /etc/init.d/apache(2). Mais il ne suffit pas d’utiliser systématiquement les scripts init.d : toujours sous Debian, /etc/init.d/tomcat5.5 peut dépendre de variables d’environnement. Concrètement, relancer un service depuis un shell avec un environnement particulier peut donc changer son comportement (dates incorrectes, problème de charset, etc.). D’ailleurs, au passage, sous Debian, il est conseillé d’utiliser systématiquement /etc/init.d/apache2 (et non apache2ctl) pour Apache car celui-ci réinitialise l’environnement, et une astuce pour Tomcat est d’exporter les variables voulues (notamment celles concernant la locale) dans le fichier /etc/default/tomcat5.5.

En règle générale, la relance de services sur un serveur en production s’effectue par sudo et/ou SSH. Pour éviter les erreurs d’inattention, il est donc préférable ne pas conserver les variables LC_*/LANG*. Avec sudo, il est ainsi recommandé d’utiliser env_reset pour des raisons de sécurité, mais env_reset conserve ces variables sans qu’il soit possible a priori de les supprimer avec env_delete (voir bug Debian #392321). Au niveau de SSH, on peut agir plus efficacement, comme éviter que ces variables soient envoyées par le client SSH en retirant la directive SendEnv LANG LC_* dans le fichier /etc/ssh/sshd_config. On peut également le faire au niveau du serveur en évitant la directive AcceptEnv LANG LC_* dans le fichier /etc/ssh/sshd_config. Bien sûr, comme toujours toutes ces “astuces” ne doivent pas être appliquées sans précaution ; le principal est de garder en tête que certains services peuvent dépendre des variables d’environnement et d’éviter de les (re)lancer depuis un environnement modifié.

Mon histoire avec les cartes Adaptec (Dell OEM) 39320 Ultra320 SCSI adapter commence il y a trois ans quand j’ai eu à installer plusieurs exemplaires de machines DELL PowerEdge SC420 incluant cette carte. Cette carte est sensée permettre du RAID hardware mais c’est loin d’être le cas. Les premiers drivers pour cette carte ont été inclus dans le noyau Linux 2.6.11 (l’installation de Sarge nécessitait donc une technique annexe : debian-installer avec un noyau custom ou debootstrap à partir d’un autre disque) mais ils ignorent tout simplement la configuration RAID effectuée au niveau du BIOS de la carte. Celle-ci gère pourtant le RAID0 et RAID1 mais au démarrage de Linux, les disques sont vus par le noyau comme des disques indépendants… Bref, pas de RAID hardware possible (des blobs pour Suse/RedHat existent mais je préfère éviter cette solution).

Récemment, j’ai du ajouter un nouveau disque sur ce controleur. J’ai donc branché ce 2e disque sur la machine concernée et tenté de démarrer la machine : le controleur ne trouvait pas de périphérique de démarrage valide. En regardant de plus près, il cherchait un volume RAID0, forcément inexistant. Or, je souhaitais simplement avoir deux malheureux disques, sans RAID. Mais même en retirant le disque ajouté, il cherchait toujours un volume RAID0 : le second disque devait contenir un reste de RAID0 et le controleur l’a considéré maître et et a écrasé la configuration du premier disque. Youpi : bien que le RAID de ce controlleur ne fonctionne pas sous Linux… me voilà coincé à cause du RAID. Premier réflexe : désactiver les fonctionnalités RAID de la carte, et la documentation d’Adaptec m’indique que c’est simple, il suffit de l’indiquer dans le BIOS de la carte. Sauf que j’ai une carte DELL/Adaptec, c’est-à-dire que DELL a placé un firmware modifié pour faire croire à une carte DELL et, au passage, a eu la chouette idée de supprimer la possibilité de désactiver le RAID. Arrivé ici, on pourrait penser qu’il suffit de mettre un firmware Adaptec mais c’est justement indiqué que l’on ne doit le faire qu’avec les cartes 100% Adaptec et non issues d’un autre fournisseur. Et de toute façon, cela risquerait de me faire perdre la garantie DELL, ultime recours en cas de soucis :-)

Je vais donc devoir me débrouiller avec ce firmware. Ma première mission est de ré-initialiser le RAID du premier disque car, avec controleur on ne peut pas effacer la configuration RAID, il faut… ré-initialiser complètement le disque (ce qui l’efface au passage). À noter que cette ré-initialisation peut être délicate, j’ai déjà explosé un disque SCSI en annulant cette opération ! À noter aussi que cela prend plusieurs heures et si l’on ajoute les temps de backup (dd powered), ça fait beaucoup de temps pour effacer quelques octets dans le firmware du disque dur… Ces opérations de réparation prennent donc des heures et des heures et un message de confirmation aurait ainsi été bienvenu avant que le controleur écrase ses fameux paramètres RAID stockés sur un disque.

En conclusion, lorsque l’on manipule les disques de volumes RAID, outre la possibilité de perdre les données, il faut bien avoir en tête le temps considérable que peuvent prendre certaines opérations, d’autant plus quand il s’agit de controleurs de qualité médiocre (qui impliquent souvent des fonctionnalités réduites).

During a random security upgrade on Debian :

# ls -l libnss-ldap.conf
-rw-r--r-- 1 root root 9863 2008-02-15 18:40 libnss-ldap.conf
# dpkg -l nscd | grep un
un  nscd           <none>         (no description available)
# aptitude upgrade
[...]
Preparing to replace libnss-ldap 251-7.5 (using .../libnss-ldap_251-7.5etch1_i386.deb) ...
Unpacking replacement libnss-ldap ...
Setting up libnss-ldap (251-7.5etch1) ...
# ls -l libnss-ldap.conf
-rw------- 1 root root 9863 2008-02-15 20:55 libnss-ldap.conf

Oops! With this permissions on the libnss-ldap.conf file, some services will be broken. For example, in Postfix/LDAP configuration, Postfix local mail delivery will fail because he can’t find homeDirectory of local user. And Postfix error message isn’t very explicit:

postfix/qmgr[12063]: warning: transport local failure --
see a previous warning/fatal/panic logfile record for the problem description

For more details, see my post on #455907

Le lobby est en route pour le Logiciel Libre
Ci-dessous extrait page 63/64 sur 245 du rapport Attali :

–Extrait–

[…]

OBJECTIF Renforcer le secteur du logiciel

Dans l’univers de l’interconnectivité généralisée, la valeur migre de l’exploitation des infrastructures de réseau, métier traditionnel
de l’opérateur de télécommunications, vers les logiciels de traitement de l’information échangée.
Aussi, le secteur du logiciel représente un enjeu stratégique en matière de recherche, d’innovation, de croissance et d’exportation. En France, il concerne 2 500 PME innovantes dans un marché dominé très largement par l’industrie américaine (14 éditeurs américains et un allemand dans les 15 premiers mondiaux).

DÉCISION 58
Promouvoir la concurrence entre logiciels propriétaires et logiciels ” libres “. Le patrimoine d’applications dites ” libres ” ou “open source “, crées par une communauté active, représente l’équivalent de 131 000 années/hommes, dont pratiquement la moitié provient de programmeurs européens. Si le coût virtuel en est de 12 Md$, le coût réel est de 1,2 Md$ et les communautés de logiciels libres s’engagent gracieusement à proposer en continu des améliorations et des applications. Le logiciel libre induit une économie moyenne de 36 % en recherche et développement pour les entreprises utilisatrices. Il permet de créer une concurrence pour les logiciels propriétaires, dont les avantages sont différents. Leur part de marchée n’est aujourd’hui que de 2 % (avec une croissance annuelle de 40 %) contre 98 % pour les logiciels dits ” propriétaires “. Pour développer la concurrence, une série d’actions est nécessaire :
* Promouvoir la concurrence entre les logiciels propriétaires et les logiciels libres dans les appels d’offres, notamment publics. Un objectif de 20 % des applications nouvellement développées ou installées au profit du secteur public en open source pourrait être fixé à l’horizon 2012.
* Considérer fiscalement, comme aux États-Unis, les aides aux communautés des logiciels libres comme du mécènat de compétence.
* Exiger, à un niveau européen dans le cadre de la politique de la concurrence entre solutions logicielles, la fixation de normes
internationales garantissant l’interopérabilité entre logiciels libres et les logiciels propriétaires, en priorité.

[…]

Une rencontre entre le bureau de Libertis - réseau des professionnels du Libre en PACA regroupant près de 25 sociétés spécialisées dans le Libre - et le bureau de la FNILL (Fédération Nationale des Industries du Logiciel Libre) [ex ASS2L Association des Sociétés de Services en Logiciel Libre] a eu lieu à Marseille le vendredi 18 janvier 2008.

Les bases d’un accord de reconnaissance de l’initiative PACA portée par Libertis ont été définies avec le président de la FNILL et PDG de Linagora accompagné d’un de ses vice-président.

Une convention devrait être prochainement publiée en ce sens donnant à Libertis, coinitiée par Evolix, une reconnaissance officielle par la fédération nationale en construction après avoir pu avoir cette reconnaissance localement par les institutions publiques avec la réussite du SPLLOS.

Les photos ici : La rencontre

Je n’ai pas oublié mon idée de bloguer sur des migrations Sarge->Etch qui le méritent. Voici donc un deuxième volet avec un petit serveur d’entreprise comprenant les services suivants : OpenLDAP (annuaire, authentification), PostgreSQL, NFS, messagerie (Postfix, Courier-IMAP, Amavisd-new, ClamAV, Bogofilter, DCC, Razor, SpamAssassin, Whitelister, Postgrey, Sympa), Apache/PHP (eGroupWare, webmail Horde, wwsympa, logiciels/sites sur mesure) ainsi qu’un certain nombre de logiciels/scripts sur mesure. J’ai donc profité des jours autour de Noël (période idéale pour les migrations de serveurs d’entreprise) pour m’attaquer à cette tâche.

Tout d’abord, je souligne que cette migration est particulière car j’en profite pour basculer sur du RAID (software) et il s’agit donc de réinstaller un système de base et de gérer les migrations “à la main” (tout en jetant un coup d’oeil sur certains maintainer scripts). Au passage, quelle horreur d’ajouter des disques supplémentaires dans un serveur D3LL format tour quand ça n’a pas vraiment été prévu : une seule paire de glissières, uniquement deux emplacements 3″5, alors que techniquement on pourrait mettre une bonne douzaine de disques… Bref, une fois les soucis matériel gérés (ah oui, la nappe SCSI et la terminaison prévues étaient foireuses), la nuit est bien avancée et je peux couper les services et me lancer dans une réinstallation de base puis re-brancher l’ancien disque et gérer service par service la migration. Voici la liste des points critiques et problèmes rencontrés :

- Au niveau du noyau, aucun problème en vue car je reste avec le même (un noyau personnalisé avec notamment le patch grsecurity). Néanmoins, un petit soucis avec la bibliothèque liblzo notamment utile à lynx (…utile à mutt pour voir les messages HTML et diverses pièces jointes) :

$ lynx
lynx: error while loading shared libraries: liblzo.so.1:
cannot enable executable stack as shared object requires: Permission denied

La solution est de “mettre un coup de pioche” dans la bibliothèque :

aptitude install prelink && execstack -c /usr/lib/liblzo.so.1.0.0

- OpenLDAP
Il faut bien gérer le passage du service slapd qui n’est plus lancé par root mais par un utilisateur openldap. Lors de la migration, il faut donc bien ajuster tous les droits (schémas LDAP, ré-injection des données avec slapadd, etc.) sinon slapd vous “segfault” dans la tête ; et ajuster le pidfile dans le slapd.conf (le mettre dans un répertoire /var/run/slapd/ où l’utilisateur openldap aura les droits pour créer le pidfile, et non plus simplement /var/run/).

- PostgreSQL
J’ai utilisé le paquet pour avoir une version 7.4 et minimiser les impacts potentiels lors de la migration car Sarge utilisait déjà une version 7.4. Un pg_dumpall dans le chroot de la machine arrêtée et un psql plus tard, aucun soucis à relever. Il a ensuite suffi de migrer les fichiers de configuration pg_*.

- Bind
Rien à sigaler de particulier, à part installer le paquet bind9, lancer mon fameux script chroot-bind.sh, et transférer l’ancienne configuration (named.conf, rndc.conf, etc.).

- Messagerie (Postfix, Courier-IMAP, Amavisd-new, ClamAV, SpamAssassin, Whitelister, Postgrey, Sympa)
Un gros morceau mais tout se passe bien dans l’ensemble pour ces logiciels extrêmement utilisés. Pas de soucis pour Postfix en reprenant l’ancien fichier main.cf. Pour info, j’utilise souvent debian-volatile (donc SpamAssassin, ClamAV et Postgrey en sont issus) et un Whitelister patché pour vérifier aussi les reverse DNS. À noter que pour pas mal de logiciels, je suis reparti de la configuration de Etch et j’ai importé mes modifications plutôt que de repartir de ma configuration pour Sarge (pour amavisd-new, il n’y a pas trop le choix de toute façon).

- Sympa
Là, ce fut un gros morceau de la migration, parce qu’il y a beaucoup de changements de la version 4 à la version 5. J’ai donc importé les configurations des listes et Sympa s’est débrouillé pour avaler tout ça et injecter les admins des listes dans PostgreSQL. Pour les archives, il faut bien penser à re-générer toutes les archives (par wwsympa) pour avoir le nouveau format car l’ancien s’affiche très mal (plein de variables sensées ne pas s’afficher apparaissent). Enfin, pour injecter les utilisateurs dans les tables user_table et subscriber_table (pour les listes qui n’utilisent pas LDAP ;), j’ai du ajouter la colonne robot_subscriber à la main avant d’injecter le tout. Mais après avoir bien ajusté la configuration et redémarré plusieurs dizaines de fois Sympa, tout marche ! Il ne reste plus qu’à activer fcgi, ajouter un petit patch trivial, refaire les couleurs (car l’interface web change complètement et les *_color deviennent des color_n) et tout roule ! Résultat ici.

- Apache/PHP
Afin de minimiser les impacts, j’ai choisi de rester en PHP4 (la migration en PHP5 se fera par la suite, une chose à la fois). Pour la migration des VirtualHosts (une bonne vingtaine), tout se passe plutôt bien à part le changement des directives pour l’authentification via LDAP déjà indiqué précédemment. Passons aux webapps. Pour eGroupWare, c’est vite vu car c’est géré indépendamment de Debian (il n’y a d’ailleurs pas de version d’eGroupWare pour Etch). De la même façon, pour les sites/logiciels développés sur mesure, rien à signaler. Reste le webmail Horde où les dernières versions apportent un ergonomie bien confortable (options intégrées dans la sidebar, dossiers virtuels, etc.) et une amélioration notable des performances IMHO. Je n’ai pas utilisé la version d’Etch mais directement la version de sid qui corrige un bug d’affichage pour Opera et IE7.

Dans l’ensemble, ce fut long, mais au final pas d’accrochage majeur. Les premiers retours des utilisateurs semblent concluants : tout marche aussi bien (voire mieux puisqu’il y a de nouvelles fonctionnalités/optimisations).

Ce salon a accueilli près de 700 personnes sur une journée de conférences et de stands et rentre ainsi dès son premier opus dans le top des salons NTIC PACA; La qualité de son contenu et de sa présentation a été remarqué et soutenu officiellement lors de la conférence de clotûre par Monsieur Laroussi OUESLATI (conseiller régional délégué aux affaires des Nouvelles Technologies de l’Information et de la Communication) qui a pu s’engager devant la salle comble de son soutien qui sera renforcé notamment financièrement lors de la deuxième édition.

J’ai pu présenter le Libre à un groupe de jeunes dirigeants (membres du CJD Marseille) et directeurs financiers (membres du DFCG Provence) le 21 Mai dernier dans le cadre d’un dejeuner organisé conjointement par ces deux associations.

J’ai présenté avec Stéphane Massonneau, Directeur de Cap Gemini Marseille, le modèle économique du Libre et son essor actuel.

De gauche à droite : Maurice WOLFF, Président DFCG 2006; Moi-même ; Laurent VERVLOET, Président CJD 2006 ; Stephane MASSONNEAU; Nathalie STALLA.

J’ai réalisé un petit document de synthèse ici

Depuis qu’Etch est stable, j’ai effectué quelques migrations Debian Sarge->Etch sur des serveurs en production (un serveur mail en frontal qui m’a appris qu’il était préférable de rebooter sur un noyau sans patch Grsecurity avant de migrer, un serveur mail LDAP/Postfix/Courier/Horde, une dedibox et quelques autres) mais finalement assez peu. Ce week-end, j’avais prévu de mettre à jour mon serveur personnel, ce qui n’est pas forcément trivial car j’ai pas mal de services (web, mail, CVS, SVN, NFS, LDAP…), l’installation date de plus de 4 ans (Woody à l’époque) et plusieurs tests/bidouillages/backports sont en place.

Pourquoi attendre autant ? Théoriquement Sarge reste maintenu jusqu’en avril 2008, donc rien ne presse si l’on a pas besoin des nouveaux logiciels d’Etch. Et surtout, j’applique le principe de précaution d’attendre un certain temps afin d’avoir une grande quantité d’informations disponibles sur Internet (ressources Debian, moteurs de recherche, blogs). Enfin, autant j’ai assez de liberté pour mon serveur personnel, autant je ne suis pas le seul décisionnaire pour des serveurs d’entreprise utiles à plusieurs dizaines ou centaines d’utilisateurs.

Bref, entrons dans le vif du sujet. Mes précautions sont d’effectuer des essais de migration avec un serveur de test, d’avoir des backups tout frais, de couper les services durant la phase de migration et de prévenir les utilisateurs à l’avance des perturbations. Ensuite, j’ai repris les Releases Notes, j’ai adapté mon sources.list puis :

# aptitude update && aptitude upgrade
# aptitude install initrd-tool

Pas de problème particulier à noter jusqu’ici. Ensuite, je dois mettre à jour mon noyau :

# uname -a
Linux serveur 2.4.27-3-k7 #1 Wed Dec 6 00:10:25 UTC 2006 i686 GNU/Linux
# aptitude install linux-image-2.6-k7

Comme prévu, udev a râlé un peu à cause de mon noyau 2.4, mais rien de bien grave. Par contre, cela s’est passé moins bien avec LILO qui a semblé un peu perturbé par tous ces changements :

# lilo
Warning: '/proc/partitions' does not match '/dev' directory structure.
Name change: '/dev/scsi/host0/bus0/target0/lun0/disc' -> '/dev/sda'
Fatal: VolumeID read error: sector 0 of /dev/sda not readable

Je n’avais pas le temps d’investiguer et j’ai décidé de tenter ma chance avec GRUB.

# aptitude install grub && grub-install /dev/hda/ && update-grub

La phase grub-install est très longue mais ça s’est bien passé lors du reboot à la fin de la mise-à-jour.

Ensuite, c’était la mise-à-jour de tout le reste des logiciels :

# aptitude dist-upgrade

Je vous fais grâce des messages/questions debconf et les mises-à-jour des conffiles (à ce sujet, pour info, j’ai pour réflexe de visualiser les différences avant de choisir de garder l’ancienne version ou pas, et je garde des notes pour y revenir en fin de mise-à-jour). Passons maintenant aux divers problèmes rencontrés :

- mod_security

Starting web server (apache2)...
apache2: Syntax error on line 116 of /etc/apache2/apache2.conf:
Syntax error on line 1 of /etc/apache2/mods-enabled/mod-security.load:
Cannot load /usr/lib/apache2/modules/mod_security.so into server:
/usr/lib/apache2/modules/mod_security.so:
cannot open shared object file: No such file or directory failed

Pour des raisons de licence, mod_security n’est plus dans Etch (on peut utiliser les packages upstream si on le souhaite).

- Authentification HTTP avec LDAP

Invalid command 'AuthLDAPEnabled', perhaps misspelled or defined by a module not included in the server configuration

J’ai du adapter mes configurations de la façon suivante :

#AuthLDAPEnabled on
AuthBasicProvider ldap
#AuthLDAPAuthoritative on
AuthzLDAPAuthoritative Off

- Apache-SSL

Syntax error on line 75 of /etc/apache-ssl/httpd.conf:
Invalid command 'TypesConfig', perhaps mis-spelled or defined by a module not included in the server configuration

Il s’agit d’un reste d’une fameuse migration Apache 1->2 ;) Ne l’utilisant plus, je me suis contenté de le supprimer et j’ai ouvert un petit bug pour améliorer le httpd.conf : #441447

- Bugzilla

Could not execute `/etc/bugzilla/localconfig'! ;
make sure permissions are ok. at /usr/share/perl5/Bugzilla/Config.pm line 161.
Compilation failed in require at /usr/share/bugzilla/lib/checksetup.pl line 505.
BEGIN failed--compilation aborted at /usr/share/bugzilla/lib/checksetup.pl line 505.
ERROR: Unable to find /usr/share/bugzilla/debian/params.new

Je n’arrive plus à repoduire ce problème après avoir désinstallé et réinstallé Bugzilla avec dbconfig. On va donc considérer cela comme une solution.

-Authentification LDAP avec Courier

Le fichier authldaprc a légèrement changé de syntaxe :

#LDAP_SERVER  127.0.0.1
#LDAP_PORT 389
LDAP_URI ldap://127.0.0.1

- Serveur NFS

Afin que le service NFS fonctionne correctement, j’ai du temporairement ajouter des autorisations sur udp/817, udp/896 et tcp/4984 sur le firewall du serveur. Je dois probablement revoir mes diverses options pour forcer les ports de mountd, lockd & co. (RPCMOUNTDOPTS, RPCSTATDOPTS et les options lockd.tcpport, lockd.udpport). Vu que cela “juste marche” pour l’instant, j’ajusterai ces paramètres “plus tard”.

- Onduleur sur le port série

Le logiciel Nut ne fonctionnait plus, mais c’était simplement une question de droits sur le périphérique /dev/ttyS0

- Problèmes mineurs

J’obtiens des messages récurrents du kernel :

parport0: FIFO is stuck
parport0: BUSY timeout (1) in compat_write_block_pio
DMA write timed out

Ils sont du à un ancien CUPS qui traînait dans le coin pour une imprimante sur le port parallèle plus branchée depuis un certain temps…

J’ai du remettre Vim en éditeur par défaut :

#  update-alternatives --config editor

Voilà pour cette migration. Rien d’extraordinaire, mais je trouve intéressant de prendre la peine de noter les petits problèmes rencontrés (ne nécessitant pas forcément un rapport de bug) sur mon blog afin d’informer (voire aider ;) d’autres personnes qui pourraient avoir des soucis similaires. Un bon complément des Releases Notes. Je vais essayer de le refaire pour d’autres migrations, et n’hésitez pas à faire de même !

Suite au décès de mon précédent ordinateur portable, il a fallu trouver rapidement un remplaçant. Je souhaitais un ultraportable léger, avec une bonne autonomie et bien supporté par Linux. Ayant entendu parler d’une nouvelle gamme d’ordinateurs portables distribués par Transtec, et après étude de l’existant, mon choix s’est porté sur le Transtec Levio 210 : écran 12″, 2 kgs, puces Intel (CPU Intel Core 2 Duo, carte vidéo i945 et carte Wi-Fi 3945ABG), le tout préinstallé sous SUSE Linux (donc assez compatible Linux ;-) pour environ 800 EUR ! Après quelques mois d’utilisation (sous Debian évidemment), tout ce dont j’ai besoin fonctionne et j’en suis très heureux notamment grâce au suspend2(ram|disk) qui marche parfaitement et me change la vie : sympa les uptimes de 30 jours avec un laptop. Vous trouverez sur mon site une page récapitulant sa compatibilité Linux (listée par TuxMobil).

Interviewé par une journaliste du Monde Informatique lors d’un colloque à Sophia Antipolis, une citation issue de cet entretien et du petit document que j’avais rédigé pour l’occasion a été publiée dans le n°1154 de cet hebdomadaire.

Vous pourrez le lire ci-dessous :

Evolix, société où je travaille, utilise en interne le logiciel eGroupWare depuis presque 2 ans. En fait, jusqu’ici, nous utilisions uniquement le module de calendrier pour gérer les rendez-vous et emplois du temps de chacun. Il faut dire que la version en place, version 1.0 (en paquets pour Debian sarge), possède d’autres modules intéressants pour Evolix, comme le module de gestion de projets, mais ça n’est pas du tout abouti (peu d’interaction avec le module calendrier en particulier). Mais sur eGroupWare 1.2, le module projet a été ré-écrit et offre des fonctionnalités très attendues, comme ces fameuses interactions avec les modules calendrier et Infolog (gestion des tâches/appels/notes).

En juillet 2006, la loooooongue migration vers eGroupWare 1.2 a donc été entreprise. Il y a eu des problèmes techniques à gérer : du code Javascript loin d’être parfait, des bugs étranges selon les versions PHP/(My|Postgre)SQL/LDAP et une migration des données à gérer « à la main » (voir mes scripts de migration du calendrier 1.0 vers 1.2 sous PostgreSQL) ; et il a également fallu faire la gestion (humaine) du changement, ce qui ne fût pas le plus facile ! À vrai dire, même dans une petite boîte et même lorsque les évolutions sont flagrantes (rapidité, ergonomie, fonctionnalités), le pilotage d’un projet de migration n’est pas forcément aisé. D’ailleurs, à ce sujet, la conduite du changement peut parfois apparaître comme une tâche triviale et accessible à tous mais les divers projets que j’effectue me renforcent dans l’idée que l’on ne s’improvise pas comme expert dans ce domaine, et seule des expériences concrètes sont gages de qualité. Et sur ces belles paroles, je retourne gérer mon emploi du temps de ministre sur mon eGroupWare 1.2 désormais migré définitivement depuis quelques jours !

Sollicité par la personne préparant la sortie d’un hors série de la revue de l’Association des Ingénieurs de Telecom Paris sur le sujet du Logiciel Libre, j’ai pu rédigé et proposer l’article suivant :
À lire ici

Le jour de la sortie officielle du dernier opus de Tolkien (The Children of Hürin), une pré-version du site officiel de “The JRR Tolkien Estate Limited” a pu être mise en ligne.
Ce site internet est toujours en cours de développement avec la collaboration d’Evolix qui assure la conception du CMS spécifique attaché.

Rendez vous sur : http://www.tolkienestate.com/

Au bureau, nous avons reçu un appel surprenant d’un acheteur d’un ordinateur Surcouf qui avait un problème sous Linux. Une conversation surréaliste a démarré avec l’acheteur qui pensait être chez… le support Linux de Surcouf !

Difficile de ne pas imaginer le technicien du service technique Surcouf, désemparé, lançant une recherche sur Google avec quelques mot-clés et renvoyant vers le premier résultat.

Oui, le service de support technique de qualité avec des ingénieurs et techniciens qualifiés a vraiment de l’avenir (et heureusement pour Evolix).

Vendredi 19h, me voilà arrivé à la dernière étape de la procédure d’installation d’un Pack Evolix Serveur. Il s’agit de mettre la touche finale avant le départ de la machine pour le datacenter, c’est-à-dire protéger le BIOS par un mot de passe.

“Facile!” me direz-vous, “Ou pas!” ajouterais-je. En effet, le mot de passe choisi va me coûter quelques précieuses heures. Je vous passe les détails sur le côté ergonomique du BIOS des machines IBM (auquel je ne m’habituerais jamais) pour aller à l’essentiel : activer ce fameux power-on password. Je valide donc mon choix avec précaution (ça serait bête de bloquer la machine) et je redémarre pour le test ultime. On me demande d’entrer mon mot de passe, et là, c’est le drame : error 189, invalid passwords. Your system is now locked.

Quelques redémarrages plus tard (précisons que ce genre de machine met quelques minutes à démarrer), je me rends à l’évidence, la machine est bloquée. Après une conférence avec moi-même (”je suis sûr d’avoir entré le bon mot de passe”, “d’ailleurs il faut le confirmer”, etc.), je me retrouve avec un problème bien stupide de mot de passe. Bien sûr, aucun manuel fourni ne précise comment réinitialiser le mot de passe du BIOS, et vu le prix de la machine, je vais éviter de me jeter tout de suite sur la carte-mère pour jouer avec les cavaliers à l’aveugle. Ravalant ma fierté, je me décide à appeler le support IBM… mais c’est pour mieux pointer du doigt le ridicule de ma situation : “voilà, j’ai mis un mot de passe et il marche plus”. Combien de fois me suis-je moqué (gentiment hein) des utilisateurs dans cette situation mais là, mon appel enregistré pourra faire le tour du callcenter. Enfin, précisons que plus de 10% des demandes à un support concernent un reset de mot de passe. Bref, il faut absolument que je me sorte de ces 10%. J’ai l’impression d’être plongé dans le feuilleton “Lost” où il faut que je trouve un moyen d’entrer ce #!@ de mot de passe avant l’explosion (de mes nerfs).

Je me décide à ouvrir le capot de l’engin et à trouver un manuel descriptif de ces jumpeurs qui ont l’air de me défier de leur trouver une utilité. Ma déception est assez grande, pas de manuel disponible !! Et oui, pour le PC de Madame Michu, on a le manuel de la carte-mère mais pour les serveurs des décideurs pressés, pas besoin (c’est pas pour rien qu’ils sont pressés). Soupir. Je rejette un coup d’oeil à la carte et là, je suis attiré par un cavalier au titre évocateur “PASSWORD RESET”. Mouarf, c’est si évident, pas besoin d’en faire un manuel. Mais ne faisons pas la fine bouche la machine est débloquée.

Je vais donc enfin savoir si la fatigue du vendredi soir m’a joué un tour en ré-essayant la même manipulation que la première fois. Et, bien l’erreur se reproduit (évidemment hein). Apparemment, le mappage du clavier dans le BIOS et au démarrage est différent car si le mot de passe contient un chiffre, ça bloque !! Est-ce trop compliqué d’écrire quelque part cette information ? Bref, avec le mot de passe test, ça fonctionne bien. Mais avec un mot de passe un peu plus complexe, le blocage se reproduit (au passage, rappelez-vous le délai de quelques minutes pour le redémarrage entre tous ces essais). Allez, nouvelle hypothèse : il faut utiliser un mot de passe compatible azerty/qwerty. J’ai deviné juste, et c’est l’occasion de sortir un nouvelle acronyme : WTFM, aka Write The F***ing Manuel. Bref, c’est enfin le bout du tunnel et deux bonnes heures plus tard, je suis enfin parvenu à activer le power-on password.

Mais ne croyez pas que cela soit complètement terminé. Il reste à choisir ce que l’on veut faire avec ce mot de passe. IBM propose deux modes : un blocage complet (le mot de passe est nécessaire pour toute opération) ou blocage transparent (le système peut démarrer mais le clavier reste inactif tant que le mot de passe n’est pas entré). À vrai dire, le principe du deuxième mode est sympa, car il permet à la machine de redémarrer sans présence humaine mais il bloque également l’accès au BIOS, au choix du périphérique de démarrage et même l’accès système au clavier. Mais c’est bien sûr trop beau pour être vrai car avec le 2e mode sous Linux, le clavier est bloqué ad vitam eternam. Mais je ne suis plus à une concession près et en attendant de reporter le problème chez IBM, on se passera du clavier (qui, à vrai dire, ne sert presque à rien au datacenter).

Vendredi 23h, fin de la journée.

Histoire d’éviter de multiples requêtes sur les mirroirs ClamAV, tous les serveurs installés par Evolix utilisant ClamAV se mettent désormais à jour sur clamav.evolix.net, un mirroir non officiel de la base des virus utilisée par ClamAV.

Pour rappel, ClamAV est un antivirus libre particulièrement efficace en terme de reconnaissance de virus. Evolix l’utilise sur de nombreux serveurs de messagerie où il donne satisfaction et des tests l’annoncent même comme l’antivirus le plus efficace. Notez bien que vous pouvez soumettre un virus si vous en découvrez un non reconnu.

À l’occasion de la Journée Méditerranéenne des Logiciels Libres (JM2L), j’ai fait une présentation d’une heure sur Samba. Vous pouvez retrouvez les slides (format PDF, 1.3 Mo) que j’ai projeté et surtout la vidéo de ma présentation (format OGG, 633 Mo) ; vous pouvez même la télécharger par BitTorrent.

À cette occasion, je tiens à préciser que mon HOWTO SAMBA est obsolète (il date de 2 ou 3 ans). J’espère pouvoir prendre le temps de le mettre à jour dans les prochains mois.

Mes photos du salon

À l’occasion d’un petit déjeuner professionnel organisé par Evolix, j’étais chargé d’afficher plusieurs sortes de slides dont certains au format PPT (PowerPoint) sur OpenOffice.org version 2. Ces slides comportaient plusieurs animations plus ou moins complexes.

L’utilisation d’un de ces slides PPT importés dans ooImpress a provoqué une lenteur excessive (jusqu’à 40 secondes pour certaines pages). Ceci est gênant car on risque de penser qu’OpenOffice est bloqué alors que ce n’est pas (vraiment) le cas. Cette lenteur persiste si le document est exporté en ODP : certains effets PPT semblent donc être mals traduits par l’import PPT d’OpenOffice.

Mais on ne peut pas blâmer OpenOffice : en effet, le format PPT est propriétaire et fermé ce qui empêche d’autres logiciels de le lire parfaitement. On constate donc encore une fois l’importance d’utiliser des formats ouverts afin d’avoir une interopératibilité pour ses documents.

Ajout : je ne suis apparemment pas le seul à avoir remarqué ce genre de problème : Bug 54676 , Bug 57767