From 7caa240c2e1c0585d5544a03f7b743514299733b Mon Sep 17 00:00:00 2001 From: s1to Date: Sat, 8 Aug 2026 19:58:25 +0200 Subject: [PATCH] =?UTF-8?q?Ajustar=20al=20manual=20del=20M1000e,=20a=C3=B1?= =?UTF-8?q?adir=20diagramas=20y=20docs=20de=20operaci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Especificaciones tomadas del manual del propietario del gabinete PowerEdge M1000e (Dell, modelo BMX01, rev. A06, oct. 2019), que corrige el spec sheet comercial usado hasta ahora. Hardware: - Peso máximo 200,5 kg, no 179. Profundidad 75,5 cm - Seis fuentes y nueve ventiladores obligatorios, se usen 3 blades o 16. Toda bahía vacía necesita relleno - Conector CEI/IEC C20 a 16 A. La fuente de 3.000 W exige 200-240 V - Irrupción de 55 A por fuente durante 10 ms: un magnetotérmico de curva C salta, hace falta curva D - Temperatura de funcionamiento continuo 10-35 °C - ECM obligatorio con blades M630 de 120 W o más, o por encima de 30 °C Red: - Fabric A (ranuras A1/A2) es la Ethernet integrada de cada blade, así que no hacen falta tarjetas intermedias. Fabrics B y C sí las exigirían y no se usan - Pendiente saber si en A1/A2 hay un switch o un módulo de paso a través: cambia el montaje de red por completo Costes recalculados: el suelo fijo del chasis sube de 350 a ~500 W al contar los nueve ventiladores, los módulos de I/O y las pérdidas de las seis fuentes. 360 €/mes a 24/7, 59 €/mes por ventanas. Que las fuentes y los ventiladores sean obligatorios convierte en hecho documentado lo que antes era estimación: los pilotos parciales en el chasis son el peor caso posible. Documentación: - assets/ con cuatro diagramas SVG propios: arquitectura, chasis, stack de software y modos de red - docs/usabilidad.md: órdenes, flujos de trabajo, problemas conocidos y ergonomía del hardware - Diagramas ASCII del panel frontal, el posterior y la topología de fabrics en hardware_m1000e.md - Eliminada la parte de charla y divulgación, fuera del alcance del repo --- 01_investigacion/capa_identidad.md | 80 ++++------ 01_investigacion/stack_tecnico.md | 2 +- 02_device_lab/README.md | 2 +- 02_device_lab/ansible/README.md | 11 ++ 02_device_lab/hardware_m1000e.md | 248 ++++++++++++++++++++++++----- 03_charla/README.md | 44 ----- GUIA.md | 156 +++++++----------- README.md | 177 ++++++++------------ assets/arquitectura.svg | 103 ++++++++++++ assets/chasis.svg | 106 ++++++++++++ assets/red-modos.svg | 67 ++++++++ assets/stack-software.svg | 61 +++++++ docs/README.md | 32 ++-- docs/costes.md | 110 +++++++------ docs/requisitos.md | 52 ++++-- docs/seguridad.md | 16 +- docs/usabilidad.md | 168 +++++++++++++++++++ 17 files changed, 1012 insertions(+), 423 deletions(-) delete mode 100644 03_charla/README.md create mode 100644 assets/arquitectura.svg create mode 100644 assets/chasis.svg create mode 100644 assets/red-modos.svg create mode 100644 assets/stack-software.svg create mode 100644 docs/usabilidad.md diff --git a/01_investigacion/capa_identidad.md b/01_investigacion/capa_identidad.md index b3d5f9d..05936da 100644 --- a/01_investigacion/capa_identidad.md +++ b/01_investigacion/capa_identidad.md @@ -1,30 +1,22 @@ # La capa de identidad: verificación, reputación de IP y atestación -El documento central del proyecto. Explica **por qué la identidad, y no el cómputo, es el único -cuello de botella real** de una granja — y cómo las tres capas que la componen se integran entre -sí para derrotarla. +Por qué la identidad, y no el cómputo, es el cuello de botella de una granja, y cómo se integran +las capas que la componen. -> **Alcance.** Esto describe cómo funcionan los mecanismos y por qué las granjas pierden contra -> ellos. No es un manual operativo de alta masiva de cuentas: no hay proveedores de SIM, ni -> técnicas de evasión de fingerprint, ni calendarios de maduración. Esa parte es fraude de -> identidad a escala y está bajo persecución activa en la UE — ver [legal_ue.md](legal_ue.md). -> Lo que sigue sirve para investigar, para defender y para dar la charla; para lo otro, no. +Alcance: esto describe cómo funcionan los mecanismos y por qué las granjas pierden contra ellos. +No es un manual operativo de alta masiva de cuentas — no hay proveedores de SIM, ni técnicas de +evasión de fingerprint, ni calendarios de maduración. Esa parte es fraude de identidad a escala y +está bajo persecución activa en la UE; ver [legal_ue.md](legal_ue.md). ---- - -## 0 · La tesis en una frase - -Una plataforma no te pregunta *quién eres*. Te pregunta tres cosas a la vez — -**¿controlas un número?**, **¿desde dónde llegas?**, **¿qué dispositivo eres?** — y luego, -la que de verdad mata: **¿en qué te pareces a los otros 44?** - -Las tres primeras se pueden atacar con dinero. La cuarta no, y es la que hunde el negocio. +Una plataforma no pregunta quién eres. Comprueba tres cosas —si controlas un número, desde dónde +llegas y qué dispositivo eres— y luego una cuarta: en qué te pareces a las otras cuentas. Las tres +primeras se atacan con dinero. La cuarta no, y es la que hunde el negocio. --- ## 1 · Verificación telefónica -### Qué se está comprobando de verdad +### Qué se comprueba El OTP por SMS no verifica tu identidad. Verifica que **controlas un número en el momento del alta**. Es una prueba de posesión, no de identidad. Pero detrás del número hay una cadena que sí @@ -49,8 +41,8 @@ evitable. Eso es lo que se revende como *número como servicio*. ### La eSIM: por qué NO es la respuesta -Es la pregunta que más se repite y la respuesta es contraintuitiva. **La eSIM es peor para una -granja que la SIM física**, y hay que entender el aprovisionamiento para ver por qué. +La eSIM es peor para una granja que la SIM física. Para ver por qué hay que mirar el +aprovisionamiento. Una eSIM no es un fichero que se copia. Es un **perfil** que se descarga a un chip concreto: @@ -76,7 +68,7 @@ Tres consecuencias que lo descartan: Resumen: la eSIM cambia un consumible anónimo y barato por un identificador de hardware trazable con contrato detrás. **Por eso el mercado sigue con plástico** — no por inercia, por diseño. -### Y aquí está el problema de fondo para un rack +### El problema para un rack Un contenedor redroid **no tiene banda base**. No hay módem, no hay IMEI legítimo, no puede recibir un SMS. Nunca. Así que el número y el dispositivo están **necesariamente desacoplados**: @@ -99,7 +91,7 @@ el dinero de comprarlas deja rastro. Detalle en [legal_ue.md](legal_ue.md). ## 2 · Reputación de IP -La segunda pregunta: *¿desde dónde llegas?* +La segunda pregunta: desde dónde llegas. ### Las tres clases de dirección @@ -125,14 +117,12 @@ bloqueo por daño colateral**. ### De dónde salen los proxies residenciales -Aquí está la parte turbia del sector, y es material de charla. La mayoría del inventario -residencial no viene de servidores: viene de **SDKs embebidos en apps gratuitas y VPNs -"gratuitas"**, que convierten el móvil del usuario en un nodo de salida a cambio de que la app sea +La mayoría del inventario residencial no viene de servidores: viene de SDKs embebidos en apps y +VPNs gratuitas, que convierten el móvil del usuario en nodo de salida a cambio de que la app sea gratis. El consentimiento suele estar enterrado en unos términos que nadie lee. -Es decir: cuando alguien compra tráfico residencial, muy probablemente está saliendo por la -conexión de una persona que no lo sabe. Eso ha generado litigios y es uno de los ángulos -periodísticos más fértiles del tema. +Cuando alguien compra tráfico residencial, muy probablemente está saliendo por la conexión de una +persona que no lo sabe. Eso ha generado litigios. ### Qué mira la plataforma, más allá de la clase @@ -148,13 +138,13 @@ MaxMind, IPQualityScore, Spur, IPinfo — que vende exactamente esto: - **Huella de transporte**: JA3/JA4 (el fingerprint del handshake TLS), orden de cabeceras HTTP, versión de la librería de red. Identifica al cliente por debajo de la aplicación -Ese último punto es el que sorprende: **no hace falta mirar la app para saber que no es la app.** +Con eso último no hace falta mirar la app para saber que no es la app. --- ## 3 · Atestación de dispositivo -La tercera pregunta: *¿qué dispositivo eres?* Y es donde la partida se decidió del todo. +La tercera pregunta: qué dispositivo eres. Es donde se decidió la partida. ### De SafetyNet a Play Integrity @@ -170,7 +160,7 @@ y la sustituyó por la **Play Integrity API**, que devuelve tres veredictos esca ### Qué significa "respaldada por hardware" -Aquí está la clave técnica del proyecto entero, y merece entenderla bien. +Es la clave técnica del proyecto entero. Un Android certificado sale de fábrica con una **clave privada de atestación grabada en su elemento seguro** — el TEE, o StrongBox si hay chip dedicado. Esa clave nunca sale del hardware. Cuando la @@ -192,7 +182,7 @@ real, sin sensor de luz que varíe. ### Por qué esto ya no es una carrera armamentística -Este es el punto que hay que subrayar, porque cambia la naturaleza del problema: +Esto cambia la naturaleza del problema: > La detección de emulador dejó de ser **estadística** y pasó a ser **criptográfica**. @@ -201,10 +191,8 @@ esquivar. Ahora es verificar una firma contra una raíz de confianza. **O tienes tienes.** No hay evasión posible, solo robo de claves de dispositivos reales, que es otro delito y otro mercado. -Y ahí está la explicación de la pregunta que abrió toda esta investigación: **por qué GenFarmer te -vende cajas con teléfonos físicos de 400 $ en vez de venderte software para tu servidor.** No es -que no sepan hacer software. Es que lo que venden no es cómputo, es **el único sitio donde vive la -clave**. +Explica también por qué GenFarmer vende cajas con teléfonos físicos de 400 $ en vez de software +para tu servidor: lo que venden no es cómputo, es el único sitio donde vive la clave. --- @@ -230,7 +218,7 @@ Las aristas que unen el grafo: - **Temporal**: cohortes de registro. 45 cuentas dadas de alta el mismo martes por la tarde ya son un grupo, aunque todo lo demás esté impecable -### La trampa matemática +### El problema de escala Fabricar **una** cuenta indistinguible de la de una persona real es caro pero factible. @@ -252,23 +240,15 @@ proxies de los móviles de terceros. Que es exactamente **lo que persiguen y por ## 5 · Qué significa para este proyecto -Sin rodeos, y es la conclusión que ordena todo el repositorio: - -**El rack no sirve para las plataformas sociales, y no por falta de potencia.** No tiene la clave. +El rack no sirve para las plataformas sociales, y no por falta de potencia: no tiene la clave. Ninguna cantidad de blades, RAM o ancho de banda produce una clave de atestación grabada en fábrica. La detección no es un umbral que se pueda esquivar, es una firma que no se puede falsificar. -**El rack sí sirve, y muy bien, como laboratorio de QA propio.** Probar `oasis_mobile` en una -matriz de versiones de Android, y el escenario multi-dispositivo de los dos APKs que se tienen que -ver entre sí, es exactamente para lo que 45 Android en red interna son inmejorables. Ahí no hay -ninguna atestación que superar: es tu app en tus dispositivos. - -**Y para la charla, esto es la tesis.** Ver [../03_charla/](../03_charla/): - -> La granja de bots perdió la guerra técnica el día que la atestación pasó de estadística a -> criptográfica. Lo que queda no es un problema de cómputo, es un problema de identidad — y quien -> controla las SIMs controla el mercado. Por eso ahí es exactamente donde pega la policía. +Sí sirve como laboratorio de QA propio. Probar `oasis_mobile` en una matriz de versiones de +Android, y el escenario multi-dispositivo de los dos APKs que se tienen que ver entre sí, es +exactamente para lo que 45 Android en red interna son buenos. Ahí no hay atestación que superar: +es tu app en tus dispositivos. --- diff --git a/01_investigacion/stack_tecnico.md b/01_investigacion/stack_tecnico.md index 4443331..14e2fbc 100644 --- a/01_investigacion/stack_tecnico.md +++ b/01_investigacion/stack_tecnico.md @@ -21,7 +21,7 @@ versiones nuevas de Android. - Encima: **Appium/UIAutomator2** para conducir, **scrcpy** para ver, **ADB sobre TCP** para todo. -## El jarro de agua fría +## Lo que un rack no resuelve Ese rack **no sirve** para el caso TikTok/Instagram, y esa es exactamente la razón por la que GenFarmer vende cajas con teléfonos físicos de $400 en vez de vender software para tu servidor. diff --git a/02_device_lab/README.md b/02_device_lab/README.md index 45f6ca7..8b46429 100644 --- a/02_device_lab/README.md +++ b/02_device_lab/README.md @@ -11,7 +11,7 @@ kernel de una máquina Debian. | | Para qué | |---|---| -| **[ansible/](ansible/)** | **La granja de verdad**: los 16 blades del M1000e, provisionados y controlados desde un sitio. Es lo que hay que usar. | +| [ansible/](ansible/) | Los 16 blades del M1000e, provisionados y controlados desde un sitio. Es la vía principal. | | Este documento | Un solo nodo, a mano. Sirve para entender las piezas y para trastear en el sobremesa. | El hardware está descrito en [hardware_m1000e.md](hardware_m1000e.md). diff --git a/02_device_lab/ansible/README.md b/02_device_lab/ansible/README.md index 5eed637..ec033c0 100644 --- a/02_device_lab/ansible/README.md +++ b/02_device_lab/ansible/README.md @@ -9,6 +9,8 @@ del blade. Es la única forma sensata de hacer esto con el hardware que hay. ## La arquitectura +![Arquitectura de la granja](../../assets/arquitectura.svg) + ``` Dell PowerEdge M1000e — 16 blades │ @@ -45,6 +47,13 @@ sudo apt install ansible - Salida a internet, o un mirror local de `download.docker.com` y `deb.debian.org` - Kernel con `binder_linux.ko` (el estándar de Debian lo trae) +**Chasis** — un módulo de I/O en **A1** como mínimo. La Fabric A es la Ethernet integrada (LOM) de +cada blade, así que **no hacen falta tarjetas intermedias**; las Fabrics B y C sí las exigirían y +no se usan aquí. Si en A1/A2 hay un módulo **switch**, la conmutación entre blades es interna al +chasis, que es lo que necesita `macvlan`. Si hay un módulo de **paso a través**, salen 16 RJ-45 al +exterior y la conmutación depende de un switch externo. Ver +[hardware_m1000e.md](../hardware_m1000e.md). + **Ejecuta siempre desde este directorio** (`ansible/`) — `ansible.cfg` y las rutas de roles son relativas a él. @@ -121,6 +130,8 @@ Se controla con `redroid_network_mode` en `group_vars/all.yml`. Cada Android detrás de NAT de Docker; adb en `:`, empezando en 5555. Funciona en cualquier sitio sin saber nada de la LAN. Es el modo con el que empezar. +![Los dos modos de red](../../assets/red-modos.svg) + ### `macvlan` — el que quieres para `oasis_mobile` Cada Android coge una **IP real de la LAN** a través del switch FlexIO del chasis. Los dos APKs diff --git a/02_device_lab/hardware_m1000e.md b/02_device_lab/hardware_m1000e.md index 014b189..34cd691 100644 --- a/02_device_lab/hardware_m1000e.md +++ b/02_device_lab/hardware_m1000e.md @@ -1,61 +1,235 @@ # 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). +> **Fuente**: *Gabinete Dell PowerEdge M1000e — Manual del propietario*, modelo reglamentario +> **BMX01**, rev. A06, octubre 2019 (© 2014-2019 Dell Inc.), más el spec sheet de dic. 2016. +> Los datos de esta página vienen del manual oficial y **sustituyen a las estimaciones previas**. -No es un servidor suelto: es un **chasis de blades**. Cada blade es una máquina independiente -con su CPU y su RAM. +No es un servidor suelto: es un **chasis de blades**. Cada blade es una máquina independiente con +su CPU y su RAM. Los ventiladores, las fuentes, la CMC y los módulos de I/O son **recursos +compartidos** de todos los blades. -## Especificaciones del chasis +--- + +## Panel frontal — los blades + +``` +┌──────────────────────────────────────────────────────────────────────────┐ +│ │ +│ ┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐ ┌───────┐ │ +│ │ 1 ││ 2 ││ 3 ││ 4 ││ 5 ││ 6 ││ 7 ││ 8 │ │ LCD │ │ +│ │ ││ ││ ││ ││ ││ ││ ││ │ │ panel │ │ +│ └────┘└────┘└────┘└────┘└────┘└────┘└────┘└────┘ │ ctrl │ │ +│ ┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐ │ │ │ +│ │ 9 ││ 10 ││ 11 ││ 12 ││ 13 ││ 14 ││ 15 ││ 16 │ │ 2×USB │ │ +│ │ ││ ││ ││ ││ ││ ││ ││ │ │ VGA │ │ +│ └────┘└────┘└────┘└────┘└────┘└────┘└────┘└────┘ └───────┘ │ +│ │ +└──────────────────────────────────────────────────────────────────────────┘ + 16 blades de media altura — 8 arriba y 8 abajo +``` + +El chasis admite **16 blades de media altura**, u 8 de altura completa, u 8 fundas de cuarto de +altura, o una combinación. + +> **Todos los compartimentos deben ir ocupados en todo momento**, con un blade o con un módulo de +> relleno. No es una recomendación estética: sin relleno, el aire se escapa por el hueco y la +> refrigeración del resto se degrada. + +--- + +## Panel posterior — la infraestructura compartida + +``` +┌──────────────────────────────────────────────────────────────────────────┐ +│ ┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐┌───┐ │ +│ │ V ││ V ││ V ││ V ││ V ││ V ││ V ││ V ││ V │ 9 módulos de ventilador │ +│ └───┘└───┘└───┘└───┘└───┘└───┘└───┘└───┘└───┘ (los 9, obligatorios) │ +│ │ +│ ┌──────────────┐ ┌─────────┐ ┌──────────────┐ │ +│ │ A1 B1 C1 │ │ CMC 1 │ │ C2 B2 A2 │ 6 módulos de I/O │ +│ │ │ │ iKVM │ │ │ + 2 CMC │ +│ │ (izquierda) │ │ CMC 2 │ │ (derecha) │ + iKVM opcional │ +│ └──────────────┘ └─────────┘ └──────────────┘ │ +│ │ +│ ┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐ │ +│ │PSU ││PSU ││PSU ││PSU ││PSU ││PSU │ 6 fuentes de alimentación │ +│ └────┘└────┘└────┘└────┘└────┘└────┘ (las 6, obligatorias) │ +└──────────────────────────────────────────────────────────────────────────┘ +``` + +Dos exigencias del manual que cambian el planteamiento del proyecto: + +> **«El sistema requiere seis fuentes de alimentación para su funcionamiento habitual.»** + +> **«Los nueve módulos de ventilador deben instalarse en todo momento para garantizar un +> enfriamiento adecuado.»** + +No se puede arrancar este chasis a medias. Seis fuentes, nueve ventiladores y todas las bahías +tapadas, se usen 3 blades o 16. Es el motivo técnico de por qué **los pilotos parciales en el +chasis son mal negocio** — ver [../docs/costes.md](../docs/costes.md). + +--- + +## Fabrics: cómo se conecta un blade a la red + +Esta es la parte del manual que más afecta al diseño del laboratorio. El M1000e tiene **tres +fabrics redundantes**, y no todas sirven para lo mismo: + +``` + blade-NN FABRICS exterior + ┌──────────────┐ + │ │ ┌──────────────────┐ + │ LOM NIC1 ──┼───────────►│ A1 (switch) │──────────────► LAN + │ (integrado) │ ├──────────────────┤ (uplink) + │ NIC2 ──┼───────────►│ A2 (switch) │──────────────► LAN + │ │ └──────────────────┘ (redundante) + │ │ FABRIC A — Ethernet + │ │ + │ mezz B ─────┼───────────► B1 / B2 1–40 Gb/s: FC, InfiniBand, 10 GbE + │ mezz C ─────┼───────────► C1 / C2 1–40 Gb/s: ídem + └──────────────┘ requieren tarjeta intermedia en el blade +``` + +**Para este proyecto solo importa la Fabric A**, y es una buena noticia: + +- Fabric A es la **Ethernet integrada de cada blade** (la LOM). No hace falta comprar ni instalar + tarjetas intermedias. +- Soporta KR (10 Gbps estándar). +- Sus ranuras son **A1 y A2**. Con un módulo en A1 basta para arrancar; A1 + A2 da redundancia. +- Las Fabrics B y C **necesitan tarjeta intermedia en cada blade**. Si el chasis no las trae, no se + usan — y para 45 Android por adb no hacen ninguna falta. + +**Lo que hay que verificar en el chasis real**: qué módulo hay en A1/A2. Un módulo de switch +(PowerConnect M6220 / M6348, Force10 MXL, M8024-k…) da conmutación interna entre blades, que es +justo lo que necesita el modo `macvlan`. Un **módulo de paso a través** en cambio saca 16 puertos +RJ-45 al exterior, uno por blade, y entonces la conmutación depende de un switch externo. + +> Los módulos pensados para Fabric B o C **no entran físicamente** en A1/A2 — el manual dice que +> están codificados por color en la placa frontal para evitarlo. + +--- + +## Especificaciones oficiales + +### Físicas | | | |---|---| -| 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 | +| Altura | 44,0 cm (17,3") — **10U** | +| Anchura | 44,7 cm (17,6") | +| Profundidad | 75,5 cm (29,7") | +| **Peso máximo** | **200,5 kg** (442 lb) | +| Peso vacío | 44,6 kg (98,1 lb) | + +> El peso máximo corregido son **200,5 kg**, no los 179 kg del spec sheet comercial. El manual +> manda: el rack y el suelo tienen que ir sobrados. + +### Alimentación + +| | Fuente de 2.700 W | Fuente de 3.000 W | +|---|---|---| +| Conector | **CEI/IEC C20** | IEC 320 | +| Tensión de entrada | 100–240 V CA, **16 A** | **200–240 V CA**, 16 A | +| Frecuencia | 50/60 Hz | 50/60 Hz | +| Disipación propia | 353 W (1.205 BTU/h) máx. | 1.200 BTU/h máx. | +| **Corriente de irrupción** | **55 A durante ≤10 ms, por fuente** | ídem | + +Tres consecuencias prácticas: + +1. **La fuente de 3.000 W exige 200–240 V.** España a 230 V vale; una instalación a 110 V no. +2. **Seis entradas C19/C20.** Hace falta una PDU adecuada — los C13 domésticos no valen. +3. **La corriente de irrupción es el detalle que se olvida**: 55 A por fuente durante 10 ms. Con + seis fuentes arrancando a la vez, un magnetotérmico de curva C salta. Hace falta **curva D**, o + arranque escalonado de las fuentes. + +### Ambientales — el requisito que muerde en verano + +| | | +|---|---| +| **Funcionamiento continuo** | **10 °C a 35 °C**, humedad relativa 10–80 % | +| Ampliado, <10 % de las horas anuales | 5 °C a 40 °C | +| Ampliado, <1 % de las horas anuales | −5 °C a 45 °C | +| Almacenamiento | −40 °C a 65 °C | +| Derating por altitud | −1 °C cada 300 m por encima de 900 m | + +**35 °C es el techo continuo.** Una habitación en Madrid en agosto, con 2,6 kW de calor dentro y +sin climatización, se pone por encima de eso sin dificultad. El rango ampliado cubre menos del +10 % de las horas del año: no es una solución, es un margen para incidencias. + +### Modo de refrigeración mejorado (ECM) + +La CMC permite activar **ECM**, que exige los nueve ventiladores de tercera generación. El manual +lo declara **obligatorio** en tres casos: + +- Blades **M630 con procesadores de 120 W o más** +- Blades **M630 en entornos por encima de 30 °C** +- Cualquier configuración con aire fresco + +ECM significa más caudal, y por tanto **más consumo y más ruido**. Si los blades resultan ser M630 +y el sitio pasa de 30 °C, hay que contarlo. + +### Gestión — CMC + +| | | +|---|---| +| Módulos | CMC 1 (principal) + CMC 2 (secundaria, a prueba de fallos) | +| Puertos | Dos RJ-45 10/100/1000: **Gb** a la red de gestión, **STK** para encadenar chasis contiguos | +| Serie | 9 patas DTE, compatible 16550 | +| Vídeo | VGA 15 patas | +| Batería | CR2032 | +| Interfaces | Web (SSL), **RACADM** por CLI, SSH/Telnet | + +La CMC **reasigna energía entre módulos según la demanda** y expone presupuesto de alimentación y +política de redundancia en *Chassis → Power Management → Configuración*. Es también donde se lee el +**consumo real**, que es lo que sustituye a las estimaciones de [../docs/costes.md](../docs/costes.md). + +--- ## Configuración de esta máquina -Según lo que recuerda el usuario: +| | | +|---|---| +| Blades | 16, 8 arriba y 8 abajo | +| RAM por blade | 8 GB → 128 GB totales, **repartidos, no agrupados** | +| Modelo de blade | **desconocido** — M610 / M620 / M630. Lo resuelve `preflight.yml` leyendo DMI | +| Módulo en A1/A2 | **desconocido** — switch o paso a través. Determina si `macvlan` funciona sin switch externo | +| Estado del CMC | **desconocido** | -- **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** +El manual menciona explícitamente compatibilidad con **M610x**, **M630** y **M710HD**, así que el +abanico de blades posibles es amplio y la generación no se puede inferir del chasis. + +--- ## 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). +- 16 máquinas independientes con **conmutación interna por Fabric A**, sin comprar tarjetas + intermedias. Es la topología ideal para el escenario de `oasis_mobile` con **dos APKs que se + tienen que ver entre sí**: quedan en la misma L2 sin montar nada. +- Con 8 GB por blade menos Debian y Docker, **~3 instancias redroid por blade → ~45 en total**. ### 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. +- **Seis fuentes y nueve ventiladores obligatorios**, se usen 3 blades o 16. El coste fijo no baja + al usar menos. +- **Consumo 2,6–3,6 kW**, del orden de 360 €/mes a 24/7. +- **Techo térmico de 35 °C** continuos. +- **Sin GPU** en los blades → `redroid_gpu_mode=guest`, render por software. +- **16 provisiones separadas** — de ahí el Ansible. -### La palanca real +### La palanca sigue siendo la misma -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. +El cuello de botella son **los 8 GB por blade, no la CPU**. Ampliar a 32 GB sube de ~3 a +~14 instancias por blade: de 45 a 210 Android por el mismo recibo de la 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 +- [ ] **Modelo de blade** → `ansible-playbook playbooks/preflight.yml` +- [ ] **Qué módulo hay en A1/A2** (switch o paso a través) → determina si `macvlan` necesita switch externo +- [ ] ¿Están las 6 fuentes y los 9 ventiladores? ¿Y los rellenos en las bahías vacías? +- [ ] ¿Responde el CMC? Da inventario completo y **consumo real** +- [ ] ¿Hay ventiladores de 3.ª generación, por si hace falta ECM? +- [ ] Ubicación: potencia, PDU con 6 tomas C19, magnetotérmico de curva D y temperatura bajo 35 °C diff --git a/03_charla/README.md b/03_charla/README.md deleted file mode 100644 index 4d6d5c5..0000000 --- a/03_charla/README.md +++ /dev/null @@ -1,44 +0,0 @@ -# Charla: la economía de las granjas de bots - -Vía 2. Ángulo defensivo/periodístico, no operativo. Hay demanda real de esto y encaja con -HackMadrid, los hacklabs y **Hackmeeting València (9–12 oct 2026)**. - -## Tesis - -La granja de bots perdió la guerra técnica y la ganó la económica. La detección de emulador es -determinista desde 2025 (Play Integrity con atestación por hardware), así que el negocio se vio -forzado a volver al hardware físico, caro y lento. Lo que queda no es un problema de cómputo sino -de identidad: **quien controla las SIMs controla el mercado** — y por eso ahí es donde pega la -policía. - -## Guion propuesto - -1. **Las tres cosas que llamamos "phone farm"** — reward farming / device lab / account farming. - Desmontar la confusión de entrada. -2. **El catálogo real** — GenFarmer y PhoneFarmBox como material de clase: qué venden, a qué - precio, qué revela su marketing (Zalo, Telegram-only, "300+ dispositivos"). -3. **Por qué no puedes hacerlo con un servidor** — atestación por hardware, sensores, baseband. - El momento en que el cómputo dejó de ser el cuello de botella. -4. **La capa SIM** — el eslabón débil, con KYC en origen y rastro de dinero. -5. **SIMCARTEL** — 1.200 SIM-boxes, 40.000 SIMs, 49 millones de cuentas falsas, 7 detenidos. - El caso que cierra el argumento. -6. **Qué significa para quien defiende** — cómo se ve una granja desde el otro lado y qué señales - deja. - -## Material - -El sustrato de los puntos 3, 4 y 5 está entero en -**[../01_investigacion/capa_identidad.md](../01_investigacion/capa_identidad.md)** — verificación -telefónica, por qué la eSIM no vale, reputación de IP, atestación por hardware y la correlación -entre cuentas. Es el documento del que sale la tesis. - -El resto en [../01_investigacion/](../01_investigacion/); las fuentes citables en -[../01_investigacion/fuentes.md](../01_investigacion/fuentes.md). - -## Pendiente - -- [ ] Decidir formato y duración -- [ ] Contactar HackMadrid / CFP de Hackmeeting València -- [ ] Buscar cifras actualizadas de 2026 (los datos son de oct 2025) -- [ ] ¿Demo en vivo? El device lab de [../02_device_lab/](../02_device_lab/) sirve para enseñar - cómo se detecta un emulador diff --git a/GUIA.md b/GUIA.md index c6d9a9c..d242905 100644 --- a/GUIA.md +++ b/GUIA.md @@ -1,137 +1,91 @@ # 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 +## Estado | 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** | +| 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 | -### Qué está verificado +### 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) +- 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 -### Qué NO está verificado +### Sin verificar -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. - ---- +- 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 -Por orden de lo que más desbloquea: +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 -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 ---- +### Sin hardware -## Siguientes pasos concretos +- [ ] 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 -### Sin tocar el hardware (se puede hacer hoy) +### Con acceso al chasis -- [ ] 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/` +- [ ] 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 sobre la ampliación de RAM: es lo único que cambia la economía del proyecto - (7,6 € → 1,7 € por dispositivo/mes) +- [ ] Decidir la ampliación de RAM: es lo único que cambia la economía (8,0 € → 1,8 € por + dispositivo y mes) -### Mejoras pendientes en el código +### Pendiente 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 +- [ ] 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 -- [ ] 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 +- [ ] 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.** Es un repo de trabajo, no un producto. +Documentación en castellano. -**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. +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 desde el resto del repositorio. +Los hallazgos de seguridad se numeran (S1…S11 en [docs/seguridad.md](docs/seguridad.md)) y se +referencian por número. -**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** +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). ---- - -## Qué NO se sube al repositorio - -Está en `.gitignore`, pero conviene saber por qué: +## Fuera del repositorio | | | |---|---| -| `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 | +| `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 | diff --git a/README.md b/README.md index 3d4a14c..8da5681 100644 --- a/README.md +++ b/README.md @@ -1,151 +1,114 @@ # Rebelión en la granja -Investigación y laboratorio sobre **granjas de dispositivos**: qué son realmente, quién las -fabrica, qué se puede montar con hardware propio y qué no, y por qué la partida técnica ya está -decidida. +Laboratorio de dispositivos Android sobre un chasis de blades Dell PowerEdge M1000e, más la +investigación sobre granjas de dispositivos que llevó a montarlo así. -Incluye la automatización completa para levantar un **laboratorio de dispositivos Android** sobre -un chasis de blades Debian — legal, reutilizable y sin un solo móvil físico. +Sin móviles físicos: cada dispositivo es un contenedor +[redroid](https://github.com/remote-android/redroid-doc) — Android real sobre el kernel del blade. -Arrancado el 2026-08-07 a raíz de dos webs del sector: -[phonefarmbox.com](https://www.phonefarmbox.com/) y [genfarmer.com](https://genfarmer.com/). +## Arquitectura ---- - -## La conclusión, por delante - -> **El cuello de botella nunca fue el cómputo. Fue la identidad.** -> -> Desde que la atestación de dispositivo pasó de ser estadística a ser **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. Por eso el mercado vende cajas con teléfonos físicos de 400 $ en lugar -> de software para tu rack. -> -> Lo que queda es un problema de SIMs, de reputación de IP y de correlación entre cuentas. Y ahí es -> exactamente donde pega la policía. - -El desarrollo está en **[01_investigacion/capa_identidad.md](01_investigacion/capa_identidad.md)**, -que es el documento central del repositorio. - ---- - -## Qué hay aquí - -### 📄 [docs/](docs/) — léelo antes de encender nada - -| | | -|---|---| -| [requisitos.md](docs/requisitos.md) | Eléctrico, físico, hardware, red, tiempo. Con checklist de bloqueantes | -| [costes.md](docs/costes.md) | La luz es el coste real: ~340 €/mes 24/7, ~56 €/mes por ventanas | -| [seguridad.md](docs/seguridad.md) | 11 hallazgos, uno crítico. Incluye los que introduce este propio código | - -### 🔍 [01_investigacion/](01_investigacion/) — el análisis - -| | | -|---|---| -| [capa_identidad.md](01_investigacion/capa_identidad.md) | **El documento central.** Verificación telefónica, por qué la eSIM no vale, reputación de IP, atestación por hardware y la correlación entre cuentas | -| [mercado_y_players.md](01_investigacion/mercado_y_players.md) | Los tres negocios bajo el mismo nombre, quién juega en Europa, TikTok vs Instagram | -| [stack_tecnico.md](01_investigacion/stack_tecnico.md) | redroid, Cuttlefish, Waydroid, GADS — y por qué el rack no resuelve el caso social | -| [legal_ue.md](01_investigacion/legal_ue.md) | DSA, Operación SIMCARTEL, riesgo penal en España | -| [fuentes.md](01_investigacion/fuentes.md) | Enlaces | - -### 🔧 [02_device_lab/](02_device_lab/) — el laboratorio - -| | | -|---|---| -| [ansible/](02_device_lab/ansible/) | **La automatización completa**: preflight, despliegue de los 16 blades y control de flota | -| [hardware_m1000e.md](02_device_lab/hardware_m1000e.md) | El chasis, sus límites y la palanca (RAM) | -| [README.md](02_device_lab/README.md) | Montaje de un solo nodo, a mano, para entender las piezas | - -### 🎤 [03_charla/](03_charla/) — divulgación - -Guion de 6 puntos para HackMadrid / Hackmeeting València. - ---- - -## Especificaciones - -### Arquitectura +![Arquitectura de la granja](assets/arquitectura.svg) ``` -Dell PowerEdge M1000e — chasis de blades, 16 slots (8 arriba + 8 abajo) +Dell PowerEdge M1000e — 16 blades (8 arriba + 8 abajo) │ -├── blade-01 ................ COORDINADOR -│ └── adb + fleet único punto de control de toda la flota +├── blade-01 ................ coordinador: adb + fleet │ -└── blade-02 .. blade-16 .... NODOS DE CARGA (15) - └── Debian 12 pelado +└── blade-02 .. blade-16 .... nodos de carga + └── Debian 12 └── Docker - └── N × redroid Android 13 en contenedor + └── N × redroid - 8 GB/blade → 3 instancias → ~45 Android - 32 GB/blade → 14 instancias → ~210 Android + 8 GB/blade → 3 instancias → 45 Android + 32 GB/blade → 14 instancias → 210 Android ``` -**No hay móviles físicos.** Cada "dispositivo" es un contenedor -[redroid](https://github.com/remote-android/redroid-doc): Android real sobre el kernel del blade. +Debian va directo sobre el hierro. Sin Proxmox, sin VMs, sin LXC anidado: con 8 GB por blade cada +capa de hipervisor se come una instancia entera. -Debian va **directo sobre el hierro**. Sin Proxmox, sin VMs, sin LXC anidado — con 8 GB por blade, -cada capa de hipervisor se come una instancia Android entera. +## Hardware -### Stack +![Dell PowerEdge M1000e](assets/chasis.svg) + +Datos del manual del propietario del M1000e (Dell, modelo BMX01, rev. A06, oct. 2019). Dos +exigencias del manual condicionan el proyecto entero: las seis fuentes y los nueve ventiladores son +obligatorios, se usen 3 blades o 16. No se puede arrancar el chasis a medias. + +Detalle en [02_device_lab/hardware_m1000e.md](02_device_lab/hardware_m1000e.md). + +## Software + +![Stack de software](assets/stack-software.svg) | Capa | Tecnología | |---|---| -| Hardware | Dell PowerEdge M1000e, 16 blades, 8 GB/blade | | SO | Debian 12 bookworm | | Kernel | `binder_linux` con devices `binder,hwbinder,vndbinder` (Debian no trae binderfs) | | Contenedores | Docker CE + Compose v2 | -| Android | redroid 13 (memfd, sin ashmem) | -| Orquestación | Ansible — solo `ansible.builtin`, sin colecciones externas | +| Android | redroid 13 | +| Orquestación | Ansible, solo `ansible.builtin` | | Control | adb sobre TCP + `fleet` | -| Red | `portmap` (NAT) o `macvlan` (IP real de LAN por el switch FlexIO) | +| Red | `portmap` (NAT) o `macvlan` (IP real de LAN por Fabric A) | -### Números +## Red + +![Los dos modos de red](assets/red-modos.svg) + +## Números | | | |---|---| -| Capacidad | ~45 Android (~210 con la RAM ampliada) | -| Consumo | 2,6–3,6 kW · 70–85 dB · 179 kg · 10U | -| Coste 24/7 | ~340 €/mes (~4.100 €/año) | -| Coste por ventanas de 4 h/día | ~56 €/mes | -| Coste por dispositivo | 7,6 €/mes → **1,7 €/mes** con la RAM ampliada | +| Capacidad | 45 Android; 210 con la RAM ampliada | +| Chasis | 10U · 44,0 × 44,7 × 75,5 cm · 200,5 kg cargado | +| Consumo | 2,6–3,6 kW · 70–85 dB · 6 fuentes C20 · 9 ventiladores | +| Térmico | 10–35 °C en continuo | +| Coste 24/7 | ~360 €/mes | +| Coste por ventanas de 4 h/día | ~59 €/mes | +| Coste por dispositivo | 8,0 €/mes; 1,8 €/mes con la RAM ampliada | ---- - -## Arranque rápido +## Arranque ```bash git clone https://gitea.laenre.net/hacklab/REBELION_EN_LA_GRANJA.git cd REBELION_EN_LA_GRANJA/02_device_lab/ansible sudo apt install ansible -cp inventory/hosts.yml.example inventory/hosts.yml # pon las IPs reales +cp inventory/hosts.yml.example inventory/hosts.yml # poner las IPs reales -ansible-playbook playbooks/preflight.yml # SOLO LECTURA — no toca nada -ansible-playbook site.yml # monta la granja +ansible-playbook playbooks/preflight.yml # solo lectura, no toca nada +ansible-playbook site.yml ansible-playbook playbooks/status.yml ``` -**Empieza por el preflight siempre.** Te dice qué blades hay dentro del chasis leyéndolo del DMI, -si esas CPUs pueden con Android x86_64, y cuántas instancias caben. Antes de gastar un minuto. +El preflight va primero. Identifica el modelo de blade leyéndolo del DMI, comprueba si esas CPUs +sirven para Android x86_64 y calcula cuántas instancias caben. -**Y antes de encender el chasis**, el inventario trae un bloque de **piloto de un nodo** para -probar el pipeline entero en un sobremesa, por 20 €/mes y sin ruido. +Para probar sin encender el chasis, el inventario incluye un bloque de piloto de un nodo que +levanta todo el pipeline en un sobremesa. -Guía de trabajo y siguientes pasos: **[GUIA.md](GUIA.md)**. +## Contenido ---- +| | | +|---|---| +| [GUIA.md](GUIA.md) | Estado, qué está verificado y qué no, siguientes pasos | +| [docs/requisitos.md](docs/requisitos.md) | Eléctrico, físico, red, tiempo. Checklist de bloqueantes | +| [docs/costes.md](docs/costes.md) | Consumo y coste por escenario | +| [docs/seguridad.md](docs/seguridad.md) | 11 hallazgos, uno crítico | +| [docs/usabilidad.md](docs/usabilidad.md) | Cómo se opera la flota | +| [02_device_lab/ansible/](02_device_lab/ansible/) | La automatización | +| [02_device_lab/hardware_m1000e.md](02_device_lab/hardware_m1000e.md) | El chasis según el manual | +| [01_investigacion/](01_investigacion/) | Mercado, stack, capa de identidad, marco legal | -## Aviso +## Por qué esto no sirve para plataformas sociales -Este repositorio documenta cómo funcionan las granjas de dispositivos y **por qué fracasan** contra -las plataformas. La automatización que contiene levanta un laboratorio de QA para probar apps -propias. +La atestación de dispositivo dejó de ser estadística y pasó a ser criptográfica. Un Android +certificado lleva una clave privada grabada en el TEE de fábrica, con cadena de certificados hasta +una raíz de Google. Un contenedor no la tiene y no puede tenerla: no hay software que la produzca. -No contiene, ni va a contener, operativa de alta masiva de cuentas: proveedores de SIM, evasión de -fingerprint o maduración de cuentas. Eso es fraude de identidad a escala, en la UE está bajo -persecución activa, y además **no funcionaría** con este hardware por lo que se explica en -[capa_identidad.md](01_investigacion/capa_identidad.md). +Por eso el mercado vende teléfonos físicos de 400 $ en lugar de software para racks, y por eso este +laboratorio sirve para probar apps propias y no para otra cosa. El desarrollo está en +[01_investigacion/capa_identidad.md](01_investigacion/capa_identidad.md). -Contexto legal: [legal_ue.md](01_investigacion/legal_ue.md). +Este repositorio no contiene operativa de alta masiva de cuentas. Contexto legal en +[01_investigacion/legal_ue.md](01_investigacion/legal_ue.md). diff --git a/assets/arquitectura.svg b/assets/arquitectura.svg new file mode 100644 index 0000000..51439c4 --- /dev/null +++ b/assets/arquitectura.svg @@ -0,0 +1,103 @@ + + + + Arquitectura de la granja + Dell PowerEdge M1000e · 16 blades Debian · ~45 Android en contenedor + + + + CHASIS M1000e · 10U · 200,5 kg · 2,6–3,6 kW + + + + blade-01 · COORDINADOR + Debian 12 · adb · fleet.sh · devices.txt + No corre Android. Único punto de control de la flota. + + + blade-02 … blade-16 · NODOS DE CARGA (15) + + + + blade-NN · 8 GB RAM + + + Debian 12 · sobre el hierro + binder · hwbinder · vndbinder + + + Docker CE + Compose v2 + + + redroid-NN-01 · Android 13 + + redroid-NN-02 · Android 13 + + redroid-NN-03 · Android 13 + + Sin VM ni LXC anidado: cada capa + se comería una instancia entera. + + + + + + + + + blade-03 → 3 Android + blade-04 → 3 Android + blade-05 → 3 Android + … + blade-16 → 3 Android + + + 15 × 3 = 45 Android + con RAM a 32 GB → 15 × 14 = 210 + + + + FABRIC A · ranuras A1 / A2 · Ethernet integrada (LOM) de cada blade + Conmutación interna entre blades, sin tarjetas intermedias. Hace posible macvlan. + Fabrics B y C (FC / InfiniBand) no se usan aquí. + + + + + + + + + + + + + + + + + Nodo de control + Ansible (solo builtin) + preflight.yml → reconocer + site.yml → desplegar + apk.yml → instalar APK + status.yml → comprobar + SSH → los 16 blades + forks = 20: la flota entera + en paralelo + + + Control de flota + fleet connect + fleet list + fleet install app.apk + fleet shell '<cmd>' + fleet ip + + + Sin móviles físicos + Cada dispositivo es un + contenedor redroid sobre + el kernel del blade. + Detectables como emulador. + diff --git a/assets/chasis.svg b/assets/chasis.svg new file mode 100644 index 0000000..f046dbe --- /dev/null +++ b/assets/chasis.svg @@ -0,0 +1,106 @@ + + + + Dell PowerEdge M1000e + Manual del propietario, modelo BMX01, rev. A06 (oct. 2019) · 44,0 × 44,7 × 75,5 cm · 10U · 200,5 kg cargado + + + PANEL FRONTAL — los blades + + + + + + + 1 + coord. + + + + + + + + + + + + 234 + 5678 + + + + + + + + + + + + + + + 9101112 + 13141516 + + + + + LCD + panel control + asistente config + 2 × USB + VGA + + 16 blades de media altura — 8 arriba y 8 abajo. Toda bahía vacía necesita módulo de relleno o se degrada la refrigeración. + + + PANEL POSTERIOR — infraestructura compartida + + + + + + + + + + + + + VENT 1VENT 2VENT 3 + VENT 4VENT 5VENT 6 + VENT 7VENT 8VENT 9 + + + + + A1 B1 C1 + módulos de I/O (izquierda) + + + CMC 1 · iKVM + CMC 2 + + + C2 B2 A2 + módulos de I/O (derecha) + + + Fabric A → Ethernet + B/C → FC · IB + + + + + + + + + PSU 1PSU 2PSU 3 + PSU 4PSU 5PSU 6 + + + Obligatorio por manual: las 6 fuentes y los 9 ventiladores instalados en todo momento — con 3 blades o con 16. + diff --git a/assets/red-modos.svg b/assets/red-modos.svg new file mode 100644 index 0000000..2f6e03c --- /dev/null +++ b/assets/red-modos.svg @@ -0,0 +1,67 @@ + + + + Los dos modos de red + redroid_network_mode en group_vars/all.yml + + + + portmap · por defecto + NAT de Docker. Funciona en cualquier sitio. + + + blade-02 · 10.0.0.12 + + + redroid-01 (interno) + + redroid-02 (interno) + + redroid-03 (interno) + + + + + :5555 + :5556 + :5557 + puertos del blade + + adb → 10.0.0.12:5555, :5556, :5557 + ✓ No hace falta saber nada de la LAN + ✓ redroid_adb_bind_ip limita la escucha + ✗ Los Android están tras NAT: no son + pares de red entre sí + + + + macvlan · para oasis_mobile + IP real de LAN por el switch de Fabric A. + + + blade-02 · 10.0.0.12 + + + redroid-01 → 10.0.0.20 + + redroid-02 → 10.0.0.21 + + redroid-03 → 10.0.0.22 + + + + + LAN + directo a la red + + adb → 10.0.0.20:5555, .21:5555, .22:5555 + ✓ Los dos APKs se ven como pares reales + ✓ Lo más cerca de "dos móviles en la misma wifi" + ✗ El anfitrión NO habla con sus propios + contenedores macvlan → coordinador aparte + + + + S1 · adb no tiene autenticación y los contenedores son privilegiados + Quien alcance el puerto 5555 acaba siendo root en el blade. En macvlan, bind_ip no aplica: la única defensa es una VLAN aislada. + diff --git a/assets/stack-software.svg b/assets/stack-software.svg new file mode 100644 index 0000000..154b90d --- /dev/null +++ b/assets/stack-software.svg @@ -0,0 +1,61 @@ + + + + Stack de software + Todo software libre. Sin colecciones externas de Ansible, sin dependencias de pago. + + + + redroid 13 + Android 13 en contenedor · memfd (sin ashmem) · ~2 GB por instancia + + + Docker CE + Compose v2 + Repo oficial de Docker · compose generado por plantilla Jinja + + + binder_linux + devices: binder, hwbinder, vndbinder + Debian trae el módulo pero SIN binderfs → hay que cargarlos a mano. Aquí es donde esto se atasca. + + + Debian 12 bookworm + Directo sobre el blade. Sin Proxmox, sin VM, sin LXC anidado. + + + Blade Dell · Fabric A + Ethernet integrada (LOM) → ranuras A1 / A2 del chasis + + + + ×15 nodos + de carga + + + + Orquestación + + Ansible + solo ansible.builtin + 6 roles · 7 playbooks + + adb sobre TCP + del coordinador a + toda la flota + + fleet.sh + connect · list · install + shell · ip · reboot + + scrcpy + ver y tocar una + instancia concreta + + GADS · Appium (pendiente) + + + + Lo que este stack NO puede hacer + Ninguna instancia pasa la atestación por hardware: no hay TEE, ni arranque verificado, ni banda base, ni clave de fábrica. + Sirve para probar tus propias apps. Para plataformas con atestación, no — y no es cuestión de potencia. Ver capa_identidad.md + diff --git a/docs/README.md b/docs/README.md index 707ee70..9dcca1c 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,25 +1,23 @@ # Docs -Lo que hay que leer antes de encender nada. - | | | |---|---| -| **[requisitos.md](requisitos.md)** | Qué hace falta: eléctrico, físico, hardware, software, red, accesos y tiempo. Con checklist de bloqueantes. | -| **[costes.md](costes.md)** | Lo que cuesta tenerlo en marcha, por escenario y por dispositivo. La luz es el coste real del proyecto. | -| **[seguridad.md](seguridad.md)** | Repaso de seguridad con 11 hallazgos, incluidos los que introduce el código de este proyecto. | +| [requisitos.md](requisitos.md) | Eléctrico, físico, hardware, red, accesos y tiempo. Checklist de bloqueantes | +| [costes.md](costes.md) | Consumo y coste por escenario y por dispositivo | +| [seguridad.md](seguridad.md) | 11 hallazgos, incluidos los que introduce el código de este proyecto | +| [usabilidad.md](usabilidad.md) | Cómo se opera la flota una vez montada | -## Las tres conclusiones, en corto +## Resumen -**Requisitos** — el bloqueante no es técnico: el chasis pide 2,6–3,6 kW, más de lo que tiene -contratado una vivienda española, y hace 70–85 dB. Sin un sitio con potencia, extracción y -tolerancia al ruido, la vía es el piloto en el sobremesa. +**Requisitos.** El bloqueante no es técnico. El chasis pide 2,6–3,6 kW —más de lo que tiene +contratado una vivienda española—, hace 70–85 dB y su techo térmico continuo son 35 °C. El manual +obliga además a las seis fuentes y los nueve ventiladores, se usen 3 blades o 16. -**Costes** — la granja completa 24/7 son **~340 €/mes**, unos 4.100 € al año: entre tres y ocho -veces lo que vale el hierro de segunda mano. Encendida **por ventanas** baja a ~56 €/mes. Y con -8 GB por blade, el sobremesa sale más barato por dispositivo que el chasis; solo la ampliación de -RAM invierte eso. +**Costes.** La granja completa 24/7 son ~360 €/mes, unos 4.300 € al año: más de lo que vale el +hierro de segunda mano. Por ventanas de 4 h/día baja a ~59 €/mes. Con 8 GB por blade el sobremesa +sale más barato por dispositivo que el chasis; solo la ampliación de RAM invierte eso. -**Seguridad** — hay un hallazgo **crítico**: adb no tiene autenticación y los contenedores son -privilegiados, así que quien alcance el puerto 5555 de un blade acaba siendo root en él. Se ha -mitigado a medias en el código (`redroid_adb_bind_ip`); lo que lo cierra de verdad es una **VLAN -aislada**. Y antes de eso, cambiar las credenciales de fábrica del CMC y de los 16 iDRAC. +**Seguridad.** Un hallazgo crítico: adb no tiene autenticación y los contenedores son +privilegiados, así que quien alcance el puerto 5555 de un blade acaba siendo root en él. Mitigado a +medias con `redroid_adb_bind_ip`; lo cierra una VLAN aislada. Antes de eso, cambiar las +credenciales de fábrica del CMC y de los 16 iDRAC. diff --git a/docs/costes.md b/docs/costes.md index 05de800..6dd84ef 100644 --- a/docs/costes.md +++ b/docs/costes.md @@ -3,8 +3,8 @@ El hardware ya está. El coste real de este proyecto es **la luz**, y no es pequeño. > **Todas las cifras de consumo son estimaciones.** El M1000e reporta consumo real por chasis y por -> blade desde el CMC — antes de comprometerse con nada, hay que mirar ahí. Es media hora de trabajo -> y sustituye todo este documento por datos. +> blade desde el CMC (*Chassis → Power Management*) — antes de comprometerse con nada, hay que +> mirar ahí. Es media hora de trabajo y sustituye todo este documento por datos. --- @@ -12,12 +12,28 @@ El hardware ya está. El coste real de este proyecto es **la luz**, y no es pequ | | | |---|---| -| Consumo fijo del chasis | 350 W (ventiladores, CMC, switches, pérdidas de las fuentes) — rango 250–500 W | +| **Consumo fijo del chasis** | **500 W** — rango 350–700 W | | Consumo por blade con Android en marcha | 140 W — rango 100–200 W | | Precio de la electricidad | **0,18 €/kWh** — rango 0,15–0,22 según tarifa y tramo | | Horas al mes | 730 | | Reparto | 1 blade coordinador + N de carga × 3 instancias | +### De dónde sale el consumo fijo + +El manual del M1000e obliga a tener **las seis fuentes y los nueve ventiladores instalados en todo +momento**, se use un blade o dieciséis. Ese suelo lo componen: + +- **9 módulos de ventilador**, con clasificación de 12 V a 5,0–6,3 A cada uno. A régimen moderado, + del orden de 150–250 W en conjunto; a plena velocidad, mucho más +- **Módulos de I/O** — un switch de fabric consume del orden de 50–150 W, y hay al menos uno +- **CMC** (una o dos) e iKVM +- **Pérdidas de conversión de las seis fuentes** — el manual da 353 W de disipación máxima por + fuente de 2.700 W + +Si los blades resultan ser **M630 y el sitio pasa de 30 °C**, el manual exige activar **ECM** +(modo de refrigeración mejorado), que sube el caudal de los ventiladores — y con él, el consumo y +el ruido. Ese caso se iría al extremo alto del rango. + --- ## Coste mensual por escenario, 24/7 @@ -25,43 +41,45 @@ El hardware ya está. El coste real de este proyecto es **la luz**, y no es pequ | Escenario | Blades | Potencia | kWh/mes | **€/mes** | Android | **€/Android/mes** | |---|---|---|---|---|---|---| | Solo sobremesa, chasis apagado | 0 | 150 W | 110 | **20 €** | 8 | **2,5 €** | -| Piloto en el chasis | 3 | 770 W | 562 | **101 €** | 6 | **16,9 €** | -| Media granja | 8 | 1.470 W | 1.073 | **193 €** | 21 | **9,2 €** | -| Granja completa | 16 | 2.590 W | 1.891 | **340 €** | 45 | **7,6 €** | -| Completa + RAM a 32 GB | 16 | 2.750 W | 2.008 | **361 €** | **210** | **1,7 €** | +| Piloto en el chasis | 3 | 920 W | 672 | **121 €** | 6 | **20,2 €** | +| Media granja | 8 | 1.620 W | 1.183 | **213 €** | 21 | **10,1 €** | +| Granja completa | 16 | 2.740 W | 2.000 | **360 €** | 45 | **8,0 €** | +| Completa + RAM a 32 GB | 16 | 2.900 W | 2.117 | **381 €** | **210** | **1,8 €** | -Granja completa 24/7: **~4.100 €/año**. +Granja completa 24/7: **~4.300 €/año**. -### Tres cosas que dice esta tabla +Tres lecturas: -**El sobremesa gana al chasis por dispositivo — hasta que se amplíe la RAM.** 2,5 €/Android en el -sobremesa contra 7,6 € en el chasis completo. Con 8 GB por blade, encender el M1000e para hacer lo -que ya hace el sobremesa es pagar tres veces más por dispositivo. - -**Los pilotos en el chasis son el peor negocio de todos.** Los 350 W fijos se pagan igual con 3 -blades que con 16, así que el piloto sale a 16,9 € por Android — casi siete veces el sobremesa. Si -se enciende el chasis, se enciende entero; y para probar, se usa el sobremesa. - -**La ampliación de RAM es lo único que cambia la ecuación.** De 7,6 € a 1,7 € por Android, por el -mismo recibo de la luz. No ahorra dinero: multiplica por 4,7 lo que se obtiene por el dinero que ya -se está gastando. +- **El sobremesa gana al chasis por dispositivo** hasta que se amplíe la RAM: 2,5 € contra 8,0 €. + Con 8 GB por blade, encender el M1000e para hacer lo que ya hace el sobremesa es pagar tres veces + más por dispositivo. +- **Los pilotos parciales son el peor caso.** El manual obliga a las seis fuentes y los nueve + ventiladores estén los blades que estén, así que el suelo de ~500 W se paga con 3 blades igual + que con 16: el piloto sale a 20 € por Android. Si se enciende el chasis, se enciende entero; para + probar se usa el sobremesa. +- **La ampliación de RAM es lo único que cambia la ecuación**: de 8,0 € a 1,8 € por Android con + prácticamente el mismo recibo. No ahorra dinero, multiplica por 4,4 lo que se obtiene por el que + ya se gasta. --- ## El modo que sí sale a cuenta: encendido bajo demanda -El CMC permite encender y apagar blades individualmente. Un laboratorio de QA no necesita 45 -Android a las cuatro de la mañana. +La CMC permite encender y apagar blades individualmente y fijar presupuesto de alimentación. Un +laboratorio de QA no necesita 45 Android a las cuatro de la mañana. -| Uso | Potencia | kWh/mes | €/mes | €/Android/mes | -|---|---|---|---|---| -| 24/7 | 2.590 W | 1.891 | 340 € | 7,6 € | -| **4 h/día** | 2.590 W | 311 | **56 €** | **1,2 €** | -| 8 h/día laborables | 2.590 W | 456 | 82 € | 1,8 € | +| Uso | kWh/mes | €/mes | €/Android/mes | +|---|---|---|---| +| 24/7 | 2.000 | 360 € | 8,0 € | +| **4 h/día** | 329 | **59 €** | **1,3 €** | +| 8 h/día laborables | 482 | 87 € | 1,9 € | **Ventanas de prueba en vez de servicio permanente**: el coste cae seis veces y el proyecto pasa de inviable a trivial. Es como debería operarse esto salvo que aparezca una razón para lo contrario. +Ojo: apagar blades **no ahorra el suelo de ~500 W** si el chasis sigue encendido. El ahorro de +verdad es apagar el chasis entero entre ventanas. + --- ## Costes de una vez @@ -69,10 +87,12 @@ inviable a trivial. Es como debería operarse esto salvo que aparezca una razón | Concepto | Coste | Notas | |---|---|---| | **RAM 8 → 32 GB × 16 blades** | **320–640 €** | Si son M620 (DDR3 ECC): ~10–20 € el módulo de 16 GB de segunda mano, 2 por blade. Si son M630 (DDR4): 800–1.300 € | +| **PDU con 6 tomas C19** | 80–250 € | Las fuentes usan **CEI/IEC C20**; los C13 domésticos no valen | +| **Magnetotérmico de curva D** | 20–60 € | La irrupción es de **55 A por fuente durante 10 ms**; una curva C salta | +| Módulos de relleno para bahías vacías | 5–15 €/ud. | Obligatorios según el manual. Si faltan, se compran | | SSD por blade, si faltan | ~400 € | 16 × ~25 € | -| PDU con tomas C19 + cableado | 50–150 € | Las fuentes del M1000e no usan C13 | | Subida de potencia contratada | 10–50 € | Derecho de cambio, una vez | -| **Total realista** | **~400–1.200 €** | Sin contar los SSD si los blades ya tienen disco | +| **Total realista** | **~450–1.400 €** | Sin contar los SSD si los blades ya tienen disco | Coste fijo adicional: subir de 3,45 a 6,9 kW contratados añade **~130 €/año** solo en término de potencia, se use o no. @@ -83,26 +103,23 @@ potencia, se use o no. | Opción | Coste | Cuándo tiene sentido | |---|---|---| -| **Sobremesa, 8 Android** | ~20 €/mes | Desarrollo diario y pruebas de `oasis_mobile`. Silencioso, ya encendido. | -| **Chasis bajo demanda, 45 Android** | ~56 €/mes + 400–1.200 € de entrada | Matrices de prueba grandes, escenarios multi-dispositivo | -| **Chasis 24/7, 45 Android** | ~340 €/mes | Solo si algo tiene que estar servido permanentemente | -| **Device farm en la nube** | ~0,09 €/dispositivo-hora | Uso esporádico. 45 dispositivos 24/7 saldrían por ~2.950 €/mes: diez veces el chasis | +| **Sobremesa, 8 Android** | ~20 €/mes | Desarrollo diario y pruebas de `oasis_mobile`. Silencioso, ya encendido | +| **Chasis bajo demanda, 45 Android** | ~59 €/mes + 450–1.400 € de entrada | Matrices de prueba grandes, escenarios multi-dispositivo | +| **Chasis 24/7, 45 Android** | ~360 €/mes | Solo si algo tiene que estar servido permanentemente | +| **Device farm en la nube** | ~0,09 €/dispositivo-hora | Uso esporádico. 45 dispositivos 24/7 saldrían por ~2.950 €/mes: ocho veces el chasis | | **Teléfonos físicos tipo GenFarmer** | 396–1.364 $/dispositivo | Otro producto: son los únicos que pasan atestación de hardware. 45 dispositivos = 17.800–61.400 $ | -**El punto de equilibrio con la nube** está en torno al **11 % de utilización**: si cada dispositivo -se usa más de ~84 horas al mes, el chasis 24/7 sale más barato. Por debajo, la nube gana. Y por -debajo del 11 %, lo que gana de verdad es encender el chasis solo cuando haga falta. +**El punto de equilibrio con la nube** está en torno al **12 % de utilización**: si cada dispositivo +se usa más de ~89 horas al mes, el chasis 24/7 sale más barato. Por debajo, la nube gana. Y por +debajo de eso, lo que gana de verdad es encender el chasis solo cuando haga falta. --- -## El dato incómodo +## Hierro contra electricidad -Un M1000e con 16 blades vale hoy de segunda mano entre **500 y 1.500 €**. - -Tenerlo encendido 24/7 durante un año cuesta **~4.100 € de luz**. - -**La electricidad de un año cuesta entre tres y ocho veces lo que vale el hierro.** Eso no es un -argumento para tirarlo — es un argumento para no dejarlo encendido por defecto. +Un M1000e con 16 blades vale hoy de segunda mano entre 500 y 1.500 €. Tenerlo encendido 24/7 +durante un año cuesta unos 4.300 € de luz: entre tres y nueve veces lo que vale el hardware. No es +argumento para tirarlo, sino para no dejarlo encendido por defecto. --- @@ -113,7 +130,8 @@ argumento para tirarlo — es un argumento para no dejarlo encendido por defecto ruido. Ver [ansible/README.md](../02_device_lab/ansible/README.md). 3. **Encender el chasis solo con un caso concreto que el sobremesa no cubra** — matriz de versiones de Android, o el escenario multi-dispositivo de los dos APKs a escala real. -4. **Si se enciende, encenderlo entero y por ventanas.** Los 350 W fijos hacen que los pilotos - parciales sean el peor negocio. -5. **La RAM antes que nada más.** 400 € que multiplican por 4,7 la capacidad sin tocar el recibo. +4. **Si se enciende, encenderlo entero y por ventanas.** Las seis fuentes y los nueve ventiladores + son obligatorios por manual: el suelo de ~500 W hace que los pilotos parciales sean el peor + negocio posible. +5. **La RAM antes que nada más.** ~400 € que multiplican por 4,4 la capacidad sin tocar el recibo. Pero primero hay que saber qué blades son — lo dice `playbooks/preflight.yml`. diff --git a/docs/requisitos.md b/docs/requisitos.md index 302df28..d52d0a2 100644 --- a/docs/requisitos.md +++ b/docs/requisitos.md @@ -5,21 +5,44 @@ es lo que descarta el proyecto antes que ninguna consideración técnica. --- -## 1 · Eléctrico y físico — lee esto primero +## 1 · Eléctrico y físico + +Datos del *Manual del propietario del M1000e* (Dell, rev. A06, oct. 2019). | Requisito | Detalle | |---|---| | **Potencia contratada** | El chasis completo tira **2,6–3,6 kW**. Un domicilio español típico tiene **3,45 kW contratados**: no da. Hace falta subir a 6,9 kW o más, o un local con suministro trifásico. | +| **Fuentes** | **Seis, obligatorias.** El manual: *«El sistema requiere seis fuentes de alimentación para su funcionamiento habitual.»* No es opcional ni escalable. | +| **Tensión** | Fuente de 3.000 W: **200–240 V CA, 16 A**. Fuente de 2.700 W: 100–240 V, 16 A. España a 230 V vale. | +| **Conectores** | **CEI/IEC C20** — hace falta una **PDU con 6 tomas C19**. Los C13 domésticos no valen. | +| **Corriente de irrupción** | **55 A por fuente durante ≤10 ms.** Con seis arrancando a la vez, un magnetotérmico de **curva C salta**: hace falta **curva D** o arranque escalonado. | | **Circuito** | Dedicado. Nada de compartir con el resto de la instalación. | -| **Tensión y conectores** | Dell recomienda **208–240 V** para el M1000e. España a 230 V vale. Fuentes con conectores **C19/C20**, no los C13 normales. | -| **Espacio** | **10U** de rack, con raíles capaces de aguantar el peso. | -| **Peso** | **179 kg cargado.** El rack tiene que soportarlo y el suelo también. | -| **Refrigeración** | 2,6 kW de consumo son 2,6 kW de calor: como dos radiadores eléctricos a tope. Necesita extracción real, no una ventana. | -| **Ruido** | 70–85 dB con los 9 ventiladores en marcha. **No es una máquina de vivienda.** | +| **Espacio** | **10U** de rack (44,0 × 44,7 × 75,5 cm) | +| **Peso** | **200,5 kg cargado** (44,6 kg vacío). Dato del manual — el spec sheet comercial decía 179 kg y se queda corto. Raíles y suelo tienen que ir sobrados. | +| **Temperatura** | **10 °C a 35 °C en continuo.** Ampliado a 40 °C solo <10 % de las horas del año, y a 45 °C solo <1 %. | +| **Refrigeración** | **Nueve módulos de ventilador, obligatorios los nueve.** 2,6 kW de consumo son 2,6 kW de calor: como dos radiadores eléctricos a tope. Extracción real, no una ventana. | +| **Bahías vacías** | **Todas tapadas con módulo de relleno.** Sin ellos el aire se escapa por el hueco y se degrada la refrigeración del resto. | +| **Ruido** | 70–85 dB con los 9 ventiladores. **No es una máquina de vivienda.** | > **Esto es lo que decide.** Si no hay sitio con potencia, extracción y tolerancia al ruido, el > resto de este documento no importa: la vía es el piloto en el sobremesa. +### Consecuencias + +**Seis fuentes y nueve ventiladores, siempre.** No se puede arrancar el chasis a medias para +"probar con tres blades": el coste fijo se paga igual. O entero, o nada — y para probar está el +sobremesa. + +**35 °C es el techo continuo.** Una habitación en Madrid en agosto, con 2,6 kW de calor dentro y +sin climatización, se pasa de ahí sin dificultad. El rango ampliado cubre menos del 10 % de las +horas del año: es margen para incidencias, no una solución. + +### ECM — modo de refrigeración mejorado + +El manual lo exige si los blades son **M630 con CPUs de 120 W o más**, o si el entorno pasa de +**30 °C**. Requiere los nueve ventiladores de tercera generación, y significa **más consumo y más +ruido**. Depende del modelo de blade, que aún no está confirmado. + --- ## 2 · Hardware @@ -29,10 +52,16 @@ es lo que descarta el proyecto antes que ninguna consideración técnica. Dell PowerEdge M1000e — ver [hardware_m1000e.md](../02_device_lab/hardware_m1000e.md). - 16 blades de media altura (8 arriba + 8 abajo) -- Al menos 2 fuentes (mejor 3+3 en redundancia) -- Módulos de I/O FlexIO con conectividad entre blades y hacia la LAN +- **Las 6 fuentes** y **los 9 ventiladores**, más rellenos en toda bahía vacía +- **Un módulo de I/O en A1** como mínimo (A1 + A2 para redundancia). Fabric A es la Ethernet + integrada de los blades, así que **no hacen falta tarjetas intermedias** - CMC accesible +> **Ojo con qué módulo hay en A1/A2.** Un módulo **switch** (M6220, M6348, MXL, M8024-k…) conmuta +> entre blades dentro del chasis, que es justo lo que necesita el modo `macvlan`. Un módulo de +> **paso a través** saca 16 RJ-45 al exterior y deja la conmutación en manos de un switch externo. +> Cambia el montaje de red por completo. + ### Por blade | | Mínimo | Recomendado | @@ -124,9 +153,12 @@ Mantenimiento posterior: 2–4 h al mes. **Bloqueantes** — si alguno falla, el proyecto no sale: -- [ ] Sitio con potencia suficiente, extracción y tolerancia al ruido +- [ ] Sitio con potencia suficiente, extracción y **temperatura por debajo de 35 °C todo el año** +- [ ] Tolerancia a 70–85 dB - [ ] Alguien asume la factura eléctrica (ver [costes.md](costes.md)) -- [ ] Rack de 10U que aguante 179 kg +- [ ] Rack de 10U que aguante **200,5 kg** +- [ ] **PDU con 6 tomas C19** y magnetotérmico de **curva D** (irrupción de 55 A por fuente) +- [ ] Las 6 fuentes, los 9 ventiladores y los rellenos, presentes - [ ] Los blades arrancan y el CMC responde **Antes de encender**: diff --git a/docs/seguridad.md b/docs/seguridad.md index 21f281a..419a509 100644 --- a/docs/seguridad.md +++ b/docs/seguridad.md @@ -25,7 +25,7 @@ Incluye los fallos que introduce el propio código de este proyecto, no solo los ## S1 · adb sin autenticación sobre contenedor privilegiado — **crítico** -El fallo más serio, y es una cadena de tres eslabones que por separado parecen asumibles: +Una cadena de tres eslabones que por separado parecen asumibles: 1. **adb no tiene autenticación** cuando escucha en TCP. Quien llega al puerto, entra. 2. **Las imágenes de redroid son `userdebug`**, así que `adb root` funciona: shell de root dentro @@ -33,19 +33,17 @@ El fallo más serio, y es una cadena de tres eslabones que por separado parecen 3. **El contenedor es `privileged: true`** — redroid lo exige para acceder a binder. Un privilegiado ve los devices del anfitrión y puede montar su sistema de ficheros. -Encadenado: **cualquiera que alcance el puerto 5555 de un blade acaba siendo root en ese blade.** -No hace falta ningún exploit, solo `adb connect`. +Encadenado: cualquiera que alcance el puerto 5555 de un blade acaba siendo root en ese blade, sin +exploit, solo con `adb connect`. Con 45 dispositivos son 45 puertas. -Y con 45 dispositivos son 45 puertas. - -**Qué se ha corregido hoy.** El compose ataba adb a `0.0.0.0` — todas las interfaces. Ahora hay -`redroid_adb_bind_ip`, así que se puede atar solo a la interfaz interna del chasis: +Corregido en parte: el compose ataba adb a `0.0.0.0`. Ahora hay `redroid_adb_bind_ip`, que permite +atarlo solo a la interfaz interna del chasis: ```yaml blade-02: { ansible_host: 10.0.0.12, redroid_adb_bind_ip: 10.0.0.12 } ``` -**Qué falta, y es lo que de verdad cierra el agujero:** +**Lo que cierra el agujero:** - **Red de laboratorio aislada.** VLAN propia para la granja, sin ruta hacia la LAN de casa ni hacia internet salvo lo imprescindible. Es la medida que importa; el resto son parches. @@ -84,7 +82,7 @@ cada Android **con IP real en la red**, cada uno con S1 encima. - VLAN dedicada para la granja, con el coordinador como único puente. - Reservar el rango de IPs en el DHCP, o habrá colisiones con máquinas reales. -- No usar la LAN de casa. Nunca. +- No usar la LAN doméstica. --- diff --git a/docs/usabilidad.md b/docs/usabilidad.md new file mode 100644 index 0000000..9131bb5 --- /dev/null +++ b/docs/usabilidad.md @@ -0,0 +1,168 @@ +# Usabilidad + +Cómo se trabaja con esto en el día a día. No la instalación —eso está en +[ansible/README.md](../02_device_lab/ansible/README.md)— sino **cómo se usa una vez montado**, y +qué decisiones de diseño hacen que sea llevadero o insufrible. + +--- + +## Un solo punto de control + +45 dispositivos son ingobernables si hay que entrar a cada blade. Por eso **todo pasa por el +coordinador**: + +``` + tú coordinador 45 Android + ┌────┐ ssh ┌──────────────────┐ adb ┌───┬───┬───┐ + │ │ ──────────► │ fleet · adb │ ─────────► │ · │ · │ · │ + └────┘ │ devices.txt │ └───┴───┴───┘ + └──────────────────┘ +``` + +`devices.txt` lo genera Ansible a partir del inventario y de la RAM real de cada blade. Nunca se +edita a mano: si cambia la flota, se relanza `playbooks/coordinator.yml` y se regenera. + +--- + +## Órdenes + +```bash +fleet connect # conecta adb a toda la flota +fleet list # qué hay conectado, y cuántos faltan +fleet install app.apk # instala en todos +fleet shell '' # ejecuta en todos +fleet ip # IP de cada Android +fleet reboot # reinicia todo +``` + +Todas son **idempotentes o inocuas**. `connect` se puede lanzar mil veces. Ninguna borra nada. +La única destructiva del proyecto es `playbooks/destroy.yml`, y exige `-e confirmar=si`. + +### Por qué `fleet list` dice "declarados" y "conectados" + +``` +declarados: 45 · conectados: 43 +``` + +Esa resta es el diagnóstico más útil del sistema. Si no cuadra, hay dos contenedores caídos y se +sabe al instante, sin mirar 15 blades. El siguiente paso es `playbooks/status.yml`, que dice en +qué nodo. + +--- + +## Flujos de trabajo reales + +### Probar una APK nueva en toda la flota + +```bash +ansible-playbook playbooks/apk.yml -e apk_local_path=~/oasis-0.9.1.apk +``` + +Un solo comando desde el portátil: copia el APK al coordinador, conecta la flota e instala en los +45. Sale un recuento de `ok` / `FALLO` por dispositivo. + +### El caso de los dos APKs que se tienen que ver + +Es el que motivó el proyecto. Con `redroid_network_mode: macvlan`: + +```bash +fleet ip # cada Android con su IP real de LAN +fleet install oasis-A.apk # ...o instalar distinto en cada mitad +adb -s 10.0.0.20:5555 install oasis-B.apk +``` + +Los dos se ven como **pares de red de verdad**, no a través de traducciones. Es lo más cerca de +"dos móviles en la misma wifi" sin tener dos móviles. + +### Mirar una instancia concreta + +```bash +scrcpy -s 10.0.0.20:5555 +``` + +Ventana con la pantalla del Android, ratón y teclado. Para depurar algo visual no hay nada mejor. + +### Comprobar una propiedad en toda la flota + +```bash +fleet shell 'getprop ro.build.version.release' +fleet shell 'pm list packages | grep oasis' +``` + +--- + +## Decisiones de diseño + +| Decisión | Por qué | +|---|---| +| **Preflight de solo lectura** | Se puede lanzar contra hardware ajeno sin miedo. Contesta "¿qué hay aquí y sirve?" sin tocar nada | +| **Instancias automáticas por RAM** | No hay que calcular ni mantener un número por blade. Se amplía la RAM y el siguiente despliegue se ajusta solo | +| **`fleet` en el PATH** | `fleet list`, no `/opt/granja/fleet.sh list` | +| **Playbooks pequeños y con nombre obvio** | `preflight`, `provision`, `devices`, `apk`, `status`, `destroy`. Se adivina cuál usar | +| **Todo relanzable** | `site.yml` es idempotente. Ante la duda, se relanza | +| **Errores que dicen qué hacer** | El fallo de binder no dice "error": dice que el módulo estaba en uso, que la config persistente ya está escrita y que basta reiniciar ese blade | +| **`destroy.yml` conserva los datos** | Borrar `/data` exige un segundo flag. Lo destructivo nunca es el camino por defecto | + +--- + +## Problemas conocidos + +Ordenados por probabilidad. Están documentados porque son inevitables, no porque sean fallos. + +### 1 · Binder, la primera vez + +**Síntoma**: el playbook falla con "faltan devices binder tras el modprobe". + +**Causa**: el módulo ya estaba cargado y en uso, así que no se pudo recargar con los parámetros +nuevos. + +**Solución**: la configuración persistente ya quedó escrita. Reinicia ese blade y relanza. Pasa una +sola vez por máquina. + +### 2 · macvlan: el anfitrión no ve a sus propios contenedores + +**Síntoma**: adb desde un blade no encuentra los Android de ese mismo blade. + +**Causa**: limitación del driver macvlan, no un error de configuración. + +**Solución**: no es un problema en este diseño — el coordinador es un blade **distinto** y desde +fuera sí se llega. Por eso `apk.yml` se ejecuta siempre desde el coordinador. Si algún día montas +adb en un nodo de carga, es esto. + +### 3 · El primer arranque de redroid tarda + +**Síntoma**: `fleet connect` falla justo después de `site.yml`. + +**Causa**: un Android recién creado tarda en levantar por primera vez, sobre todo con render por +software y 45 a la vez. + +**Solución**: esperar y reintentar. `fleet connect` es inocuo y se puede repetir. + +--- + +## Ergonomía del hardware + +Cosas que no son software pero deciden si esto se usa o se abandona: + +**El ruido manda.** 70–85 dB significa que no se puede estar en la misma habitación sin protección. +Todo el trabajo tiene que ser remoto — de ahí que no haya nada en el diseño que exija tocar el +chasis en marcha. + +**El LCD frontal es el mejor amigo en el arranque.** Configura la red de la CMC con su asistente, +sin cable serie ni portátil enganchado. Es el camino corto la primera vez. + +**Encender por ventanas cambia el hábito.** Si el chasis no está siempre en marcha (y no debería, +ver [costes.md](costes.md)), el flujo pasa a ser: encender → esperar arranque → `fleet connect` → +trabajar → apagar. Merece la pena tener eso en un script y no en la cabeza. + +--- + +## Pendiente + +- **GADS** — UI web con la flota, vista de pantallas y Appium integrado. Es el salto de calidad + cuando se pasa de una decena de dispositivos. No está automatizado a propósito: montar un + despliegue de Node sin poder probarlo sería complejidad sin verificar +- **Script de encendido/apagado por ventanas** contra la CMC vía RACADM +- **`fleet watch`** — un panel de estado que se refresque solo +- **Registro de auditoría en `fleet`** — hoy no deja rastro de quién hizo qué (hallazgo S10 en + [seguridad.md](seguridad.md))