Guide de la console opérateur AeroNyx Nodeboard
Exploitez les nœuds de confidentialité décentralisés AeroNyx avec une console orientée workflow pour l’inscription, l’attention flotte, la capacité, les preuves relay chiffrées, la maintenance sûre et la clôture d’incident.
Nodeboard est la console d’exploitation des nœuds de confidentialité décentralisés AeroNyx. Elle transforme inscription, santé agrégée, capacité, preuves du protocole, maintenance et clôture d’incident en workflows répétables sans exposer trafic utilisateur ni contenu chiffré. Ouvrez app.aeronyx.network. Un panneau ne prouve que ce que sa source actuelle rapporte ; configuration, runtime readiness et preuves observées sont distinctes.
Périmètre et modèle d’exploitation
Utilisez trois niveaux. Dashboard indique si la flotte demande une action. Services compare un domaine de service ou capacité entre vos nœuds. Node detail explique un nœud et contient preuves, contrôles et historique d’audit. Les nœuds sains restent silencieux ; raw proof history et command timeline appartiennent au détail. Nodeboard gère les nœuds liés à l’opérateur authentifié, ce n’est pas un explorateur public du trafic.
Enregistrer un nœud
Créez un code court dans Registration Codes, puis utilisez la commande générée ou l’installateur officiel. Suivez séparément planning, installation, registration, démarrage du service, heartbeat et admission. Après apparition, vérifiez région, visibilité publique, version runtime, source commit, capacité et santé. Le code lie un seul onboarding ; ce n’est pas une API key réutilisable et le secret consommé ne doit jamais être réaffiché.
Commencer par l’attention de flotte
Priorité : heartbeat offline/stale ; commande failed/timeout/stale ; maintenance avec active sessions ; packet drops ou pression IP pool, conntrack, file descriptors, disque ; policy drift ; incohérence discovery/relay ; puis preuve recovery/proof vieillissante. Stale, not reported et disabled ne valent ni zéro ni healthy. Ouvrez l’élément le plus impactant, identifiez l’impact utilisateur et une condition de clôture vérifiable.
Utiliser Services et le détail du nœud
Services regroupe Privacy Network, Discovery & Relay, MemChain & Storage et Runtime. Comparez, puis ouvrez le détail pour timestamp source, policy sync, risques, état de commande et recovery evidence. Chaque incident a besoin de signal, impact, action et clôture. Un exit code zéro ne clôt rien à lui seul : heartbeat récent, service, endpoint protocolaire et capacité touchée doivent revenir.
Décider capacité et placement
La capacité guide admission, ce n’est pas un score décoratif. Examinez IP pool used/free, max_connections, policy max_sessions, active sessions, conntrack, fd, packet drops, pps/bps, politique de bande passante, disque, mémoire et CPU. Distinguez hard runtime limits et politique commerciale ; zéro peut signifier unlimited selon le backend. Affichez Accepting, Limited, Drain ou Maintenance avec sa raison, sans déduire l’activité individuelle des taux agrégés.
Lire discovery et les preuves de relay chiffré
Séparez configured capability, signed advertisement, endpoint reachability, stabilité des probes, observation d’un relay chiffré réel, terminal client receipt et continuité après restart. Un synthetic probe prouve un chemin de test, pas du trafic utilisateur. OnionMiddle est un relay chiffré sans sortie ; il requiert peer API joignable, ChatRelay prêt, descriptor signé, peers routeable et preuve récente. N’exposez ni hops, social graph, payload ni identité client.
Lire MemChain et les preuves de commitment
MemChain peut indiquer si sealed storage, commitment follower, witnesses, quota, cleanup et recovery sont configurés et récents. Ces fonctions sont config-gated : empty/disabled ne prouve pas une panne. Les compteurs witness/checkpoint prouvent rollback/fork, pas un consensus de chaîne publique ni la possession du payload. N’affichez que l’agrégat, jamais owner key, record ID, project, vector, edge, checkpoint material ou ciphertext.
Maintenir, redémarrer et mettre à niveau
Le restart_service distant est une commande privilégiée protégée par le backend. Exigez permission, avertissement de sessions, conseil maintenance/drain, confirmation explicite, audit immuable et cycle pending -> sent -> executing -> completed | failed | timeout ; annulez seulement si permis. Ensuite vérifiez runtime, heartbeat, healthcheck, policy sync et preuves affectées avant de quitter maintenance. Upgrade montre version drift, staged state, blockers et cutover safety, sans promettre un upgrade distant universel en un clic. Utilisez le workflow approuvé et le rollback.
Séparer les identifiants d’accès
Un registration code inscrit un nœud ; un private access code admet des clients autorisés sur un nœud restreint ; un anonymous voucher prouve l’éligibilité au service sans devenir identifiant opérateur. Ils ne sont pas interchangeables. Appliquez moindre privilège, expiration courte, révélation unique, révocation et audit. Ne placez jamais secrets, private keys, raw bearer ou recovery material dans événements, URL, captures ou tickets.
Utiliser événements, fraîcheur et audit
Chaque panneau indique provenance et fraîcheur : signed Rust heartbeat, health endpoint local, discovery status, systemd/upgrade report, backend policy ou command audit. Un événement répond quand, quel nœud/service, quel acteur autorisé et si la preuve de clôture est arrivée. Conservez timestamps et reason codes grossiers ; excluez payloads, destinations, message IDs, activité IP client, contenu mémoire et social graph.
Permissions et frontière de confidentialité
Protégez inscription, policy, maintenance, commandes, codes et audit par rôles. Nodeboard peut afficher sessions, bytes, packets, pression de capacité, routeability, proof outcomes, recovery et cycle de commande agrégés. Il ne doit pas montrer DNS, destinations, historique, plaintext paquet/message/MemChain, activité IP publique client, trafic wallet, private keys ou voucher secrets. L’opérateur doit gérer l’infrastructure sans connaître le comportement utilisateur.
Routine opérateur et références
Chaque jour : Attention, offline/stale, placement, drops, ressources, fraîcheur discovery et SLA commandes. Avant : sessions, drain/maintenance, version/commit cible et rollback. Après : service active/enabled, heartbeat récent, healthcheck, policy sync et admission discovery/relay configurée, puis clôturez.