Category Archives: Entretien

Une année de progrès en matière d’infrastructure : mise à jour pour 2023 / 2024 de l’ingénieur chargé de la fiabilité des sites

En tant que Senior Site Reliability Engineer (SRE) de la Fondation OpenStreetMap, je me suis concentré sur l’efficacité, l’amélioration de la résilience et la mise à l’échelle de notre infrastructure pour soutenir la croissance continue du projet OpenStreetMap au cours de l’année écoulée. De la migration vers le cloud à la mise à niveau des serveurs, nous avons apporté plusieurs améliorations depuis l’année dernière afin de mieux positionner l’infrastructure d’OpenStreetMap pour répondre à ces défis de résilience et de croissance.

Améliorer les services aux utilisateurs

Services de rendu améliorés

L’infrastructure de rendu des tuiles a fait l’objet d’améliorations notables, notamment des optimisations matérielles et logicielles, une expiration plus rapide du cache des tuiles pour lutter contre le vandalisme, et l’automatisation pour bloquer les utilisateurs qui n’attribuent pas les tuiles OSM. Les tuiles à faible zoom sont désormais rendues quotidiennement, ce qui améliore les performances et permet un retour d’information plus rapide. Le service de tuiles est largement utilisé et répondre à la demande est un défi permanent.

Nouveau service d’imagerie aérienne

Lancement d’un nouveau service d’imagerie aérienne qui prend en charge les COG GeoTIFF. Le service héberge désormais aerial.openstreetmap.org.za qui s’appuie sur 16 To d’images à haute résolution. Le nouveau service facilite l’hébergement d’images supplémentaires à l’avenir.

Transition vers des alternatives à Gmail et Google Docs et réduction des spams

Après avoir été confronté à d’importants problèmes de spam avec l’espace de travail Google de l’OSMF, j’ai migré les services de messagerie électronique de l’OSMF vers mailbox.org. Cela a permis de réduire le volume de spam et d’améliorer l’efficacité administrative. Nous sommes également en train de transférer les données historiques d’OSMF sur Google Docs vers un service auto-hébergé.

Faire face aux attaques DDoS et au vandalisme

Cette année, nous avons été confrontés à plusieurs attaques par déni de service distribué (DDoS), y compris un incident majeur de DDoS contre rançon, qui a été signalé aux autorités policières. Ces attaques ont mis à l’épreuve notre infrastructure, mais nous avons mis en œuvre des mesures pour renforcer notre résilience et mieux nous protéger contre les menaces futures.

Nous avons également fait face à des actes de vandalisme à grande échelle qui ont affecté les services d’OpenStreetMap. Grâce à la réaction rapide et aux ajustements effectués par l’équipe des opérations, nous avons renforcé notre infrastructure afin de mieux gérer les abus et d’assurer un service continu.

Hébergement de Planet Data sur AWS S3

Avec l’équipe opérationnelle d’OpenStreetMap, j’ai transféré l’hébergement de nos données planet sur AWS S3 avec des miroirs dans l’UE et aux États-Unis, ce qui nous permet de rétablir complètement le catalogue des données historiques. Grâce au parrainage OpenData d’AWS, les différences de réplication et les données planet sont désormais plus accessibles.

Faciliter la gestion des systèmes

Gestion complète de l’infrastructure AWS avec OpenTofu

Avec l’équipe des opérations d’OpenStreetMap, j’ai réussi à migrer toutes les ressources AWS gérées manuellement vers l’Infrastructure-as-Code (IAC) en utilisant OpenTofu (anciennement Terraform). Cette transition nous a permis d’améliorer la rentabilité, de renforcer la sécurité en adoptant un modèle IAM à moindre privilège, et d’obtenir une meilleure visibilité sur les dépenses grâce à des étiquettes de facturation détaillées. En outre, nous avons intégré S3 Storage Analytics pour optimiser davantage nos coûts, mis en place des sauvegardes supplémentaires et implémenté des règles de cycle de vie améliorées.

Amélioration de l’alerte en cas d’interruption de service

Nous avons mis en place un système d’alerte par SMS pour les pannes de service critiques, ainsi qu’un compte PagerDuty sponsorisé. Ces améliorations garantissent des temps de réponse plus rapides et une meilleure coordination pendant les pannes, avec une intégration complète avec Prometheus/Alertmanager et Statuscake en cours de réalisation.

Réduction de la dette technique

Cette année, nous avons progressé dans la réduction de la dette technique en déplaçant plusieurs services hérités vers des solutions plus faciles à maintenir. Par exemple, nous avons conteneurisé d’anciens services, notamment les sites web des State of the Mapqui fonctionnaient auparavant avec des installations WordPress mal entretenues. Cette transition a permis d’améliorer l’évolutivité, la sécurité et la maintenabilité à long terme de ces services.

En outre, nous avons remplacé notre installation personnalisée d’OTRS par une installation de paquets Znunyde Debian. Ce changement simplifie les mises à jour et réduit la charge de maintenance, garantissant que le système reste à jour et sécurisé sans modifications personnalisées.

Assurer la résilience de l’infrastructure malgré les défaillances matérielles

Au cours de l’année écoulée, nous avons maintenu une infrastructure résiliente, même en cas de défaillance du matériel. Nous avons remplacé de nombreux disques et de la mémoire vive, ce qui a permis de minimiser les interruptions de service. Notre système de surveillance sur mesure nous permet de détecter les premiers signes de défaillance du matériel, ce qui nous permet d’agir rapidement et de remplacer les composants défectueux avant qu’ils ne causent des problèmes importants. Cette approche proactive a été essentielle pour maintenir la disponibilité et la fiabilité du système.

Modernisation des infrastructures

Réplication intersites des sauvegardes

Pour garantir une solide reprise après sinistre, j’ai mis en place une réplication inter-comptes et inter-régions pour les sauvegardes AWS S3, ce qui permet une reprise à point nommé. Cela permet de sauvegarder les données et les services essentiels, même en cas de défaillance majeure, et d’assurer une tranquillité d’esprit à long terme.

Infrastructure à haute disponibilité

Des mises à niveau matérielles importantes dans nos sites d’Amsterdam, de Dublin et de l’OSUOSL ont permis d’améliorer les performances, la capacité de stockage et la fiabilité du réseau. De nouveaux commutateurs ont été installés en 2022, et nous avons maintenant terminé la mise en place d’une configuration de haute disponibilité (HA) pour assurer un meilleur service, que nous avons continué à améliorer en passant à des liaisons montantes ISP doubles et diversifiées pour une meilleure résilience.

Migration vers Debian

Nous migrons d’Ubuntu à Debian 12 (Bookworm) comme distribution standard. Tous les nouveaux serveurs fonctionnent désormais sous Debian. La gestion de la configuration de notre chef a été mise à jour avec du code de test pour assurer une compatibilité continue. Cette transition marque un changement vers une plus grande stabilité et sécurité à long terme. Voici un essage sur Mastodon célébrant la transition.

Perspectives d’avenir

L’année à venir nous offre de nouvelles opportunités passionnantes en nous appuyant sur les progrès accomplis. Les principales priorités pour 2024 / 2025 sont les suivantes :

Engagement

Engagement communautaire et communication externe : nous chercherons à renforcer la collaboration avec le groupe de travail sur la communication (CWG) et améliorer notre communication avec le public sur l’état des services et les pannes.

Améliorer la documentation et l’intégration : nous améliorerons la documentation d’accueil et organiserons des sessions dédiées pour aider les nouveaux contributeurs à s’impliquer plus facilement dans les opérations. Il s’agit notamment d’améliorer la fiabilité et la couverture de nos processus de test, de garantir des contributions plus fluides et de réduire la courbe d’apprentissage pour les nouveaux membres de l’équipe.

Planification et optimisation

Planification de la capacité pour la croissance de l’infrastructure : au fur et à mesure qu’OpenStreetMap et la demande pour nos services augmenteront, nous nous assurerons que nous pouvons évoluer pour répondre à la demande. En anticipant les besoins futurs et en équilibrant les performances avec une croissance rentable, nous visons à maintenir la qualité de service et la disponibilité que notre communauté attend.

Optimisation continue des coûts: nous continuerons à trouver des moyens de réduire les coûts en tirant parti de parrainages tels que le programme AWS OpenData, afin de garantir des opérations durables.

Poursuite de la réduction de la dette technique : nous continuerons à simplifier notre infrastructure en réduisant la charge de maintenance des systèmes existants, notamment en augmentant l’utilisation des conteneurs. Cela contribuera à rationaliser les tâches de gestion et nous permettra de nous concentrer sur d’autres améliorations, rendant l’infrastructure plus efficace et plus évolutive au fil du temps.

Poursuivre l’amélioration des infrastructures

Mise en œuvre d’équilibreurs de charge à haute disponibilité : déploiement de la configuration HA (VRRP + LVS + DSR) pour les équilibreurs de charge afin d’améliorer la fiabilité du système et de réduire les temps d’arrêt potentiels.

Finalisation de l’intégration de Prometheus avec PagerDuty : achèvement de l’intégration de Prometheus pour la surveillance et de PagerDuty pour la rationalisation des alertes et de la réponse aux incidents.

Achever la transition vers un environnement Debian complet : migration de tous les services restants d’Ubuntu vers Debian pour une stabilité et une sécurité accrues.

Améliorer les stratégies de récupération et de sauvegarde en cas de catastrophe : continuer à affiner notre documentation sur la reprise et introduire des mesures de sauvegarde supplémentaires pour que les services essentiels soient protégés et puissent être récupérés en cas de panne.

Fermeture d’OAuth 1.0a et HTTP Basic Auth sur OpenStreetMap.org

En 2024, le groupe de travail OSMF Operations Working Group (OWG) retire OAuth 1.0a et HTTP Basic Auth sur OpenStreetMap.org. Il s’agit de moyens techniques permettant aux applications d’authentifier les utilisateurs auprès du site web OSM ou de l’API. OAuth 1.0a et HTTP Basic Auth sont obsolètes depuis 2023, car OAuth 2.0 est désormais la méthode d’autorisation standard pour la plupart des systèmes.

Il y a trois dates clés dans le processus de transition :

1er mars 2024 : les nouveaux enregistrements d’applications OAuth 1.0a ont été désactivés. Les applications existantes n’ont pas été affectées. L’authentification de base HTTP n’a pas été affectée.
1er mai 2024 : les administrateurs de système commenceront à faire des recherches pour trouver les applications qui utilisent encore OAuth 1.0a ou HTTP Basic Auth.
1er juin 2024 : OAuth 1.0a et HTTP Basic Auth seront supprimés.

La suppression de ces méthodes d’authentification est nécessaire pour des raisons de sécurité et en raison de la complexité de la maintenance d’un si grand nombre d’implémentations d’autorisation, y compris celles qui reposent sur des composants non maintenus.

Quel est l’impact pour moi en tant que développeur ?

Si vous êtes développeur d’une application utilisant OAuth 1.0a ou HTTP Basic Auth pour vous connecter au site OpenStreetMap.org, vous devrez peut-être effectuer quelques changements pour passer à OAuth 2.0. Heureusement, il s’agit là d’un standard qui est largement soutenu.

Si votre application n’effectue que des appels en lecture à l’API, l’autorisation est facultative. Pour des raisons de limitation du débit, il est toujours souhaitable d’ajouter une autorisation à vos demandes, mais ce n’est pas obligatoire. Si votre application est un site web utilisant OSM pour les connexions, il est beaucoup plus facile d’utiliser OAuth 2.0, qui est beaucoup mieux pris en charge parce que de nombreux autres sites l’utilisent. Cela permet également d’éviter les problèmes liés au fait que les utilisateurs se retrouvent avec de nombreux jetons dans leur liste sur le site web.

Si vous développez un logiciel qui édite à l’aide de l’API et qui est exécuté localement, il se peut que vous deviez modifier du code. Tous les langages courants disposent de bibliothèques qui gèrent OAuth 2, et les bibliothèques sont le meilleur choix pour toute autorisation. Vous pouvez également utiliser la bibliothèque d’outils de ligne de commande de Zverik ou écrire votre propre script shell d’une douzaine de lignes.

Vous devriez pouvoir trouver en ligne de nombreux exemples d’implémentations de clients OAuth 2 dans votre langue. Si vous souhaitez obtenir des informations plus détaillées ou poser des questions techniques, veuillez utiliser le ticket GitHub. Ici, l’OWG suit également les applications nécessitant une modification pour utiliser OAuth 2.0.

Quel est l’impact pour moi en tant que cartographe ?

La plupart des cartographes ne remarqueront aucun changement. La transition n’affectera pas la façon dont vous vous connectez à votre compte OSM ou dont vous utilisez le site web. L’iD et le JOSM supportent OAuth 2.0 comme méthode d’authentification par défaut depuis un certain temps. Si vous utilisez votre compte OSM pour vous connecter à un site tiers tel que HOT Tasking Manager, MapRoulette ou HDYC, vous ne serez pas affecté, car ces sites sont déjà passés à OAuth 2.0. L’accès à l’API en lecture seule ne nécessite aucune autorisation.

Arrêt pour maintenance des serveurs – 9 mai

Le groupe de travail Opérations planifie des changements de matériel dans le cadre de la maintenance de notre centre de données primaire. Le plan d’exécution peut être modifié en cours de route, mais ces interventions sont prévues le lundi 9 mai et cela entrainera une période (24 heures maximum) d’accès en lecture seule.

Cela signifie que le site et la carte OpenStreetMap seront toujours disponible. Neanmoins, aucune édition de la carte ne sera possible pendant cette intervention.

La page du wiki ‘2016 May server maintenance’ fournit quelques détails techniques supplémentaires. Elle sera mise à jour avec des informations plus précises dans les prochains jours.

Ce billet de blog n’est qu’une annonce préalable et nous comprenons que certains d’entre vous voudront connaître les temps d’interruption exacts. Nous vous prions de patienter pendant que le groupe de travail peaufine la préparation de l’intervention.

L’édition d’adaptation à la nouvelle licence est prête

Bonjour à tous,
Je suis heureux d’annoncer que le robot d’édition est prêt à démarrer.

Nous commencerons l’édition des contributions non compatibles aux nouvelles Conditions de contribution (CT) et licence ODbL (moins de 1% des données) dès cette semaine. Nous devrions débuter le mercredi 11 juillet, assumant que certains détails finaux de mise en place auront été réglés d’ici là.

Le robot fera l’édition dans la séquence suivante:

Irlande
Royaume-Uni
Europe de l’Ouest
Amérique du Nord
Australie
Le reste de la planète

Une fois complétés, nous serons prêts à distribuer sous la licence ODbL et nous en ferons l’annonce dans un autre communiqué. Le dernier jeu de données préédition disponibles sous CC-BY-SA a été généré à http://planet.openstreetmap.org/planet-120704.osm.bz2. À mesure que les régions seront éditées, toute tentative d’accès à partir de l’API ou du site retournera une réponse à cet effet.

Les tests ont montré que le robot fonctionne comme nous le voulions, mais nous surveillerons évidemment ces progrès. Nous nous attendons que l’édition dure environ un mois; compte tenu des différentes variables, j’ai bien peur que nous ne puissions donner une image plus précise pour le moment, mais nous souhaitons vous informer au fur et à mesure du déroulement via les listes announce@ et talk@).

Il n’y aura pas de pannes de l’API, ni autre interruption d’édition. Lorsque le robot éditera dans votre région du monde, sauvegardez fréquemment vos éditions pour minimiser les conflits potentiels.

(Des messages séparés sont envoyés à talk-ie@ et talk-gb@ compte tenu que ce seront les deux premières régions affectées. S’il vous plait, traduisez et faites suivre dans vos listes de courriel régionales.)

Comme vous savez, nous nous attendions à démarrer le tout juste après le 1er avril, mais la complexité de la tâche à provoquer le délai. Merci à tous pour votre patience, et un merci particulier à tous ceux qui ont contribué à la programmation, que ce soit par des corrections, suggestions ou en consolidant le tout.

posté sur la liste de courriel par Richard, pour le conseil d’administration de la fondation (OSMF)

Traduit de l’anglais par Daniel Bégin

Le changement de licence encore en cours

Il y a plusieurs semaines, nous écrivions que nous étions encore à améliorer le «robot d’édition». La composante de code qui passe à travers les données et édite (enlève/cache) toute donnée qui n’est pas compatible avec la nouvelle licence. À notre grande déception, ça prendra encore du temps avant que le robot fonctionne parfaitement. Bonne nouvelle : le robot passe présentement plus de tests que jamais; mauvaise nouvelle : il ne les passe pas tous. Plusieurs personnes travaillent là-dessus, pour le faire fonctionner sans erreurs.

Lorsque ces tests système passeront, des tests sur des données réelles seront conduits sur un serveur déjà configuré qui est en attente. Suite au succès de ce test, un nouveau test sera effectué sur un secteur isolé de la base de données, probablement l’Irlande. Si tout se passe avec succès, nous procéderons alors avec le reste des données.

Sur une note positive : au cours des dernières semaines, nous nous sommes également entendus avec plusieurs contributeurs pour conserver leurs données dans la base de données. Nous voudrions remercier toutes les personnes qui ont permis que cela se réalise.

Nous donnerons une nouvelle mise à jour le weekend prochain.
Merci à tous pour votre patience.

Traduit de l’anglais par Daniel Bégin

Nouvelles sur le changement de licence : Obtenir les bons résultats

Avec le nouveau serveur installé avec succès par l’équipe d’administration des systèmes, nous abordons maintenant la seconde partie de la migration — le travail d’édition des données nécessaire au passage à la nouvelle licence ODbL. Nous avions promis un rapport pour la semaine du 9 avril, mais beaucoup de gens le demande, voici donc un rapport quatre jours plus tôt.

Le changement de code à l’API d’Openstreetmap a été complété et revu avec succès. Openstreetmap.org est par conséquent prêt à distribuer la nouvelle donnée. Merci à Matt Amos pour la rédaction du code et Tom Hughes pour sa revue.

La seconde composante est le robot d’édition. C’est la partie de code qui, pour chaque région couverte par Openstreetmap, passera à travers les données pour éditer (enlever/cacher) celles qui ne sont pas compatibles avec la nouvelle licence. C’est la partie la plus critique de tout le processus de migration. Nous souhaitons ne conserver aucune donnée pour laquelle le contributeur original n’a pas permis sa distribution sous la nouvelle licence ODbL, et inversement, ne rien détruire accidentellement de la vaste majorité des données qui est compatible.

Depuis mercredi 4 avril, nous procédons à des tests sur des données réelles (merci à Frederik Ramm pour son aide). Nous ne sommes pas encore satisfaits à 100 % du résultat alors nous continuons à travailler le code. Évidemment, nous ne démarrerons pas le robot d’édition avant que nous ne soyons certains qu’il produise les résultats attendus. Nous devrions pouvoir compléter le tout avant la fin de la semaine du 9 avril. Ça nous donne quelques jours de retard sur l’horaire, mais nous devons bien cela aux contributeurs.

Si vous êtes développeur, vous pouvez aider à corriger les tests qui échouent encore. Vous pouvez accéder le code à https://github.com/zerebubuth/openstreetmap-license-change.

Si vous êtes un contributeur, ça vous donne quelques jours supplémentaires pour mettre votre région en bon état! Et si vous êtes un utilisateur des données, vous pouvez continuer à utiliser les données existantes sous licence CC-BY-SA 2.0.

Nous aurons d’autres mises à jour la semaine prochaine et, dans tous les cas, avant que le robot d’édition ne commence son travail.

Traduction de l’anglais par Daniel Bégin

Coordonnées GPS en lot

Les contributeurs d’Openstreetmap ont utilisé leurs fichiers de données GPS depuis des années alors qu’ils amélioraient les données OSM. Ils ont partagé ce fichier et les coordonnées de leurs tracés ont été rendues disponibles aux autres éditeurs via différents outils d’édition et le site web. Nous rendons maintenant disponible une façon d’accéder à tous ces points d’un seul coup.

Nous vous présentons planet.osm.org/gps

Il s’agit de toutes les coordonnées GPS collectées au cours des sept dernières années et demie d’Openstreetmap. Il s’agit d’une très grosse collection de points bruts.

le fichier compressé est de 7GBytes.
décompressé, c’est un fichier texte qui fait 55GByte.
il s’agit d’un ensemble de coordonnées, sans métadonnées.
les coordonnées proviennent de milliers d’usagers.
les coordonnées proviennent de milliers de fichiers GPS distincts.
les données comprennent 2,770,233,904 points

Est-ce une grosse affaire?

Il s’agit probablement de la plus grosse collection de coordonnées GPS publiée avec une licence ouverte. Vous en connaissez une plus large? Faites-le-nous savoir dans les commentaires.

Travailler avec ce fichier n’est peut-être pas votre tasse de thé. Avec le temps, je m’attends à ce que des outils émergent de la communauté pour en simplifier la gestion. Pour le moment, il s’agit d’un gros volume de données.

Par le passé, toutes ces données ont été rendues disponibles aux contributeurs d’Openstreetmap sous différentes formes, via les éditeurs et le site web. Ce fichier permet d’accéder à toutes ces données en même temps.

Exemple de données

Si vous décidez de travailler avec ce fichier, voici le format auquel vous devez vous attendre.

-900000000,1771882380 -900000000,1293757490 -891154290,1237501070 -877697750,1653442410 -871875000,1589069750 -871875000,1237507350 -843750000,1350007780 -843750000,1153132660 -843750000,1040632590 -843750000,1012507800 -843750000,1012507340 -824414060,1082922390 -815625000,1575007660 -805627440,1579614290 -805517580,1579284700 -805517580,1578845240 -804473020,1373773550 -787500000,1237507380 -787500000,1181257510 -787500000,1096882780 -787499970,1096882780 -778591613,1666901550 -778591613,1666898345 -778591384,1666911621

Quelle sorte de format est-ce?

Il s’agit de latitudes/longitudes en nombre entières, séparées par une virgule, le tout dans un format texte très simple. Pour obtenir les coordonnées en nombre réel, il suffit de diviser chaque nombre par 10**7. Les points sont triés par localisation, l’origine se trouvant à l’extrémité sud-ouest du globe (90 S,180 E) et les données s’étendant vers le nord-ouest.

Merci

Merci, comme toujours, aux centaines de milliers de contributeurs d’Openstreetmap qui ont participé au projet au cours des dernières sept années et demie. Merci également aux administrateurs du système qui ont déplacé ces données en un endroit accessible à tous.

Cette version du fichier GPS est sous licence CC-By-SA et publié par Openstreetmap et ses Contributeurs. L’image au haut de cet article est une visualisation d’une partie de ces points en Europe. Cette image est également sous licence CC-By-SA et a été produite par Dave Stubbs.

Traduit de l’anglais par Daniel Bégin

Période d’entretien des systèmes : Mars — avril 2012

La mise à niveau de la licence, attendue avec tant d’impatience, arrive bientôt. La conclusion d’un processus qui a pris des années. Pour minimiser les périodes d’interruptions de service auprès des usagers, nous profiterons de l’opportunité pour installer notre nouveau serveur de base de données (payé par vos généreuses contributions).

Veuillez prendre connaissance du calendrier des opérations d’entretien et de migration dans les lignes qui suivent.

La mise à niveau de la licence commencera par le changement de serveur de la base de données. Toutes les dates et heures indiquées sont sujettes à changement : nos bénévoles travaillent d’arrache-pied. Merci à l’avance pour votre patience et votre soutien.

Éditeurs de données

Il y aura plusieurs jours où la disponibilité de l’API sera limitée. L’API sera en lecture seulement pendant le déplacement des données vers le nouveau serveur, ramoth. Ce serveur a été payé par vos contributions lors de la campagne de financement du mois de décembre 2011. Il n’y aura pas d’édition possible de la carte pendant que l’API sera en lecture seulement.

Pendant le reste de la mise à niveau, l’API devrait opérer normalement. Si possible, remettez les éditions de masse jusqu’après le changement de licence. Comme toujours lors des améliorations du système, vos suggestions sont appréciées. Référez-vous au “OSM IRC chat channel”, #osm sur irc.oftc.net, si vous avez des questions.

Nous demandons aux éditeurs qui n’ont pas encore accepté la nouvelle licence de se connecter sur OSM avant le début de la migration le 1er avril (08:00 UTC) et de signaler leur intention. Nous sommes heureux que la vaste majorité des données OSM ne soient pas affectées par le changement de licence et nous remercions tous les éditeurs qui ont consenti à ce que leurs données soient distribuées sous la nouvelle licence.

Consommateur de données

La génération du “Planet file” prévue cette semaine-là a été remise à plus tard. Le dernier “Planet file” associé à l’ancienne licence sera créé à partir des données du 1er avril 2012. Il sera publié lorsque sa création sera complétée, ce qui pourrait être reporté de quelques jours.

L’ancien service de réplication (diff) sera arrêté lorsque la base de données passera en mode de lecture lors de la migration de serveur. Un nouveau service de réplication (diff) débutera dès la fin de la mise à niveau de la licence à partir d’une nouvelle adresse. Les détails d’utilisation de ce nouveau service seront diffusés lorsque ce sera le temps de l’utiliser.

Dates importantes

Ces dates sont sujettes à modification sans préavis.

1er avril : Passage au mode lecture seulement 08:00 UTC
4 avril : Fin de la mise à niveau. Passage au mode lecture/écriture sur le nouveau serveur en avant-midi (sujet à changement.
5-6 avril : Test de reconstruction de logique.
7 avril : Début des opérations de nettoyage des données associées à la vieille licence.
9 avril : Rapport sur le progrès des opérations et estimation du temps nécessaire pour compléter les opérations.
À déterminer : À la fin des opérations, si nous sommes satisfaits des résultats, les données sont déclarées ODbL. Immédiatement après, un premier “Planet file” sera généré/publié et la création des fichiers “diff” recommencera

Remerciements

Merci, comme toujours, à tous les gens qui fond d’Openstreetmap quelque chose de grand. Ces individus incluent les innombrables éditeurs qui améliorent les données, les bénévoles qui s’assurent que tout fonctionne correctement, les programmeurs qui rendent l’utilisation d’OSM plus simple tous les jours, et à nos donateurs qui nous fournissent la quincaillerie de laquelle nous dépendons.

Plusieurs d’entrevous font partit de plusieurs de ces catégories. Sachez que ces remerciements sont cumulatifs 🙂

[Extraits de “Dermot McNally’s announcement”. Contexte ajouté de sources additionnelles.]

Traduit de l’anglais par Daniel Bégin

Arêt de la Base de données – 20 mars 2012

Mardi 20 mars 2012, entre 13:45 et 16:15 (GMT / UTC) le serveur principal de la base de données ne sera pas disponible en raison d’un entretient d’urgence.

Les services suivants seront affectés:

www.openstreetmap.org – le site ne permettra pas aux usagers de se connecter ou d’éditer (Potlatch). [1]
L’API et l’édition de la base de données (JOSM, Merkaartor etc.) ne seront pas disponibles.
planet.openstreetmap.org sera disponible, mais il n’y aura pas de diffs générés pendant la coupure de service.
Forum (pas de connexion)
trac (bug-tracker, pas de connexion)
help.openstreetmap.org (pas de connexion)

Les autres services ne seront pas affectés – tous les services suivants devraient fonctionner normalement:

Serveur de tuiles (“Voir la carte ” & “Exporter”)
Wiki
Nominatim (recherche)
Liste de courriels
subversion et git (dépôts de code source)
donate.openstreetmap.org

Technique: Serveur Smaug: Remplacement de la carte mère.
Spécialiste sur place. Nous avons du matériel d’urgence disponible.

1: Les cartes continueront d’être visibles sur la page d’openstreetmap.org et sur les autres sites web.

Sincèrement
Grant Slater
Au nom de l’équipe d’administration des systèmes d’Openstreetmap

Traduit de l’anglais par Daniel Bégin

Mise à niveau de la quinquaillerie de la Fondation

Serveurs, ramoth et bowser, en place.

L’équipe d’administration des systèmes a acheté de la quincaillerie additionnelle pour notre plus grand plaisir. Les serveurs d’Openstreetmap portent le nom de dragons, tirés de « Here be Dragons », reprenant l’inscription désignant les parties inexplorées sur les cartes du moyen-âge. (voir les dragons d’Openstreetmap).

azure – Java-XAPI. Expérimental. Distribue en lecture seulement des données OSM à partir d’un code XAPI rafraichi. Azure a eu une mise à niveau longuement anticipée de son disque.
bowser – rejoint soup et fiddlestick à titre de “Web Front End”. Ce serveur web de première ligne rendra la navigation du site web osm.org plus fringante.
eustace – Statistiques Web. Expérimental. Observe le comportement des usagers à travers les serveurs OSM pour comprendre et améliorer leur expérience.
gorwen et orm –Cache de tuiles geoDNS. gorwen est gracieusement fourni et hébergé par Teleservice Skåne AB. GeoDNS fournit des rendus cartographiques (tuiles) à partir du serveur le plus proche. L’équipe d’administration des systèmes espère avoir un serveur nord-américain très bientôt. Nous cherchons de l’hébergement pour d’autres serveurs (géographique). Si vous êtes intéressé et que 100Mbits/s ne vous inquiète pas, adressez-vous à l’administration des systèmes sur #osm-dev at http://irc.osm.org
poldi – Toponymie. Fournis un outil de recherche et de géolocalisation de noms utilisant les données OSM. Retourne un positionnement local d’un nom en un clin d’oeil.
ramoth – est le second serveur de base de données. Le succès de la campagne de financement de décembre 2011 a permis l’installation de ce serveur. Ce serveur accroit la fiabilité des opérations de la base de données. Statut : installé et en cours de configuration.

Nous souhaitons également la bienvenue aux deux nouveaux membres de l’équipe des serveurs – Ian Dees (iandees) and Sarah Hoffman (lonvia). Ils maintiendront les serveurs Java-XAPI et Toponymie.

Photo de Firefishy.
Traduit de l’anglais par Daniel Bégin