Bir AeroNyx düğümünü çalıştırma ve denetleme

Bu çalıştırma kılavuzu, kayıtlı bir AeroNyx düğümü için günlük komutları kapsar: durum, sağlık, günlükler, aktarım ve posta kutusu kanıtları, güvenli yükseltmeler, geri alma ve bir yeniden başlatmadan sonra neyin denetleneceği. Her komut düğüm deposunda (deploy/node/aeronyx-node.sh ve aeronyx-server ikili dosyası) bulunur ve kodun kabul ettiği seçeneklerle gösterilir.

Henüz bir düğüm kurmadıysanız Bir AeroNyx düğümünü kurma ve kaydetme ile başlayın.

Başlamadan önce

Her şeyi bir root kabuğundan (sudo -i) çalıştırın. Yapılandırma dizini /etc/aeronyx ve durum dizini /var/lib/aeronyx 700 kipindedir; bu nedenle durum, sağlık, doğrulama ve aktarım komutları bunları başka bir kullanıcı olarak okuyamaz.

Hizmetin gerçekten çalıştığı depoya geçin ve her betik komutunda bunu --repo-dir ile iletin. --repo-dir olmadan betik /opt/aeronyx/AeroNyx konumunu varsayar.

cd "$(systemctl show aeronyx-server -p WorkingDirectory --value)"
pwd

Nodeboard komutuyla kurulan düğümlerde bu, /root/open/AeroNyx yazdırır.

Bir bakışta komutlar

Durum

./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"

status sırasıyla şunları yazdırır:

1. systemctl status aeronyx-server (son 20 satır)
2. yerel sağlık API'sinin (http://127.0.0.1:8421/api/vpn/health) ve operatör durum API'sinin (http://127.0.0.1:8421/api/operator/status) bir özeti
3. http://127.0.0.1:8422/api/discovery/status üzerinden yerel keşif hazırlığı: ChatRelay duyurusu ve eş yeter sayısı (quorum)
4. /var/lib/aeronyx/upgrade-status.json dosyasından son yükseltme iş akışı durumu
5. bir operatör önerisi: operator_status, operator_title, operator_detail ve operator_next_step

Öneri, sağlık denetiminden gelir. Durumu şunlardan biridir:

Sağlık

./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

Sağlık denetimi dosyaları, systemd'yi ve yerel uç noktaları okur; ana makineyi asla değiştirmez. Her denetim [PASS], [WARN] veya [FAIL] yazdırır, ardından bir [SUMMARY] pass=… warn=… fail=… satırı ve ardından tek bir JSON satırı gelir. Yalnızca JSON'u yazdırmak için --json-only kullanın. Herhangi bir denetim başarısız olursa komut sıfır olmayan bir durum koduyla çıkar.

Denetlediği şeyler: depo, izlenen Cargo.lock ve sürüm ikili dosyası; aeronyx-server validate ile yapılandırma doğrulaması; kayıt ve anahtar dosyaları; systemd birimi, yeniden başlatma politikası ve sıkılaştırma; bellek, disk ve 51820 ile 8421 bağlantı noktaları; IP yönlendirme ve NAT; yerel sağlık uç noktası; keşif; ve sürüm yedekleri.

Başlıca JSON alanları:

Ham yerel uç noktaları doğrudan okuyabilirsiniz:

curl -s http://127.0.0.1:8421/api/vpn/health
curl -s http://127.0.0.1:8422/api/discovery/status

Günlükler

./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --lines 200
./deploy/node/aeronyx-node.sh logs --repo-dir "$PWD" --follow

Bunlar journalctl -u aeronyx-server -n <lines> --no-pager (varsayılan 160 satır) ve journalctl -u aeronyx-server -f komutlarını sarmalar. Zaman aralıkları için journalctl komutunu doğrudan kullanın; örneğin journalctl -u aeronyx-server --since "1 hour ago".

Aktarım ve posta kutusu kanıtları

Bu komutlar farklı soruları yanıtlar. Başarılı bir sentetik yoklamayı gerçek teslimatın kanıtı olarak görmeyin.

relay-probe (sentetik)

./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --json
./deploy/node/aeronyx-node.sh relay-probe --repo-dir "$PWD" --two-hop --json

Bu düğümden keşfedilmiş bir ChatRelay eşine tek bir sentetik, rastgele ve opak BlindRelay zarfı gönderir ve yalnızca sayaç değişikliklerini bildirir. --two-hop, zarfı bir ara atlama üzerinden bir uç düğüme gönderir. Sonuçtaki status değeri ok, attention, blocked veya error olur ve two_hop_readiness, iki atlamalı bir yol mümkün olmadığında neyin eksik olduğunu açıklar. Eş önbelleğini ve düğüm anahtarını okuduğu için root gerektirir. Kullanıcı trafiği değildir ve posta kutusu teslimatını kanıtlamaz. fleet-smoke, --endpoints ile listelediğiniz birkaç genel düğüm üzerinde benzer bir sentetik denetim çalıştırır.

relay-smoke (kimliği doğrulanmış, uçtan uca)

./target/release/aeronyx-server relay-smoke --confirm-live-relay-smoke --json

relay-smoke, bu ana makinedeki düğüme karşı gerçek bir istemci gibi davranır. Geçici kimliklerle kısa ömürlü iki oturum açar ve bu düğümün anahtarına sabitlenmiş olarak üretim el sıkışmasını tamamlar. Kimliği doğrulanmış çok atlamalı aktarım yolu üzerinden uçtan uca şifrelenmiş, 48 baytlık tek bir rastgele mesaj gönderir. Ardından tam olarak bu isteğe ait imzalı uç makbuzunu doğrular, mesajı bu düğümün posta kutusundan çeker, şifresini çözer, alındısını onaylar ve posta kutusunun boş, oturumların kapalı olduğunu denetler.

Her kapı geçilmedikçe başlamayı reddeder:

Notlar:

• Düğümün kendisinde root olarak çalışmalıdır. /etc/aeronyx/server.toml dosyasını ve düğüm anahtarını okur ve yalnızca geri döngü (loopback) adreslerini kabul eder (--server, varsayılan 127.0.0.1:51820; --health-url, varsayılan http://127.0.0.1:8421/api/vpn/health).
• --timeout-seconds kanıt penceresini ayarlar: 5 ile 120 saniye arası, varsayılan 30.
• Sıfır etkin oturum şartı, VPN kullanıcılarına hizmet veren bir düğümün önce boşaltılması gerektiği anlamına gelir. Nodeboard'da Maintenance Mode'u açın ve oturumların sıfıra inmesini bekleyin.
• İki test oturumu gerçek protokol oturumlarıdır; bu nedenle Nodeboard Sessions bölümünde kısa süreliğine görünebilirler.
• Başarılı bir sonuçta "status": "passed" bulunur, terminal_receipt_observed, entry_mailbox_round_trip_verified, entry_mailbox_ack_verified ve e2e_ciphertext_verified değerlerinin tümü true olur ve session_cleanup değeri explicit_authenticated_close olur. terminal_replica_cleanup değeri node_ttl_managed olur: giriş düğümünde alındı onayı vermek, uç düğümün tuttuğu kopyayı silmez; o kopyanın süresi kendiliğinden dolar.
• Başarısız herhangi bir kapı, hata veya eksik alan, kısmi bir başarı değil, başarısız bir kanıttır.

mailbox-probe (istemci kaynaklı)

./target/release/aeronyx-server mailbox-probe \
  --seed http://SEED_PUBLIC_IP:8422 \
  --target <64-hex node ID of the mailbox node> \
  --entry <64-hex node ID of a different entry node> \
  --confirm-live-mailbox-probe --json

mailbox-probe bir uygulama gibi davranır: geçici anahtarlar kullanır, --seed düğümlerinden toplanan imzalı tanımlayıcılardan kendi onion rotasını oluşturur ve VPN oturumu olmadan giriş düğümünün genel eş API'sine düz HTTP gönderir. Hedef düğümde tam anonim posta kutusu yaşam döngüsünü çalıştırır: ticket_issue, lease_create, put, pull_one, ack ve son bir pull_one. Çekilen baytların eşleştiğini ve posta kutusunun sonrasında boş olduğunu denetler. Başarılı bir sonuç "status": "verified" değerini ve atlama sayısını bildirir.

• --seed birden çok kez verilebilir. --entry olmadan rota tek atlamalıdır.
• Düğüm kimliği, düğümün 64 karakterlik onaltılık genel anahtarıdır. İşlettiğiniz bir düğümde ./target/release/aeronyx-server pubkey -c /etc/aeronyx/server.toml bunu yazdırır.
• Hedefte anonim posta kutusunun etkin olması gerekir ([memchain.chat_relay.anonymous_mailbox] enabled = true); varsayılan olarak kapalıdır.
• --work-bits (varsayılan 12) en az hedefin bilet iş ayarı kadar olmalıdır. --timeout-seconds istek başınadır (varsayılan 20).
• Yerel düğüm dosyalarını okumadığı için ikili dosyanın bulunduğu herhangi bir makineden çalışabilir. Opak bir öğenin emanetini kanıtlar; bir alıcının onun şifresini çözebileceğini kanıtlamaz.

Güvenli yükseltme

git pull ardından systemctl restart değil, yükseltme iş akışını kullanın:

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --build-priority live --build-jobs auto

Yaptıkları:

1. Bir dağıtım kilidi alır ve çalışma kopyasındaki izlenen dosyalar değiştirilmişse çalışmayı reddeder (--allow-dirty bunu geçersiz kılar).
2. main dalını çeker (veya --commit <40-hex SHA> ile yalıtılmış bir çalışma kopyasında tam bir commit'i derler).
3. Depoda sabitlenmiş Rust araç zinciriyle derler. live önceliği (varsayılan) ve --build-jobs auto, çalışan düğümün hizmet vermeye devam etmesi için CPU'ların yaklaşık yarısını kullanır.
4. /etc/aeronyx/server.toml dosyasını yeni ikili dosyayla doğrular. Yapılandırma dosyasının üzerine asla yazılmaz.
5. Gerçekte çalışan ikili dosyayı /var/lib/aeronyx/releases/ konumuna yedekler.
6. Etkin oturumları derlemeden sonra ve yeniden başlatmadan hemen önce bir kez daha denetler. Herhangi bir oturum varsa veya hizmet çalışırken sayı okunamıyorsa sürüm değiştirmeden durur.
7. systemd birimlerini günceller, yeni ikili dosyayı yerine koyar ve hizmeti yeniden başlatır.
8. Yerel sağlığın az önce derlediği commit'ten ok bildirmesi için 180 saniyeye kadar (2 saniye arayla 90 denetim) bekler. Yeniden başlatma, hizmet durumu veya sağlık denetimi başarısız olursa önceki ikili dosyayı ve birimleri otomatik olarak geri yükler.
9. Her türden en son 10 yedeği saklar ve sonucu /var/lib/aeronyx/upgrade-status.json dosyasına kaydeder.

Düğümde etkin oturumlar varsa derleme yine çalışır ve yükseltme ardından Active sessions appeared during compilation. Enter maintenance mode, drain sessions, and run the upgrade again. mesajıyla durur. Nodeboard Settings bölümünde Maintenance Mode'u açın, etkin oturumların sıfıra inmesini bekleyin ve aynı komutu yeniden çalıştırın. Yeniden derleme önbelleği yeniden kullanır.

Şimdi hazırla, sonra yeniden başlat

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --no-restart

--no-restart derler, doğrular ve yedekler, ardından yeni ikili dosyayı yeniden başlatmadan diske kurar. status bundan sonra upgrade_staged bildirir. Çalışan süreç eski sürümü korur. Yeniden başlatma veya bir çökme sonrasındaki otomatik yeniden başlatma da dahil olmak üzere sonraki herhangi bir yeniden başlatma yeni ikili dosyayı başlatır.

Bir bakım penceresinde geçiş yapmak için düğümü boşaltın ve yükseltmeyi çekme yapmadan yeniden çalıştırın; böylece oturum denetimi, sağlık beklemesi ve geri alma ile tam olarak hazırladığınız sürüme geçer:

./deploy/node/aeronyx-node.sh upgrade --repo-dir "$PWD" --skip-pull

--force kullanmayın. Oturumlar etkinken veya oturum sayısı bilinmezken bile yeniden başlatır ve kullanıcıların bağlantısını keser.

Elle geri alma

Yeni sürüm başlatılamadığında veya sağlıklı olduğunu bildiremediğinde yükseltme otomatik olarak geri alınır. Daha sonra önceki bir sürüme dönmek için kaydedilmiş ikili dosyalardan birini yükseltin (promote):

ls -lt /var/lib/aeronyx/releases/
./deploy/node/aeronyx-node.sh promote-binary --repo-dir "$PWD" \
  --binary /var/lib/aeronyx/releases/<aeronyx-server.binary.YYYYMMDD_HHMMSS.xxxxxx>

promote-binary, yapılandırmayı seçilen ikili dosyayla doğrular ve etkin oturumlar tam olarak sıfır olmadıkça çalışmayı reddeder. PROMOTE BINARY yazmanızı ister, mevcut ikili dosyayı yanına yedekler, ikili dosyayı değiştirir ve yeniden başlatır. Hizmet 180 saniye içinde sağlıklı olmazsa önceki ikili dosyayı geri yükler. systemd birimlerini değil, yalnızca ikili dosyayı değiştirir.

Her yeniden başlatmadan sonra

Şunları sırasıyla denetleyin:

1. systemctl is-active aeronyx-server, active döndürür. Birim Type=notify türündedir; bu nedenle active, sürecin hazır olduğunu bildirdiği anlamına gelir; başlatma, systemd vazgeçmeden önce 300 saniyeye kadar sürebilir.
2. ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD", operator_status=ok veya anladığınız bir uyarı gösterir.
3. ./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json, "success":true ile biter ve local_vpn_health.status değeri ok olur.
4. Çalışan commit, amaçladığınız commit'tir: curl -s http://127.0.0.1:8421/api/vpn/health bunu runtime.git_commit olarak bildirir. (health --json içindeki runtime.git_commit, çalışma kopyasının commit'idir.)
5. İlk dedikodu turlarından sonra discovery_readiness.peer_quorum.quorum_ready değeri true olur.
6. Aktarım düğümleri için: relay-probe --two-hop --json, ok bildirir.
7. Nodeboard'da kalp atışı günceldir, Rust Runtime yeni sürümü gösterir ve yeniden başlatma Alerts / Events altında görünür. İşiniz bittiğinde Maintenance Mode'u kapatın.
8. journalctl -u aeronyx-server --since "15 min ago" tekrarlayan hata içermez.

Bunun Nodeboard'da görünümü

Nodeboard, düğümün imzalı kalp atışını ve oturum raporlarını alır. Ana makinede kendi başına komut çalıştırmaz; orada seçtiğiniz eylemler kuyruğa alınır ve düğüm bunları bir sonraki kalp atışında çalıştırır.

Düğüm ayrıntısında ayrıca algılanan depo yolu için kopyalanabilir health, status, logs ve hazırlanmış yükseltme komutlarını içeren bir Operator Runbook kartı bulunur.

Çıktıların içeriği

status, health, relay-probe, relay-smoke ve mailbox-probe yalnızca toplu değerleri yazdırır: sayılar, durumlar, zamanlamalar ve neden kodları. Özel anahtarları, kayıt kodlarını, istemcilerin genel IP adreslerini, hedefleri, DNS içeriklerini, yükleri veya mesaj düz metnini yazdırmaz. İstemci anahtarlarını içeren oturum kayıtları bu çıktılarda değil, Nodeboard'da görünür; Nodeboard operatör konsolu kılavuzu sayfasına bakın. Destek için çıktı paylaşırken ana makine adreslerini veya kimlik bilgilerini değil, JSON'u ve zaman damgasını paylaşın.

Sıkça sorulan sorular

Bir şeyler yanlış göründüğünde ilk hangi komutu çalıştırmalıyım?

Root olarak ./deploy/node/aeronyx-node.sh status --repo-dir "$PWD" çalıştırın. Hizmet durumunu, yerel sağlığı, keşfi ve önerilen sonraki adımı gösterir ve ana makineyi değiştirmez.

health neden "config missing" veya Git uyarılarıyla başarısız oluyor?

Büyük olasılıkla root değilsiniz veya yanlış depoyu gösteriyorsunuz. /etc/aeronyx ve /var/lib/aeronyx yalnızca root'a açıktır ve --repo-dir olmadan betik, hizmetin çalıştığı çalışma kopyası yerine /opt/aeronyx/AeroNyx konumunu denetler.

relay-probe ile relay-smoke arasındaki fark nedir?

relay-probe tek bir sentetik opak zarf gönderir ve yalnızca bir aktarım yolunun trafiği kabul ettiğini gösterir. relay-smoke gerçek bir istemci gibi davranır: tek bir şifreli test mesajı için imzalı bir uç makbuzunu ve posta kutusundan tam çekme ile alındı onayını doğrular.

relay-smoke neden sıfır etkin oturum gerektiğini söylüyor?

Sayaç değişikliklerini kendi test oturumlarına atfeder; bu nedenle yalnızca boşta olan bir düğümde çalışır. Nodeboard'da Maintenance Mode'u açın, etkin oturumların sıfıra inmesini bekleyin, ardından çalıştırın.

Kullanıcıların bağlantısını kesmeden yükseltme yapabilir miyim?

Kullanıcılar bağlıyken --no-restart ile bir yükseltmeyi derleyip hazırlayabilirsiniz. Yeni sürüme geçmek bir yeniden başlatma gerektirir; bu nedenle düğümü Maintenance Mode ile boşaltın ve ardından upgrade --skip-pull çalıştırın.

Önceki sürüme nasıl dönerim?

Başarısız bir yükseltme otomatik olarak geri alınır. Daha sonra geri almak için /var/lib/aeronyx/releases/ içindeki yedeklerden biriyle promote-binary kullanın; bu komut sıfır etkin oturum gerektirir ve yükseltilen ikili dosya sağlıksızsa önceki ikili dosyayı geri yükler.