Ejecutar el nodo

El trabajo del día a día en un nodo es poco. Esto es lo que hay.

Salud

sudo scripts/tc-operator/tc-operator status --config operator.yaml

Solo lectura, y nunca te pide confirmar nada, así que lo puedes programar. Imprime un resumen humano del estado de cada contenedor, la identidad de federación del nodo, qué indicadores están activos, qué integraciones están configuradas, y la construcción en marcha ahora mismo. También escribe una línea JSON legible por máquina, así puedes apuntar un monitor a ella.

Ejecútalo como root. Todo lo que va más allá de los estados de los contenedores se lee a través de /etc/trusted-codes/secrets.env, que solo puede abrir root. Sin root obtienes los estados de los contenedores y nada más, y no te dice que falta el resto — así que un monitor configurado sin privilegios informa de un nodo saludable sin ver nada de su identidad.

Los contenedores de los que informa, y qué significa que cada uno esté caído:

Contenedor	Qué es	Si está caído
db	la base de datos — todo el estado del nodo	todo está caído
auth	registro, inicio de sesión, emisión de tokens	sin inicios de sesión nuevos; los tokens emitidos funcionan hasta que caducan
rest	la API REST sobre la base de datos	fallan todas las lecturas y escrituras de los clientes
functions	toda la lógica de negocio y los manejadores de federación	fallan las acciones de la aplicación y la federación; la autenticación y REST en crudo siguen respondiendo
storage	archivos y blobs	fallan las subidas y descargas; nada más
realtime	avisos de sincronización por WebSocket	los clientes recurren a barridos en primer plano — degradado, no roto
kong	la única puerta de enlace delante de todo esto	toda la API es inalcanzable aunque los servicios estén activos

Dos más se ejecutan en paralelo: un sidecar WebFinger, que es cómo los pares resuelven usuarios en tu nodo, y el proxy que termina el TLS y sirve las superficies.

/etc/trusted-codes/README.md en la máquina lleva la misma tabla con los nombres reales de los contenedores de tu nodo, más para qué sirve cada archivo de ese directorio. /etc/trusted-codes/install.log tiene la salida completa de cada comando que ejecutó el instalador.

Arrancar y parar superficies

Qué superficies están activadas viene de operator.yaml, pero puedes activar o desactivar una en tiempo de ejecución sin volver a instalar.

tc-operator service status              # por superficie: activada, generada, sirviendo
tc-operator service start my            # construir si hace falta, y después servir
tc-operator service stop business       # quitar el vhost; el paquete se conserva
tc-operator service restart verify
tc-operator service start all           # cada superficie excepto admin

Las superficies son my, business, verify, provider, status y admin.

• start genera el paquete si no se ha construido todavía, añade el vhost de la superficie y recarga en caliente el proxy. Un host nuevo emite su certificado en unos 30 a 60 segundos; service status muestra cert-pending hasta que responde, después serving.
• Una superficie necesita su propio registro A de DNS antes de que se pueda emitir el certificado.
• admin nunca se puede detener. Es la superficie de recuperación.
• Esta es la única forma de controlar el servicio de superficies. La aplicación de administración te muestra el comando pero nunca arranca ni detiene nada por sí misma — una aplicación web no debe poder controlar tu máquina.

Cuentas de administrador

La aplicación de administración de tu nodo está protegida por roles. Hay un rol que usas: operator_admin. Administra este servidor — usuarios, sesiones, historial de accesos, intentos bloqueados, organizaciones, bóvedas, notificaciones.

Se le niega cualquier superficie de control central: concesiones de operador, derechos, planes, parámetros del sistema, marketing, y las acciones privilegiadas detrás de ellos. Esa negación se aplica en el servidor en cada petición, no solo se oculta en la interfaz, y no hay ninguna vía de operator_admin hacia el rol central super_admin.

Añadir y quitar

tc-operator add-admin --email alguien@ejemplo.com
tc-operator add-admin --email alguien@ejemplo.com --revoke

Sin confirmación de terminal, idempotente, seguro de volver a ejecutar. El verbo está fijado a operator_admin y nunca puede conceder el rol central.

La cuenta ya tiene que existir — la persona tiene que haber iniciado sesión al menos una vez. add-admin solo concede; no crea cuentas. La vía admin_email del instalador es lo que crea la primera.

Dos capacidades encima del rol

tc-operator add-admin --email <dirección> --can-revoke
tc-operator add-admin --email <dirección> --can-reveal
tc-operator add-admin --email <dirección> --revoke --can-reveal   # solo esa capacidad

can_revoke corta la relación con un servidor par, en ambas direcciones. Tu primer administrador la obtiene en la instalación, porque un control de emergencia que necesita un paso de línea de comandos en mitad de un incidente no es un control de emergencia.

can_reveal desenmascara una dirección en el registro de invitaciones — con un motivo escrito, auditado, con límite de tasa — y activa la retención que crea la copia recuperable en primer lugar. Está desactivada por defecto y se queda así hasta que decidas lo contrario. Es exposición nueva de datos personales, así que es tu decisión consentida y no un valor por defecto.

Un --revoke a secas quita el rol y todas las capacidades. --revoke con un indicador de capacidad quita solo esa capacidad.

Iniciar sesión

La aplicación de administración detecta qué métodos tiene configurados tu nodo y los muestra.

• Password. Siempre disponible, y tu primera forma de entrar: admin_email más la contraseña de un solo uso que imprimió el instalador. Funciona en un nodo desnudo sin correo y sin OAuth, por lo que es la vía garantizada. Cámbiala después del primer inicio de sesión.
• Magic link. Necesita SMTP. La opción se oculta hasta que el transporte está configurado.
• Google o Apple. Necesita credenciales de proveedor en el entorno del servicio de autenticación, con la URL de retorno de tu propio nodo registrada en Google o Apple. El botón aparece automáticamente en cuanto están fijadas.

En todos los casos, el nodo solo admite usuarios que tienen operator_admin o super_admin. Un inicio de sesión con éxito de cualquier otra persona se rechaza y se cierra la sesión.

URLs del portal

Los enlaces de invitación y las referencias al portal se resuelven a URLs derivadas de home_server — https://my.<dominio>, https://admin.<dominio>, y así. Para dirigirlas a otro sitio, abre la aplicación de administración y edítalas bajo This Server → Portal URLs. Los cambios surten efecto de inmediato, y volver a ejecutar la instalación nunca sobrescribe una URL que hayas personalizado.

Si tu nodo funciona bajo una concesión de operador

sudo scripts/tc-operator/tc-operator renew-grant --config operator.yaml

Un intento de renovación de concesión: firma una certificación, la envía de forma centralizada, verifica la concesión devuelta y la guarda. La instalación conecta una tarea programada diaria para esto, así que normalmente nunca lo ejecutas a mano. Termina limpiamente y no hace nada si no se puede llegar a central o no hay ninguna concesión presente, y registra en /etc/trusted-codes/renew-grant.log.

Rotar el certificado mTLS del nodo

Tu nodo guarda un certificado de cliente autofirmado, emitido una vez en la primera instalación, guardado bajo /etc/trusted-codes/mtls/, válido durante 398 días. Su huella forma parte de tu carga de admisión — es la identidad estable de tu nodo ante el registro, por lo que volver a ejecutar la instalación la conserva deliberadamente y nunca la rota en silencio.

Rótala solo cuando se acerque a caducar o creas que la clave quedó expuesta. Todavía no hay un único comando para ello:

sudo mv /etc/trusted-codes/mtls /etc/trusted-codes/mtls.old
sudo scripts/tc-operator/tc-operator install --config operator.yaml
scripts/tc-operator/tc-operator submit-admission

La instalación acuña un certificado nuevo, lo que significa una huella nueva. El registro sigue confiando en la antigua hasta que alguien en Trusted Codes verifique la huella nueva fuera de banda y la apruebe — exactamente como en la primera instalación. Guarda mtls.old hasta entonces, así puedes volver atrás.

Cómo está protegida la máquina

Cada puerto de contenedor publicado se une solo a 127.0.0.1. Este es el control estructural, y importa más de lo que parece: Docker publica puertos insertando sus propias reglas de cortafuegos, que se saltan ufw. Una denegación de cortafuegos no bloquea un puerto de contenedor publicado. Un puerto unido a loopback es alcanzable solo desde la propia máquina, sin importar lo demás. Las reglas de cortafuegos en 22, 80 y 443 son defensa en profundidad, no el mecanismo.

Alcanza Postgres desde tu puesto de trabajo por un túnel SSH:

ssh -L 5432:127.0.0.1:5432 <tu-máquina>

El proxy es el único proceso unido a un puerto público. Termina el TLS y reenvía a la puerta de enlace por loopback.

Los secretos viven solo en /etc/trusted-codes/secrets.env, modo 0600. La carga de admisión lleva solo material de clave pública.