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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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). >>> >>> >>>
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
