# Guía de trabajo Cómo seguir con esto. Estado real, qué está verificado y qué no, y por dónde continuar. --- ## Estado a 2026-08-08 | Parte | Estado | |---|---| | Investigación | **Cerrada.** Cinco documentos en `01_investigacion/` | | Automatización Ansible | **Escrita, sin ejecutar** contra hardware | | Documentación de requisitos, costes y seguridad | **Cerrada** | | Hardware | **Sin acceso.** Modelo de blade sin confirmar | | Decisión de qué vía se ejecuta | **Pendiente** | ### Qué está verificado - Los 18 ficheros YAML parsean correctamente - La plantilla de `docker-compose` renderiza YAML válido en **los dos modos de red**, con puertos e IPs bien asignados - `fleet.sh` pasa `bash -n` una vez renderizado, sin Jinja pendiente - El M1000e está identificado por su spec sheet oficial (Dell EMC, dic 2016) ### Qué NO está verificado Y conviene tenerlo claro antes de fiarse de nada: - **Nada se ha ejecutado contra hardware real.** Ni un blade, ni el sobremesa - Que las imágenes x86_64 de Android arranquen en la generación de CPU de estos blades — el riesgo real si resultan ser **M610** (Xeon 2009–2011) - El comportamiento de `macvlan` sobre los switches FlexIO concretos del chasis - Que 3 instancias por blade sean cómodas con 8 GB en carga real, no solo en el papel - **Las cifras de consumo son estimaciones.** El CMC da el dato real; media hora ahí sustituye todo `docs/costes.md` por medidas --- ## Las tres vías Ninguna elegida todavía. ### 1 · Device lab en el rack Infra legal y reutilizable. Primer uso real: probar `oasis_mobile` a escala, incluido el escenario de **dos APKs que se tienen que ver entre sí**. La automatización ya está escrita. **Bloqueante**: sitio con 2,6–3,6 kW, extracción y tolerancia a 70–85 dB. Ver [docs/requisitos.md](docs/requisitos.md). ### 2 · Charla sobre la economía de los bots Ángulo defensivo y periodístico, con demanda real. HackMadrid, hacklabs, **Hackmeeting València (9–12 oct 2026)**. El material está entero en `01_investigacion/`; el guion en [03_charla/](03_charla/). **Es la vía con menos fricción**: no necesita encender nada. ### 3 · Reward farming Ingreso pasivo, legal-gris. Márgenes malos en 2026. Documentado por completitud, no recomendado. --- ## Preguntas abiertas Por orden de lo que más desbloquea: 1. **¿Qué modelo de blade hay en el chasis?** M610 / M620 / M630. Determina CPU, generación y tipo de RAM — y si el proyecto es viable. → `ansible-playbook playbooks/preflight.yml` 2. **¿Responde el CMC en red?** Si sí, da el inventario completo y el **consumo real** 3. **¿Dónde va el chasis y quién asume la factura?** Es lo que decide, más que ninguna consideración técnica 4. **¿Cuánta utilización real va a tener?** Por debajo del ~11 % la nube sale más barata que tenerlo 24/7. Ver [docs/costes.md](docs/costes.md) --- ## Siguientes pasos concretos ### Sin tocar el hardware (se puede hacer hoy) - [ ] Lanzar el **piloto de un nodo** en un sobremesa: valida el pipeline entero por ~20 €/mes. El bloque está comentado en `02_device_lab/ansible/inventory/hosts.yml.example` - [ ] Con eso, confirmar que redroid arranca, que `fleet` habla con los contenedores y que un APK de `oasis_mobile` se instala en toda la flota - [ ] Preparar la charla — el material ya está ### Cuando haya acceso al chasis - [ ] Credenciales de fábrica del **CMC y de los 16 iDRAC** (`root`/`calvin`) — [docs/seguridad.md](docs/seguridad.md) S2 - [ ] VLAN aislada para la granja y **otra** para gestión — S1 y S3 - [ ] `preflight.yml` sobre los 16 blades → informe en `ansible/reports/` - [ ] Medir consumo real en el CMC y corregir `docs/costes.md` - [ ] Decidir sobre la ampliación de RAM: es lo único que cambia la economía del proyecto (7,6 € → 1,7 € por dispositivo/mes) ### Mejoras pendientes en el código - [ ] Fijar la imagen de redroid **por digest** en vez de por tag mutable — S6 - [ ] Cortafuegos (nftables) en los blades: 5555+ solo desde el coordinador — S1 - [ ] `ansible-vault` para secretos — S7 - [ ] Rol de GADS, cuando la flota pase de una decena de dispositivos. No está automatizado a propósito: montar un despliegue de Node sin poder probarlo es complejidad sin verificar - [ ] Provisión de Debian por PXE, para no instalar 16 blades a mano --- ## Convenciones **Documentación en castellano.** Es un repo de trabajo, no un producto. **Todo lo verificable, verificado, y lo demás dicho.** Si algo no se ha ejecutado, el documento lo dice. Las estimaciones van etiquetadas como estimaciones y con sus supuestos a la vista. Si encuentras una afirmación sin respaldo, es un fallo — corrígela o márcala. **Los hallazgos de seguridad se numeran** (S1…S11 en [docs/seguridad.md](docs/seguridad.md)) y se referencian por número desde el resto del repositorio. **Nada operativo de alta masiva de cuentas.** Ni proveedores de SIM, ni evasión de fingerprint, ni maduración. No es una postura moral: es que está bajo persecución activa en la UE y **no funciona** con este hardware, por lo que explica [01_investigacion/capa_identidad.md](01_investigacion/capa_identidad.md). --- ## Qué NO se sube al repositorio Está en `.gitignore`, pero conviene saber por qué: | | | |---|---| | `inventory/hosts.yml` | IPs reales de los blades y posibles credenciales. Solo va el `.example` | | `ansible/reports/` | Informes de preflight con el inventario real del hardware | | `*.apk` | Binarios | | `vault.yml`, `*.vault` | Secretos de ansible-vault |