- Détails
Après Taïwan, la France, les Pays-Bas, la tournée de mon célèbre PowerBook fait une escale en Grande-Bretagne.
Mon PowerBook est né à Taïwan, en octobre 2003. Il a fait le long voyage jusqu'aux Pays-Bas (la lointaine Péïbadie 😉), pour une visite médicale concernant l'écran, avant d'arriver en France, dans mes bras.
Il est reparti ensuite en convalescence en Péïbadie pour son problème d'écran.
Il se la coulait douce depuis un an, et il a dû sentir qu'il avait besoin de vacances. Hop un problème de slot mémoire de derrière les fagots, et le voilà parti en Grande-Bretagne. Le centre de maintenance de la Péïbadie a fait faillite, du coup le PowerBook voit du pays...
D'après le suivi d'UPS, mon brave PowerBook est bien arrivé à destination aujourd'hui 27 octobre à 7 h 39. Il est parti hier à 15 h 30. Il a même eu le droit à un passage aux rayons X. 🙂
Le suivi de réparation Apple montre aussi que la machine est bien arrivée, et qu'elle est en attente de réparation. Et vu que là à 16 h il n'y a pas de nouveau, je le reverrai pas avant mercredi je pense (week-end de 4 jours oblige)...
Suite au prochain épisode...
- Détails
En fait le nouveau problème de mon Powerbook est un problème courant chez ses congénéres...
La dernière fois que mon PowerBook est tombé en panne, c'était un problème connu (les tâches blanches sur l'écran). AppleCare a remplacé l'écran rapidement et j'ai pas eu de problèmes depuis (quoi que l'écran est un peu sombre à l'allumage).
Avant hier, j'ai découvert qu'un des slots mémoire partait en sucette. Et aujourd'hui, j'apprends que c'est pas isolé...
En effet, les forums chez Apple parlent de problèmes récurrents sur cet emplacement mémoire, il y en a même qui font une pétition pour faire remplacer la carte mère même hors garantie.
En fait mon pauvre PowerBook a un instinct très grégaire, il prend tous les problèmes qu'on ses potes et attrape les plus courants...
Enfin bon, je pense l'expédier aujourd'hui et le revoir en fin de semaine, guéri et en pleine forme.
- Détails
Aka PowerBook: Revenge of the Slot...
Bon finalement après tests, c'est pas une barette de RAM, mais un des slots de RAM qui part en vrille... 😕 J'ai ouvert le compartiment à RAM, j'ai interverti les barettes, testé chacune dans chaque emplacement, et conclusion, le slot du bas est mort...
C'est aussi confirmé par l'Apple Hardware Test, il me rapporte l'erreur suivante :
post/0/2048 SODIMM0/J25LOWER
Et en effet, c'est bien le connecteur du bas...
J'ai appelé donc AppleCare aujourd'hui, et ils m'envoient une boîte pour expédier la machine après-demain au plus tard. Et le mec me dit qu'elle pourrait être de retour avant la fin de la semaine (c'est en effet ce qui s'est passé la dernière fois).
Voilà, j'ai plus qu'à attendre la boîte, expédier et croiser les doigts...
- Détails
Le site officiel manque de docs, et vu que j'y ai été empêtré toute une semaine, je vais relater mon expérience dans la migration de Plone vers la version 2.1. Pour utilisateurs avertis de Zope/Plone.
Plone est un système de gestion de contenus open source et gratuit. C'est la technologie derrière mon site. Dernièrement, les gens de chez Plone ont sorti une nouvelle version, la 2.1, qui apporte quelques nouveautés et améliorations, dont l'adoption d'Archetypes en tant que base des types de contenus, à la place des types CMF (Content Management Framework), utilisés depuis les débuts de Plone.
De fait, la migration de Plone 2.0.5 (ou antérieur) à Plone 2.1 (et supérieur) implique la migration automatique des anciens types de contenus, ce qui peut être à la fois long et laborieux. Dans mon cas, il s'agissait de migrer 4 sites répartis sur deux instances.
Première instance, le site web de ma boîte, plus un petit site perso. Le site web a un contenu majoritairement statique, composés de documents (CMFDocument), avec quelques fichiers PDF stockés en CMFFile. Le site perso est très réduit en taille, avec des documents et quelques photos. Le Data.fs de l'instance pèse dans les 500 Mo.
Deuxième instance, le site intranet de ma boîte, plus un site communautaire sur un artiste vietnamien. Le site intranet est très lourd, et chargé à bloc de fichiers PDF stockés en CMFFile, ainsi que des CMDDocuments. Le site communautaire est composé de documents en CMFDocument, de photos en CMFPhoto et de quelques chansons en MP3 (CMFFile). Le Data.fs fait environ 1 Go.
La procédure normale de migration de Plone (sur FreeBSD, ou d'autres Unix) est de tout d'abord, faire une sauvegarde complète du site, avec tous les produits (on sait jamais), télécharger le tarball de la nouvelle version de Plone sur leur site, placer les produits nouveaux et mis à jour dans le répertoire Products
de l'instance, et lancer la mise à jour dans la ZMI par l'outil portal_migration
, qui sait détecter la version installée, et qui effectue la migration tout seul comme un grand.
La migration en elle-même effectue la mise à jour des produits de support de Plone, comme Archetypes, et met à jour le site Plone en lui-même (avec les changements de paramètres, nouvelles variables, etc). Mais la migration en version 2.1 effectue une étape importante supplémentaire : elle convertit les éléménts CMFTypes du site en éléments Archetypes. Ça consiste en fait à prendre un objet CMFType, créer un nouvel objet Archetype équivalent, et à répliquer tous les paramètres et données au nouvel objet, et détruire l'objet CMFType. Ainsi on obtient un objet Archetype d'apparence identique à l'ancien objet CMFType.
Le script effectuant cette manœuvre recatalogue le site, trouve les objets CMFTypes à partir du portal_catalog
, et les convertit. Or cette opération est longue et consommatrice de mémoire et d'espace disque temporaire.
La première erreur que j'ai eue, c'est No space left on device
... En effet, l'interprêteur python qui effectuait la mise à jour a saturé le répertoire /tmp
de la machine. En même temps, ce n'était pas très difficile, la taille par défaut de la partition abritant /tmp
sur FreeBSD est de 256 Mo. Ce qui est suffisant pour la plupart des cas, mais là, les devs de Plone recommendaient au moins la taille du Data.fs pour la migration. Là, j'en étais loin... Normalement, python utilise tour à tour les répertoires /tmp
, /var/tmp
, /usr/tmp
et le répertoire courant (et peut-être un autre, je sais plus) pour stocker les fichiers temporaires, et ne devrait théoriquement jamais se trouver à court d'espace disque avant la saturation totale de tous les disques. Mais là, il semble qu'il n'y a qu'un seul fichier utilisé pour la migration, et qui grossit pendant toute la durée de l'opération. Donc pas de fallback possible...
Du coup, j'ai monté une machine dédiée à la migration, avec une seule partition couvrant tout le disque. Plus de problème d'espace disque. Mais j'ai été confronté à des erreurs de type Memory Error
... Et c'est à peu près les pires erreurs qu'on peut rencontrer dans Zope/Plone, ça veut dire en gros qu'il y a eu une erreur de lecture/écriture sur le Data.fs irrécupérable...
Au bout de deux ou trois échecs de migration directe, je me suis dit que je ne pouvais pas continuer comme ça : il y a tellement de choses qui sont faites dans la migration que je ne sais pas où s'est produit l'erreur, et l'opération met tellement de temps que j'en aurais pour des semaines avant de dépatouiller la chose à ce rythme.
J'ai alors essayé de comprendre la procédure. Et c'est pas bien sorcier. D'abord, essayer de nettoyer et alléger le fichier Data.fs pour faciliter la migration. Rien de compliqué, recataloguer le site (<site>/portal_catalog
, onglet Advanced
, Update Catalog
),recompresser le fichier (Control_Panel/Database/main
, onglet Database
, Pack
).
Ensuite, mettre à jour les produits déjà installés (par portal_quickinstaller
. Ensuite, installer les nouveaux produits dont Plone a besoin (toujours par portal_quickinstaller
). La version 2.1 apporte les produits suivants :
- ATContentTypes
- ATReferenceBrowserWidget
- Archetypes
- CMFActionIcons
- CMFCalendar
- CMFFormController
- CMFQuickInstallerTool
- GroupUserFolder
- MimetypesRegistry
- PloneErrorReporting
- PloneLanguageTool
- PortalTransforms
- PortalTransport
- ResourceRegistries
- kupu
Tout réinstaller/installer, sauf ATContentTypes. Une fois que les autres produits sont installés sans erreurs, on passe au point crucial, ATContentTypes.
ATContentTypes, c'est le produit qui apporte les types de contenus Archetypes (comme son nom l'indique). Or ça implique de recataloguer le site avant, et de créer un double Archetype de chaque objet CMFTypes du site, et enfin de supprimer les objets CMFTypes. Et c'est long !
A l'installation du produit, il y a un Update Catalog
qui se fait, ça prend un moment (surtout si le site est grand). Une fois le produit installé, il faut passer aux choses sérieuses : portal_atct
. C'est un outil placé par ATContentTypes à la racine du site. La première fois, si vous aviez déjà installé Archetypes avant, l'outil vous indiquera que l'instance n'est pas à jour. Il faudra passer par Version Migration
pour ce faire.
Une fois que l'instance est à jour, il faut passer à la migration des types, dans Type Migration
. Comme l'indique l'outil, pour cette étape, il vaut mieux lancer Zope en mode debug, ou consulter régulièrement le log de Zope, pour voir ce qu'il fabrique. Un clic sur Migrate
lance la migration des types. Là j'ai connu l'enfer, avec des Memory Error
inexplicables (pas de veleur d'erreur...).
Mais j'ai fini par voir qu'il y a au début du log le chemin complet de l'objet en cours quand l'erreur s'est produite. Pour moi, c'était à peu près tous les objets binaires (type octet-stream
), comme des fichiers exécutables ou des fichiers Zip stockés en tant que CMFFile. Il est possible que notre utilisation de TextIndexNG2, un produit permettant une indexation plus fine des langues non latines, ait contrinué à cette erreur, car les index sont également regénérés lors de la migration des types. Peut-être que TextIndexNG2 n'a pas trouvé de "lecteur" approprié pour ces types et qu'il s'est emmêlé les pinceaux...
En tous cas, supprimer ces objets a suffi pour que la migration des types se fasse sans erreurs (mais bon, il faut relancer la migration de types autant de fois qu'il y a de fichiers problématiques).
Une fois les types migrés, c'est gagné. Il suffit d'utiliser l'outil portal_migration
, et lancer la migration Plone. Il va alors repasser les étapes qu'on a déjà effectué, mais il ne fera rien ou presque, vu que tout est installé et migré côté Archetypes (mais la mise à jour du catalog va quand même se faire, et ça prend du temps...). Il va donc mettre à jour l'instance Plone, et le site sera opérationnel sous la nouvelle version !
Merci d'avoir lu jusqu'ici, c'est brouillon parce que mes tentatives de migration ont été brouillonnes, mais j'espère que ça pourra vous aider si vous rencontrez des problèmes pendant la migration.