currency:php

Un mois et demi plus tard,

https://media.discordapp.net/attachments/536889987078029313/562701141348057108/Repartition_des_versions_PHP_pour_SPIP3.0_2_avril_2019.png https://media.discordapp.net/attachments/536889987078029313/562701205596536870/Repartition_des_versions_PHP_pour_SPIP3.1_2_avril_2019.png

Entre temps, et en dépit des prédictions pessimistes d’Eric, l’équipe de dev de SPIP a décidé d’arrêter le maintien de SPIP 3.0 et on a améliorer l’algorithme des stats pour mettre de coté les sites pétés/abandonnés.

En bonus, la distribution des versions PHP de SPIP 3.2, avec une hypothèse « Eligible 3.3 » équivalent à une version mini 5.6 de PHP.

https://media.discordapp.net/attachments/536889987078029313/562701236881719298/Repartition_des_versions_PHP_pour_SPIP3.2_2_avril_2019.png

#spip_blog ^^

/me va cliquer sur le bouton Générer un nouveau mot de passe et l’envoyer par email sur spip blog ^^

#gestion #association

▻https://www.youtube.com/watch?v=sHHl5kihXD4

ha ben ce gif tombe juste à point :p

Quand je refactorise du code historique

https://ljdchost.com/lThMG7X.gif

Et le faux gif qui va avec :)
▻https://twitter.com/i/videos/tweet/758640130978639872

(parce que, ton dieu, parce que !) :p

▻http://news.php.net/php.internals/86449

Apparemment, la méthode a été jugée cavalière ;)

D’après ce que je comprends, une lib appelée t1lib n’est plus maintenue de longue date, debian l’a retirée de ses dépôts et GD a donc cessé le support.

intéressant pour #SPIP

@halleck45 s’en sert dans #phpmetrics (c’est comme ça que j’ai découvert)

Ya même un compilateur et un compilateur de compilateur. :)

Mais est-ce qu’il y a un ou des articles expliquant les différences et/ou en quoi ce serait mieux ou moins bien que les libs de symfony par exemple (qui sont aussi modulaires et structurées en dépendances) ?

Je cherche encore. Je vous tiens au jus ;)

▻http://keynote.hoa-project.net/AFUPLyon13/AFUPLyon13.html

Pour effectivement l’utiliser ponctuellement, et avoir pas mal regardé le code, je pense que c’est un framework d’excellente qualité. Il existe des passerelles vers Symfony2 (par exemple pour le composant Console).

Merci de ce retour @halleck45 ;-)

Un petit détail, la version 2 nécessite PHP 5.4 (la version 1 nécessitait PHP 5.3, mais je n’en trouve pas de trace)

Il oublie deux usages de PHP : les utilisateurs des CMS/CRM et autres progiciels... Et les hébergeurs.

Retour d’expérience sur un cas pénible où j’étais des deux côtés :
– vTiger, le CRM, à installer sur mon infra, où le mutualisé est basé sur Debian Stable (7, Wheezy).

1) vTiger en version 5 n’est pas compatible PHP 5.4, y compris dans la toute dernière version.
2) vTiger en version 6.2, la dernière, n’est compatible qu’avec la version 5.6 de PHP. Il m’a donc fallu installer la version 6.1 de vTiger qui a la gentillesse de ne pas inclure de rupture de compatibilité... (j’imagine, quand je fais du mauvais esprit, que les nouveautés de PHP5.6 sont limitées à une nouvelle fonctionnalité mineure...).
3) Debian Stable ne propose pas l’installation en standard d’une version supérieure à PHP 5.4, et de plus en plus, les logiciels opensource vont être tentés, à n’en pas douter, de profiter des nouveautés des dernières versions de PHP.

J’ai un mutualisé en « old stable » pour les clients qui ne veulent pas upgrader leurs logiciels au delà de PHP5.3, car il y avait déjà une rupture avec PHP5.4... Mais avec l’arrêt du LTS, ça va devenir pénible.

Bref, la stabilité d’un langage, c’est bien aussi... ... ...

En effet, les hébergeurs manquent à sa description. Mais selon moi, les utilisateurs de produits devraient être (et sont probablement) totalement indifférents aux technologies employées : Qui se soucie de savoir en quoi est codé MS-Word, par exemple ?

Pour ce qui est de l’opensource, c’est difficile tout de même d’y être indifférent. J’assistais un client dans un appel d’offre pour son nouveau site institutionnel... les offres reçues allait de Wordpress à des trucs propriétaires à base de .net en passant par d’autres trucs exotiques à base de Ruby On Rails.
Il se trouve que ce client a son hébergement chez moi. Et héberger du RoR ou du .net, ce n’est pas tout à fait la même chose que du PHP.
Quand on choisit son logiciel quand on est simple utilisateur, choisir un truc basé par exemple sur Ruby, ça veut dire se bloquer chez les hébergeurs qui acceptent de maintenir un hébergement de ce type à jour. Ce n’est pas aussi courant que pour PHP. Quoi qu’avec la façon d’évoluer de PHP, finalement, cela remet un petit peu de fun dans le métier et le marché !

Pour ma part j’utilise PHP en pro et en amateur donc d’une certaine façon j’ai les 2 visions du langage. Et je dois dire que la simplicité de PHP est effectivement un gros plus pour mes projets amateurs pour lesquels je ne suis pas perdu quand je reviens dessus plusieurs mois après y avoir touché. J’avais pendant un moment utilisé Ruby on Rails sur un projet perso, puis quand j’ai voulu y retouché après quelques mois d’abandon, le projet était de facto devenu obsolète pour cause de nombreuses dépendances soient supprimées soit dépréciées.
Et professionnellement j’y trouve mon compte car PHP a maintenant à peu près tous les outils qu’il faut (tout est toujours perfectible évidemment...). En conclusion je suis donc pour qu’on garde l’aspect « simple » de PHP, en tant que développeur pro et amateur. :)

Hop : en utilisation à l’instant pour les vignettes de navigation sur Orient XXI (qui sont systématiquement recadrées horizontalement ou au carré) :
►http://orientxxi.info

Avant :

http://i.imgur.com/ABOkcDB.png

Après :

http://i.imgur.com/Q2OIxET.png

Un petit squelette pour tester sur des documents pris au hasard sur ton site :

cc @matlap

@speciale : comme tu le vois, si tu passes par |mult{100}%, tu obtiens bien des pourcentages. J’ai préféré la vieille méthode du pseudo-pourcentage en stockant directement la valeur entre 0 et 1 (0.35 est égal à 35%), parce qu’avec des vrais pourcentages, il faudrait que je stocke aussi le symbole % dans la variable, et là c’est super-lourd derrière (si tu veux faire des manipulations mathématiques, tu dois alors d’abord virer le symbole de pourcentage…)

De mon côté j’avais commencé à imaginer un petit plugin « Focus » dont le but est de permettre aux admins/rédacs de définir explicitement le point de focus de chaque image. Libre ensuite à d’autres plugins ou aux squelettes d’utiliser ces x/y lors des recadrage.

@rastapopoulos oui, c’est exactement ça qui me manque. Tu as du code ou des idées ?

Sympa, je l’ai testé avec le petit squelette suivant et une sélection d’images déposées dans squelettes/images :

J’ai bien fait attention à utiliser des images où « le centre d’intérêt » était déporté dans un coin et jamais au centre, et le résultat était souvent bon. Le squelette de test affiche l’image originale réduite à 150 px, puis la même « recadrée » au centre et enfin une version recadrée #automagiquement sur le focus. Du coup, cela permet de mettre en évidence l’action de l’argument focus par rapport à un recadrage au centre.

Idée, je pense que ça serait sympa d’intégrer la fonction image_proportions dans le plugin filtres images du core (elle y a sa place amha). Et puis, cela permettrait aux personnes qui le souhaitent de jouer avec centre_image sans installer image_responsive. Tu en penses quoi @arno ?

#spip_blog #merci :)

yep @b_b et @arno, je suis d’accord, je l’ai dit plusieurs fois : ça commence à faire un certain temps maintenant qu’on a nos fonctions d’images dans un plugin bien propre séparé du core (et fourni en dist), donc pour moi TOUTES les fonctions d’images intéressantes devraient s’y trouver, une fois qu’on les a un peu testé. D’après moi ça n’a pas de sens d’avoir plusieurs plugins différents comme « conteneur » de fonctions d’images (sur la zone/contrib il y avait un plugin de fonctions supplémentaires comme ça). On balance tous les trucs utiles dans le plugin commun.

@nidal j’avais commencé un tout début de truc, mais jamais eu le temps de le faire en entier parce que sur mon temps libre j’essaye de ne pas coder. :)
Mais je l’ai toujours en tête, et j’en ai même reparlé dans le cadre un projet pro cette semaine…

Je ne pense pas que ce soit un truc énorme à faire, peut-être une idée d’atelier en plus pour la rencontre de Toulouse dans 3 semaines.

@b_b : je suis d’accord. La difficulté, c’est de savoir ensuite comment on continue à faire évoluer ces fonctions une fois qu’elles sont dans le core. (La dernière fois que j’ai voulu intervenir dans un plugin_dist, on m’a annulé ma modif en me renvoyant à des séries de tests à valider et tout et tout. Autant dire que ça me fait chier si c’est pour retourner là-dedans.)

Après, en l’occurence, on a spip_proportions stable et bien pratique qu’on pourrait sans difficulté ajouter au core. Mais là il s’agit d’intégrer dedans la fonctionnalité « focus », qui est carrément expérimentale. Je ne sais pas trop comment on gèrerait ça.

@arno ça pourrait pas être géré à base de pipeline(s) ? La fonction image_proportions (générique, dans le noyau) pourrait avoir un pipeline quand on est dans le cas « focus ». Quand y a rien de spécial, ça prendrait le centre par exemple, mais un plugin pourrait s’insérer dedans et définir X et Y. Cette fonction n’aurait pas à connaître qui peut venir changer ça. Et ce serait donc au plugin centre_image de s’insérer dans le pipeline et de définir X et Y suivant sa méthode. Un truc comme ça.

Après on peut aussi se dire qu’il n’y aura toujours qu’une seule manière de trouver un centre de manière automatique, et qu’il y ait une fonction unique (non existante par défaut) qui peut être définie (par un autre plugin donc) et quand elle est définie ça l’utilise pour sortir X et Y.

Mais bon pipeline ou fonction unique, le principe reste le même : « image_proportions » doit juste permettre de s’y insérer (dans le cas « focus » tout du moins), en donnant l’image en question et en permettant de renvoyer un X et un Y.

Yo @arno, je viens de voir que tu viens de commiter un ajout pour permettre la définition explicite manuelle du focus d’une image : Allelujah ! :D

Du coup ça correspond tout à fait au plugin « Focus » que j’avais mollement commencé et dont je parlais. Si ton plugin peut bien être utilisé de manière tout à fait autonome, c’est vraiment ça.

Par contre je ne comprenais pas où tu stockais les coordonnées du focus. Mais après lecture, il semblerait que tu les gardes dans un fichier JSON contenant le MD5 de l’image, c’est ça ?

Du coup, en plus d’être utilisable pour les images « spip_documents » avec l’ajout d’interface que tu as fait, c’est potentiellement utilisable aussi pour d’autres images non-"spip_documents", c’est ça ? (Bon ce sont des cas plus rares hein, mais c’est toujours bien de le savoir.)

#merci !

@rastapopoulos : exactement, ça se base « bêtement » sur l’URL du fichier. Dans l’espace privé, ça récupère toutes les images qui ont un lien .hasbox et un type image/…. Et j’ai ajouté l’exclusion sur les images qui sont intégrées à l’intérieur des articles, sinon ça se met à déconner (à cause des doublons).

Attention : la nouvelle version réclame qu’on utilise la dernière version du plugin-dits medias, et mon plugin contient des motifs pour forcer l’affichage des images de portfolio en grand (150 pixels de large, et non plus les minuscules trucs de 60 pixels).

C’est assez contraignant pour l’instant, en attendant qu’on modifie le comportement natif de medias (j’ai demandé à le faire ce matin, mais aucune réponse sur spip-dev).

Dans l’interface privée, un javascript va attaquer les logos et les documents joints :

http://i.imgur.com/pvTiwUm.jpg http://i.imgur.com/eWW5CuI.jpg

Sur la seconde image, on voit bien la différence avec l’actuel : les vignettes sont de très bonne taille (ça donne une impression d’interface carrément plus moderne).

Le javascript récupère chaque image, et à chacune ajoute un petit cadre vert (indiquant que le centre d’intérêt est chargé), et une croix à l’endroit du centre d’intérêt automatique.

Si on veut corriger, c’est immédiat : on prend la croix, on la fait glisser vers le centre d’intérêt et voilà, c’est corrigé. Je vois pas comment faire plus simple.

Autre question : le filtre « image_recadre » du noyau sait aussi prendre en entrée un ratio maintenant ("3:2, +").
(Et du coup image_proportions est-il d’ailleurs toujours pertinent, peut-être vaut-il mieux mutualiser puisque la fonction du noyau sait déjà le faire.)

Mais du coup il manque le fait de pouvoir donner des pourcentages (ceux de centre_image) dans le troisième argument $position, il me semble, c’est ça ? (Car je crois que ça ne connait que top, left, etc.)

Et un corollaire : dans ce genre de recadrage, si on donne le point de focus, c’est pour qu’il soit « à peu près » au centre une fois le recadrage terminé. Mais suivant où il est placé, ce n’est pas forcément pile au centre. S’il est proche d’un bord, ben ça doit s’arrêter au bord.

C’est assez contraignant pour l’instant, en attendant qu’on modifie le comportement natif de medias (j’ai demandé à le faire ce matin, mais aucune réponse sur spip-dev).

( je ne vois pas ton message sur spip-dev)

Oui, je suppose qu’il faudrait aussi améliorer image_recadre, mais encore une fois c’est une question pratique : image_proportions est chez moi et je peux le patcher instantanément. Dans le core je ne sais plus trop si j’ai le droit de patcher ou si je vais me faire jeter.

Pour ta dernière remarque, oui c’est pris en compte : on recadrer au plus proche du centre d’intérêt, mais ça ne va pas forcément le placer au centre si ce point est près du bord. Mon code qui fait ça n’est pas d’une compacité folle, c’est parce que ça laisse la logique mathématique plus visible comme ça :-))

@ben : je crois que j’ai posté avec la mauvaise adresse email, mon message n’a pas dû passer. Je viens de réexpédier avec mon adresse usuelle.

Ah et aussi en rapport : ce plugin jQuery qui recadre en javascript suivant le focus de chaque image (qu’on précise dans le code de l’image) :
▻http://seenthis.net/messages/289821

Cela peut être complémentaire pour générer moins d’images, et aussi pourquoi pas pour définir les hauteurs d’images en « em » afin d’être alignées sur la grille typo et les largeurs sur la grilles des colonnes (qui peut être en %), et donc pas toujours la même proportion suivant l’écran.

@rastapopoulos : j’ai un script remplir_image.js qui fait ça aussi. Mais l’avantage avec image_proportions et les nouvelles subtilités d’image_responsive (et <picture>), c’est qu’on n’attend plus sur javascript pour charger et afficher les images. Avec Chrome pour l’instant (et Firefox le mois prochain), c’est incroyablement plus réactif que quand on compte sur jQuery pour faire des calculs et des affichages.
►http://seenthis.net/messages/264068

@arno pour le core, logiquement, tu as le droit de patcher tant que ça ne casse rien à l’existant.

Si on veut faire « propre », je crois qu’il y a deux méthodes pour ça :

– Soit la fonction a une batterie de tests unitaires. Et donc tu peux modifier dans la branche stable (3.0), tester si ça renvoie toujours les bons trucs pour les anciens comportements, et si tests ok, commiter. Si on part du principe que les tests unitaires sont complets, alors tant que ça renvoie ok, toute modif peut être commitée sans danger.

– Soit ya pas de tests, ou bien tu n’as pas le temps de comprendre comment les faire tourner (hihi). Dans ce cas, tu peux modifier dans la branche dev (3.1) ! Tu testes sur tes cas à toi (pas les tests unitaires normalisés du coup), et si tu penses que c’est bon, tu envoies en 3.1. Du coup c’est public et tu peux demander à d’autres de tester ton ajout. Si plusieurs personnes pensent que c’est bon (ou que personne ne répond pendant longtemps :D) : tu reportes ta modif dans la branche stable (3.0). Un « backport ».

Ça ce sont les deux manières qui normalement devraient toujours marcher. Sinon c’est pas gentil. :)

Après, au-delà, il est possible aussi de commiter directement en 3.0 sans tests unitaires, et reporter en 3.1 (c’est moins logique mais c’est logique quand on est dans un projet réel qui utilise la stable !). Là faut juste être sûr de soi, de ne rien casser.

Enfin, mon avis purement personnel est que ce serait super que tu améliores image_recadre du noyau avec ces ajouts (notamment le fait de pouvoir lui passer les coordonnées précises), et que ça soit ainsi mutualisé dans un seul endroit (le plugin d’images du noyau, commun à tou⋅te⋅s).

Un truc qui me questionne : je vois que ça enregistre les coordonnées calculées ou forcées dans local/ ... du coup, si on vide le cache des images, on perd les coordonnées qu’on avait forcées à la mano en déplaçant la croix ?

Est-ce qu’il ne vaudrait pas préférer, si on est dans le cas d’un document eregistré dans la table spip_documents, ajouter 1 ou 2 champs pour stocker les coordonnées ?

Là l’avantage c’est que ça marche pour n’importe quelle image, même quand c’est pas un document SPIP (les logos par exemple, mais ça pourrait être d’autres choses).

Mais par contre oui, l’emplacement des JSON posent clairement un problème : une vraie information pérenne ne DOIT PAS se placer dans un dossier temporaire. :D

Pour rappel, SPIP à 4 dossiers variables : 2 fixes, et 2 temporaires. Et dans le même temps : 2 accessibles, et 2 inaccessibles.

Les noms des dossiers sont très mal choisis mais restent là par compatibilités. Mais dans le code les noms sont beaucoup plus clairs et logiques :

– permanent_accessible : IMG
– permanent_inaccessible : config
– temporaire_accessible : local
– temporaire_inaccessible : tmp

En conséquence, les infos de positions sont permanentes, et accessibles. Et donc si on ne veut pas les enregistrer en base, mais dans des fichiers, alors elles devraient aller dans IMG, pas dans local.

Et peut être en EXIF si le format d’image le supporte ?

et +1 pour image_proportions dans SPIP directement (ou dans filtres_images) @b_b, @arno

@marcimat non non : image_recadre fait déjà les proportions (et je l’utilise régulièrement). Donc pas besoin d’ajouter une fonction pour ça à mon avis.

Au lieu de faire |image_passe_partout|image_recadre maintenant je fais |image_reduire{taille maximum que je veux}|image_recadre{16:9,''}.

Mais ce qu’il faudrait du coup, c’est améliorer image_recadre qu’on a déjà, pour lui intégrer la possibilité de définir le centre manuellement et précisément dans l’un de ses paramètres.

Ce plugin m’intéresse particulièrement en conjonction avec le plugin image_responsive, plus précisément dans ce qui était décrit dans le premier post avec la fonction image_proportion.
Cependant,
#FICHIER|image_proportions{16,9,"focus"}|image_responsive{320/640,1,0}
avec ou sans guillemets à focus, ne semble rien donner de manière automatique. Si l’on définit le focus de l’image, cet argument semble inutile.
Je suis en SPIP 3.0.20, Filtre image_responsive en 6.4.1 et Centre image en 0.5.1.

Merci pour tous ces plugins et pour le coup de main :)

J’ai ajouté en SPIP 3.1, en espérant ne rien n’avoir cassé, la possibilité d’utiliser le centrage avec la fonction |image_recadre, du plugin fonctions_images qui est fourni par défaut avec SPIP

Donc, on activant ce plugin, sans forcément avoir le plugin image_responsive, on peut utiliser des recadrages en centrant sur le point d’intérêt, de la sorte :

[(#LOGO_ARTICLE|image_recadre{16:9, -, focus})]

ou encore, pour avoir une taille spécifique

[(#LOGO_ARTICLE|image_recadre{200:80, - focus}|image_reduire{200, 80})]

Il y a aussi focus-center comme dans image_proportions.

@marcimat \o/

J’ai une question : je viens de rajouter une invalidation du cache (▻http://zone.spip.org/trac/spip-zone/changeset/97747) pour pouvoir voir l’effet d’un changement du point d’intérêt immédiatement.
Du coup, j’ai étudié un peu le code et j’ai été sidéré de voir qu’au lieu de sauvegarder dans la base, c’était un fichier .json qui était créé pour enregistrer la position du point d’intérêt.
Qu’est-ce qui a présidé à ce choix technique ?

Je me suis fait une fonction sympa :

Et si l’image est plus petite, elle est affichée au centre par défaut, mais on peut indiquer sa position.

Qu’est-ce qui a présidé à ce choix technique ?

@realet Peut être parce que ça prend en compte les logos, qui ne sont pas stockés en BDD :)

@marcimat Mais oui bien sûr, c’est évident maintenant que tu le dis ;-)

J’en parle ici un peu ▻http://medias.spip.net/medias/video-tutorials/article/affichage-ordre-et-point-d

Bonjour. Le plugin medias est-il toujours nécessaire ? En l’état je ne peux pas changer le point de focus sur le logo de l’article car le clic provoque l’ouverture de la mediabox. Est-ce lié stp ?

@vlentz Tu dois cliquer sur la croix et la déplacer, pas cliquer n’importe où sur l’image directement.

Merci pour le tip. J’ai réussi à le faire sur Firefox (mais plus maintenant) et pas du tout sur Chrome.

Merci pour ce plugin qui s’avère rapidement être indispensable.
Une chose à préciser dans une éventuelle future documentation (c’est peut-être mentionné dans le fil de discussion mais j’ai pas tout relu) : le point d’intérêt n’est pris en compte que si le filtre image_recadre est appliqué en premier à l’image.

Ceci fonctionne :
[(#LOGO_PATATE|image_recadre{4:3, -, focus}|image_machin|image_truc)]

Mais pas cela :
[(#LOGO_PATATE|image_machin|image_truc|image_recadre{4:3, -, focus})]

Oui et on disait avec @marcimat que peut-être ça pourrait être bien de garder en mémoire cette info au fil des modifs d’une image OU de garder en mémoire la toute première image source quand il y a une suite de filtres d’images d’affilée, et SI la dernière chose avant le « recadre » a les mêmes dimensions que l’image d’origine, alors on peut recadrer avec le même centre, même 12 filtres plus loin.

Bon, en attendant, faut bien le mettre en premier…

Y’a t-il un moyen de tester le « focus » si il a été utilisé ou pas ? Si ça valeur par défaut a été changée ?

La doc : ►https://www.paris-beyrouth.org/Plugin-centre_image

@fil (ou) on est tous tout avec toi.

Bien alors, bilan des courses : le serveur a en effet totalement crashé…

Un petit blanc de 6 heures,…

Pas sûr que tout soit en place : p. ex., pas d’accès par compte, style senthis.net/people/fil
plus de personnalisation des fonds de page

#merci pour le boulot

senthis non, mais ►http://seenthis.net/people/fil fonctionne

Par contre comme le serveur d’origine est mort ou presque, j’ai été obligé de migrer toutes les données et l’installation vers une autre machine — et je n’ai pas encore réinstallé le moteur de recherche sphinx…

Les fonds, je viens de les remettre :)

correcteur d’orthographe, grrr.

sinon, à l’instant, un truc comme ça

https://dl.dropbox.com/s/xhq2563akj9a07j/ST_upgrade20141004.jpg

Yes !

la suite…demain

Mhh... je ne sais pas si c’est lier, mais l’URL qui de twitter fait ouvrir une page seenthis ne marche pas...
 :-(
Quand on clique sur le lien, ça donne cela :

http://i.imgur.com/WGaF2tr.jpg

@cdb_77 ce problème est transitoire, et devrait être réglé d’ici quelques heures ; à vérifier donc

@simplicissimus j’ai réinstallé un serveur sphinx pour le moteur de recherche, ça a l’air bon (à vérifier aussi !)

#étrange : je découvre ce message à l’instant, ça explique pour le /all :-) #étrange parce que je n’ai pas (encore) eu de souci pour cette migration. Sauf pour l’update de grub... une fois... mais à part ça, jamais eu de truc insurmontable. Mais seenthis doit utiliser des trucs et astuces particuliers forcément...

(au fait, le dépôt « squeeze-lts » ne t’a pas convaincu de continuer avec Squeeze ? Ou bien peut-être en as-tu eu marre d’être scotché à PHP 5.3 ?)

Problème résolu (twitter). MERCI Fil !

Ah oui en effet, on a perdu : les étoiles, les follow, les nouveaux inscrits, etc, arrivés entre samedi 4 oct. 5h00 (date de la dernière sauvegarde de la base) et dimanche 5 oct. 5h00 (heure de remis en ligne du site sur le nouveau serveur).

Fort heureusement on n’a perdu aucun message (mais c’est pas passé loin : je suis allé les repiocher dans l’export expérimental).

Quelques précisions supplémentaires :

-- j’ai suivi le conseil de @stephane qui disait, après le trou de bash, qu’il était souhaitable de faire ses mises à jour régulièrement de façon à ne pas être en panique avec un vieux système quand un problème de sécurité se présente

-- je n’ai pas suivi @lazuly qui me conseillait de ne pas tenter de truc dangereux un samedi soir

-- ce n’est pas la mise à jour Debian qui a fait crasher le serveur, c’est le reboot après la mise à jour : la machine n’a jamais su retrouver son disque et redémarrer correctement, elle plantait avant même de lancer le noyau linux

-- @stephane, appelé en renfort au milieu de la nuit, est parvenu à lancer la babasse en mode « secours » et à monter le disque ; j’ai ainsi pu récupérer ce qui manquait comme données, et réinstaller seenthis sur un autre serveur ; j’ai aussi configuré le serveur nginx du mode secours en proxy vers le nouveau serveur, et finalement @arno a modifié les DNS

-- ce matin j’ai installé sphinx sur le nouveau serveur, ainsi que le plugin autoembed qui était porté disparu.

Au final, donc, @seenthis a changé de serveur, et est temporairement hébergé par @rezo ; ouf !

DeBleu tout ce que vous parvenez à faire tandis que moi je dors !

C’est quand on lit le résumé de fil que comme simple « utilisateur » totalement « codes-analphabètes », on se sent vraiment tout petit petit.

Tu as rencontré, donc, le souci de la mise à jour de Grub, à ce qu’il me semble. Il pose la question pourtant, faut juste répondre le moins mal possible :-D

Ceci dit, squeeze-lts permettait d’être à jour encore quelques temps, pour ce qui est des composants systèmes essentiels. Et... tu devrais virtualiser, ça te permettrait de faire des tests :-p

(Ceci dit, bravo pour l’efficacité de la remise en ligne !)

Un petit ban bourguignon (entre autres) version Deep Purple…
▻http://www.youtube.com/watch?v=Nm99vVTX9Gc

C’est quand même un site qu’on utilise (et qu’on aime) beaucoup :)

Pour la mise à jour de grub j’ai répondu « oui » et stephane a vérifié que les UUID étaient bien référencés dans fstab, donc je suis pas sûr que ce soit ça l’origine du problème.

https://dl.dropbox.com/s/et8b6jbeen7o2zn/crash%20dedibox%20seenthis.png?dl=0

squeeze-lts ne couvre pas tous les paquets de la distribution en terme de sécurité. Par exemple xen ne l’est pas.
J’ai aussi fait des migrations « en urgence » récemment pour m’assurer que la dernière faille xen serait bien couverte par des mises à jour de sécurité. La blague, c’est que squeeze n’était pas concerné par cette faille, wheezy si 8)

@fil @lazuly a tout à fait raison et j’ajoute : ne jamais faire une migration (même d’une Debian, sans doute le système le plus simple à migrer) sans avoir avant soigneusement testé la console (ses mots de passe, le Java qu’elle veut dans le cas d’Online), etc.

Apparemment, le HTTPS n’est pas reparti (donc, notamment, pas l’API). C’est bien ça ?

En fait il n’y a pas de https du tout sur le serveur où on est maintenant hébergés… celui qui héberge aussi rezo.net etc. Ce n’est pas par mauvaise volonté, mais je n’ai pas la compétence pour installer ça, je n’ai jamais compris ces histoires de certificats multi-domaines.

@fil ▻http://www.bortzmeyer.org/auth-x509-plusieurs-noms.html CAcert gère (bien) le Subject Alternative Name de X.509.

je vais voir avec benjamin, mais je n’aime pas du tout l’idée qu’on donnerait aux visiteurs Firefox un panneau de la mort
« This Connection is Untrusted »

Si tu as un certificat qui va bien, faut « juste » avoir plusieurs IPs, pas obligé d’avoir un certificat avec plusieurs domaines dedans (quoique c’est bien aussi, mais faut prévoir à l’avance tous les domaines...).

#NetBeans aime bien apigen : ▻http://plugins.netbeans.org/plugin/34676/php-apigen-api-documentation-generator

attention il reste encore un bug embêtant pour les sites non utf8

#spip_blog