The Daily Shaarli
@Oros :
Pour http://kosmogonia.fr/ et https://switchy.o2switch.net:2083/ le wget fonctionne bien.
Ils sont pourtant dans le même réseau (/24) que les shaarlis auxquels tu n'accèdes pas. Donc, ce n'est pas un problème de routage. Ce n'est très probablement pas un filtrage global à l'entrée du réseau d'o2switch (dans ce cas-là, on bloque /24 par /24, en général).
Quand tu dis que tu n'arrives pas à accéder, ça veut dire quoi ? Est-ce que la poignée de main TCP s'effectue ou alors tu n'obtiens même pas de réponse à ton TCP SYN ?
Pour 109.234.161.33, 109.234.161.21, kosmogonia.fr, switchy.o2switch.net, j'ai :
Oui, c'est normal. Par défaut, l'implémentation GNU/Linux de traceroute bosse au-dessus d'UDP. o2switch bloque cela. J'ai le même résultat que toi. En revanche, traceroute -T -p 443 (TCP + port 443) fonctionne impec.
@Oros :
Genre warriordudimanche.net ou lien.shazen.fr ne me retournent aucune réponse.
T'arrives à wget http://kosmogonia.fr/ ou https://switchy.o2switch.net:2083/ depuis ton serveur ? Un traceroute / mtr / traceroute -T -p 443 ?
J'ai voulu tester avec RIPE Atlas, mais il n'y a pas de sonde participante dans le réseau d'Edis.
$ dig +short warriordudimanche.net
109.234.161.33
$ dig +short lien.shazen.fr
109.234.161.21
$ whois 109.234.161.33
[…]
route: 109.234.161.0/24
descr: o2switch Internet Routing
origin: AS50474@Liandri :
Du coup, si vous souhaitez un ajout ou retrait de la river, vous pouvez me contacter par mail ou Shaarli interposé, mais je me laisse le droit de validation finale. Point.
C'est l'évidence même, donc OK pour moi.
@Oros :
Là où j'ai besoin d'aide c'est de trouver si dans le lot, il y en a où l'erreur était temporaire ou s'ils ont changé d'URL.
Je m'en suis occupé.
Au début, on a 208 shaarlis marqués invalides.
Combien y a-t-il de domaines non associées avec une IPv6 ou une IPv4 ? Boucle for + commande `host'.
Quel contenu est pointé par ces 78 URLs ? Allons-voir avec wget --quiet --max-redirect=0 --connect-timeout=10 --tries=1 -O - (un seul essai, on tente d'établir la connexion TCP durant 10 secs maximum, on refuse les redirections HTTP). Quand on a une réponse, on grep « pubDate » afin de nous assurer qu'il s'agit d'un flux RSS (et de voir la date du dernier shaarli publié).
10 shaarlis sortent avec le code retour 0. C'était donc une erreur temporaire ;
15 sortent en 4 : timeout TCP. Ça peut être dû à une IPv6 foireuse. On applique un wget -4 sur cette liste : on récupère aucun shaarli, donc c'est tout des shaarlis disparus ;
11 sortent en 5 : erreur x509. On utilise wget --no-check-certificate. 9 URL passent en code retour 8. 2 URLs sont des shaarlis OK avec un certificat x509 invalides ;
37 sortent en 8 : erreur HTTP. + les 9 URL du point précédent. 46 URL en tout. Ça peut être une redirection. On utilise wget sans interdire la redirection + grep 'Emplacement' | tail -n 1 pour choper l'URL de destination et l'ajouter à la liste.
wget | grep 'erreur'. On a 16 URLs OK, 30 erreurs (404, 403, 410, 500).
5 présentent un résultat qui n'est pas du RSS. J'ai vérifié à la main : soit le site web entier n'existe plus, soit je n'ai pas trouvéé de lien vers le shaarli (abandon de shaarli probable).
Au final, dans la liste https://github.com/Oros42/shaarlis_list/blob/master/shaarlis_HS.json , seuls les shaarlis suivants fonctionnent et peuvent être ajoutés à la rivière :
Les shaarlis suivants ont besoin d'un ajustement avant de rejoindre la rivière :
