[OSM-talk-fr] résumés des problèmes majeurs du rendu osm-fr et osm.org

Philippe Verdy verdy_p at wanadoo.fr
Sam 11 Aou 03:57:30 UTC 2018


Une piste à propos de Wget (voir http://www.gnu.org/software/wget/) qui
indique :
 "Uses local file timestamps to determine whether documents need to be
re-downloaded when mirroring"

Note: "wget" peut utiliser HTTP ou FTP, mais les serveurs FTP sont connus
pour ne pas afficher la date UTC mais uniquement la date locale du serveur
source : le client FTP ne sait pas quell est la date locale du serveur ! En
HTTP la précision du fuseau est normalement obligatoire dans les entêtes
MIME, ce n'est pas le cas de FTP. La note ci-dessus peut indiquer un
changement pour qu'en HTTP, wget se comporte comme en FTP (et cela suppose
donc alors que le client positionne d'abord sa date locale avec le fuseau
horaire du serveur interrogé avant d'utiliser "wget")... Ce serait bien de
vérifier ça si wget a bien été modifié sur la façon d'interpréter les dates
indiquées par le serveur distant: le serveur distant étant en HTTP ici, il
doit préciser ce fuseau, mais l'info est perdue/ignorée en cours de route.


Le sam. 11 août 2018 à 05:45, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> Il toutefois que la synchro des diffs est basée sur les dates rapportées
> par  https://tile.openstreetmap.org/cgi-bin/debug
> Il n'est pas clairement précisé dans ce "debug" comment est calculée cette
> date : est-ce une date "UTC" ou une date locale ? Sachant que les
> déménagement d'un serveur de Londres à Amsterdam change la date locale d'1
> heure avec le changement de fuseau horaire. Reste à savoir de quel serveur
> viennent ces diffs sources: ils étaient générés à Londres sur l'instance
> principale, qui a été déménagée à Amsterdam.
>
> Un des outils d'Ubuntu a pu changer la date affichée par défaut pour
> passer de l'heure UTC à l'heure locale du serveur...
> Ce serait donc bien lié au déménagement d'une partie des serveurs. Mais le
> bogue serait lié à une soucis de compatibilité d'un des utilitaires
> d'Ubuntu mis à jour.
>
> Cela n'explique pas complètement pourquoi "Vial" (qui est resté en
> Allemagne) n'est pas affecté par le changement de date locale sur le
> serveur de base de données principal (déménagé de Londres à Amsterdam),
> mais on doit noter que lui n'a pas encore eu la mise à jour vers Ubuntu
> 18.04.
>
> On doit chercher du côté de l'outil de téléchargement des diffs utilisé
> sur les serveurs esclaves (probablement "wget"). Ce serait un bogue de
> compatibilité de cet outil dans la façon de gérer et rapporter les dates
> (locales ou UTC) : le serveur principal omet de préciser son fuseau horaire
> (mais si le protocole est HTTP ou HTTPS, normalement ce fuseau horaire est
> précisé dans les entêtes HTTP), et le script sur le serveur escalve faisant
> la requête HTTP interprète alors la date de façon différente en Ubuntu
> 18.04 si le fuseau n'est pas précisé (16.04: supposerait que la date est
> indiquée en UTC; 18.04 : supposerait que la date est indiquée dans la date
> locale du serveur local)
>
>
>
>
>
> Le sam. 11 août 2018 à 05:27, Philippe Verdy <verdy_p at wanadoo.fr> a
> écrit :
>
>>
>> le serveur utilisé actuellement dépend de la position géographique
>>> principalement mais peux aussi changer en cas de surcharge,
>>> info vérifiable en temps réel avec
>>> https://tile.openstreetmap.org/cgi-bin/debug
>>> les 2 serveurs ok : Yevaud et Vial
>>> les 2 serveurs affectés : Scorch et Rhaegal
>>>
>>
>> Les 4 serveurs de rendus d'OMS.org sont "yevaud", "vial", "scorch", et
>> "orm" (et non pas "rhaegal" ou c'est un ancien alias).
>> - "Yevaud" est encore à Londres (à l'UCL), mais n'a pas eu la mise à jour
>> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
>> - "Vial" est en Allemagne (à Hetzner), mais n'a pas eu la mise à jour
>> d'Ubuntu 16.04 vers 18.04, il n'est pas affecté par le bogue
>> - "Scorch" est en France (à Roubais chez OVH): il est affecté par le
>> bogue, Ubuntu été mis à jour de 16.04 vers 18.04
>> - "Orm" était parmi les serveurs déménagés de Londres (à l'UCL) à
>> Amsterdam (chez Equinix): il est affecté par le bogue, Ubuntu été mis à
>> jour de 16.04 vers 18.04
>>
>> La mise à jour d'Ubuntu n'explique pas le rendu incorrect et la
>> persistence de ways parasites (marqués comme supprimés dans les "diffs"
>> mais qui sont tracés avec une partie des noeuds conservés par ailleurs). Il
>> semble que l'impact de cette mise à jour serait que les fichiers "diffs"
>> seraient traités alors qu'ils ne sont pas complètement téléchargés : le
>> traitement se fait sur une partie seulement des changesets qui sont alors
>> tronqués.
>>
>> Ce n'est apparemment pas un problème de base de données (sur la base de
>> données esclave), mais des outils de téléchargement et synchronisation de
>> répertoires (je ne sais pas si cela se fait par "rsync" ou pour un script
>> shell avec "wget", mais cet outil ne semble pas correctement synchronisé
>> avec l'outil qui va ensuite traiter les nouveau diffs reçus et "prêts" pour
>> les charger sur la base esclave, une ancienen opération qui était bloquante
>> semble être devenue asynchrone et il manque une étape de validation des
>> téléchargements de diffs effectivement terminés avant de placer ces
>> fichiers dans la file d'attente à traiter pour l'import).
>>
>>
>>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20180811/5b64557c/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr