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

[Philippe Verdy]

Voir aussi cette page de doc de wget au sujet des "timestamps".

https://www.gnu.org/software/wget/manual/html_node/Time_002dStamping-Usage.html

Et la note concernant FTP:

https://www.gnu.org/software/wget/manual/html_node/FTP-Time_002dStamping-Internals.html#FTP-Time_002dStamping-Internals


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

> 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/dd539f38/attachment.htm>