Guía de la consola de operadores AeroNyx Nodeboard
Opera nodos de privacidad descentralizados AeroNyx con una consola orientada a flujos para registro, atención de flota, capacidad, evidencia de relay cifrado, mantenimiento seguro y cierre de incidentes.
Nodeboard es la consola operativa de los nodos de privacidad descentralizados AeroNyx. Convierte registro, salud agregada, capacidad, evidencia del protocolo, mantenimiento y cierre de incidentes en flujos repetibles sin exponer tráfico de usuarios ni contenido cifrado. Abre app.aeronyx.network. Un panel solo demuestra lo que reporta su fuente actual; configuración, runtime readiness y evidencia observada son estados distintos.
Alcance y modelo operativo
Trabaja en tres niveles. Dashboard indica si la flota requiere atención. Services compara un dominio de servicio o capacidad entre los nodos propios. Node detail explica un nodo y contiene evidencia, controles e historial de auditoría. Los nodos sanos deben permanecer silenciosos; el historial proof y la línea temporal de comandos pertenecen al detalle. Nodeboard administra nodos asociados al operador autenticado, no es un explorador público de tráfico.
Registrar un nodo
Crea un código breve en Registration Codes y usa el comando generado o el instalador oficial. Sigue por separado planning, instalación, registro, arranque del servicio, heartbeat y admission. Cuando aparezca el nodo, confirma región, visibilidad pública, versión runtime, source commit, capacidad y salud. El código vincula un único onboarding; no es una API key reutilizable y el secreto consumido no debe volver a mostrarse.
Empezar por la atención de flota
Prioriza: heartbeat offline o stale; comando failed, timeout o stale; maintenance con active sessions; packet drops o presión de IP pool, conntrack, file descriptors o disco; policy drift; discordancia discovery/relay; y después evidencia de recovery/proof envejecida. Stale, not reported y disabled no significan cero ni saludable. Abre el elemento de mayor impacto y define impacto al usuario y condición verificable de cierre.
Usar Services y el detalle del nodo
Services agrupa Privacy Network, Discovery & Relay, MemChain & Storage y Runtime. Compara nodos y abre el detalle para revisar timestamp de la fuente, policy sync, riesgos, estado de comandos y recuperación. Todo incidente requiere señal, impacto, acción y cierre. Un exit code cero no basta: deben recuperarse heartbeat fresco, salud del servicio, endpoint del protocolo y capacidad afectada.
Decidir capacidad y placement
La capacidad sirve para admission, no para vanidad. Revisa IP pool usado/libre, max_connections, policy max_sessions, active sessions, conntrack, file descriptors, packet drops, pps/bps, política de ancho de banda, disco, memoria y CPU. Distingue límites runtime de política comercial; cero puede significar unlimited según el backend. Muestra Accepting, Limited, Drain o Maintenance con su razón y no infieras actividad individual desde tasas agregadas.
Leer discovery y evidencia de relay cifrado
Separa configured capability, signed advertisement, endpoint reachability, estabilidad de probes, observación de relay cifrado real, terminal client receipt y continuidad tras restart. Un synthetic probe demuestra una ruta de prueba, no tráfico de usuario. OnionMiddle es un relay cifrado sin salida; requiere peer API alcanzable, ChatRelay listo, descriptor firmado, peers routeable y evidencia fresca. No expongas hops, social graph, payload ni identidad del cliente.
Leer MemChain y evidencia de commitment
MemChain puede mostrar si sealed storage, commitment follower, witnesses, quota, cleanup y recovery están configurados y frescos. Son funciones config-gated: empty o disabled no prueba fallo. Los contadores witness/checkpoint son evidencia de rollback/fork, no consenso de cadena pública ni prueba de posesión del payload. Solo estado agregado; nunca owner keys, record IDs, projects, vectors, edges, checkpoint material o ciphertext.
Mantener, reiniciar y actualizar con seguridad
El restart_service remoto es un comando privilegiado con gate del backend. Exige permiso, aviso de sesiones activas, guía maintenance/drain, confirmación explícita, audit inmutable y ciclo pending -> sent -> executing -> completed | failed | timeout; cancela solo cuando esté permitido. Después verifica runtime, heartbeat, healthcheck, policy sync y evidencia afectada antes de terminar maintenance. Upgrade muestra version drift, staged state, bloqueos y seguridad de cutover, pero no implica un upgrade remoto universal de un clic. Usa el flujo aprobado y material de rollback.
Separar las credenciales de acceso
Un registration code incorpora un nodo; un private access code admite clientes aprobados en un nodo restringido; un anonymous voucher acredita servicio sin ser credencial de operador. No son intercambiables. Aplica mínimo privilegio, expiración breve, visualización única, revocación y auditoría. Nunca pongas secrets, private keys, raw bearer o recovery material en eventos, URL, capturas o tickets.
Usar eventos, frescura y auditoría
Cada panel debe indicar procedencia y frescura: signed Rust heartbeat, health endpoint local, discovery status, systemd/upgrade report, backend policy o command audit. Los eventos deben explicar cuándo cambió el estado, qué nodo/servicio, qué actor permitido inició la acción y si llegó evidencia de cierre. Conserva timestamps y reason codes gruesos; excluye payloads, destinos, message IDs, actividad de IP cliente, memoria y social graph.
Permisos y límite de privacidad
Protege registro, policy, maintenance, comandos, códigos y audit con autorización por roles. Nodeboard puede mostrar sessions, bytes, packets, presión de capacidad, routeability, proof outcomes, recovery y ciclo de comandos agregados. No debe mostrar DNS, destinos, historial, plaintext de mensajes/paquetes/MemChain, actividad de IP pública del cliente, tráfico de wallet, private keys ni voucher secrets. El operador debe mantener infraestructura sin conocer conducta del usuario.
Rutina del operador y referencias
Diario: Attention, nodos offline/stale, placement, drops, recursos, frescura discovery y SLA de comandos. Antes: sesiones, drain/maintenance, versión/commit objetivo y rollback. Después: servicio active/enabled, heartbeat fresco, healthcheck, policy sync y admission discovery/relay si está configurado; luego cierra el incidente.