s1to 74bfbe9437 Rebelión en la granja — investigación y laboratorio de dispositivos

Investigación sobre granjas de dispositivos y automatización completa para
levantar un laboratorio Android sobre un chasis de blades Debian.

Conclusión que ordena el repositorio: el cuello de botella nunca fue el
cómputo sino la identidad. Desde que la atestación de dispositivo pasó de
estadística a criptográfica, un servidor no puede hacerse pasar por un
teléfono — le falta una clave grabada en fábrica que ningún software produce.

Contenido:

- 01_investigacion/ — capa de identidad (verificación telefónica, eSIM,
  reputación de IP, atestación por hardware, correlación entre cuentas),
  mercado y players, stack técnico, marco legal en la UE
- 02_device_lab/ansible/ — Ansible para 16 blades: preflight de solo lectura
  que identifica el hardware por DMI, despliegue de redroid en Docker y
  control de flota por adb. Solo ansible.builtin, sin colecciones externas
- docs/ — requisitos, costes y repaso de seguridad con 11 hallazgos
- 03_charla/ — guion para HackMadrid / Hackmeeting València

Estado: la automatización está escrita pero SIN ejecutar contra hardware.
YAML validado, plantillas renderizadas en ambos modos de red y fleet.sh
comprobado con bash -n. El modelo de blade sigue sin confirmar.

2026-08-08 19:42:14 +02:00

2.9 KiB

Raw Blame History

El hardware: Dell PowerEdge M1000e

Identificado el 2026-08-08. Fuente: ~/Downloads/poweredge-m1000e-spec-sheet.pdf (spec sheet oficial Dell EMC, 6 de diciembre de 2016).

No es un servidor suelto: es un chasis de blades. Cada blade es una máquina independiente con su CPU y su RAM.

Especificaciones del chasis


Factor de forma	Modular 10U — 44,0 alto × 44,7 ancho × 75,4 cm fondo
Capacidad	16 blades de media altura (8 arriba + 8 abajo) · u 8 de altura completa · o 32 de cuarto
Alimentación	Hasta 6 fuentes de 3.000 W / 2.700 W (config 3+3, 2+2, 2+1…)
Refrigeración	9 módulos de ventiladores redundantes
Gestión	CMC (Chassis Management Controller) + iDRAC por blade; web SSL, SSH/Telnet, LDAP/AD
Red interna	Hasta 6 módulos I/O FlexIO — los blades se ven entre sí a 1/10 GbE
Peso	44 kg vacío · 179 kg cargado

Configuración de esta máquina

Según lo que recuerda el usuario:

16 blades, 8 arriba y 8 abajo
8 GB de RAM por blade → 128 GB totales, pero repartidos, no agrupados
Modelo de blade: desconocido (M610 / M620 / M630 — pendiente de confirmar en el frontal)
Estado / ubicación / accesibilidad de red: pendiente

Qué implica para el device lab

A favor

16 máquinas independientes con red interna de chasis. Mejor topología que un solo host para el escenario de oasis_mobile con dos APKs que se tienen que ver entre sí: el switch FlexIO los pone en la misma L2 sin montar nada.
Con 8 GB por blade menos Debian + Docker (~1–1,5 GB), salen ~3 instancias redroid por blade → ~48 instancias totales. Casi el triple que el sobremesa (12–20).

En contra

Consumo: 1,5–2,5 kW en marcha. A precio doméstico en España, del orden de 160–350 €/mes si está 24/7. Este es el factor que decide la viabilidad, no los cores.
Ruido: no es máquina de casa. Necesita sala con extracción.
Sin GPU en los blades → redroid_gpu_mode=guest (render por software). Vale para test funcional, no para nada gráfico.
16 provisiones separadas: cada blade necesita su Debian + Docker + módulo binder. A partir de 4-5 blades esto pide Ansible o netboot, no hacerlo a mano.

La palanca real

El cuello de botella son los 8 GB por blade, no la CPU. Si los blades son M620 (DDR3 ECC), ampliar a 32 GB por blade cuesta poco en segunda mano y sube de ~3 a ~14 instancias por blade. Eso multiplica por 4-5 la capacidad del proyecto entero por menos de lo que cuesta un mes de luz.

Pendiente de averiguar

Modelo de blade (serigrafiado en el frontal) → determina CPU, generación y tipo de RAM
¿Está encendido y accesible el CMC en red? Si responde, da el inventario completo
Ubicación física y quién asume el coste eléctrico
Con eso: decidir si se levantan los 16 blades o solo 2-3 como piloto

2.9 KiB Raw Blame History Unescape Escape