28 03 | 2013

Nouvelle planète auto-hébergement

Written by Tanguy

Classified in : Homepage, Auto-hébergement, Debian-FR, Libre, April

Comme prévu, je viens de remplacer l'ancien Planet auto-hébergement par une nouvelle version basée sur Planet Venus sur mon propre serveur.

La Terre entourée d'un petit maillage de fibres optiques

Vous pouvez donc maintenant venir découvrir la nouvelle Planète auto-hébergement, qui propose :

Si vous tenez un blog ou vous parlez d'auto-hébergement, il n'est pas trop tard pour me l'indiquer !

La configuration de Planet Venus est intéressante, et il faudra sans doute que je rédige un article synthétisant mon expérience avec ce logiciel, mais j'attends d'abord que les débats actuels se calment un peu pour pouvoir finaliser un autre projet de Planète Catholique…

20 comments

thursday 28 march 2013 à 15:04 MerMouy said : #1

Le flux ne semble pas être valide, et du coup, j'arrive pas à l'ajouter à mon lecteur...
http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fplanet.auto-hebergement.fr%2Frss.xml

thursday 28 march 2013 à 15:47 Nono said : #2

J'allais dire exactement la meme chose que MerMouy : http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fplanet.auto-hebergement.fr%2Frss.xml

Flux invalide, impossible à ajouter ...

thursday 28 march 2013 à 15:51 TuxGasy said : #3

C'est normal que j'arrive à un formulaire sur le lien http://planet.auto-hebergement.fr/
?

thursday 28 march 2013 à 16:08 Tanguy said : #4

@TuxGasy : Ça c'est parce que tu utilises un résolveur DNS qui continue à conserver l'adresse de l'ancien serveur de façon anormale, alors qu'elle est censé avoir expiré depuis longtemps. Attends encore un peu ou change de résolveur pour en prendre un qui respecte la norme.

@Nono, @MerMouy : C'est une erreur qui devrait être sans conséquence, mais je vais la corriger. Il est visiblement obligatoire de préciser une adresse électronique pour les auteurs d'articles, avec RSS : pour ceux qui n'en précisent pas, je vais simplement en indiquer une syntaxiquement valide mais sémantiquement explicitement invalide à la place… En attendant, vous pouvez toujours utiliser le flux Atom, qui est valide.

thursday 28 march 2013 à 16:41 ph said : #5

Bravo !

J'apprécie le lien direct vers l'article qui est publié dans l'ATOM.

thursday 28 march 2013 à 16:44 Tanguy said : #6

@ph : Ça c'est un des avantages de Planet Venus par rapport à BilboPlanet qui ajoute une redirection à lui pour effectuer un comptage.

thursday 28 march 2013 à 16:48 Thomas said : #7

Salut,

Je voulais juste signaler une petite erreur parmi la liste des sources. Il s'agit de "Halpanet" et non "Halplanet".

thursday 28 march 2013 à 17:05 Tanguy said : #8

@Thomas : Oups. Corrigé.

thursday 28 march 2013 à 18:33 -Fred- said : #9

Bonjour et déjà merci.

Pour ce qui est de mon blog (blog.sujets-libres.fr), tout les articles que j'y publie sont relayés sur le planet (la planète ???) auto-hébergement, y compris ceux qui n'ont rien à voir. Je pense que ça pollue plus qu'autre chose.

J'ai mis en place une catégorie exprès pour ça : http://blog.sujets-libres.fr/?cat=84
Tout ce qui y figure a sa place sur le planet.

thursday 28 march 2013 à 19:19 Tanguy said : #10

@-Fred- : En effet, et c'est ce que j'avais pris, sauf que j'avais fait une erreur au début, qui est restée à cause du cache de Planet Venus. Ça devrait être corrigé à la prochaine mise à jour.

thursday 28 march 2013 à 21:18 AgentSteel said : #11

Sympa ce nouveau planet, bien plus agréable visuellement que l'ancien.

sunday 07 april 2013 à 22:44 Comète said : #12

Bonjour,

Le flux RSS ne semble pas valide

http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fplanet.auto-hebergement.fr%2Frss.xml

Je n'arrive pas à ajouter le flux ATOM (valide) non plus dans mon lecteur (Kriss Feed).

tuesday 09 april 2013 à 12:49 Tanguy said : #13

@Comète : Effectivement, c'est curieux, ça vient d'un attachement généré par Planet Venus alors qu'il n'est pas présent dans le flux d'origine. Mais ça ne devrait pas poser de problème normalement ça…

tuesday 07 may 2013 à 17:12 nikonoel said : #14

Merci pour ce planet que je viens de (re-) découvrir :-)
Bien utile pour quelqu'un qui se (re-)met à l'auto-hébergement!

friday 20 september 2013 à 23:44 Ouate? said : #15

Je reviens sur le commentaire #12, j'utilise aussi Kriss feed pour lire mes flux et j'ai également un problème. Je n'ai pas contacté tontof pour ça car le problème semble peut-être déjà ciblé : il s'agit d'un problème de compression entre celui qui envoie la requête et celui qui envoie la réponse. Visiblement, le site de la planète n'envoie qu'en gzipé, tandis que kriss utilise curl par php avec un encoding complet et ne fait pas de décompression (peut-être un problème de header).
Tanguy, qu'en penses-tu ?

saturday 21 september 2013 à 13:29 Tanguy said : #16

@Ouate? : Ah, je vois. J'ai fais en sorte de proposer le flux gzippé ou non selon ce que demande le client, mais s'il ne précise rien ça le fournit gzippé. Deux solutions du coup : faire en sorte de préciser « Accept-Encoding: identity », ou demander http://planet.auto-hebergement.fr/rss.xml.raw qui est l'adresse exacte du flux non compressé. Mais c'est dommage, ça utilise pas mal de bande passante en plus pour rien…

saturday 21 september 2013 à 17:42 Ouate? said : #17

Super merci Tanguy; ok, on aurait donc une une double compression qui ne plaît pas à curl sous php ? Car le serveur web le fait très probablement à la volée (retour dans le header vu "content-encoding" à x-gzip ou gzip selon identity ou gzip explicitement dans le accept-encoding), du coup je me demande si c'est nécessaire de le zipper a priori - sauf si la machine est "limitée". Enfin j'avoue avoir trouvé ce comportement étrange avant cette information.

En tout cas, ça serait en effet dommage de demander et fournir par défaut sans compression, surtout quand on s'auto-héberge... ça fait mal.

saturday 21 september 2013 à 19:25 Tanguy said : #18

@Ouate? : Il n'y a qu'une compression simple. En revanche ce n'est pas du tout fait à la volée : pour économiser du temps processeur, je pré-compresse les pages à chaque mise à jour de la planète. Il y a donc deux fichiers, rss.xml.raw et rss.xml.pgz (pour « pré-gzippé »). Grâce au mod_negociation du Serveur HTTP Apache, quand on demande rss.xml, qui n'existe pas vraiment, on obtient selon ce qu'on accepte comme codage le premier (Content-Encoding: identity) ou le second (Content-Encoding: gzip). L'ennui donc, ce que quand on ne précise pas ce qu'on accepte, Apache fournit visiblement le second, avec tout de même l'en-tête Content-Encoding correctement positionné à gzip. Mais si le client n'a pas prévu de décompresser, c'est inutilisable évidemment.

sunday 22 september 2013 à 11:08 Ouate? said : #19

Parfait, donc en cherchant ailleurs je me suis aperçu que j'ai fait fausse route. Je suis parti du principe que php utilisait curl; dans le doute j'ai regardé la présence du paquet php5-curl... qui n'y était plus (aurais-je été trop zélé dans une phase de ménage ?).
Bref, c'est l'alternative de libxml qui pose problème et qui donc ne faisait pas la décompression. Je vais soumettre le problème à tontof (j'utilise la version 8 de kriss feed, et j'ai pallié ça avec une vilaine petite verrue)... en tout cas, merci de ton temps et de ton aide. :-)

sunday 22 september 2013 à 13:44 Ouate? said : #20

J'oubliai, pour les personnes qui utiliseraient également kriss feed et qui sont intéressées par le sujet (le but étant de me passer du consommateur liferea sur mon pc "courant" et passer par mon petit serveur auto-hébergé), le bug peut être suivi à : https://github.com/tontof/kriss_feed/issues/49

Write a comment

What is the first letter of the word ccnid? : 

Archives