Vous êtes ici : Accueil / 2011 / Avril / Zope 2.12 et Plone 4 via des paquets Debian ?

Zope 2.12 et Plone 4 via des paquets Debian ?

écrit le 28/04/2011 Par Gaël Le Mignot
Comments
Cet article évoque les travaux, auxquels Pilot Systems a participé, visant à avoir Zope 2.12 et Plone 4 installables via des paquets Debian. Après avoir étudié rapidement les besoins à adresser, il expliquera les difficultés rencontrées, les solutions retenues et l'état d'avancement actuel.

Introduction

Jusqu'à Zope 2.10, il existait des paquets Debian de Zope, et même des paquets Debian de Plone. Ces paquets étaient prévus pour pouvoir faire coexister plusieurs versions majeures (par exemple, 2.9 et 2.10) de Zope sur la même machine, et un outil très pratique, dzhandle permettait de gérer ces instances.

Depuis Zope 2.12 et le passage de l'ensemble de Zope en eggs, il n'existe plus de tels paquets, quelle que soit la distribution d'ailleurs.

Pourquoi ne pas utiliser buildout ?

L'objectif de cet article n'est pas de lancer un troll velu sur buildout, cependant, il est nécessaire d'expliquer les raisons qui nous poussent à préférer des paquets Debian plutôt que l'utilisation de buildout pour déployer des Zope dans notre infrastructure.

1. Tout un tas de raisons techniques sur le fonctionnement de buildout par rapport à dpkg/apt (la richesse des commandes de gestion pour apt, l'existence d'une cohérence entre les paquets d'une même distribution, la gestion des mises à jour ou des suppressions...).

2. La volonté d'avoir un système homogène de gestion des déploiements et des installations, sur un parc hétérogène, contenant du Zope de différentes versions, du Django, du PHP, des outils non-Web (serveurs de messagerie, supervision, backup...).

3. Le fait d'avoir plusieurs instances de Zope sur un même serveur, en mutualisant certains composants (comme l'Apache frontal); buildout n'offre pas de solution souple et robuste à ce problème.

4. Le fait d'utiliser, autant que possible, les paquets du système pour toutes les bibliothèques Python (par exemple python-ldap, PIL...), et donc d'avoir les mises à jour de sécurité centralisées de Debian sur tous ces paquets.

5. Éviter la duplication du code entre les instances, et entre les instances et le système.

6. Ne pas compiler de code sur les serveurs, ce qui est particulièrement important lorsqu'un serveur est mutualisé (installation d'une nouvelle instance) ou déjà en production (mise à jour ou installation d'un produit additionnel) car la compilation est très lourde en terme d'utilisation de ressources, et peut affecter les performances de la production.

Le packaging de Zope 2.12

Quels sont les problèmes posés ?

S'il existait des paquets jusqu'à Zope 2.10, pourquoi n'y en a-t-il pas eu pour Zope 2.11, ni pour Zope 2.12 jusque là ?

La raison principale est que Zope, jusqu'au Zope 2.10, fournissait une archive (tarball) contenant l'ensemble du serveur. Cette archive était facile à packager comme n'importe quel autre programme.

À partir de Zope 2.12, seuls des eggs correspondant à différents morceaux de Zope sont diffusés, et c'est à easy_install, pip ou buildout de télécharger tous les morceaux et de les compiler ensemble.

Les solutions

Afin d'avoir un paquet Zope 2.12 sur Debian, une petite équipe s'est réunie lors d'un meeting sur IRC : composée de plusieurs développeurs Debian (Jonas Meurer, Michael Mulich, Arnaud Fontaine) et de moi-même (Gaël Le Mignot).

Afin d'arriver à un plan d'attaque, nous avons posé un certain nombre de contraintes :

  • le paquet Debian doit supporter la coexistence de plusieurs versions majeures (comme Zope 2.12 et Zope 2.13) sur la même installation, comme c'était le cas jusqu'alors ;
  • il ne doit pas gêner les paquets déjà existant des composants du Zope Toolkit (ztk), utilisés par certains framework ou par des programmes Python ;
  • il doit permettre d'utiliser tous les modules Python natifs.

Le principal problème pour remplir tous ces objectifs a été que les composants du ztk ont tendance à changer assez vite, et ne respectent pas toujours la compatibilité ascendante.

La solution retenue a donc été de faire un snapshot des composants du ztk nécessaires pour une version donnée de Zope, et de mettre cette version dans un paquet versionné (par exemple zope2.12). Cette solution n'est pas totalement satisfaisante, mais est celle qui répond au plus grand nombre d'objectifs initiaux.

Le paquet actuel

Un paquet expérimental existait déjà, réalisé principalement par Michael Mulich. Ce paquet fonctionne en trois étapes :

1. Un script, à lancer manuellement pour construire le paquet, charge les composants d'une version de Zope donnée en utilisant pip, et fabrique une tarball avec.

2. La compilation du paquet proprement dite (qui sera à terme lancée sur les autobuilders Debian) qui prend la tarball et la compile pour l'architecture choisie (par exemple amd64 ou i386).

3. L'installation du paquet lui-même, qui peut se faire sur une autre Debian, indépendamment des deux étapes précédentes.

Grâce au travail d'Arnaud Fontaine, et un petit patch de ma part pour lui faire utiliser la dernière version de Zope 2.12 (le 2.12.17) ce paquet est désormais utilisable, il est en phase de polissage, et sera bientôt soumis aux FTP Masters de Debian, pour inclusion dans la Sid (puis ultérieurement dans la Testing, et enfin peut-être en backport sur squeeze).

Pour ceux qui souhaitent le tester dés maintenant (attention, il s'agit bien d'un paquet non officiel pour l'instant, même si nous l'utilisons quotidiennement), il est disponible, compilé pour Squeeze en AMD64 sur http://debian.pilotsystems.net.

L'attaque sournoise du shebang récursif

Une petite anecdote, mais qui mérite d'être citée car d'autres peuvent en être victimes : il s'agit de l'attaque sournoise du shebang récursif.

Imaginons la scène : après avoir testé et validé le paquet de Zope 2.12 sur ma Sid, tout heureux d'avoir un paquet opérationnel, je le compile sur notre VM dédiée à la compilation de paquets Squeeze. Je le déploie sur une VM dédiée à accueillir des Plone 4 mutualisés.

Et là... dans un roulement de tonnerre et un flash de lumière, dzhandle refuse de créer une instance avec un "Cannot execute binary file". Je cherche des histoires d'architecture, de bibliothèque, non, rien de tout ça.

Sortant ma pelle et mon casque de mineur, je creuse un peu plus. Et je me rends compte du problème suivant : dzhandle appelle /usr/lib/zope2.12/bin/mkzopeinstance. Ce programme a comme shebang (le nom de l'interpréteur à utiliser, après le #! initial) un script nommé /usr/lib/zope2.12/bin/python qui lui-même utilise le Python du système mais en lui rajoutant des chemins de recherche.

Donc : un programme utilise comme interpréteur un autre programme lui-même interprété. On a un shebang récursif. Or, le noyau utilisé jusque là sur nos VMs, le 2.6.26-xen de la Lenny, ne supporte pas les shebang récursif.

Il a donc fallu mettre à jour le noyau utilisé par la VM, opération délicate vu que nos DOM0 n'ont pas encore été migrés en Squeeze (cette opération est prévue, mais non réalisée pour l'instant).

En effet, en utilisant le 2.6.32 des backports de la Lenny, la machine virtuelle se bloquait sur le "Waiting for root filesystem...".

Après avoir testé différentes options (le noyau en -xen ou pas, les disques en sda1/sda2 ou en xvda/xvdb, ...), je finis par comprendre que c'était le module blkfront (utilisé pour gérer les disques en mode paravirtualisé sur Xen) qui n'était pas inclus à la construction de l'initrd.

Assez surpris d'avoir du creuser aussi profondément et d'avoir du me battre avec un noyau, un xen et un initrd pour une histoire de shebang, j'ai utilisé une solution radicale : copier l'image du noyau et l'initrd installés sur une Squeeze, et les utiliser pour démarrer cette VM. C'est du temporaire, les DOM0 seront migrés d'ici peu. Mission accomplie.

Installation de Plone 4

Extraction des eggs de Plone 4

Maintenant qu'un Zope 2.12 géré en paquets Debian et via dzhandle tourne, il ne restait plus qu'à installer un Plone 4 dessus.

Mais Plone lui-même n'est plus diffusé sous la forme d'un tarball non plus. Il a donc fallu écrire un script qui, depuis un Plone installé via l'Unified Installer, fait le tri entre :

  • les eggs fournis par des paquets Debian (comme PIL ou autres modules Python) ;
  • les eggs déjà inclus dans le paquet Zope 2.12 de Debian ;
  • les eggs utilisés par Plone lui-même.

Ensuite, il n'y a plus qu'à installer ces eggs dans le lib/python de l'instance créée par dzhandle, et le tour est joué.

Ce tarball est disponible dans https://svn.pilotsystems.net/projets/plone-tar/

Pistes pour le futur

Actuellement, le Zope est géré par l'architecture Debian, mais Plone est plutôt installé manuellement instance par instance. Cette solution est peu satisfaisante, et il serait souhaitable de créer un paquet Debian pour Plone.

Le problème est qu'un changement de version de Plone, même mineur (du 4.0.4 au 4.0.5 par exemple) n'est pas une opération anodine, et demande des interventions dans la ZMI et peut perturber le fonctionnement d'applications tierces. Il faudra donc :

  • soit créer des paquets très versionnés (plone4.0.4 comme nom de paquet) ce qui est lourd et peu élégant ;
  • soit fixer une version, et s'y tenir, ne faisant que du backport des mises à jour de sécurité, ce qui est dommage est en terme de petites corrections de bugs.

Conclusion

Bien que tout cela soit encore neuf et nécessite un peu de stabilisation, les paquets de Zope 2.12 sur Debian sont installables et utilisables au quotidien, et offrent les principaux avantages recherchés par Pilot Systems, afin d'intégrer de manière industrielle des sites Plone dans un parc d'hébergement très varié au niveau des technologies utilisées, sans avoir à maintenir une multitude de systèmes d'installation et de déploiement, tout en bénéficiant, au maximum, des paquets Debian avec la qualité et le niveau de support (en particulier sur la sécurité) qui font, à juste titre, la réputation de Debian.

Actions sur le document

blog comments powered by Disqus