Category Archives: Operaciones

Publicaciones relacionadas con la administración de hardware y sistemas. Todo lo relacionado con el Grupo de Trabajo de Operaciones

Cierre de OAuth 1.0a y HTTP Basic Auth en OpenStreetMap.org

En 2024, el Grupo de Trabajo de Operaciones (OWG) de la OSMF retirará OAuth 1.0a y HTTP Basic Auth en OpenStreetMap.org. Estas son formas técnicas para que las aplicaciones autentiquen a los usuarios con el sitio web o API de OSM. OAuth 1.0a y HTTP Basic Auth han quedado obsoletos desde 2023, ya que OAuth 2.0 es ahora el método de autorización estándar para la mayoría de los sistemas.

Hay tres fechas clave en el proceso de transición:

  • 1 de marzo de 2024: Se deshabilitaron los nuevos registros de aplicaciones OAuth 1.0a. Las aplicaciones existentes no se vieron afectadas. HTTP Basic Auth no se vio afectado.
  • 1 de mayo de 2024: los administradores del sistema iniciarán caídas de tensión para encontrar aplicaciones que todavía usan OAuth 1.0a o HTTP Basic Auth.
  • 1 de junio de 2024: OAuth 1.0a y HTTP Basic Auth se cerrarán.

Es necesario retirar estos métodos de autenticación debido a motivos de seguridad y a la complejidad de mantener tantas implementaciones de autorización, incluidas aquellas que dependen de componentes no mantenidos.

¿Cómo me afecta esto como desarrollador?

Si eres desarrollador de una aplicación que utiliza OAuth 1.0a o HTTP Basic Auth para iniciar sesión en el sitio web OpenStreetMap.org, es posible que debas realizar algunos cambios para migrar a OAuth 2.0. Afortunadamente, este es un estándar industrial bien respaldado.

Si su aplicación solo realiza llamadas de lectura a la API, la autorización es opcional. Para fines de limitación de tráfico, sigue siendo una buena idea agregar autorización a sus solicitudes, pero no es obligatorio. Si su aplicación es un sitio web que utiliza OSM para iniciar sesión, utilizar OAuth 2.0 es mucho más fácil, pues tiene un soporte mucho mejor debido a que muchos otros sitios lo usan. También evita problemas como que los usuarios terminen con muchos tokens en su lista en el sitio web.

Si estás desarrollando software que edita mediante la API y se ejecuta localmente, es posible que debas realizar cambios en el código. Todos los lenguajes comunes tienen bibliotecas que manejan OAuth 2 y las bibliotecas son la opción preferida para cualquier autorización. También puedes usar la biblioteca de Zverik para herramientas de línea de comandos, o escribir tu propio shell script de aproximadamente una docena de líneas.

Deberías poder encontrar muchos ejemplos en línea de implementaciones de clientes OAuth 2 en tu idioma. Si deseas obtener información más detallada o hacer preguntas técnicas, utilice el ticket de GitHub. Aquí, el OWG también rastrea las aplicaciones que requieren modificaciones para usar OAuth 2.0.

¿Cómo me afecta esto como mapeador?

La mayoría de mapeadores no notarán ningún cambio. La transición no afectará la forma en que inicias sesión en tu cuenta OSM ni en la que utilizas el sitio web. iD y JOSM han admitido OAuth 2.0 como método de autenticación predeterminado desde hace algún tiempo. Si utilizas tu cuenta OSM para iniciar sesión en un sitio de terceros como HOT Tasking Manager, MapRoulette o HDYC, no te verás afectado porque esos sitios ya se han migrado a OAuth 2.0. El acceso a la API en modo solo lectura no requiere autorización alguna.


La Fundación OpenStreetMap es una organización sin fines de lucro, formada para apoyar el Proyecto OpenStreetMap. Se dedica a fomentar el crecimiento, desarrollo y distribución de datos geoespaciales gratuitos para que cualquiera pueda usarlos y compartirlos. La Fundación OpenStreetMap posee y mantiene la infraestructura del proyecto OpenStreetMap, está financiada por cuotas de membresía y donaciones, y organiza la conferencia anual internacional State of the Map. Nuestros grupos de trabajo voluntarios y nuestro pequeño personal central trabajan para apoyar el proyecto OpenStreetMap. Únete a la Fundación OpenStreetMap por solo £ 15 al año o gratis si eres un colaborador activo de OpenStreetMap.

Impulsando el futuro de OpenStreetMap: Un año de mejoras del ingeniero de fiabilidad del sitio de la Fundación OpenStreetMap

Hace poco más de un año, me uní a la Fundación OpenStreetMap (OSMF) con el objetivo de mejorar la fiabilidad y seguridad de la tecnología y la infraestructura que sustenta OpenStreetMap. A lo largo del año pasado, he trabajado estrechamente con el Grupo de Trabajo de Operaciones, un equipo dedicado de voluntarios. Juntos, hemos logrado un progreso significativo en la mejora de nuestros procesos y documentación, fortaleciendo en última instancia nuestra eficacia colectiva. Estoy inmensamente agradecido por el apoyo y la colaboración dentro de este grupo, y estoy encantado de presenciar los notables avances que hemos dado en la construcción de una base sólida para el futuro de OpenStreetMap.

Entraré en un poco de detalle a continuación sobre lo que se ha hecho. A un alto nivel, facilité la administración de la implementación del software que se ejecuta en nuestros servidores; fortalecí nuestra infraestructura de red a través de una mejor redundancia, monitoreo, acceso y documentación; aumenté nuestro uso de servicios en la nube para la representación de teselas, aprovechando un generoso patrocinio de AWS; mejoré nuestras prácticas de seguridad; actualicé nuestros entornos de desarrolladores; y por último, pero definitivamente no menos importante, finalicé la migración de 16 años de contenido de nuestros antiguos foros a nuestros nuevos foros.

Si quieres saber más de mí en el transcurso del trabajo del año pasado, echa un vistazo a mi charla en State of the Map 2022 y mi entrevista en el podcast GeoMob. Y me encantaría saber de ti, envíame un correo electrónico a osmfuture@firefishy.com.

Detalles de confiabilidad del sitio 2022-2023

Gestión de software en nuestros servidores

Pequeños Componentes de infraestructura en contenedores (GitHub Actions for building)

He puesto en contenedores muchos de nuestros sitios pequeños que se construyeron previamente utilizando métodos a medida en nuestra base de código de chef como parte de la configuración de “Configuración como código”. Se movieron los pasos de compilación a Github Actions. Configuré una base para cualquier proyecto futuro basado en contenedores (“docker”) en el futuro. Estos son nuestros primeros proyectos basados en contenedores / docker alojados en la infraestructura OSMF.

Nuestro código basado en chef ahora es más simple, más seguro y se implementa más rápido.

Pruebas de chef mejoradas (documentación de incorporación de operaciones)

Utilizamos chef.io para la gestión de la infraestructura (configuración) de todos nuestros servidores y el software utilizado en ellos. Durante el último año, las pruebas de cocina del chef test se han extendido y ahora también funcionan en las modernas máquinas Apple Silicon. Las pruebas ahora se ejecutan de manera confiable como parte de nuestros procesos de CI / PR. Las pruebas agregan control de calidad y garantía a los cambios que hacemos. El soporte ARM fue más fácil de agregar porque podíamos usar la cocina de prueba antes de pasar al hardware del servidor ARM.

Tener pruebas confiables debería ayudar a incorporar nuevos colaboradores del chef.

Se reforzó nuestra infraestructura de red

Network Upgrades @ AMS (Nuevos switches, enlaces redundantes duales, Dublín pronto)

Nuestra configuración de red en Ámsterdam no era tan redundante como debería haber sido. El equipo Cisco Small Business que utilizamos se nos había quedado pequeño. Tuvimos cortes de energía inesperados debido a problemas de hardware. El equipo también estaba limitando futuras actualizaciones. El grupo de operaciones decidió reemplazar el hardware con equipos Juniper que habíamos estandarizado en el centro de datos de Dublín. Reemplacé el equipo con un tiempo de inactividad mínimo en un entorno en vivo (<15 minutos).

Los centros de datos de Dublín y Ámsterdam ahora utilizan una configuración estandarizada y más segura. Cada servidor ahora tiene enlaces totalmente vinculados para mejorar la redundancia y el rendimiento. Los switches han mejorado la potencia y la redundancia de la red. Estamos esperando la instalación de los enlaces ascendentes totalmente resistentes (pedido enviado) en el próximo mes.

Acceso fuera de banda a ambos centros de datos (basado en 4G)

Construí e instalé dispositivos de acceso fuera de banda en cada sitio. Los dispositivos están cableados a equipos de red y administración de energía mediante consolas seriales. Los dispositivos fuera de banda tienen un enlace 4G resistente a una red 4G privada (1NCE). Los dispositivos de acceso fuera de banda son Raspberry PI personalizadas con fuentes de alimentación redundantes y 4 conectores seriales.

Documentación de Infraestructura para facilitar el mantenimiento (Racks / Power)

Documenté cada unidad rack, puerto de alimentación (Power Distribution Unit), conexión de red y cable en los centros de datos. Esto facilita la administración de los servidores, reduce los errores y nos permite instruir adecuadamente a las manos remotas (proveedor de soporte externo) para que realicen cualquier cambio en nuestro nombre.

Oxidized (visibilidad de equipos de red)

Nuestra configuración de red y distribución de energía ahora se almacena en git y se informan los cambios. Esto mejora la visibilidad de cualquier cambio, lo que a su vez mejora la seguridad.

La configuración se supervisa continuamente y cualquier desviación de configuración entre nuestros sitios ahora es mucho más fácil de resolver.

Infraestructura Terraform como Código (mejorar la gestión / repetibilidad)

Terraform es una herramienta de infraestructura como código, ahora la usamos para administrar nuestro servicio de monitoreo remoto (statuscake) y estoy en el proceso de implementarlo para administrar nuestra infraestructura de AWS y Fastly.

Anteriormente, todos estos componentes se administraban manualmente utilizando las respectivas interfaces de usuario web. La infraestructura como código permite al equipo de operaciones trabajar colaborativamente en los cambios, mejora la visibilidad y la repetibilidad / reversión de cualquier cambio.

Gestionamos todos los dominios DNS utilizando el código dnscontrol. Se han realizado mejoras incrementales durante el último año, incluida la adición de pruebas de IC para mejorar la colaboración externa.

Aumentó nuestro uso de servicios en la nube

AWS en uso para la infraestructura de representación. Optimización de los costos de AWS. Seguridad mejorada. Copia de seguridad mejorada. Más en trámite

El equipo de operaciones ha ido aumentando lentamente nuestro uso de AWS en los últimos años. He creado varias cuentas de AWS específicas de uso utilizando un modelo de organización de AWS para mejorar la facturación y la seguridad según las directrices de prácticas recomendadas de AWS. Recibimos generosamente el patrocinio de AWS para expandir nuestra infraestructura de renderizado. Creamos la nueva infraestructura de renderizado experimental con la arquitectura ARM con AWS Graviton2 EC2.
No hemos usado anteriormente servidores basados en ARM. Como parte de las mejoras en nuestro chef (configuración como código) habíamos agregado soporte de pruebas locales para Apple Silicon (ARM), solo se requirieron pequeñas adiciones para agregar la compatibilidad requerida para los servidores ARM al chef.

Nos impresionó el rendimiento de las instancias EC2 de AWS Graviton2 para ejecutar la pila de representación de teselas de OSM. También probamos el escalado bajo demanda y la creación de instantáneas de instancias para posibles mejoras adicionales de la pila de render en AWS.
Hemos aumentado nuestro uso de AWS para la copia de seguridad de datos.

Mejoramos nuestra seguridad

Durante el último año se han realizado una serie de mejoras generales de seguridad. Por ejemplo: El acceso al servidor ahora es a través de clave ssh (el acceso con contraseña ahora está deshabilitado). También hemos pasado de un administrador de contraseñas basado en gpg a medida para el equipo de operaciones a usar gopass (versión rica en funciones de https://www.passwordstore.org/), GoPass mejora la administración de claves y el uso compartido del almacén de contraseñas.

Además, también hemos mejorado el bloqueo de nuestras instancias de WordPress al reducir los componentes instalados, deshabilitar las actualizaciones en línea y deshabilitar el acceso XMLRPC. También estamos trabajando para reducir los usuarios con acceso y eliminar los permisos de acceso no utilizados.

Áreas clave documentadas de vulnerabilidad que requieren mejoras (redundancia, seguridad, etc.)

Documentación sobre vulnerabilidad técnica: Estoy elaborando un informe sobre áreas clave de vulnerabilidad que requieren mejoras (Redundancia, Seguridad, etc.). El documento se puede utilizar para enfocar la inversión en el futuro para reducir aún más nuestra exposición a los riesgos.

Hemos renovado nuestros entornos de desarrollo

Nuevo servidor de desarrollo

Hemos migrado todos los usuarios de desarrollo a un nuevo servidor de desarrollo en el último año. El servidor antiguo había terminado su vida útil (~ 10 años) y estaba alcanzando límites de capacidad (CPU y almacenamiento). El nuevo servidor se entregó directamente al centro de datos de Ámsterdam, se instaló físicamente con manos remotas y comuniqué la migración, y luego migré todos los usuarios y proyectos.

Subversion retirada

Retiré nuestro viejo repositorio de código svn.openstreetmap.org el año pasado. El repositorio de código se utilizó desde el inicio del proyecto, y contenía un rico historial de desarrollo de código en el proyecto. Convertí el repositorio de código svn a git usando una configuración de reposurgeon personalizada, se prestó atención a mantener el historial de contribuciones completo y vincular correctamente a los contribuyentes anteriores (350+) a las respectivas cuentas de github y relacionadas. Los antiguos enlaces svn se mantuvieron y ahora enlazan al archivo en github https://github.com/openstreetmap/svn-archive.

Migración del foro

En la migración del antiguo foro migramos 1 millón de publicaciones y 16 años de publicaciones a discourse. Todas las publicaciones se convirtieron de fluxbb markdown a la versión de markdown de discourse. Todas las cuentas se fusionaron y la autenticación se convirtió a OpenStreetMap.org “inicio de sesión único” basado en auth.

Todos los enlaces antiguos del foro redirigen (enlace al importado) para corregir el contenido. Usuarios, categorías (países, etc.), temas de hilo y publicaciones individuales.