Migrer vers StatusNet 1.0, retour d’expérience… malheureux

closeCet article a été publié il y a 12 ans 5 mois 4 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

L’annonce est arrivée, après une phase de mise au point sur Identi.ca, la release finale 1.0 de StatusNet est rendue officiellement disponible. J’avais décidé d’attendre cette version stable pour éviter les déboires potentiels d’une version non finalisée. Cette annonce m’a donc poussé à franchir le pas. Ais-je bien fait ?

Une sauvegarde avant toute chose

Avant tout chose, je commence par une bonne sauvegarde de ma base de données et du répertoire actuel. A noter que je pars de la version 0.9.6 qui n’était pas la dernière version disponible. Mais j’imagine que cela a été prévu dans les scripts de migration (je croise les doigts dans mon dos).

Je constate au passage que ma base de données a atteint la taille respectable de 295Mo avec plus de 235 000 notices. Je me demande quand même s’il y a un intérêt à garder tout cela. Je ne fais pour ainsi dire jamais de recherche dedans. Je me suis parfois dit que je pourrais m’en servir pour retrouver des lectures que j’avais faites, mais dans les faits c’est difficilement exploitable. Si l’un d’entre vous a un usage ou une façon d’exploiter toutes ces données, je suis preneur de l’information.

Passons à la mise à jour

Je me suis basé sur les informations données sur le wiki de StatusNet. Je télécharge l’archive de la version 1.0. Vous la trouverez sur le dépôt Git  car sur le wiki c’est toujours le lien vers la release candidate qui est donné. Je la décompresse et positionne les droits qui vont bien pour mon serveur utilisant Apache sur une Debian.

Il me faut maintenant rendre mon instance StatusNet inaccessible pour qu’il n’y ait plus d’opérations durant la mise à jour. En effet, un serveur StatusNet reçoit en permanence les notices « poussées » par les autres instances sur lesquelles je me suis abonné.

Dans mon cas je vais simplement supprimer le lien symbolique StatusNet qui pointe sur le répertoire où est installée la version 0.9.6. C’est un peu « cochon », mais efficace 🙂 .

Je copie de mon ancien répertoire le fichier config.php et le contenu des dossiers avatar/, background/, file/, et local/ vers le nouveau. Mais je n’oublie pas non plus de copier le script de mon plugin qui fait l’interface avec mon raccourcisseur d’URL et qui se trouve dans le dossier plugin. Là ce sera la surprise pour voir s’il marche encore.

Je renomme le fichier htaccess.sample en .htaccess dans le nouveau répertoire. Je mets à jour la ligne contenant la variable RewriteBase pour correspondre à mon installation soit simplement :

Rewrite /

Dernière étape et pas des moindres, la mise à jour de la base de données. A ce point-là, assurez-vous d’avoir une bonne sauvegarde de votre base. En cas de problème durant la mise à jour vous pourriez perdre toutes vos données. Je lance donc la commande fatidique :

php ./scripts/upgrade.php

J’étais un peu inquiet sur la durée du traitement, mais celui-ci s’achève au bout d’environ 5 minutes. Je passe en revue les tables de ma base de données StatusNet et je constate qu’elle a pris au passage une bonne quarantaine de Mégaoctets. Il ne me reste plus qu’a recréer le lien symbolique vers le nouveau répertoire pour voir le résultat de toutes ces opérations.

Le résultat, le résultat !!

Moment toujours exaltant dans une mise à jour que celui où l’on découvre le résultat de son labeur. Un petit refresh de ma page d’accueil de mon instance et bonne surprise, ça marche. Enfin pas très longtemps, visiblement il y a un problème de réécriture des URL car j’obtiens une « Page non trouvée. » sur les liens que je clique.

Je vérifie que mon .htaccess est bien là, les logs d’apache, j’active même les logs du module rewrite pour être sûr que les règles sont bien appliquées…

Les symptômes : les urls « jolies » comme http://status.scoffoni.net/index.php/notice/235528 renvoient une page non trouvée. Si j’utilise l’url « moche » http://status.scoffoni.net/index.php?p=notice/235528 la page est bien retournée.

La réécriture ne se fait pas me direz-vous… Pourtant dans la log du rewrite j’ai bien des :

x.x.x.x – – [01/Oct/2011:23:22:29 +0200] [status.scoffoni.net/sid#7f49ab8bc618][rid#7f49abc929a0/subreq] (2) [perdir /home/www/statusnet/] rewrite ‘user/3’ -> ‘index.php?p=user/3’

Si je supprime le .htaccess, les réécritures n’apparaissent plus dans la log. Donc je dirais que celle-ci marchait. Côté apache je n’ai rien changé dans la configuration du host. D’ailleurs, il m’a suffi de restaurer ma base et de refaire mon lien symbolique vers le répertoire de la version 0.9.6 pour que celle-ci fonctionne parfaitement à nouveau.

Voilà, je n’ai donc rien compris au problème rencontré. Peut-être rien, un détail, qui m’a échappé…Si vous avez des pistes, elles sont les bienvenues….

Philippe Scoffoni

Je barbote dans la mare informatique depuis 30 ans (premier ordinateur à 16 ans, un ORIC ATMOS) et je travaille à mon compte au travers de ma société Open-DSI. J'accompagne les associations, TPE et PME dans leurs choix et dans la mise en oeuvre se solutions informatiques libres.

8 réponses

  1. Tr4sK dit :

    J’ai eu le même soucis que toi lors de ma migration.

    Je crois que c’était un problème de droit sur le fichier .htaccess dans mon cas.

    Par contre, je suis actuellement en train de bloquer sur le fait que je n’arrive pas à communiquer avec les autres site. Depuis la maj, mon statusnet ne communique plus avec l’extérieur :/

    Si t’as une idée.

  2. gege2061 dit :

    Par contre, je suis actuellement en train de bloquer sur le fait que je n’arrive pas à communiquer avec les autres site. Depuis la maj, mon statusnet ne communique plus avec l’extérieur :/

    Même soucis, rapporté sur le forum puis le gestionnaire de bugs sans retour…

    http://status.net/open-source/issues/3355

  3. Vinilox dit :

    Même problème pour moi aussi, mon statusnet ne communique plus avec l’extérieur et l’url /main/ostatus/ affiche une erreur 404

  4. Philippe dit :

    @Tr4sK : à priori non, j’avais vérifé. Mais je me rends compte que les url de mon instances sont bizarre par rapport à celle d’autres instances, le index.php est de trop. Pourtant j’ai bien l’option « fancy » à true et un .htaccess… Je me demande si le soucis ne vient pas là

    POur ce qui est de communiquer avec les autres instances je n’ai pas pu tester…

  5. JB dit :

    @Philippe
    Après quelques essais, il semble que j’ai corrigé le problème en patchant le fichier lib/urlmapper.php
    Plus de détails ici:

    J’espère que mon patch n’ontroduit pas d’effets de bord, en tout cas, il fonctionne chez moi 🙂

  6. Philippe dit :

    Je testerais ça et je te tiens au courant. Merci !

  7. Sylvain dit :

    J’ai également des erreurs 404 plein mes logs (par exemple /main/push/callback/23). Pourtant, mes url fonctionnent à la manière d’identi.ca : sans /index.php/. Je vais aller refaire un tour du côté de la version 0.9 🙁

  1. 3 octobre 2011

    […] Migrer vers StatusNet 1.0, retour d’expérience… malheureux L’annonce est arrivée, après une phase de mise au point sur Identi.ca, la release finale 1.0 de StatusNet est rendue officiellement disponible. Source: philippe.scoffoni.net […]