Remove ansible.nodejs.org
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Refactorización
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- ansible, docker, docker-compose
- Área
- cloud, devops, infrastructure, security
Línea de trabajo
Start by reviewing ansible/inventory.yml, the ~/.ssh/config conventions, and the secrets repository for references to ansible.nodejs.org, infra-ibm-ubuntu2004-x64-1, and awx_password. Confirm that no credentials, scheduled jobs, webhooks, or workflows depend on the AWX host, then coordinate decommissioning the host and removing its DNS and Cloudflare configuration. Done means the host and related references are safely removed and exclusive credentials are rotated.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
ansible.nodejs.org (IBM host infra-ibm-ubuntu2004-x64-1, 169.60.150.91) is an unmanaged, unwatched AWX (open-source Ansible Tower) instance that has been effectively dead for years and should be decommissioned rather than repaired.
What's running there
- AWX 17.1.0 (
ansible/awx:17.1.0), deployed via docker-compose, containers created ~5 years ago. awx_web,awx_task,awx_rediscontainers, plusawx_postgres.- No nginx/reverse proxy — the AWX web container binds host ports 80/443 directly.
Key detail: it's been idle for years, then crashed
The last time this AWX instance did anything at all was around 2023-09-29 (a project sync attempt), and the last time there's evidence of actually running a job against current code was back when the checkout was at the Feb 2022 commit. Either way, it's been sitting completely idle for roughly 2.5+ years before postgres even died in Dec 2025 — the disk-full crash-loop just finished off something that was already effectively unused.
Supporting evidence:
awx_postgreshas been crash-looping since 2025-12-29 (no space left on device, 605+ restart attempts logged), because the host's root disk is 100% full (99G/99G).- The AWX-synced checkout of
nodejs/buildunder/var/lib/awx/projectsis pinned at commit472b2953("Update README.md", #2874, merged 2022-02-21). - The project's
.git/FETCH_HEAD(updated on each pre-job sync) has an mtime of 2023-09-29 11:56 UTC, and picked up no newer commits — the last sync attempt, whatever triggered it, did nothing useful. - The host's origin TLS cert (served directly by the AWX container, not through Cloudflare) is self-signed and expired 2024-04-09. The only reason
https://ansible.nodejs.orgstill shows a valid cert to browsers is that Cloudflare is terminating TLS at the edge with the shared*.nodejs.orgwildcard cert and not validating the origin connection.
Why this should be removed, not fixed
- It's a privileged automation platform (AWX manages Ansible credentials/inventory) that nobody has been watching for 2.5+ years.
- Disk exhaustion took down its database in Dec 2025 and nobody noticed for ~9 months — reinforcing that it has no active owner.
- The AWX release (17.1.0) is multiple years out of date.
- No current build/infra workflow appears to depend on it (last real activity predates most current infra automation, which now runs through this
ansible/repo directly).
Suggested next steps
- Confirm nothing currently depends on this AWX instance (credentials stored only here, scheduled jobs, webhooks pointing at it, etc.)
- Decommission the host (
infra-ibm-ubuntu2004-x64-1/ansible.nodejs.org, IBM, 169.60.150.91) - Remove its DNS record and Cloudflare configuration
- Remove/rotate any credentials that were only ever exposed to this box (e.g.
awx_passwordin the secrets repo) - Remove references to it from
ansible/inventory.ymland~/.ssh/configconventions once decommissioned
🤖 Generated with Claude Code
- Lenguaje dominante
- Jinja
- Estrellas
- 541
- Forks
- 185
- Merge medio
- 2 d 19 h
- PR fusionados (30 d)
- 6
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de nodejs/build
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
nodejs/build#4482 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
platform:ppc
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
nodejs/build#4479 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
nodejs/build#4324 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
incident
Dificultad 4/5 3-5 días Aptitud para principiantes 42/100
nodejs/build#4483 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
nodejs/build#4477 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de nodejs/build
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
kedacore/keda#8225 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
bug status/needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
prowler-cloud/prowler#12887 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area-deployment triage:bot-seen triage:needs-human
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/aspire#20533 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día