StatusNet, mutualisé, déboires et déconfiture

La saga des « Bordayl ça marche pas » liée à StatusNet me poursuit encore et, visiblement, ne s’arrêtera pas à cet épisode récent que je m’en vais vous conter (si vous n’en avez rien à foutre, voici une conférence gesticulée de Franck Lepage concernant les mensonges structurels de l’Éducation Nationale).

Cette nuit, j’ai reçu une missive électronique (un e-mail, manant) de la part mon hébergeur, m’annonçant un souci technique. Je ne m’inquiète pas, j’ai l’habitude, comme je suis sur un mutualisé qui permet néanmoins l’exécution de scripts et une connexion par SSH, j’ai très rapidement eu l’insigne honneur et privilège de toucher aux limites implicites de celui-ci. Pour les plus visuels de mes lecteurs : j’ai foncé dans un mur la tête la première.

Ceci est un message pour vous alerter que le script /home/postblue/public_html/statusnet/scripts/queuedaemon.php tente de s’exécuter en boucle rendant votre hébergement inaccessible. Nous vous recommandons de vérifier les plugins et modules installés.

Nous avons temporairement désactivé le script /home/postblue/public_html/statusnet/scripts/queuedaemon.php (CHMOD 000) pour éviter que votre hébergement soit inaccessible. Pour le réactiver, il suffirait de remettre le CHMOD sur ce fichier à 644.

Avant que je ne m’emballe encore (même si c’est hélas trop tard, puisqu’il a fallu que je me calme pour écrire – hélas j’ai répondu au support avant cela, ce qui ne joue certainement pas en ma faveur auprès du support), décomposons la chose dans l’ordre, cette saga statusnet, histoire de situer tout ce qui s’est passé pour en arriver là.

Très tôt après avoir acquis mon nom de domaine et mon hébergement me suis-je lancé dans le déploiement d’une instance StatusNet. Ou plutôt de ma première instance : status.postblue.info/postblue, avant de découvrir la joie du mono-utilisateur. Avant de tout crasher lors d’un chipotage et de me retrouver, enfin, sur sn.postblue.info. Ce fut une expérience riche, où j’ai pu apprendre de mes erreurs et, à force de tâtonnements, j’ai aussi pu acquérir une relative autonomie technique (moyennant quelques discussions avec d’autres joyeux bonhommes ayant leur propre instance et la lecture de leurs billets de compte-rendu d’expérience comme j’ai pu en faire également), me rendant plus ou moins maître de l’objet (même quand subitement mon profil d’utilisateur disparaît de la base de donnée et que je dois l’y réinsérer a la mano).

Hélas j’ai très vite déchanté face aux performances déplorables de mon hébergement, qui étaient bien plus basses que n’importe quel autre hébergement dédié (dont celui de mon meilleur ami) que j’avais pu tester : erreur à chaque envoi d’un message, ce dernier n’étant que rarement  reçu sur les instances fédérées, lenteurs innommables de la base de données, … Allant jusqu’à l’absence de l’extension pcntl.so qui m’aurait permis d’utiliser les files d’attentes asynchrones (queuedaemon.php) et bénéficier d’un surcroît de réactivité à mon instance, tournant en boucle et en tâche de fond afin de « pousser » mes messages sur l’instance de mes contacts.

Ce que j’ai enfin pu solutionner. Et ce qui a amené mes plus gros ennuis jusqu’alors, comme vous avez pu le lire dans l’extrait plus haut, à une petite imprécision prêt.

En effet, ce n’est pas queuedaemon.php seul à qui il a été balancé un CHMOD 000 rédempteur, mais tout mon répertoire www/statusnet/ ; je n’ai plus accès à rien dans le sous-domaine concerné, FTP et SSH compris. Étranger dans mon propre domaine, moralement je le vis très mal. Cette « mesure de sécurité » afin d’éviter que mon hébergement soit inaccessible a, ironiquement, rendu inaccessible l’entièreté d’un de mes sous-domaines, sans coup férir et sans recours.

L’exécution redondante et continue de queuedaemon.php est intentionnelle, puisque je l’ai activé moi-même dans ce but !

chmod: changing permissions of 'www/statusnet/': Operation not permitted

Dans de telles conditions, comment suis-je supposé faire un CHMOD 644 sur l’intégralité de mon dossier ? Suis-je sensé passer par une faille 0day histoire d’être root sur la machine et m’amuser à prendre les commandes ? Notez que c’est un défi excitant, quoique je craigne ne pas en avoir les moyens, techniquement.

Alors que faire ? Attendre une réaction du support ? Ce dernier me balade depuis des mois à me dire que memcache est installé (l’extension PHP, mais pas le programme) et activé, à l’instar d’eAccelerator, mais que c’est de la faute à W3TC s’il me renvoie une erreur de connexion, le vilain. Je n’attends pas de miracle de sa part.

Un serveur dédié ou un VPS ? Ça a un prix, que je n’ai pas les moyens d’assumer.

De l’autohébergement ? J’ai bien une machine, quoique le ventirad en soit absent, mais ma mal-aimée BBox (la TV digitale, tout ça) a tendance à s’éteindre dès qu’elle est un peu trop sollicitée. Elle doit être de fabrication Corse. Ajoutons aussi une formidable IP dynamique.

Ça s’annonce mal. Quelqu’un aurait-il une solution à m’offrir ?