# Guía de trabajo

## Estado

| Parte | Estado |
|---|---|
| Investigación | Cerrada, en `01_investigacion/` |
| Automatización Ansible | Escrita, sin ejecutar contra hardware |
| Requisitos, costes y seguridad | Cerrados |
| Hardware | Sin acceso. Modelo de blade sin confirmar |

### Verificado

- Los 19 ficheros YAML parsean
- 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
- Los 4 diagramas SVG parsean y renderizan sin desbordes
- Las especificaciones del chasis vienen del manual del propietario (Dell, BMX01, rev. A06,
  oct. 2019), no de estimaciones

### Sin verificar

- Nada se ha ejecutado contra hardware real
- Que las imágenes x86_64 de Android arranquen en la generación de CPU de estos blades. Es el
  riesgo si resultan ser M610 (Xeon 2009–2011)
- El comportamiento de `macvlan` sobre los módulos de I/O concretos del chasis
- Que 3 instancias por blade sean cómodas con 8 GB en carga real
- Las cifras de consumo son estimaciones. El CMC da el dato real

## Preguntas abiertas

1. **Modelo de blade**: M610 / M620 / M630. Determina CPU, generación y tipo de RAM.
   → `ansible-playbook playbooks/preflight.yml`
2. **Qué módulo hay en A1/A2**: un switch conmuta entre blades dentro del chasis, que es lo que
   necesita `macvlan`; un módulo de paso a través saca 16 RJ-45 y deja la conmutación a un switch
   externo. Cambia el montaje de red por completo
3. **¿Responde el CMC?** Da el inventario completo y el consumo real
4. **Dónde va el chasis y quién paga la luz.** El sitio tiene que estar por debajo de 35 °C todo
   el año
5. **Utilización prevista.** Por debajo del ~12 %, la nube sale más barata que tenerlo 24/7

## Siguientes pasos

### Sin hardware

- [ ] Lanzar el piloto de un nodo en un sobremesa. El bloque está comentado en
      `02_device_lab/ansible/inventory/hosts.yml.example`
- [ ] Confirmar que redroid arranca, que `fleet` habla con los contenedores y que un APK de
      `oasis_mobile` se instala en toda la flota

### Con acceso al chasis

- [ ] Cambiar credenciales de fábrica del CMC y de los 16 iDRAC (`root`/`calvin`) — S2
- [ ] VLAN aislada para la granja y otra para gestión — S1 y S3
- [ ] `preflight.yml` sobre los 16 blades
- [ ] Medir consumo real en el CMC y corregir `docs/costes.md`
- [ ] Decidir la ampliación de RAM: es lo único que cambia la economía (8,0 € → 1,8 € por
      dispositivo y mes)

### Pendiente en el código

- [ ] Fijar la imagen de redroid por digest en vez de por tag mutable — S6
- [ ] nftables en los blades: 5555+ solo desde el coordinador — S1
- [ ] `ansible-vault` para secretos — S7
- [ ] Script de encendido y apagado por ventanas contra el CMC vía RACADM
- [ ] Rol de GADS cuando la flota pase de una decena de dispositivos
- [ ] Provisión de Debian por PXE, para no instalar 16 blades a mano

## Convenciones

Documentación en castellano.

Lo verificable se verifica y lo demás se dice. Si algo no se ha ejecutado, el documento lo indica.
Las estimaciones van con sus supuestos a la vista.

Los hallazgos de seguridad se numeran (S1…S11 en [docs/seguridad.md](docs/seguridad.md)) y se
referencian por número.

Nada de operativa de alta masiva de cuentas: 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).

## Fuera del repositorio

| | |
|---|---|
| `inventory/hosts.yml` | IPs reales y posibles credenciales. Solo se versiona el `.example` |
| `ansible/reports/` | Informes de preflight con el inventario real |
| `*.apk` | Binarios |
| `vault.yml`, `*.vault` | Secretos de ansible-vault |