Yaşam döngüsü aşamasına göre gruplanmış, cihazın kendi tanılama verileri üzerinde çalıştırılabilen belirti odaklı çalışma kitaplarının tam kataloğu.

Her çalışma kitabı tanıyabileceğiniz bir belirtiden başlar, cihazın kendi durumunu denetler ve hem nedeni hem çözümü söyler. Baştan aşağı ilerleyin: denetimler, en ucuz ve en olası neden önce elenecek biçimde sıralanmıştır.

Tip

Tanılama anlık görüntüsünü okuyan denetimler kendi kendine çalışır — cihazın kendi belge kopyasında her denetimin yanında canlı bir sonuç görürsünüz; bunun için yapılandırılmış bir model ya da internet bağlantısı gerekmez. Manuel olarak işaretlenmiş denetimler hiçbir aracın göremediği denetimlerdir; onları siz yanıtlarsınız.

Sizi buraya tanılama anlık görüntüsündeki bir bulgu gönderdiyse, o bulgu bir çalışma kitabı kimliği vermiştir: o kimliği taşıyan başlığı kullanın. Kurulum, ilk açılış, lisanslama, TLS ya da güncelleme aşamalarındaki bir belirtiden başlıyorsanız kurulum ve etkinleştirme sayfası daha kısa bir yoldur.

Kurulum

Sağlama "6/8 container images" adımında duruyor

Makinenin kayıt defterine çalışan bir yolu yoktur. Hata satırının üzerindeki girintili satırı okuyun: o satır, engellenmiş bir portu bozuk bir çözümleyiciden, eskimiş kimlik bilgilerinden ve incelenen bir TLS bağlantısından ayırır.

Çalışma kitabıinstall

Sağlama "6/8 container images" adımında duruyor

Şunları görebilirsiniz: 6/8 container images (6/8 kapsayıcı imajları — sağlamanın durduğu adım) · cannot log in to api.cid222.live (kayıt defterine oturum açılamıyor — üstteki girintili satır docker'ın kendi iletisidir) · FAILED: cannot log in to (kayıt defterine oturum açılamadı) · sağlama 6/8 adımında durdu

Başlamadan önce

Kırmızı FAILED satırının hemen üzerine yazılan girintili satırı okudunuz mu? O satır docker'ın kendi iletisidir ve aşağıdaki durumları birbirinden ayıran şey odur.beklenen · docker'ın kendi iletisini aktarabiliyorsunuz — bir oturum açma hatası, bir TLS hatası, bir zaman aşımı ya da bulunamadı yanıtı.Değilse, önce /install/from-iso sayfasına gidin.
Bu, CID222 muhatabınızın bu dağıtım için verdiği kurulum ortamı mı, yoksa daha önceki bir değerlendirmeden kalma bir ISO mu?beklenen · Sürümler eşleşiyor ve sağlama toplamı doğrulanıyor.Değilse, önce /install/from-iso sayfasına gidin.

Denetimler

1
Makinede bir IPv4 adresi ve bir varsayılan rota olduğunu doğrulayın
beklenen · Bir IPv4 adresi ve bir varsayılan rota var. Yalnızca fe80:: adresi gösteren bir sanal makine özeti, port grubunda DHCP olmadığı anlamına gelir.
2
Kayıt defteri ana makinesini, bu makinenin gerçekte kullandığı çözümleyiciyle çözün
beklenen · CID222 muhatabınızın verdiği adresle eşleşen bir yanıt geliyor. SERVFAIL, zaman aşımı ya da başka bir adres hata sayılır.
3
Cihazın kendisinden kayıt defterine 443 üzerinde bir TCP bağlantısı açın
beklenen · Komut 443 open yazıyor.
4
Kayıt defterinin sunduğu sertifikanın kayıt defterinin kendisine ait olduğunu doğrulayın
beklenen · Sertifikayı veren taraf, kurumunuzun denetim CA'sı değil, herkese açık bir sertifika otoritesi.
5
Kayıt defterine, kurulum ortamındaki kimlik bilgileriyle oturum açın
beklenen · Login Succeeded.
6
Bu hattın kayıt defterine gerçekte ne sürdürebildiğini ölçün
beklenen · Ölçülen hız kabaca 2 MB/s ya da üstü.
7
Önceki denemeyi çekirdeğin mi yoksa dolan bir diskin mi durdurduğunu denetleyin
beklenen · Hiçbir satır "KILLED BY THE KERNEL" bildirmiyor ve hiçbiri diskin dolduğunu söylemiyor.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`no-ipv4` (kritik)	Sağlama, kayıt defterinden yaklaşık 10-15 GB indirir; dolayısıyla adresi ve varsayılan rotası olmayan bir makine ilk çekmede durur. vSphere ve ESXi'de olağan neden DHCP sunmayan bir port grubudur: sanal makine yalnızca bağlantı yerel bir fe80:: adresiyle açılır ve bu, özet bölmesinde çalışan bir ağ kartı gibi görünür. Düzeltme: Ağ kartını DHCP sunan bir ağa taşıyın ya da cihaz konsolundan sabit bir adres verin: konsol için Alt+F1'e, ardından F2'ye basın ve adresi, ağ geçidini ve ad sunucularını girin. Ardından yeniden başlatın — sağlama kendiliğinden kaldığı yerden sürer ve indirilmiş olan her şeyi korur. VMware Workstation ve Fusion'da adaptörü NAT'a almak, başka hiçbir yapılandırma gerekmeden hem DHCP hem dışarıya erişim sağlar. Doğrulama: beklenen · Bir IPv4 adresi ve bir varsayılan rota var ve çalışma 6/8'i geçerek sürüyor.
denetim 2 başarısız olduğunda	`dns-cannot-resolve-registry` (kritik)	Cihaz adları bu ağın çözümleyicisiyle çözer. O çözümleyici kayıt defteri için yanıt veremediğinde her çekme, oraya tek bir paket ulaşmadan başarısız olur. Tarayıcılar DNS-over-HTTPS üzerinden çözümlediği için çalışmayı sürdürür; ağın iyi niyetle açık bildirilmesinin nedeni de budur. Kurulum programı o tek etki alanını herkese açık çözümleyicilere yönlendirmeyi dener, bu da olmazsa kurulum ortamının derlendiği adrese sabitler — dolayısıyla buradaki bir hata üç yolun da kapalı olduğu anlamına gelir. Düzeltme: Cihazı, kayıt defteri için yanıt verebilen bir çözümleyiciye yönlendirin; bunu konsoldan yapın (Alt+F2, ardından ağ sayfası için F2). Çözümleyiciyi değiştiremiyorsanız, CID222 muhatabınızın verdiği adresi /etc/hosts dosyasına ekleyerek yalnızca o ad için DNS'i devre dışı bırakın ve yeniden başlatın. Sağlama kendiliğinden kaldığı yerden sürer. Doğrulama: beklenen · Yanıt, CID222 muhatabınızın verdiği adres.
denetim 3 başarısız olduğunda	`https-blocked` (kritik)	Ad çözümleme çalışıyor, TCP 443 çalışmıyor. İmaj çekmeleri 443 üzerinde TCP'dir, dolayısıyla dışarı hiçbir şey çıkmaz. ICMP'ye izin verip 443'ü engelleyen bir güvenlik duvarı olağan bir yapılandırmadır ve Ubuntu'nun kendi yansıları port 80 üzerinden sunulur — ping ile apt başarılı olurken kurulumun başarısız olmasının nedeni budur. Düzeltme: Kurulum süresi boyunca cihazdan kayıt defteri ana makinesine doğrudan dışarı HTTPS erişimine izin verin, ardından yeniden başlatın. Yalnızca vekil üzerinden çıkılan bir segmentte vekili konsoldan ayarlayıp yeniden başlatın: ilk açılış bunu Docker'ın kendi yapılandırmasına kopyalar, çünkü Docker ne apt'ın yapılandırmasını ne de kabuk ortamını okur. İkisi de mümkün değilse CID222 muhatabınızdan, imajları taşıyan ve hiçbir şey indirmeyen ağdan yalıtım ortamını isteyin. Doğrulama: beklenen · Bağlantı kuruluyor.
denetim 5 başarısız olduğunda	`registry-refuses-credentials` (kritik)	Kayıt defteri yanıt verdi ve bu cihazı reddetti. Kurulum programının kendi ifadesi şudur: "the registry rejected this appliance's credentials — this install media is stale or its account was revoked". Kimlik bilgileri kurulum ortamına gömülüdür, dolayısıyla onunla birlikte eskirler. Düzeltme: CID222 muhatabınızdan güncel kurulum ortamı isteyin. Cihazda kimlik bilgilerini yenileyebilecek hiçbir şey yoktur ve aynı ISO'yu yeniden denemek başarılı olamaz. Doğrulama: beklenen · Kayıt defteri oturumu açılıyor ve çekme sürüyor. Bu geçerli değilse: Açılış menüsü girdisindeki sürümü ve kurulum ortamının verildiği tarihi bildirin.
denetim 4 başarısız olduğunda	`tls-inspection` (kritik)	Bu ağ HTTPS'i sonlandırır ve cihazın güvenmediği kendi sertifikasını sunar. Kurulum programı bunu "the certificate presented for this registry is not trusted — this network inspects HTTPS" diye bildirir. Docker bağlantıyı kimlik doğrulamadan önce reddeder. Düzeltme: Sitenizin CA sertifikasını cihazda /usr/local/share/ca-certificates dizinine koyun (konsol: Alt+F2), update-ca-certificates çalıştırın, ardından yeniden başlatın — sonraki çalışma sertifikayı çekmeden önce kurar ve ona güvenir. Siteniz için derlenmiş bir kurulum ortamı bu sertifikayı hâlihazırda taşıyor olabilir; CID222 muhatabınıza sorun. Yanlış bir saat de aynı biçimde okunan bir sertifika hatası ürettiğinden, önce zaman eşitlemesini doğrulayın. Doğrulama: beklenen · Sertifika hatası olmadan Login Succeeded.
denetim 6 başarısız olduğunda	`link-too-slow` (uyarı)	İmaj kümesi kabaca 10-15 GB'dır ve tek tek katmanlar 2 GB'ı aşar. Yaklaşık 2 MB/s'nin altında büyük bir katman, docker vazgeçmeden tamamlanamaz; bu nedenle çekme 6/8'de baştan başlar ya da zaman aşımına uğrarken küçük istekler — oturum açma ve manifestler — başarılı olmayı sürdürür. Kurulum programı hattı zaten ölçer, tek bir indirme akışına düşer ve yeniden deneme sayısını artırır; dolayısıyla docker arka plan süreci yapılandırmasını elle düzenlemek nadiren eksik parçadır. Düzeltme: Hattı suçlamadan önce cihazdan gerçek iş hacmini ölçün. Saha kabaca 2 MB/s'yi sürdüremiyorsa CID222 muhatabınızdan ağdan yalıtım ISO'sunu isteyin: imajları taşır ve hiçbir şey indirmez. Doğrulama: beklenen · Ölçülen hız kabaca 2 MB/s'nin üstünde ya da ağdan yalıtım ortamı kullanılıyor.
denetim 7 başarısız olduğunda	`killed-or-full` (kritik)	Önceki denemeyi ağ değil, makinenin kendisi durdurdu. Bellek tükenmesi nedeniyle sonlandırma "the previous attempt was KILLED BY THE KERNEL" olarak bildirilir; dolan bir disk çekmeyi "the disk filled up" ile durdurur. İkisi de aynı donanımda yeniden denenerek geçiştirilemez. Düzeltme: Belleği en azından desteklenen 32 GB alt sınırına çıkarın ya da makineye daha büyük bir disk verin ve yeniden açın. İndirilmiş imajlar korunur, bu yüzden yeniden deneme kısa sürer. Bkz. Kurulum sırasında kaynak denetimi başarısız oluyor. Doğrulama: beklenen · 6/8 adımı tamamlanıyor ve çalışma "8/8 starting the stack" adımına ulaşıyor.

Bu ağda DHCP yok

Gözetimsiz açılış girdisi kendisine bir adres sunulmasını bekler. Adres sunmayan bir segmentte, adres soran açılış girdisi ya da cihaz konsolundan verilen sabit bir adres gerekir.

Çalışma kitabıinstall

Bu ağda DHCP yok ve cihaz adressiz açılıyor

Şunları görebilirsiniz: no IPv4 network (no default route) (IPv4 ağı yok, varsayılan rota yok) · sanal makine özetinde yalnızca bir fe80:: adresi görünüyor · kurulumdan sonra cihazın IP adresi yok · bu ağda DHCP yok

Başlamadan önce

Sanal ağ bağdaştırıcısı bir ağa iliştirilmiş ve açılışta bağlı durumda mı, yoksa sanal makine ayarlarında bağlantısız mı bırakılmış?beklenen · Bağdaştırıcı bağlı ve cihazın hizmet vermesini istediğiniz ağda.Değilse, önce /install/network-prerequisites sayfasına gidin.
Bu segmentin DHCP'yi yavaş sunduğunu ya da MAC'e göre rezerve ettiğini değil, hiç sunmadığını doğruladınız mı?beklenen · Bu segmentte hiçbir adres sunulmuyor.Değilse, bunun yerine install-provisioning-stops-at-images çalışma kitabını uygulayın.

Denetimler

1
Bu cihazın hangi açılış menüsü girdisinden kurulduğunu denetleyin
beklenen · Kurulum "set the network by hand — no DHCP" girdisinden başlatılmış ya da oradan başlatılacak.
2
Bunun yerine cihaz konsolundan sabit bir adres ayarlanıp ayarlanmadığını denetleyin
beklenen · Bir IPv4 adresi, ağ geçidi ve ad sunucuları ayarlı ve bir varsayılan rota var.
3
Yapılandırdığınız ad sunucularının gerçekten yanıt verdiğini doğrulayın
beklenen · İki sorgu da yanıt veriyor. Zaman aşımına uğrayan yapılandırılmış bir çözümleyici hiç olmamasından kötüdür, çünkü arıza bir ağ kesintisi gibi görünür.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`wrong-boot-entry` (uyarı)	Varsayılan açılış girdisi tümüyle gözetimsizdir ve DHCP bekler; hiçbir zaman adres sormaz. DHCP'si olmayan bir segmentte o girdi, ağı olmayan bir makine ve ilk indirmede duran bir kurulum üretir. Buna ayrılmış girdi ise diske dokunmadan önce bir ağ sayfası gösterir. Düzeltme: "set the network by hand — no DHCP" açılış girdisinden yeniden kurun. Kurulum programı kendi ağ sayfasını gösterir: arabirimi seçin, Edit IPv4 → Manual seçeneğini işaretleyin, alt ağı, adresi, ağ geçidini ve ad sunucularını doldurun, ardından Done seçin. Başka bir şey sorulmaz ve yazdığınız adres, tamamlanmış cihazın koruduğu adrestir. Doğrulama: beklenen · Cihaz yazdığınız adresi tutuyor ve sağlama sonuna kadar çalıştı.
denetim 2 başarısız olduğunda	`no-static-address` (kritik)	Elle hiçbir adres yapılandırılmadı ve ağ da bir adres sunmadı; dolayısıyla cihazın yalnızca bağlantı yerel bir adresi var. Dışarı giden her adım — kayıt defterinden çekme, ad çözümleme, güncelleme kanalı — aynı biçimde başarısız olur; bu da nedeni belirtilerden okumayı zorlaştırır. Düzeltme: Yeniden kurmak yerine adresi cihaz konsolundan ayarlayın: konsol için Alt+F1, ardından F2 tuşlarına basın ve adresi, ağ geçidini ve ad sunucularını girin. Konsol ABD klavye düzenini kullanır ve Caps Lock açıkken uyarır. Sonrasında yeniden başlatın — sağlama kendiliğinden kaldığı yerden sürer ve indirilmiş olan her şeyi korur. Doğrulama: beklenen · Ayarladığınız adres duruyor ve bir varsayılan rota var.
denetim 3 başarısız olduğunda	`resolver-unreachable` (kritik)	Sabit yapılandırma ad sunucularını da içerir ve oradaki yanlış bir girdi, adresi olan ama hiçbir şeyi çözümleyemeyen bir cihaz üretir. Kurulum programı bunun üzerine kayıt defterini ne bu ağın DNS'iyle, ne genel çözümleyicilerle, ne de sabitlenmiş bir adresten çözümleyebildiğini bildirir. Düzeltme: Konsolun ağ sayfasındaki ad sunucularını düzeltin ve yeniden başlatın. Sahanın çözümleyicileri kayıt defteri için hiç yanıt veremiyorsa, CID222 muhatabınızın verdiği adresi kurulum penceresi boyunca geçici bir atlatma olarak /etc/hosts dosyasına ekleyin. Doğrulama: beklenen · Sorgu beklenen adresle yanıt veriyor.

Hiçbir şey indirilmeden kaynak denetimi başarısız oluyor

Bellek ve boş disk, ilk indirmeden önce denetlenir. Kurulum programının kendi eşikleri şu anda desteklenen alt sınırdan eskidir; bu nedenle yalnızca uyarı veren bir kurulum da yetersiz boyutlandırılmış olabilir.

Çalışma kitabıinstall

Kurulum programı, hiçbir şey indirmeden bellek ya da boş disk yüzünden duruyor

Şunları görebilirsiniz: this machine has 4096 MB of RAM — the appliance cannot run below 6 GB (bu makinede 4096 MB RAM var; cihaz 6 GB'ın altında çalışamaz) · only 12 GB free on / — the release images need about 40 GB (/ üzerinde yalnızca 12 GB boş; sürüm imajları yaklaşık 40 GB ister) · memory is 8192 MB; 16 GB is the designed size (bellek 8192 MB; tasarım boyutu 16 GB) · kurulum programı "0/8 this machine" adımında durdu

Başlamadan önce

Bu cihazın hangi paket için lisanslandığını biliyor musunuz? RAM tabanı pakete göre değişir.beklenen · Cihazın hangi paket için kurulduğunu söyleyebiliyorsunuz.Değilse, önce /install/requirements sayfasına gidin.

Denetimler

1
Kurulum programının bu makinede ölçtüğü belleği okuyun
beklenen · Bildirilen bellek en az 32 GB — tüm yığın için desteklenen alt sınır.
2
Kurulum programının kök dosya sisteminde ölçtüğü boş diski okuyun
beklenen · En az 100 GB boş — desteklenen alt sınır. Kurulum programı 20 GB'ın altında reddeder, 45 GB'ın altında uyarır.
3
Çekirdeğin önceki denemeyi durdurup durdurmadığını denetleyin
beklenen · Hiçbir satır "KILLED BY THE KERNEL" bildirmiyor.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`ram-too-small` (kritik)	Kurulum programı, hiçbir şey indirmeden önce belleği ve boş diski denetler; aksi hâlde yetersiz boyutlandırılmış bir makine bir saat sonra ayakta kalmayan kapsayıcılar biçiminde başarısız olur. 6 GB'ın altında reddeder, 16 GB'ın altında uyarır — ancak 16 GB eski tasarım değeridir ve tüm yığın için desteklenen alt sınır artık 32 GB'dır. Dolayısıyla yalnızca uyarı üreten bir çalışma da yük altında bellek nedeniyle sonlandırılacak bir makine olabilir. Düzeltme: Makineyi kapatın, belleği starter ve professional paketleri için en az 32 GB'a, enterprise için 64 GB'a yükseltin ve yeniden açın. İndirilmiş imajlar korunur, bu nedenle yeniden deneme hızlıdır. Bkz. Gereksinimler ve boyutlandırma. Doğrulama: beklenen · Adım yükseltilmiş belleği bildiriyor ve çalışma bu adımı geçiyor.
denetim 2 başarısız olduğunda	`disk-too-small` (kritik)	Sürüm imajı kümesinin inmesi ve açılması yaklaşık 40 GB ister; bir güncelleme ise bunun üstüne her imajın ikinci bir kopyası için yer ister. Kurulum programı 20 GB boş alanın altında reddeder, 45 GB'ın altında uyarır; üretim cihazı için desteklenen alt sınır 100 GB'dır. Düzeltme: Makineye daha büyük bir disk verin ve yeniden kurun. Aynı diskte yeniden denemek başarılı olamaz — kurulum programının kendi iletisi bunu söyler. Sanal diski büyütüp dosya sistemini büyütmemek de işe yaramaz; denetim, kök dosya sistemindeki boş alanı okur. Doğrulama: beklenen · Kök dosya sisteminde en az 100 GB boş.
denetim 3 başarısız olduğunda	`oom-during-install` (kritik)	Çekirdek, önceki denemeyi bellek tükendiği için sonlandırdı. Kurulum programı bu nedeni saklar ve sonraki açılışta bildirir; çünkü kurulumunu sessizce yeniden başlatan bir makine ağ arızası gibi görünür. Bütün kurulumun bellek tepesi, imaj kümesinin açılmasıdır. Düzeltme: Belleği en az 32 GB'a yükseltin ve yeniden açın. İndirilmiş olan her şey korunur. Makine zaten 32 GB'daysa ve hâlâ sonlandırılıyorsa, başka bir şeyi değiştirmeden önce konsol çıktısını ve günlüğü toplayın. Doğrulama: beklenen · Çalışma, çekirdek sonlandırması olmadan tamamlanıyor. Bu geçerli değilse: /var/log/cid-firstboot.log dosyasını ve sanal makinenin hipervizördeki kendi bellek yapılandırmasını ekleyin.

Cihaz dışarı çıkamıyor

Ad çözümleme, 443 üzerinde bir TCP bağlantısı ve kurum vekil sunucusu üzerinden kimlik doğrulamalı bir istek birbirinden bağımsız olarak başarısız olur. Diğerleri başarısızken her biri rutin olarak geçebilir.

Çalışma kitabıinstall

Cihaz dışarı çıkamıyor — bir ya da daha fazla çıkış testi başarısız

Şunları görebilirsiniz: egress tests failed (dışarı çıkış denemeleri başarısız oldu) · cihaz imaj kayıt defterine erişemiyor · ETIMEDOUT after 5000ms (5000 ms sonra zaman aşımı) · proxy returned 407 Proxy Authentication Required (vekil sunucu 407 döndürdü — vekil kimlik doğrulaması gerekli)

Başlamadan önce

Bu cihazın bilinçli olarak ağdan yalıtılmış olması değil de internete erişmesi mi bekleniyor?tanılama · appliance.channel = "offline"Değilse, önce /install/updates sayfasına gidin.
Bu sahada, ağdan çıkan her şey için giden bir HTTP vekil sunucusu zorunlu mu?beklenen · Evet ya da hayır diyebiliyorsunuz. Yalnızca vekil sunucuya izin veren bir ağda vekil yapılandırılmamışsa ortaya bir ret değil bir zaman aşımı çıkar; durumu belirsiz kılan da budur.

Denetimler

1
Cihazın giden denemelerini gerçekten çalıştırdığını doğrulayın
tanılama · appliance.egress
2
Cihazın erişmesi gereken ana bilgisayarlar için ad çözümleme sonuçlarını okuyun
tanılama · appliance.dns
3
Cihazda giden bir vekil sunucunun yapılandırılmış olup olmadığını okuyun
tanılama · appliance.proxy.configured = true
4
Son denemede sürüm kanalının yanıt verip vermediğini okuyun
tanılama · appliance.update.channelReachable = true
5
TLS denetleyen bir aygıtın cihaza kendi sertifikasını sunup sunmadığını denetleyin
beklenen · Düzenleyen, kuruluşunuzun denetim CA'sı değil genel bir sertifika otoritesi.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`probes-disabled` (bilgi)	Bu dağıtımda giden denemeler kapatılmıştır; dolayısıyla anlık görüntü hiçbir yönde kanıt taşımaz ve hiçbir dışarı çıkış bulgusu tetiklenemez. Bu, dışarıya hiç istek yapmaması gereken bir kutu için bilinçli bir ayardır. Düzeltme: Ağ geçidi kapsayıcısındaki tanılama dışarı çıkış denemelerini yeniden etkinleştirip anlık görüntüyü yeniden toplayın ya da üç testi cihazın ana makinesinde elle çalıştırın. Cihazın kendiliğinden yaptığı tek giden istek bu denemelerdir. Doğrulama: tanılama · appliance.egress
denetim 2 başarısız olduğunda	`dns-broken` (kritik)	Cihaz, bu ağın çözümleyicisiyle ad çözer. Sağlayıcı ya da kanal ana bilgisayarları için yanıt veremeyen bir çözümleyici her giden çağrıyı aynı biçimde başarısız kılar; bir dizüstündeki tarayıcı ise DNS-over-HTTPS üzerinden çözümlediği için çalışmayı sürdürür. Bu düzelene kadar çözümlemenin aşağısındaki hiçbir şey tanılanamaz. Düzeltme: Anlık görüntünün DNS bölümündeki ana bilgisayarlar için yanıt veren bir çözümleyici ayarlayın, ardından anlık görüntüyü yeniden toplayın. Bkz. Ağ ön koşulları. Doğrulama: tanılama · appliance.dns
denetim 3 başarısız olduğunda	`proxy-not-configured` (kritik)	Bu saha giden bir vekil sunucu zorunlu kılıyor ve cihazda hiç yok; dolayısıyla her giden bağlantı doğrudan denenir ve zaman aşımına uğrar. Bir zaman aşımı, eksik bir ayar gibi değil ölü bir ağ gibi okunur; ağın açık bildirilmesinin nedeni budur. Düzeltme: Giden vekil sunucuyu cihazda yapılandırın ve ayarı yeniden okuması için ağ geçidi kapsayıcısını yeniden başlatın. Docker'ın kendisi ne kabuk ortamını ne de apt'ın yapılandırmasını okur; dolayısıyla yalnızca kabuk için ayarlanmış bir vekil imaj çekmelerine ulaşmaz. Doğrulama: tanılama · appliance.proxy.configured = true
denetim 4 başarısız olduğunda	`https-path-blocked` (kritik)	Adlar çözümleniyor ama HTTPS yolu tamamlanmıyor. Ad çözümleme, 443 üzerinde bir TCP bağlantısı ve kimlik doğrulamalı bir HTTPS isteği birbirinden bağımsız olarak başarısız olur: ICMP'ye izin verip 443'ü engelleyen bir güvenlik duvarı olağandır ve Ubuntu'nun yansıları 80 portundan sunulur, dolayısıyla bu başarısız olurken ping de apt de başarılı olur. Üç test birbirinin yerine geçmez. Düzeltme: Cihazdan, anlık görüntünün başarısız olarak adını verdiği ana bilgisayarlara doğrudan giden HTTPS'e izin verin ya da bunları saha vekil sunucusuna yönlendirip vekili cihazda yapılandırın. Bir kuralı değiştirmeden önce anlık görüntüde başarısız olan her hedefin ayrıntı satırını okuyun — 407 bir vekil kimlik bilgisi sorunudur, zaman aşımı engellenmiş bir yoldur, TLS hatası ise denetimdir. Doğrulama: tanılama · appliance.update.channelReachable = true
denetim 5 başarısız olduğunda	`tls-inspection-untrusted` (kritik)	Bir ara aygıt TLS'i sonlandırıp cihazın güvenmediği bir sertifika sunar; bağlantı bu yüzden el sıkışmada başarısız olur. Ayrıntı satırı zaman aşımı değil bir TLS hatası bildirir; bunu engellenmiş bir porttan ayırmanın tek yolu da budur. Düzeltme: Denetim aygıtına güvenmesi için sahanızın CA sertifikasını cihaza kurun ya da cihazın giden hedeflerini denetimden muaf tutun. İkisi de meşrudur; güvenlik ekibinizin zaten işlettiğini seçin. Doğrulama: beklenen · Başarısız olan dışarı çıkış hedefleri ok bildiriyor ya da düzenleyene artık cihaz tarafından güveniliyor.

Makinenin RAM'i paketin gerektirdiğinden az

Tam yığın, kullanımda yaklaşık 30 GiB olarak ölçülmüştür. Paket alt sınırının altında, baskı zirveye çıktığında çekirdek en büyük tespit servisini tahliye eder.

Çalışma kitabıinstall

Makinenin RAM'i lisanslı paketin gerektirdiğinden az

Şunları görebilirsiniz: This box has 16.0 GB of RAM (bu makinede 16.0 GB RAM var; paket 32 GB istiyor) · ML services will be OOM-killed under load (ML servisleri yük altında bellek tükenmesi nedeniyle sonlandırılacak) · memory is 8192 MB (bellek 8192 MB; tasarlanan boyut 16 GB) · cihaz çalışıyor ama servisler sürekli tahliye ediliyor

Başlamadan önce

Ana makine ajanı bildirim yapıyor mu? O olmadan anlık görüntü makinenin belleğini hiç göremez.tanılama · host.memTotalMb = 0Değilse, önce /troubleshoot/diagnostic-snapshot sayfasına gidin.
Bu cihaz hangi paket için lisanslı? Asgari değer paketten pakete değişir.tanılama · appliance.license.tierDeğilse, önce /install/licensing sayfasına gidin.

Denetimler

1
Toplam belleği, tam yığın için geçerli 32 GB asgarisiyle karşılaştırın
tanılama · host.memTotalMb = 32768
2
Belge ve görüntü işleyen bir dağıtım için 64 GB önerisiyle karşılaştırın
tanılama · host.memTotalMb = 65536
3
Yetersiz boyutlandırmanın şimdiden bir servise mal olup olmadığını denetleyin
beklenen · Hiçbir kapsayıcı bellek nedeniyle sonlandırılmamış.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`below-minimum` (kritik)	Tam yığın, kullanımda kabaca 30 GiB olarak ölçüldü. 32 GB'ın altında makine, tespit servislerini ve modellerini aynı anda tutamaz; baskı tepe yaptığında çekirdek en büyük olanı tahliye eder. Ürün bir gösterimde çalışır ve ilk gerçek yükte başarısız olur; bunu devreye aldıktan sonra değil önce düzeltmeye değmesinin nedeni budur. Düzeltme: Makinenin belleğini en az 32 GB'a yükseltin ve yeniden başlatın. Donanım değiştirilemiyorsa yalnızca çekirdek ağ geçidini ve zorunlu üç tespit servisini çalıştırın, geri kalanını bilinçli olarak kapatın — 16 GB'lık bir makine bir geliştirme yapılandırmasıdır, desteklenen bir üretim yapılandırması değil. Bkz. Gereksinimler ve boyutlandırma. Doğrulama: tanılama · host.memTotalMb = 32768
denetim 2 başarısız olduğunda	`below-recommendation` (uyarı)	32 GB yığını taşır; belgeler, görüntüler ve OCR ise üründeki en büyük geçici ayırmaları ekler ve 64 GB, bunların tespit motorlarıyla çekişmesini önleyen değerdir. Bu iş için GPU önerilir, asla zorunlu değildir. Düzeltme: Belge ve görüntü analizini bütün bir kuruluşa açmadan önce makineyi 64 GB'a yükseltin ya da yükseltebilene kadar bu özellikleri bir pilot grupla sınırlı tutun. Doğrulama: tanılama · host.memTotalMb = 65536
denetim 3 başarısız olduğunda	`already-losing-services` (kritik)	Yetersiz boyutlandırma artık kuramsal değil: bir kapsayıcı sonlandırıldı ya da yeniden başlıyor. Bir tespit motoru kapalıyken çalışması gereken tespitler çalışmadı ve hiçbir şey bunları yeniden denemiyor. Düzeltme: Önce belleği yükseltin, ardından etkilenen pencereye ait tespitleri gözden geçirin — kapalı olan bir tespit motoru kapalı biçimde başarısız olmadı. Bkz. Bir kapsayıcı bellek tükendiği için sonlandırıldı. Doğrulama: beklenen · Hiçbir kapsayıcı bellek tükenmesi sonlandırması bildirmiyor ve yeniden başlatma sayıları kararlı.

Bir dosya sistemi neredeyse dolu

Bir güncelleme her imajın ikinci bir kopyası için yer ister ve kök dosya sistemi dolduğunda durum dizini sessizce başarısız olur.

Çalışma kitabıinstall

Bir dosya sistemi neredeyse dolu

Şunları görebilirsiniz: is 94% full (%94 dolu — 100 GB'ın 6 GB'ı boş) · bir güncelleme, her imajın ikinci bir kopyası için yer ister · no space left on device (aygıtta yer kalmadı) · güncelleme yarıda başarısız oluyor

Başlamadan önce

Ana makine ajanı bildirim yapıyor mu? Ağ geçidi kapsayıcısı, makinenin disklerini değil kendi katman dosya sistemini görür.tanılama · host.disksDeğilse, önce /troubleshoot/diagnostic-snapshot sayfasına gidin.

Denetimler

1
Kök dosya sistemindeki boş alanı okuyun
tanılama · host.disks[/].freeGb = 20
2
Docker'ın imajlarını ve birimlerini tuttuğu yerdeki boş alanı okuyun
tanılama · host.disks[/var/lib/docker].freeGb = 40
3
CID veritabanının ne kadar büyüdüğünü okuyun
tanılama · datastores.postgres.dbSizeMb = 50000

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`root-filling` (kritik)	Cihaz; durumunu, günlüklerini ve güncelleme kuyruğunu kök dosya sistemine yazar. Burası dolduğunda, ürünün günlüğe yazıp devam eden bir işleyiciye sardığı yazmalar sessizce başarısız olur — kurulum durumu, lisans ve güncelleme istekleri kaydedilmiş gibi davranır, oysa kaydedilmemiştir. Düzeltme: Yer açın ya da diski büyütün, ardından durumunu yeniden okuması için ağ geçidi kapsayıcısını yeniden başlatın. Günlük kaydını ve sahanın topladığı günlük dosyalarını denetleyin: aylarca çalışmış bir cihazın dolmasının olağan nedeni, döndürülmeyen bir günlüktür. Doğrulama: tanılama · host.disks[/].freeGb = 20
denetim 2 başarısız olduğunda	`image-store-filling` (kritik)	Bir güncelleme, geçiş yapmadan önce her imajın ikinci bir kopyasını indirir; dolayısıyla cihazın, güncellediği anda kabaca sürüm kümesi boyutunda boş alana ihtiyacı vardır. Bu yer olmadan güncelleme yarıda başarısız olup geri alınır ve bu, dolu bir disk gibi değil bozuk bir güncelleme gibi okunur. Düzeltme: Cihazın artık çalıştırmadığı imajları kaldırın, sonra güncelleyin. Yer açmak için birimleri silmeyin: veritabanını, tespitleri ve cihaz kimliğini onlar tutar. Doğrulama: tanılama · host.disks[/var/lib/docker].freeGb = 40
denetim 3 başarısız olduğunda	`retention-too-long` (uyarı)	Tespit ve olay geçmişi kullanımla birlikte büyür ve varsayılanda hiçbir şey onu budamaz. Yoğun bir cihazda diskin tek başına en büyük tüketicisi veritabanı olur ve ilk belirti, şikâyet eden bir veritabanı değil sığmayan bir güncellemedir. Düzeltme: Tespitler ve olay günlükleri için saklama penceresini, uyumluluk yükümlülüğünüzün gerçekten gerektirdiği süreye indirin ve ardından boyutun düştüğünü doğrulayın. Kayıtların cihazın dışında tutulması gerekiyorsa önce dışa aktarın. Doğrulama: tanılama · datastores.postgres.dbSizeMb = 50000

Ana makine saati senkron değil

Lisans bitişi, sertifika geçerliliği, token ömürleri ve tespit zaman damgalarının tamamı bu saatten gelir. Kayan bir saat, her biri başka bir şeye benzeyen üç ayrı hata üretir.

Çalışma kitabıinstall

Ana makine saati senkron değil

Şunları görebilirsiniz: The host clock is not synchronised (ana makine saati senkron değil) · clock is not synchronised — if the registry login fails on a certificate error, this is why (saat senkron değil; kayıt defteri girişi bir sertifika hatasıyla başarısız oluyorsa nedeni budur) · geçerli bir lisans süresi dolmuş olarak bildiriliyor · oturum açıldıktan hemen sonra token'lar süresi dolmuş diye reddediliyor

Başlamadan önce

Ana makine ajanı bildirim yapıyor mu? Saat bilgisi kapsayıcıdan değil, makinenin kendisinden gelir.tanılama · host.kernelDeğilse, önce /troubleshoot/diagnostic-snapshot sayfasına gidin.

Denetimler

1
Ana makine saatinin bir zaman servisi tarafından ayarlanıp ayarlanmadığını okuyun
tanılama · host.timeSynced = true
2
Cihazın bir zaman kaynağına erişebildiğini doğrulayın
beklenen · Durum, saati senkron olarak bildiriyor ya da ağın izin verdiği bir sunucunun adını veriyor.
3
Kaymanın lisansı çoktan eskitip eskitmediğini denetleyin
tanılama · appliance.license.state = "active|trial"

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`no-time-source` (uyarı)	Lisans bitişi, sertifika geçerliliği, oturum token'ı ömürleri ve her tespit zaman damgası bu saate göre belirlenir. Kayan bir saat bu nedenle lisansları erken bitirir, az önce verilmiş token'ları reddeder ve güncel bir sertifikayı henüz geçerli değil gösterir — her biri başka bir şeye benzeyen üç ayrı arıza. Kurulum sırasında ayrıca kayıt defteri girişini, ağ arızası gibi okunan bir sertifika hatasıyla bozar. Düzeltme: Cihaz ana makinesinde zaman eşitlemesini etkinleştirin ve bu ağın izin verdiği bir zaman kaynağına yöneltin. Ardından ağ geçidi kapsayıcısını yeniden başlatın; böylece açılışta önbelleğe aldığı her şey düzeltilmiş saate göre yeniden değerlendirilir. Doğrulama: tanılama · host.timeSynced = true
denetim 2 başarısız olduğunda	`ntp-blocked` (uyarı)	Bir sunucuya erişemeyen zaman istemcisi saati serbest bırakır ve arıza sessizdir: tarihe bağlı bir şey başarısız olana kadar cihazda hiçbir şey zamanın yanlış olduğunu bildirmez. Birçok saha dışarıya zaman trafiğini kapatır ve bunun yerine iç bir sunucu sağlar. Düzeltme: Cihazı sahanın kendi zaman sunucusuna yöneltin, ya da izin verilen bir dış sunucuya zaman protokolünü açın. Bkz. Ağ ön koşulları. Doğrulama: beklenen · Saat senkron olarak bildiriliyor.
denetim 3 başarısız olduğunda	`licence-mis-aged` (kritik)	Kayma, lisansı geçerlilik penceresinin dışına çoktan itmiştir; dolayısıyla ürün, gerçek bir süre dolumundaki gibi engeller. Bu noktada yenileme istemek, süresi dolmuş görünecek bir lisans daha üretir. Düzeltme: Önce saati düzeltin, sonra lisans durumunu yeniden okuyun. Zaman doğru olduktan sonra durum hâlâ süresi dolmuş görünüyorsa yenileme isteyin. Bkz. Lisansın süresi dolmuş. Doğrulama: tanılama · appliance.license.state = "active\|trial"

Yayımlanmış parolalara sahip örnek hesaplar hâlâ duruyor

Cihaz imajları örnek tohumlama kapalı olarak gelir. Açık bırakıldığı yerlerde, tanıtım kiracıları belgeleri okumuş herkes için çalışan birer oturum açma yolu olur.

Çalışma kitabıinstall

Bu cihazda yayımlanmış parolalara sahip örnek hesaplar var

Şunları görebilirsiniz: Sample accounts are seeded (örnek hesaplar tohumlanmış) · bu makinede sarah_smith hesabı duruyor · bir müşteri cihazında tanıtım kullanıcıları duruyor · belgelerde yazan tanıtım parolası çalışıyor

Başlamadan önce

Bu cihaz, örnek kiracıların asıl amaç olduğu bir tanıtım ya da eğitim kurulumu değil de gerçek kullanıcılara mı hizmet veriyor?tanılama · appliance.deploymentMode = "development"Değilse, önce /develop/getting-started/introduction sayfasına gidin.

Denetimler

1
Bu dağıtımda örnek hesap tohumlamasının kapalı olup olmadığını okuyun
tanılama · posture.seedSampleAccounts = false
2
Örnek kiracıların hâlâ var olup olmadığını denetleyin; tohumlamayı kapatmak, daha önce oluşturulanları silmez
beklenen · Hiçbir örnek kiracı yok.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`sample-seeding-enabled` (bilgi)	Tohumlayıcı, sağlayıcı kataloğunu ekler ve örnek hesaplar kapatılmadıkça parolaları belgelerde yayımlanmış tanıtım kiracılarını da ekler. Cihaz imajları örnek hesaplar kapalı olarak gelir; bu nedenle durum bir geliştirici makinesinde olağan, başka her yerde bir bulgudur — tohumlanmış bir tanıtım kullanıcısı, belgeleri okumuş herkes için çalışan bir oturum açma yoludur. Düzeltme: Dağıtımın ortam dosyasında `SEED_SAMPLE_ACCOUNTS` değerini `false` yapın ve ağ geçidi kapsayıcısını yeniden başlatın; böylece sonraki bir tohumlama bunları yeniden oluşturmaz. Tohumlamanın tamamını kapatmayın: bu, sağlayıcı kataloğunu da atlar ve ürünü bir modeli çözemez durumda bırakır. Doğrulama: tanılama · posture.seedSampleAccounts = false
denetim 2 başarısız olduğunda	`sample-accounts-still-present` (uyarı)	Ayarı kapatmak, sonraki tohumlamanın hesapları oluşturmasını durdurur; hâlihazırda var olan hesapları kaldırmaz. Devredilmeden önce tanıtımı yapılmış bir makine, birileri silene kadar bu hesapları yayımlanmış parolalarıyla birlikte taşımaya devam eder. Düzeltme: Örnek kiracıları Kiracılar altında silin, ya da oturumlarının ve tespitlerinin bir tanıtım için korunması gerekiyorsa parolalarını değiştirin. Ardından asıl kullandığınız yönetici hesabının tohumlananlardan biri olmadığını doğrulayın. Doğrulama: beklenen · Oturum açma reddediliyor.

Ağdan yalıtılmış bir cihazda OCR servisinin modelleri yok

Model denetimi eklenmeden önce derlenmiş bir imaj, motoru taşıyıp modellerini taşımayabilir: modelleri istek üzerine indiren bağlantılı bir makinede sağlıklı, ağdan yalıtılmış bir makinede ölümcül.

Çalışma kitabıinstall

Ağdan yalıtılmış bir cihazda OCR servisinin modelleri yok

Şunları görebilirsiniz: HTTP 503: det/rec models not found (algılama ve tanıma modelleri bulunamadı) · ocr-service yanıt verdi ama sağlıklı değil · görüntü analizi cihazda hiç metin döndürmüyor, geliştirme makinesinde çalışıyor · makinenin interneti varken OCR çalışıyor, yokken başarısız oluyor

Başlamadan önce

Bu dağıtım görüntü ya da belge analizi kullanıyor mu? OCR servisi birçok müşteride isteğe bağlıdır.beklenen · En az biri kullanımda. Hiçbiri kullanılmıyorsa sağlıksız bir OCR servisinin bugün bir maliyeti yok.Değilse, önce /troubleshoot/health-matrix sayfasına gidin.
OCR servisi hiç yanıt veriyor mu, yoksa ortada yok ya da kapalı mı?tanılama · services[ocr-service].reachable = trueDeğilse, bunun yerine service-unhealthy çalışma kitabını uygulayın.

Denetimler

1
OCR servisinin kendini sağlıklı bildirip bildirmediğini okuyun
tanılama · services[ocr-service].healthy = true
2
Sağlıksız bir OCR servisini başka bir nedenle üreten bellek tükenmesi sonlandırmasını eleyin
beklenen · oomKilled false.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`models-absent-from-image` (uyarı)	OCR modelleri imaja derleme sırasında gömülür. Güncel sürümlerde motorun kurulması yalnızca yön sınıflandırıcısını indirir — algılama ve tanıma ilk kullanımda gelir — bu nedenle kurulum adımında duran bir derleme, birkaç megabaytlık model taşıyan devasa bir imaj üretti. O imaj, geri kalanını gerektiğinde indiren ağa bağlı bir makinede sağlıklı, indiremeyen ağdan yalıtılmış bir makinede ölümcüldür. Derleme artık gerçek bir tahmini zorunlu kılıyor ve algılama ile tanıma yoksa imajı reddediyor; dolayısıyla bu durum yalnızca o denetimden önce derlenmiş imajları etkiler. Düzeltme: OCR imajını, model denetimini geçen bir derlemeden gelen imajla değiştirin; çalışan bir kapsayıcının içinde onarılacak bir şey yoktur, çünkü dosyalar oraya hiç girmemiştir. Yeniden derlerken önbelleği kıran bir derleme argümanı geçirin — aksi hâlde ön indirme katmanı önbellekten sunulur ve başarısız bir indirme kalıcıymış gibi görünür. Doğrulama: tanılama · services[ocr-service].healthy = true Bu geçerli değilse: Destek paketini ve anlık görüntünün ocr-service için bildirdiği imaj özetini ekleyin.
denetim 2 başarısız olduğunda	`ocr-oom` (kritik)	Üründeki en büyük geçici ayırmaları OCR servisi tutar; bu nedenle yetersiz boyutlandırılmış bir makinede çekirdeğin ilk sonlandırdığı şey odur. Sonuç — sağlıksız bir OCR servisi ve hiçbir şey döndürmeyen görüntü analizi — sonlandırma bayrağını okuyana kadar eksik bir modelden ayırt edilemez. Düzeltme: Bir kapsayıcı bellek tükendiği için sonlandırıldı yolunu izleyin. Belge ve görüntü işleyen bir dağıtım için öneri 64 GB'tır. Doğrulama: beklenen · oomKilled false ve servis kendini sağlıklı bildiriyor.

İlk açılış ve kurulum sihirbazı

Kurulum bitti ama pano yüklenmiyor

ISO'dan kurulan bir cihaz yalnızca HTTPS sunar ve ön yüz, kullanamadığı bir sertifikayla başlamayı reddeder. Boş bir sayfanın, reddedilen bir bağlantının ve kısa süreli bir yukarı akış hatasının üç ayrı nedeni vardır.

Çalışma kitabıfirst-boot

Kurulum bitti ama pano yüklenmiyor

Şunları görebilirsiniz: tarayıcı boş beyaz bir sayfa gösteriyor · https://<ip>/ bağlantıyı reddediyor · HTTPS sidecar FAILED (HTTPS yardımcı kapsayıcısı başarısız oldu) · 3 of 16 containers are running; these are not: (16 kapsayıcının 3'ü çalışıyor, çalışmayanlar şunlar)

Başlamadan önce

Konsol, kırmızı bir FAILED satırıyla durmak yerine çalışmanın sonuna ulaştı mı?beklenen · Çalışma "8/8 starting the stack" adımına ulaştı ve bir durum özeti yazdırdı.Değilse, bunun yerine install-provisioning-stops-at-images çalışma kitabını uygulayın.
http:// değil https:// adresini mi açıyorsunuz? ISO'dan kurulan bir cihaz yalnızca HTTPS sunar.beklenen · Adres https:// ile başlıyor. Düz bir http:// sayfası boş çizilir, çünkü ön yüz upgrade-insecure-requests politikası gönderir.Değilse, önce /install/setup-wizard sayfasına gidin.
Makine açıldığından bu yana yığına birkaç dakika tanıdınız mı? ML servisleri modellerini ilk açılışta yükler.beklenen · Açılıştan bu yana en az beş dakika geçmiş.

Denetimler

1
Konsolun kendi çalışan kapsayıcı sayımını okuyun
beklenen · Her kapsayıcı çalışıyor ve hiçbir satır "N of M containers are running" bildirmiyor.
2
Cihaz ana makinesinde 443 portunu tutan bir şey olduğunu doğrulayın
tanılama · appliance.tls.servedBy
3
Ağ geçidinin kendisine erişilebildiğini doğrulayın
tanılama · services[nestjs-core].reachable = true
4
Ağ geçidi kapsayıcısının sürekli yeniden başlamadığını doğrulayın
tanılama · containers[nestjs-core].restarts = 3

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 2 başarısız olduğunda	`https-listener-not-installed` (kritik)	HTTPS ön yüzü, çalışmanın sonunda ayrı bir adımla kurulur ve isteğe bağlı değildir: pano upgrade-insecure-requests politikası gönderdiği için düz bir http:// sayfası boş çizilir, dinleyici hiç kurulmadığında ise https:// doğrudan reddedilir. Konsol bunu çalışmanın sonunda bildirir. Düzeltme: Cihaz ana makinesinde HTTPS kurulum programını `sudo bash /opt/cid-install/install-https.sh` ile yeniden çalıştırın, ardından panoyu https:// üzerinden yeniden yükleyin. Cihaz bu aşamada kendinden imzalı bir sertifika sunar ve bu doğrudur — henüz bir adı ve CA'sı yoktur, sertifikayı saha daha sonra değiştirir. Doğrulama: tanılama · appliance.tls.servedBy
denetim 1 başarısız olduğunda	`containers-not-up` (kritik)	Kurulumun kendisi başarılı oldu ve bir ya da daha fazla servis ayakta kalmadı. Konsol her birinin adını verir ve günlüğünün son üç satırını yazdırır; gerekçe oradadır. 137 çıkış kodu, çekirdeğin bellek tükenmesi nedeniyle sonlandırmasıdır ve servisin bozuk olduğu değil, makinenin yetersiz boyutlandırıldığı anlamına gelir. Düzeltme: Kapalı olan her kapsayıcı için konsolun yazdırdığı son satırları okuyun. 137 için makinenin belleğini en az 32 GB'a çıkarıp yeniden başlatın — bkz. Makinenin RAM'i lisanslı paketin gerektirdiğinden az. Başka her durumda günlüğün tamamını `docker compose -f /opt/cid/docker-compose.release.yml logs` ile okuyun. Doğrulama: beklenen · Özet, kapsayıcıların tamamının çalıştığını bildiriyor ve hiçbirini kapalı olarak adlandırmıyor.
denetim 3 başarısız olduğunda	`gateway-down` (kritik)	Pano, her şey için ağ geçidini çağıran durağan bir ön yüzdür. Ağ geçidi yanıt vermediğinde sayfa yüklenip ardından her isteği başarısız kılabilir ya da ön yüz, hiç gelmeyen bir yukarı akışı beklerken 502 döndürebilir. Düzeltme: Ağ geçidi kapsayıcısının en son açılışından itibaren günlüğünü okuyun ve bildirdiği açılış hatasını giderin. Yer tutucu bir JWT gizli anahtarı, tasarım gereği açılışı reddeder; bekleyen geçişler ise yeni sütunları okuyan bileşenleri durdurur — ikisi de burada hizmet vermeyen bir ağ geçidi olarak görünür. Doğrulama: tanılama · services[nestjs-core].reachable = true Bu geçerli değilse: Ağ geçidi günlüğünün son satırlarını taşıyan destek paketini ekleyin.
denetim 4 başarısız olduğunda	`gateway-crashloop` (kritik)	Ağ geçidi yeniden başlıyor; bu nedenle yeniden başlatmanın ortasına denk gelen istekler, okuyucunun yaptığı işle ilgisi olmayan hatalarla başarısız olur. Sürekli yüksek bir yeniden başlatma sayısı yükün değil, bir açılış hatasının imzasıdır. Düzeltme: Bir kapsayıcı sürekli yeniden başlıyor yolunu izleyin; orada bellek tükenmesi nedeniyle sonlandırma ile yapılandırma reddi birbirinden ayrılır. Doğrulama: tanılama · containers[nestjs-core].restarts = 3

Bağlantı adımı 500 döndürüyor

Neredeyse her zaman ağ sorunu değil, durum dizinindeki bir izin sorunudur — bağlantı denemesinin kendisi, yazma işlemi başarısız olmadan önce pekâlâ başarılı olmuş olabilir.

Çalışma kitabıfirst-boot

Kurulum sihirbazının bağlantı adımı 500 döndürüyor

Şunları görebilirsiniz: POST /setup/connectivity → 500 (kurulum bağlantı adımı sunucu hatası döndürüyor) · kurulum sihirbazının bağlantı testi sunucu hatasıyla başarısız oluyor · Internal server error (sihirbazın ağ adımında dâhilî sunucu hatası) · sihirbaz bağlantı adımını geçmiyor

Başlamadan önce

Cihaz hâlâ kurulum kipinde mi, sihirbaz bitmemiş durumda mı?tanılama · appliance.setupComplete = falseDeğilse, önce /administer/settings sayfasına gidin.
Ağ geçidi hiç yanıt veriyor mu — sihirbaz sayfasının kendisi yükleniyor mu?tanılama · services[nestjs-core].reachable = trueDeğilse, bunun yerine update-version-zero-or-500 çalışma kitabını uygulayın.

Denetimler

1
Ağ geçidi kapsayıcısının çalıştığını ve sürekli yeniden başlamadığını doğrulayın
tanılama · containers[nestjs-core].restarts = 3
2
Sihirbazın her adımı kalıcılaştırdığı durum dizinine ağ geçidinin yazabildiğini doğrulayın
beklenen · Komut 0 ile çıkıyor ve hiçbir şey yazmıyor. İzin reddi hatası bu nedeni doğrular.
3
Bağlantı adımının yokladığı ana makine adlarının gerçekten çözümlendiğini doğrulayın
tanılama · appliance.dns
4
Dışarı çıkış yoklamalarının sonuçlarını okuyun
tanılama · appliance.egress

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 2 başarısız olduğunda	`state-dir-permissions` (kritik)	Sihirbaz her adımın sonucunu /var/lib/cid altında kalıcılaştırır. Bu dizin root'a aitken ağ geçidi süreci yetkisiz çalışıyorsa — elle atılmış bir `mkdir` ya da sahipliği korumayan bir geri yükleme sonrasındaki durum — yazma hata fırlatır ve işleyici bunu bir izin hatası olarak değil 500 olarak yüzeye çıkarır. Bağlantı yoklamasının kendisi pekâlâ başarılı olmuş olabilir. Düzeltme: Ana makinede durum dizininin sahipliğini, ağ geçidinin kullanıcısı yazabilecek biçimde düzeltin, ardından ağ geçidi kapsayıcısını yeniden başlatıp adımı yeniden deneyin. Dizini herkese yazılabilir yapmayın; cihaz kimliğine ait malzeme tutar. Doğrulama: beklenen · Yoklama 0 ile çıkıyor ve sihirbaz bir sonraki adıma geçiyor.
denetim 1 başarısız olduğunda	`gateway-crashloop` (kritik)	Ağ geçidi kapsayıcısı yeniden başlıyordur; dolayısıyla yeniden başlatmanın ortasına düşen bir istek, bağlantıyla hiç ilgisi olmayan bir 500 ile başarısız olur. Sihirbaz burada bir açılış arızasının belirtisini bildirmektedir — çoğu zaman reddedilen bir yer tutucu JWT gizli anahtarı ya da uygulanmamış bir geçiş. Düzeltme: Ağ geçidi kapsayıcısının günlüğünü en son yeniden başlatmanın başından itibaren okuyun ve açılış hatasının kendisini düzeltin. Önce güvenlik duruşunu denetleyin: yer tutucu bir `JWT_SECRET` açılışı tasarım gereği reddeder ve bekleyen geçişler, şemayı okuyan uçların başarısız olacağı anlamına gelir. Doğrulama: tanılama · containers[nestjs-core].restarts = 3 Bu geçerli değilse: Ağ geçidi günlüğünün son satırlarını taşıyan destek paketini ekleyin.
denetim 3 başarısız olduğunda	`no-dns` (uyarı)	Cihaz, yoklaması istenen ana makine adlarını çözümleyemiyordur. NXDOMAIN yanıtı vermek yerine zaman aşımına uğrayan bir çözümleyici adımı önce askıda bırakır, sonra başarısız eder; bu da sunucu hatası gibi okunur. Düzeltme: Cihazın ağ yapılandırmasında erişilebilir bir DNS sunucusu tanımlayın ve adımı yeniden çalıştırın. DHCP'siz bir kurulumda çözümleyici açıkça yapılandırılmalıdır — bkz. Ağ ön koşulları. Doğrulama: tanılama · appliance.dns
denetim 4 başarısız olduğunda	`egress-blocked` (uyarı)	Ad çözümleme çalışıyor ama dışarıya hiçbir şey çıkmıyor. Ad çözümleme, bir sağlayıcıya TCP/TLS bağlantısı ve yapılandırılmış vekil üzerinden kimlik doğrulamalı bir istek birbirinden bağımsız olarak başarısız olur — başarılı bir DNS sorgusu diğer ikisinin çalıştığının kanıtı değildir ve bunları birbirinin yerine saymak bu adımı kafa karıştırıcı kılan şeydir. Düzeltme: Tanılama anlık görüntüsünde üç yoklama sonucunu ayrı ayrı okuyun ve gerçekte başarısız olanı düzeltin. Saha giden bir vekil gerektiriyorsa yeniden denemeden önce bunu cihazda yapılandırın; yalnızca vekille çıkılan bir ağda tanımsız bir vekil, ret değil zaman aşımı üretir. Doğrulama: tanılama · appliance.egress

Sihirbaz bitiyor ve cihaz yeniden kurulum istiyor

Tamamlanma yazımı, hatayı kaydedip devam eden bir işleyicinin içindedir; bu nedenle yazılamayan bir dizin, tamamlanan bir sihirbaz ve sonraki yeniden başlatmada kendini yeniden kilitleyen bir ürün üretir.

Çalışma kitabıfirst-boot

Kurulum sihirbazı bitiyor ve cihaz yeniden kurulum istiyor

Şunları görebilirsiniz: 423 SETUP_REQUIRED (kurulum gerekli) · Appliance setup is not complete (cihaz kurulumu tamamlanmadı; ürünü kullanmak için ilk açılış kurulumunu bitirin) · sihirbaz tamamlanıyor ve pano beni yeniden ona gönderiyor · kurulumdan sonra her sayfa 423 döndürüyor

Başlamadan önce

Sihirbaz, daha önceki bir adımda durmak yerine son adımına ulaşıp kurulumun tamamlandığını bildirdi mi?beklenen · Sihirbaz son adıma ulaşıyor. Daha erken duruyorsa sorun kilit değil, başarısız olan adımdır.Değilse, bunun yerine setup-connectivity-500 çalışma kitabını uygulayın.
Sihirbazın oluşturduğu yönetici hesabıyla hâlâ oturum açabiliyor musunuz?beklenen · Oturum açma başarılı oluyor. Kimlik doğrulama, ürün kilitliyken de tasarım gereği erişilebilir kalır.Değilse, önce /install/setup-wizard sayfasına gidin.

Denetimler

1
Ağ geçidinin kurulumu tamamlanmış sayıp saymadığını okuyun
tanılama · appliance.setupComplete = true
2
Ağ geçidinin, sihirbazın durumunu kalıcı kıldığı durum dizinine yazabildiğini doğrulayın
beklenen · Komut 0 ile çıkıyor ve hiçbir şey yazdırmıyor.
3
Ağ geçidinin sihirbaz adımları arasında yeniden başlamadığını doğrulayın
tanılama · containers[nestjs-core].restarts = 3

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 2 başarısız olduğunda	`state-dir-not-writable` (kritik)	Sihirbaz durumunu, paylaşılan durum dizinindeki bir dosyaya yazar. Bu yazma, hatayı günlüğe kaydedip devam eden bir işleyicinin içindedir; dolayısıyla yazılamayan bir dizin şu sonucu doğurur: sihirbaz bellekte tamamlanır, kapsayıcı yeniden başlayana kadar ürünün kilidini açar, sonra durum dosyası hâlâ ortada yokken ürünü yeniden kilitler. Olağan nedenler, ana makinede root olarak elle oluşturulmuş bir dizin, sahipliği korumayan bir geri yükleme ya da salt okunur bir bağlamadır. Düzeltme: Ana makinedeki durum dizininin sahipliğini, ağ geçidinin kendi kullanıcısı yazabilecek biçimde düzeltin ve bağlamanın salt okunur olmadığını doğrulayın. Ardından ağ geçidi kapsayıcısını yeniden başlatıp sihirbazı bir kez daha çalıştırın. Dizini herkesçe yazılabilir yapmayın; cihaz kimlik malzemesini tutar. Doğrulama: beklenen · Yoklama 0 ile çıkıyor ve pano sihirbazı değil ürünü yüklüyor.
denetim 1 başarısız olduğunda	`completion-not-persisted` (kritik)	Ağ geçidi kurulumu tamamlanmamış olarak bildirir; dolayısıyla kurulum koruması, sihirbazın, kimlik doğrulamanın ve sağlık denetiminin ihtiyaç duyduğu küçük izin listesinin dışındaki her yolda 423 yanıtı verir. Durum değişene kadar üründeki diğer her şey kilitlidir; panonun sizi geri göndermesinin nedeni budur. Düzeltme: Tamamlanmanın neden kaydedilmediğini saptayın — olağan neden yazılamayan bir durum dizinidir — ardından sihirbazı yeniden tamamlayın. Durum tamamlanmayı kaydettiği anda koruma etkisiz kalır; kilidi açmak için yeniden başlatma gerekmez, yalnızca yitirilmiş bir durumu yeniden yüklemek için gerekir. Doğrulama: tanılama · appliance.setupComplete = true
denetim 3 başarısız olduğunda	`restart-loses-memory-state` (kritik)	Ağ geçidi sihirbaz sırasında yeniden başlıyor. Her yeniden başlatma durumu diskten yeniden yükler; dolayısıyla yalnızca bellekte var olmuş ilerleme yitirilir ve sihirbaz, dosyanın son kaydettiği adımdan yeniden başlar. Düzeltme: Önce yeniden başlatmayı düzeltin, sonra sihirbazı bir kez ve kesintisiz çalıştırın. Bkz. Bir kapsayıcı sürekli yeniden başlıyor. Doğrulama: tanılama · containers[nestjs-core].restarts = 3

Cihazın kaydettiği ayarlar yeniden başlatmadan sonra kalmıyor

Aynı kök nedenin diğer yüzü: kurulum durumu, lisans, güncelleme istekleri ve tanılama aktarımı tek bir dizini paylaşır ve birlikte sessizce başarısız olur.

Çalışma kitabıfirst-boot

Cihazın kaydettiği ayarlar yeniden başlatmadan sonra kalmıyor

Şunları görebilirsiniz: the setup state directory is not writable (kurulum durumu dizinine yazılamıyor) · setup-state write failed (kurulum durumunun yazılması başarısız oldu) · yüklediğim lisans yeniden başlatmadan sonra kayboldu · sihirbaz tamamlanıyor ve yeniden karşıma çıkıyor

Başlamadan önce

Ağ geçidi kapsayıcısı çalışıyor mu — yani bir yazma denemesi hiç yapılabiliyor mu?tanılama · services[nestjs-core].reachable = trueDeğilse, bunun yerine first-boot-no-dashboard çalışma kitabını uygulayın.

Denetimler

1
Ortak durum dizinine, ağ geçidinin kendi kullanıcısı olarak bir yoklama dosyası yazıp silin
beklenen · Komut 0 ile çıkıyor ve hiçbir şey yazmıyor. Permission denied ya da salt okunur bir dosya sistemi bu çalışma kitabını doğrular.
2
Aynı yoklamayı ürünün yazdığı her alt dizinde yineleyin
beklenen · Dördü de 0 ile çıkıyor.
3
Durum dizinini barındıran dosya sisteminde yer olduğunu denetleyin
tanılama · host.disks[/].freeGb = 2

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`ownership-or-readonly-mount` (kritik)	Ağ geçidi ayrıcalıksız çalışır ve kalıcı durumunu tek bir ortak dizinin altına yazar: kurulum durumu dosyası, lisans, güncelleme istekleri ve tanılama aktarımı hep oradadır. Bu yazmaların her biri, hatayı günlüğe yazıp devam eden bir işleyicinin içindedir; dolayısıyla yazılamayan bir dizin, hata bildiren bir ürün değil, değişiklikleri kabul ediyor görünen ve bir sonraki yeniden başlatmada unutan bir ürün üretir. Düzeltme: Ana makinede durum dizininin sahipliğini, ağ geçidinin kullanıcısı yazabilecek biçimde düzeltin ve bağlama noktasının salt okunur olmadığını doğrulayın. Ardından var olan durumu yeniden okuması için ağ geçidi kapsayıcısını yeniden başlatın. Dizini herkese yazılabilir yapmayın — cihazın kimlik malzemesini taşır. Doğrulama: beklenen · Yoklama 0 ile çıkıyor ve ayar yeniden başlatmadan sonra da duruyor.
denetim 2 başarısız olduğunda	`subdirectory-owned-by-root` (kritik)	Üst dizin yazılabilir, bir alt dizin değildir — root olarak elle yapılmış bir mkdir'in ya da ağacı sahiplikleri korumadan yeniden oluşturan bir geri yüklemenin ardından kalan durum. Yalnızca o tek alt dizine yazan özellik başarısız olur; belirtinin depolamaya değil de lisanslamaya ya da güncellemelere özgü görünmesinin nedeni budur. Düzeltme: Yalnızca kökün değil, durum kökünün altındaki her alt dizinin sahipliğini düzeltin, ardından ağ geçidi kapsayıcısını yeniden başlatın. Doğrulama: beklenen · Dördü de 0 ile çıkıyor.
denetim 3 başarısız olduğunda	`disk-full` (kritik)	Durum dizinini barındıran dosya sisteminde yer kalmamıştır, dolayısıyla yazmalar izinlerle hiç ilgisi olmayan bir nedenle başarısız olur. Ürün her iki durumda da aynı davranır, çünkü ikisi de aynı işleyici tarafından yutulur. Düzeltme: Cihazda yer açın ya da diski büyütün. Bkz. Bir dosya sistemi neredeyse dolu. Doğrulama: tanılama · host.disks[/].freeGb = 2

Sağlayıcı adımı boş liste gösteriyor

Sağlayıcı ve model kayıtları koddan değil, veritabanı tohumlayıcısından gelir. Bozuk bir şey yoktur; veriler hiç eklenmemiştir.

Çalışma kitabıfirst-boot

Kurulum sihirbazının sağlayıcı adımı boş liste gösteriyor

Şunları görebilirsiniz: GET /setup/providers boş liste döndürüyor · sihirbazda seçilecek sağlayıcı yok · kurulum sırasında sağlayıcı açılır listesi boş · sihirbazda OpenAI ya da Anthropic seçilemiyor

Başlamadan önce

Cihaz hâlâ kurulum kipinde mi?tanılama · appliance.setupComplete = falseDeğilse, önce /administer/credentials sayfasına gidin.

Denetimler

1
Ağ geçidinin PostgreSQL'e erişebildiğini doğrulayın — sağlayıcı listesi koda gömülü değil, oradan okunur
tanılama · datastores.postgres.reachable = true
2
Bekleyen geçiş olmadığını, böylece sağlayıcı ve model tablolarının güncel biçimleriyle var olduğunu doğrulayın
tanılama · datastores.postgres.migrationsPending
3
Kurulum API'sinden sağlayıcı listesini isteyin
GET /setup/providers

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 3 başarısız olduğunda	`seed-never-ran` (kritik)	Sağlayıcı ve model satırları koddan değil, veritabanı tohumlayıcısından gelir. Açılışta tohumlama kapalıyken tablolar boş kalır ve sihirbaz sadakatle seçilecek hiçbir şey göstermez. Bozuk bir şey yoktur — veriler hiç eklenmemiştir. Düzeltme: Açılışta tohumlamayı etkinleştirin ya da tohumlayıcıyı bu veritabanına karşı bir kez çalıştırın, ardından sihirbaz adımını yeniden yükleyin. Tohumlama, sağlayıcı satırlarını ve modellerini ekler; kimlik bilgisi eklemez, bu yüzden kendi API anahtarınızı yine sonraki adımda verirsiniz. Doğrulama: GET /setup/providers Bu geçerli değilse: Tohumlayıcı hatasız çalışıyor ve liste hâlâ boşsa destek paketini ve tohumlayıcı günlüğünü ekleyin.
denetim 1 başarısız olduğunda	`database-unreachable` (kritik)	Ağ geçidi PostgreSQL'e erişemiyor; bu nedenle veritabanına dayanan her liste görünür bir hata vermek yerine boş kalır. Sağlayıcı adımı, bunun sihirbazda belirginleştiği ilk yerdir, o kadar. Düzeltme: Veritabanı kapsayıcısını başlatın ve sağlık denetiminin geçmesini bekleyin, ardından adımı yeniden yükleyin. Kapsayıcı çalışıyor ama erişilemiyorsa ağ geçidinin veritabanı ana makinesinin, portunun ve kimlik bilgilerinin veritabanının gerçekte sunduklarıyla eşleştiğini denetleyin. Doğrulama: tanılama · datastores.postgres.reachable = true
denetim 2 başarısız olduğunda	`migrations-pending` (kritik)	Derlenmiş geçiş zinciri, şemada kayıtlı olmayan geçişler içeriyor; dolayısıyla sağlayıcı ya da model tablolarında geçerli kodun seçtiği sütunlar eksik. Sorgu başarısız olur ya da hiçbir şey döndürmez ve sihirbaz boş liste gösterir. Düzeltme: Bekleyen geçişleri uygulayıp ağ geçidini yeniden başlatın. Giriş noktası, eşitleme kapalıyken bunları her açılışta uygular; bu yüzden açılmış bir cihazda boş olmayan bir bekleyen liste, o çalışmanın başarısız olduğu anlamına gelir — körlemesine yeniden çalıştırmak yerine başarısız olan açılıştan itibaren ağ geçidi günlüğünü okuyun. Doğrulama: tanılama · datastores.postgres.migrationsPending

Token imzalama gizli anahtarı bir yer tutucu

Yayımlanmış bir yer tutucu, kaynağa erişimi olan herkesin yönetici token'ı üretmesine izin verir. Tanımsız bir gizli anahtar bundan farklıdır ama o da güvenli değildir: her yeniden başlatma her oturumu geçersiz kılar.

Çalışma kitabıfirst-boot

Token imzalama gizli anahtarı bir yer tutucu ya da hiç tanımlı değil

Şunları görebilirsiniz: JWT_SECRET is a known placeholder (JWT_SECRET bilinen bir yer tutucu) · ağ geçidi, imzalama gizli anahtarıyla ilgili bir ileti vererek açılmayı reddediyor · her yeniden başlatmadan sonra herkesin oturumu kapanıyor · kapsayıcı yeniden başladığında tokenlar çalışmayı bırakıyor

Başlamadan önce

Bu kutuyu sizden başkası da kullanıyor mu, ya da kutu gerçek kiracı verisi tutuyor mu?tanılama · appliance.deploymentMode = "development"Değilse, önce /develop/getting-started/authentication sayfasına gidin.

Denetimler

1
Etkin imzalama gizli anahtarının bir yer tutucu ya da tanımsız olup olmadığını okuyun
tanılama · posture.jwtSecretPlaceholder = false
2
Bilinen bir yer tutucu tasarım gereği açılışı reddettiği için, ağ geçidinin gerçekten başladığını doğrulayın
tanılama · services[nestjs-core].reachable = true

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`placeholder-secret` (kritik)	Bu cihazın verdiği her oturum tokenı bu gizli anahtarla imzalanır; aynı anahtar, saklanan dizin bağlanma parolalarını koruyan anahtarı da türetir. Yayımlanmış bir yer tutucu, kaynağa erişebilen herkesin bu cihaz için bir yönetici tokenı basabilmesi demektir. Tanımsız bir gizli anahtar bundan farklıdır ama güvenli değildir: ağ geçidi her açılışta geçici bir anahtar üretir, dolayısıyla her yeniden başlatma her oturumu geçersiz kılar. Düzeltme: `openssl rand -hex 64` ile 64 onaltılık karakter üretin, cihazın ortam dosyasında `JWT_SECRET` değerini bu değere ayarlayın ve ağ geçidi kapsayıcısını yeniden başlatın. Gizli anahtarı döndürmek herkesin oturumunu bir kez kapatır; amaçlanan maliyet budur. Sonrasında dizin bağlanma parolalarını yeniden girin: bunlar eski gizli anahtardan türetilmiş bir anahtarla şifrelenmişti. Doğrulama: tanılama · posture.jwtSecretPlaceholder = false
denetim 2 başarısız olduğunda	`boot-refused` (kritik)	Açılış, bilinen bir yer tutucuyla hizmet vermektense onu reddeder; dolayısıyla ağ geçidi hiç ayağa kalkmaz ve her sayfa ön yüzün kendi yukarı akış hatasını bildirir. Ret bilinçlidir — tokenları herkese açık bir gizli anahtarla imzalayan bir ürün, hiç başlamayandan kötüdür. Düzeltme: Yukarıdaki gibi gerçek bir `JWT_SECRET` ayarlayın ve kapsayıcıyı yeniden başlatın. Reddin gizli anahtarla mı yoksa açılışta ayrıca başarısız olan başka bir şeyle mi ilgili olduğunu doğrulamak için kapsayıcının ilk günlük satırlarını okuyun. Doğrulama: tanılama · services[nestjs-core].reachable = true

Lisanslama

Etkinleştirme aşamasına iki hata egemendir ve ikisinin kök nedeni ortaktır: yapısal olarak doğrulayamadığı bir lisansı zorunlu kılan bir cihaz.

Lisans yüklemesi 400 "rejected: signature" ile başarısız oluyor

Lisans dosyası genellikle sağlamdır. Cihazda onu denetleyecek bir imzalama açık anahtarı yoktur, bu yüzden her lisans sahte görünür.

Çalışma kitabılicensing

Lisans yüklemesi 400 "rejected: signature" ile başarısız oluyor

Şunları görebilirsiniz: 400 rejected: signature (imza reddedildi) · 400 rejected: ENOENT (dosya bulunamadı) · License upload → 400 (lisans yüklemesi 400 döndürüyor) · lisans dosyası yüklenmiyor

Başlamadan önce

Bu cihazda ilk açılış kurulum sihirbazı tamamlandı mı?tanılama · appliance.setupComplete = trueDeğilse, bunun yerine setup-connectivity-500 çalışma kitabını uygulayın.
Yüklediğiniz dosya, tam olarak BU cihazın kurulum kimliği için verilmiş ve verildiğinden beri değiştirilmemiş lisans mı?beklenen · İki kimlik karakteri karakterine aynı.Değilse, önce /install/licensing sayfasına gidin.

Denetimler

1
Lisans güven çıpasının ana makinede var olduğunu doğrulayın
tanılama · appliance.license.trustAnchorPresent = true
2
Cihazın bir kurulum kimliği bildirdiğini doğrulayın
tanılama · appliance.license.installationId
3
Ana makine saatinin NTP ile disipline edildiğini doğrulayın
tanılama · host.timeSynced = true
4
Ağ geçidinin bildirdiği lisans durumunu okuyun
GET /admin/license/status → {"state":"active|trial"}

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`missing-anchor` (kritik)	Lisans imzalama açık anahtarı (/etc/cid/license-pubkey.pem) bu imaja hiç gömülmemiş ya da sonradan kaldırılmıştır. Doğrulamanın imzayı karşılaştıracağı bir şey yoktur; dolayısıyla kusursuz geçerli olanlar da dahil her lisans sahte sayılıp reddedilir. API bunu eksik anahtar hatası olarak değil, imza ya da ENOENT iletisi taşıyan bir 400 olarak gösterir; suçun lisans dosyasına atılmasının nedeni budur. Düzeltme: Güven çıpasını ana makinede geri yükleyip ağ geçidi kapsayıcısını yeniden başlatın, ardından lisansı yeniden yükleyin. Cihazda çıpa imajın parçasıdır: onu taşımayan bir imaj yanlış derlenmiştir ve çözüm, kaynağı belirsiz bir anahtarı elle yerleştirmek değil ana makine onarımını yeniden çalıştırmaktır. Lisanslama ve etkinleştirme yolunu izleyin; cihaz çıpasız gönderilmiş bir imajdan derlendiyse kendiniz anahtar bulmaya çalışmak yerine destek paketini toplayıp konuyu yükseltin. Doğrulama: tanılama · appliance.license.trustAnchorPresent = true Bu geçerli değilse: Destek paketini ekleyin. Kusur cihazda değil, imaj derlemesindedir.
denetim 2 başarısız olduğunda	`null-installation-id` (kritik)	Cihaz hiçbir kurulum kimliği bildirmiyor; dolayısıyla onun için verilmiş bir lisans olamaz ve hiçbir lisans ona bağlanamaz. Bu normalde kimliğin ilk açılış sırasında hiç üretilmediği ya da kimliği tutan dosyanın ağ geçidi kapsayıcısınca okunamadığı anlamına gelir. Düzeltme: İlk açılış kimlik adımını yeniden çalıştırın ve kimliğin Ayarlar → Lisans sayfasında göründüğünü doğrulayın. Lisansı ancak kararlı bir kimlik göründükten sonra isteyin; boş bir kimliğe karşı verilmiş lisans kullanılamaz. Bkz. Lisanslama ve etkinleştirme. Doğrulama: tanılama · appliance.license.installationId
denetim 3 başarısız olduğunda	`clock-skew` (uyarı)	Lisans geçerliliği tarihlerle sınırlanır. Lisansın ek süresinden daha fazla sapmış bir ana makine saati, geçerli bir lisansı henüz geçerli değil ya da süresi dolmuş gösterir ve hata, bir imza hatasıyla aynı yerde ortaya çıkar. Düzeltme: Ana makine saatini düzeltip NTP ya da chrony'yi etkinleştirin, ardından ağ geçidi kapsayıcısını yeniden başlatıp lisansı yeniden yükleyin. Cihazın ihtiyaç duyduğu NTP dışarı çıkışı için bkz. Ağ ön koşulları. Doğrulama: tanılama · host.timeSynced = true
denetim 4 başarısız olduğunda	`wrong-licence-for-this-box` (kritik)	Güven çıpası, kurulum kimliği ve saat doğru; yani imza denetimi anlamlıdır ve başarısız oluyor. Lisans başka bir kurulum kimliği için verilmiş, aktarım sırasında değiştirilmiş (olağan suçlu, satırları yeniden saran bir posta istemcisidir) ya da kırpılmıştır. Düzeltme: Lisans dosyasını veren portaldan yeniden indirin, ikili bir ek olarak ya da sağlama toplamı doğrulanmış bir kopyayla aktarın ve bir düzenleyicide açmadan yeniden yükleyin. Lisanstaki kurulum kimliği bu cihazınkiyle eşleşmiyorsa lisansın yeniden düzenlenmesini isteyin. Doğrulama: GET /admin/license/status → {"state":"active\|trial"} Bu geçerli değilse: Destek paketini ve Ayarlar → Lisans sayfasında gösterilen kurulum kimliğini ekleyin.

Cihazda lisans güven çıpası yok

Aynı eksik anahtar, henüz kimse bir şey yüklemeden önce. Zorunluluk kapalıyken cihaz deneme sürümünü sessizce çalıştırır; bu nedenle eksiklik ancak deneme süresi bittiğinde ortaya çıkar.

Çalışma kitabılicensing

Cihazda lisans güven çıpası yok ve yalnızca denemeyi çalıştırabiliyor

Şunları görebilirsiniz: No license trust anchor (/etc/cid/license-pubkey.pem) (lisans güven çıpası yok) · bu makinede hiçbir lisans doğrulanamıyor · cihaz yalnızca yerleşik denemeyi çalıştırıyor · hangi lisans dosyasını yüklersek yükleyelim hepsi reddediliyor

Başlamadan önce

Bu, compose dosyasından başlatılmış bir geliştirme yığını değil de CID222 kurulum ortamından oluşturulmuş bir cihaz mı?tanılama · appliance.deploymentMode = "appliance"Değilse, önce /develop/getting-started/introduction sayfasına gidin.

Denetimler

1
Lisans imzalama açık anahtarının ana makinede var olup olmadığını okuyun
tanılama · appliance.license.trustAnchorPresent = true
2
Lisans zorunluluğunun açık olup olmadığını okuyun; eksik güven çıpasının ne kadar kötü olduğuna bu karar verir
tanılama · appliance.license.requireLicense = false

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`anchor-absent` (uyarı)	Lisans imzalama açık anahtarı cihaz imajının bir parçasıdır ve /etc/cid/license-pubkey.pem konumunda durur. O olmadan doğrulamanın bir imzayı karşılaştıracağı hiçbir şey yoktur; bu nedenle geçerli olanı dahil her lisans sahte sayılarak reddedilir. Zorunluluk kapalıyken cihaz yerleşik denemesini çalıştırmayı sürdürür — eksik güven çıpasının çoğu zaman ancak deneme süresi bittiğinde fark edilmesinin nedeni budur. Düzeltme: Ayarlar → Sistem Güncellemeleri sayfasından ana makine onarımını çalıştırın; bu, imajın taşıması gereken dosyaları yeniden oluşturur. Ardından anlık görüntüyü yeniden denetleyin. Onarımdan sonra da güven çıpası bulunmayan bir imaj yanlış oluşturulmuştur: kaynağı bilinmeyen bir anahtarı elle yerleştirmek yerine destek paketini toplayın ve konuyu yükseltin. Doğrulama: tanılama · appliance.license.trustAnchorPresent = true Bu geçerli değilse: Destek paketini ekleyin. Kusur cihazda değil, imaj derlemesindedir.
denetim 2 başarısız olduğunda	`enforcement-on-without-anchor` (kritik)	Zorunluluk geçerli bir lisans ister ve cihaz hiçbirini doğrulayamaz; bu nedenle ne yüklenirse yüklensin her lisanslı rota 402 yanıtı verir. Cihaz, yapısal olarak geçemeyeceği bir denetimi zorunlu kılmaktadır. Düzeltme: Güven çıpasını yukarıdaki gibi geri yükleyin ve bu kurulum kimliği için verilmiş lisansı yükleyin. Bkz. Lisans yüklemesi 400 imza hatasıyla başarısız oluyor. Zorunluluğu kapatmak yalnızca bir laboratuvar önlemidir — katmanın dayandığı hak denetimlerini devre dışı bırakır. Doğrulama: GET /admin/license/status → {"state":"active\|trial"}

Sihirbaz tamamlandıktan sonra her istek 402 döndürüyor

Lisans zorunluluğu açıktır ve hiçbir lisans geçerli olarak çözümlenmez. Sorunu bir kurtarma yordamı olmadan çözebilmeniz için yönetim arayüzü erişilebilir kalır.

Çalışma kitabılicensing

Sihirbaz tamamlandıktan sonra her istek 402 LICENSE_EXPIRED döndürüyor

Şunları görebilirsiniz: 402 LICENSE_EXPIRED (lisans geçerli olarak çözümlenmiyor) · kurulum bittikten sonra sohbet 402 döndürüyor · pano yükleniyor ama her eylem "ödeme gerekli" hatasıyla başarısız oluyor · kurulumdan hemen sonra ürün engelleniyor

Başlamadan önce

Kurulum sihirbazı başarıyla tamamlandı mı?tanılama · appliance.setupComplete = trueDeğilse, bunun yerine setup-connectivity-500 çalışma kitabını uygulayın.
Pano ve oturum açma çalışıyor, yalnızca ürün rotaları mı — sohbet, tespit, denetim, görüntü ve belge analizi — 402 döndürüyor?beklenen · İlk sayfa yükleniyor, ikincisi 402 döndürüyor. İkisi de başarısız oluyorsa bu bir lisanslama sorunu değildir.Değilse, önce /troubleshoot/health-matrix sayfasına gidin.

Denetimler

1
Bu dağıtımda lisans zorunluluğunun açık olup olmadığını okuyun
tanılama · appliance.license.requireLicense = true
2
Ağ geçidinin açılışta çözümlediği lisans durumunu okuyun
tanılama · appliance.license.state = "active|trial"
3
Lisans güven çıpasının var olduğunu doğrulayın; o olmadan hiçbir lisans hiçbir zaman etkin olarak çözümlenemez
tanılama · appliance.license.trustAnchorPresent = true
4
Kurulu lisansın ne kadar süresi kaldığını denetleyin
tanılama · appliance.license.expiresAt

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 3 başarısız olduğunda	`enforcement-on-without-anchor` (kritik)	CID_REQUIRE_LICENSE true ve lisans imzalama açık anahtarı yok. Koruma geçerli bir lisans ister, doğrulama ise güven çıpası olmadan başarılı olamaz; bu nedenle ne yüklenirse yüklensin her lisanslı rota 402 yanıtı verir. Cihaz, geçemeyeceği bir denetimi zorunlu kılmaktadır. Düzeltme: Güven çıpasını geri yükleyin ve lisansı Lisans yüklemesi 400 imza hatasıyla başarısız oluyor yolunu izleyerek yükleyin. Zorunluluğu kapatmak yalnızca laboratuvar için bilinçli ve geçici bir önlemdir — müşteri cihazında asla çözüm değildir, çünkü katmanın dayandığı hak denetimlerini devre dışı bırakır. Doğrulama: tanılama · appliance.license.trustAnchorPresent = true
denetim 2 başarısız olduğunda	`no-valid-license` (kritik)	Zorunluluk açık ve lisans, etkin ya da deneme dışında bir duruma çözümlendi: eksik, geçersiz ya da süresi dolmuş. Kurulum sihirbazı bir lisans kurmaz; bu nedenle zorunluluğu açık, yeni tamamlanmış bir cihaz, bir lisans yüklenene kadar tam olarak bu duruma gelir. Düzeltme: Bu cihaz için verilmiş lisansı Ayarlar → Lisans altında yükleyin. Henüz bir lisans verilmediyse, o sayfada gösterilen kurulum kimliğine karşı bir lisans isteyin. Bkz. Lisanslama ve etkinleştirme. Doğrulama: GET /admin/license/status → {"state":"active\|trial"}
denetim 4 başarısız olduğunda	`license-genuinely-expired` (kritik)	Bir lisans kurulu ve doğrulanıyor, ancak geçerlilik süresi sona ermiş. Zorunluluk bunun üzerine ürün rotalarını engellerken yönetimi erişilebilir bırakır; böylece cihaz bir kurtarma yordamı olmadan yeniden lisanslanabilir. Düzeltme: Yenilenmiş bir lisans yükleyin. Süre dolumu yanlış görünüyorsa önce ana makine saatini denetleyin — kayan bir saat geçerli bir lisansı erkenden eskitir ve tam olarak bu durumu üretir. Doğrulama: tanılama · appliance.license.state = "active\|trial"
denetim 1 başarısız olduğunda	`unexpected-402-without-enforcement` (uyarı)	Zorunluluk kapalı, dolayısıyla lisans korumasının hiçbir şeyi engellememesi gerekir. Bu durumdaki bir 402, ağ geçidinin açılışta okuduğu değerin şu anda yapılandırılmış değerden farklı olduğu anlamına gelir — genellikle kapsayıcı, ayar değişmeden önce başlatılmış ve yeniden başlatılmamıştır. Düzeltme: Ağ geçidi kapsayıcısını yeniden başlatın, böylece yapılandırmasını yeniden okur; ardından yeniden deneyin. Zorunluluk kapalıyken 402 sürüyorsa destek paketini toplayın: etkin yapılandırma ile yapılandırılmış olan uyuşmuyordur. Doğrulama: tanılama · appliance.license.requireLicense = false Bu geçerli değilse: Etkin duruş bölümü dahil olmak üzere destek paketini ekleyin.

Lisansın süresi dolmuş ve ürün kilitli

Çalışan ve şimdi ürün yollarını engelleyen bir cihaz. Yenileme istemeden önce saati denetleyin.

Çalışma kitabılicensing

Lisansın süresi dolmuş ve lisanslı uç noktalar 402 döndürüyor

Şunları görebilirsiniz: License expired / product locked (lisansın süresi dolmuş, ürün kilitli) · 402 LICENSE_EXPIRED (lisansın süresi dolduğu için istek reddedildi) · License state is "expired" (lisans durumu "expired") · deneme süresi doldu

Başlamadan önce

Hâlâ oturum açıp panoyu açabiliyor, yalnızca ürün yolları mı başarısız oluyor?beklenen · İlki yükleniyor, ikincisi 402 döndürüyor. Ürün kilitliyken lisans yolunun erişilebilir kalması tasarım gereğidir.Değilse, önce /troubleshoot/health-matrix sayfasına gidin.

Denetimler

1
Ağ geçidinin çözümlediği lisans durumunu okuyun
tanılama · appliance.license.state = "active|trial"
2
Ana makine saatinin disiplinli olduğunu doğrulayın; kayan bir saat geçerli bir lisansı erkenden eskitir
tanılama · host.timeSynced = true
3
Güven çıpasının var olduğunu doğrulayın; o olmadan hiçbir yenileme de doğrulanamaz
tanılama · appliance.license.trustAnchorPresent = true
4
API'nin bildirdiği lisans durumunu okuyun
GET /admin/license/status → {"state":"active|trial"}

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 veya 4 başarısız olduğunda	`expired-or-invalid` (kritik)	Kurulu bir lisans var ve geçerlilik süresi bitmiş ya da lisans artık doğrulanmıyor. Bunun üzerine koruma, lisanslı yolları — sohbet, tespit, denetim, görüntü ve belge analizi — 402 ile engellerken yönetimi erişilebilir bırakır; böylece cihaz bir kurtarma yordamına gerek kalmadan yeniden lisanslanabilir. Düzeltme: Ayarlar → Lisans altından yenilenmiş bir lisans yükleyin. Yenilemeyi o sayfada gösterilen kurulum kimliğine göre isteyin: başka bir kimlik için verilmiş bir lisans burada doğrulanmaz. Bkz. Lisanslama ve etkinleştirme. Doğrulama: tanılama · appliance.license.state = "active\|trial"
denetim 2 başarısız olduğunda	`clock-skew-fake-expiry` (uyarı)	Lisans geçerliliği, ana makine saatinden okunan tarihlerle sınırlanır. Ek süre penceresinden fazla sapmış bir saat, geçerli bir lisansı süresi dolmuş gösterir ve ürün tam olarak gerçek bir süre dolumundaki gibi engeller. Düzeltme: Ana makine saatini düzeltip zaman eşitlemesini etkinleştirin, ardından ağ geçidi kapsayıcısını yeniden başlatın ve yenileme istemeden önce lisans durumunu yeniden okuyun. Bkz. Ana makine saati senkron değil. Doğrulama: tanılama · host.timeSynced = true
denetim 3 başarısız olduğunda	`renewal-cannot-verify` (kritik)	Güven çıpası yok; dolayısıyla yüklemek üzere olduğunuz yenileme de, mevcut lisansın artık doğrulanmamasıyla aynı nedenle reddedilecek. Önce yüklemek bakım penceresini boşa harcar. Düzeltme: Herhangi bir şey yüklemeden önce güven çıpasını geri getirin. Bkz. Cihazda lisans güven çıpası yok. Doğrulama: tanılama · appliance.license.trustAnchorPresent = true

TLS ve sertifikalar

Sertifikanın süresi dolmuş ya da 443'ü sunan yok

Şemsiye çalışma kitabı: reddedilen bir bağlantı ile süresi dolmuş bir sertifika kullanıcıya farklı görünür ama beklediğinizden daha sık aynı nedeni paylaşır.

Çalışma kitabıtls

Sertifikanın süresi dolmuş ya da 443'ü sunan yok

Şunları görebilirsiniz: ERR_CERT_DATE_INVALID (sertifikanın tarihleri geçerli değil) · NET::ERR_CERT_AUTHORITY_INVALID (sertifikayı veren otoriteye güvenilmiyor) · connection refused on 443 (443'te bağlantı reddedildi) · panoya HTTPS üzerinden erişilemiyor

Başlamadan önce

Cihaza, IP adresiyle değil, sertifikanın verildiği adla mı erişiyorsunuz?beklenen · Yazdığınız ad sertifikada geçiyor.Değilse, önce /install/naming-dns-tls sayfasına gidin.
Cihaz ağda yanıt veriyor mu — bir ping'e ya da başka bir porttaki HTTP isteğine karşılık veriyor mu?beklenen · İkisinden en az biri bağlanıyor. Hiçbiri bağlanmıyorsa bu bir TLS sorunu değil, ağ ya da elektrik sorunudur.Değilse, önce /install/network-prerequisites sayfasına gidin.

Denetimler

1
Cihaz ana makinesinde 443 portunu gerçekten tutan bir şey olduğunu doğrulayın
tanılama · appliance.tls.servedBy
2
Cihazın sunabileceği bir sertifikası olduğunu doğrulayın
tanılama · appliance.tls.mode = "none"
3
Sunulan sertifikanın kaç günü kaldığını okuyun
tanılama · appliance.tls.daysLeft = 0
4
Sertifikanın yenileme penceresinde olup olmadığını denetleyin — 30 gün; bu, `appliance/tls/ensure-tls.sh` betiğinin cihazın kendi verdiği yaprak sertifikayı yenilediği ve müşteri sertifikası için uyardığı `CID_TLS_RENEW_DAYS` varsayılanıdır
tanılama · appliance.tls.daysLeft = 30
5
Cihaz kök CA'sının var olduğunu doğrulayın; istemcilerin, cihazın verdiği bir sertifikaya güvenmesi ancak böyle sağlanabilir
tanılama · appliance.tls.caPresent = true

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`nothing-on-443` (kritik)	443'ü hiçbir süreç tutmuyor, dolayısıyla istemcinin bağlantısı daha TLS el sıkışması başlamadan reddedilir. Tarayıcı sertifika hatası değil bağlantı hatası bildirir; bu yüzden sorun ilk bakışta TLS sorununa benzemez. Bunun ardında genellikle başarısız bir sertifika dağıtımı vardır: ön yüz, kullanamadığı bir sertifikayla bozuk hizmet vermektense hiç başlamamayı seçer. Düzeltme: Ayarlar → Sistem Güncellemeleri sayfasından ana makine onarımını çalıştırın; onarım HTTPS ön yüzünü yeniden kurar ve cihazın sertifika isteğini yeniden uygular. Ardından panoyu yeniden yükleyin. Onarım bir sertifika sorunu bildiriyorsa önce onu çözün — sunması söylenen sertifika geçerli olana kadar ön yüz başlamayı reddetmeyi sürdürür. Doğrulama: tanılama · appliance.tls.servedBy Bu geçerli değilse: Ana makinenin HTTPS envanterini taşıyan destek paketini ekleyin.
denetim 2 başarısız olduğunda	`no-certificate` (kritik)	Cihazda hiç sertifika yapılandırılmamış — ne kendi CA'sının verdiği ne de yüklenmiş bir sertifika var. Bu giderilene kadar 443'te hiçbir şey sunulamaz. Düzeltme: Ayarlar → Sertifikalar altında cihaz CA'sından bir sertifika verin ya da orada üretilmiş bir CSR'ye karşı kurumunuzun CA'sının imzaladığı bir sertifikayı yükleyin. Bkz. Adlandırma, DNS ve TLS. Doğrulama: tanılama · appliance.tls.mode = "none"
denetim 3 başarısız olduğunda	`certificate-expired` (kritik)	Sunulan sertifikanın süresi dolmuş. Tarayıcılar bağlantıyı doğrudan reddeder; cihaza güvenecek biçimde yapılandırılmış istemciler — satır içi vekilin kendi çağıranları, tarayıcı eklentisi, uç nokta ajanı — zayıflayarak değil kapalı kalarak başarısız olur. Düzeltme: Hemen yerine yenisini verin. Cihaz CA'sının verdiği bir sertifika Ayarlar → Sertifikalar sayfasından yerinde yeniden verilir; dışarıdan imzalanmış bir sertifika için yeni bir CSR, imza ve yükleme gerekir. Sertifikayı suçlamadan önce ana makine saatini denetleyin: kayan bir saat geçerli bir sertifikayı süresi dolmuş gösterir. Doğrulama: tanılama · appliance.tls.daysLeft = 0
denetim 4 başarısız olduğunda	`certificate-expiring-soon` (uyarı)	Sertifika hâlâ geçerli ama yenileme penceresinin içinde. Şimdi yenilemek, aksi hâlde uyarısız gelecek bir kesintiyi önler ve dış bir CA'nın bir CSR'yi imzalayıp döndürmesi için zaman bırakır. Düzeltme: Sertifikayı süresi dolmadan yenileyin; Adlandırma, DNS ve TLS sayfasını izleyin. Sertifika dışarıdan imzalanıyorsa hemen başlayın — uzun süren adım cihaz değil, imza sürecidir. Doğrulama: tanılama · appliance.tls.daysLeft = 30
denetim 5 başarısız olduğunda	`ca-missing` (uyarı)	Cihaz kök CA'sı yok; dolayısıyla istemciler cihazın verdiği bir sertifikaya güvenecek duruma getirilemez ve herkese açık kök CA indirmesinin sunacağı bir şey kalmaz. Sertifikanın kendisi güncel olsa bile her istemci güvenilmeyen otorite hatası bildirir. Düzeltme: Ayarlar → Sertifikalar altında cihaz CA'sını yeniden oluşturun, kök sertifikayı cihazın herkese açık indirme yolundan yeniden dağıtın ve sunucu sertifikasını yeniden verin. Yeniden vermenin, istemcilerin daha önce kurduğu güveni geçersiz kıldığını unutmayın; dağıtımı yeniden vermeden önce planlayın. Doğrulama: tanılama · appliance.tls.caPresent = true

443'te hiçbir şey dinlemiyor

Bağlantılar el sıkışma olmadan reddedilir; bu nedenle tarayıcı sertifika hatası değil ağ hatası bildirir.

Çalışma kitabıtls

443'te hiçbir şey dinlemiyor

Şunları görebilirsiniz: Nothing is listening on 443 (443'te hiçbir şey dinlemiyor) · connection refused on 443 (443'te bağlantı reddedildi) · https://<ip>/ bağlantıyı reddediyor · panoya HTTPS üzerinden erişilemiyor

Başlamadan önce

Cihaz ağda hiç yanıt veriyor mu?beklenen · En az biri bağlanıyor. Hiçbiri bağlanmıyorsa bu bir TLS sorunu değil, ağ ya da elektrik sorunudur.Değilse, önce /install/network-prerequisites sayfasına gidin.

Denetimler

1
Cihaz ana makinesinde 443 portunu neyin tuttuğunu okuyun
tanılama · appliance.tls.servedBy
2
Cihazın sunabileceği bir sertifikası olup olmadığını doğrulayın
tanılama · appliance.tls.mode = "none"
3
Dinleyicinin vekil olarak yönlendirdiği pano kapsayıcısının çalıştığını doğrulayın
tanılama · containers[frontend].state = "running"

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`listener-absent` (kritik)	443'ü hiçbir süreç tutmuyor; dolayısıyla istemcinin bağlantısı daha el sıkışma başlamadan reddedilir ve tarayıcı sertifika hatası değil bağlantı hatası bildirir. Yeni kurulmuş bir cihazda olağan neden HTTPS ön yüzünün hiç kurulmamış olmasıdır; çalışan bir cihazda ise ardında başarısız bir sertifika dağıtımı vardır, çünkü ön yüz kullanamadığı bir sertifikayla bozuk hizmet vermektense hiç başlamamayı seçer. Düzeltme: Yeni bir kurulumda HTTPS kurucusunu ana makinede `sudo bash /opt/cid-install/install-https.sh` ile yeniden çalıştırın. Çalışan bir cihazda Ayarlar → Sistem Güncellemeleri sayfasından ana makine onarımını çalıştırın; onarım ön yüzü yeniden kurar ve sertifika isteğini yeniden uygular. Onarım bir sertifika sorunu bildiriyorsa önce onu giderin — sunması söylenen sertifika geçerli olana kadar ön yüz başlamayı reddetmeyi sürdürür. Doğrulama: tanılama · appliance.tls.servedBy Bu geçerli değilse: Ana makinenin HTTPS envanterini taşıyan destek paketini ekleyin.
denetim 2 başarısız olduğunda	`no-certificate-to-serve` (kritik)	Cihazda hiç sertifika yapılandırılmamış — ne kendi CA'sının verdiği ne de yüklenmiş bir sertifika var — dolayısıyla bir dinleyicinin sunacağı hiçbir şey yoktur ve 443'te hiçbir şey sunulamaz. Düzeltme: Ayarlar → Sertifikalar altında cihaz CA'sından bir sertifika verin ya da orada üretilmiş bir imzalama isteğine karşı kurumunuzun CA'sının imzaladığı bir sertifikayı yükleyin. Bkz. Adlandırma, DNS ve TLS. Doğrulama: tanılama · appliance.tls.mode = "none"
denetim 3 başarısız olduğunda	`frontend-down` (kritik)	Dinleyici TLS'i sonlandırır ve pano kapsayıcısına vekil olarak yönlendirir. O kapsayıcı çalışmadığında 443, hangi yarının önce başarısız olduğuna göre ya bağlantıları reddeder ya da bir yukarı akış hatasıyla yanıt verir. Düzeltme: Pano kapsayıcısını başlatın ve yeniden çıkarsa günlüğünü okuyun. Bkz. Bir kapsayıcı sürekli yeniden başlıyor. Doğrulama: tanılama · containers[frontend].state = "running"

Sertifikanın süresi doluyor ya da dolmuş

Bu cihaza güvenecek biçimde yapılandırılmış istemciler zayıflayarak değil kapalı kalarak başarısız olur; dolayısıyla zorunluluk, panonun erişilemez hâle geldiği anda durur.

Çalışma kitabıtls

Cihazın HTTPS sertifikasının süresi doluyor ya da dolmuş

Şunları görebilirsiniz: The appliance HTTPS certificate expires in 6 day(s) (cihazın HTTPS sertifikasının bitmesine 6 gün kaldı) · ERR_CERT_DATE_INVALID (tarayıcı sertifikanın tarihini geçersiz buluyor) · certificate expired (sertifikanın süresi dolmuş) · your connection is not private (bağlantınız gizli değil)

Başlamadan önce

Ana makinenin saati doğru mu? Kayan bir saat, geçerli bir sertifikayı süresi dolmuş gösterir.tanılama · host.timeSynced = trueDeğilse, bunun yerine time-not-synced çalışma kitabını uygulayın.

Denetimler

1
Sunulan sertifikanın kaç günü kaldığını okuyun
tanılama · appliance.tls.daysLeft = 0
2
Sertifikanın yenileme penceresine girip girmediğini denetleyin — 30 gün, yani `appliance/tls/ensure-tls.sh` içindeki `CID_TLS_RENEW_DAYS` varsayılanı
tanılama · appliance.tls.daysLeft = 30
3
Cihazın hangi tür sertifika sunduğunu okuyun; çünkü yenileme yolu buna göre değişir
tanılama · appliance.tls.mode = "unknown"

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`already-expired` (kritik)	Sunulan sertifikanın süresi dolmuştur. Tarayıcılar bağlantıyı reddeder ve bu cihaza güvenecek biçimde yapılandırılmış istemciler — tarayıcı eklentisi, uç nokta ajanı, satır içi vekilin çağıranları — zayıflayarak değil kapalı kalarak başarısız olur; dolayısıyla zorunluluk, panonun erişilemez hâle geldiği anda durur. Düzeltme: Hemen yerine yenisini düzenleyin. Cihazın kendi CA'sının düzenlediği bir sertifika Ayarlar → Sertifikalar üzerinden yerinde yeniden düzenlenir; dışarıdan imzalı bir sertifika ise yeni bir imzalama isteği, bir imza ve bir yükleme gerektirir. Bkz. Adlandırma, DNS ve TLS. Doğrulama: tanılama · appliance.tls.daysLeft = 0
denetim 2 başarısız olduğunda	`inside-renewal-window` (uyarı)	Sertifika hâlâ geçerlidir ve yenilemenin başlaması gereken pencerenin içindedir. Dışarıdan imzalı bir sertifika, cihaz tarafındaki işin yanı sıra imzalama gidiş-dönüşünü de gerektirir ve işi uzatan şey cihaz değil, o gidiş-dönüştür. Düzeltme: Bitişte değil şimdi yenileyin. İmzalama isteğini Ayarlar → Sertifikalar üzerinden oluşturun, imzalatın ve sonucu yükleyin. Cihaz CA'sından gelen bir sertifika, dışarıya hiçbir bağımlılık olmadan yerinde yeniden düzenlenir. Doğrulama: tanılama · appliance.tls.daysLeft = 30
denetim 3 başarısız olduğunda	`mode-unknown` (uyarı)	Cihaz hangi sertifikayı sunduğunu söyleyemez; dolayısıyla iki yenileme yolundan hiçbiri önerilemez ve okunan bitiş tarihi artık 443'te olmayan bir sertifikaya ait olabilir. Ana makinenin TLS envanteri eksik olduğunda anlık görüntünün bildirdiği durum budur. Düzeltme: TLS envanteri yeniden yazılsın diye ana makine onarımını Ayarlar → Sistem Güncellemeleri üzerinden çalıştırın, ardından bir şeyi yenilemeden önce anlık görüntüyü yeniden okuyun. Doğrulama: tanılama · appliance.tls.mode = "unknown"

Sağlayıcılar

Katalogda hiç sağlayıcı yok

Sohbet bir model çözümleyemez, dolayısıyla her tamamlama başarısız olur. Katalog koddan değil, veriden ibarettir.

Çalışma kitabıproviders

Katalogda hiç LLM sağlayıcısı yok, bu yüzden her tamamlama başarısız oluyor

Şunları görebilirsiniz: No LLM providers are in the catalogue (katalogda hiç LLM sağlayıcısı yok) · sohbet bir modeli çözümleyemiyor · model açılır listesi boş · her tamamlama bir model hatasıyla başarısız oluyor

Başlamadan önce

Kurulum sihirbazı tamamlandı mı? Tamamlanmadan önce bakılacak yer, sihirbazın kendi sağlayıcı adımıdır.tanılama · appliance.setupComplete = trueDeğilse, bunun yerine setup-providers-step-empty çalışma kitabını uygulayın.

Denetimler

1
Katalog koda gömülü değil veritabanından okunduğu için, ağ geçidinin veritabanına erişebildiğini doğrulayın
tanılama · datastores.postgres.reachable = true
2
Sağlayıcı ve model tablolarının güncel biçiminde olması için bekleyen geçiş bulunmadığını doğrulayın
tanılama · datastores.postgres.migrationsPending
3
Ağ geçidinden model kataloğunu isteyin
GET /models

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 3 başarısız olduğunda	`catalogue-never-seeded` (kritik)	Sağlayıcı ve model satırları koddan değil veritabanı tohumlayıcısından gelir. Tohumlama tümüyle kapalıyken hazırlanmış bir kutunun kataloğu boştur ve sohbet hiçbir istek için model çözümleyemez. Bozuk bir şey yoktur: satırlar hiç eklenmemiştir. Düzeltme: Örnek hesaplar kapalı durumdayken tohumlayıcıyı bu veritabanına karşı bir kez çalıştırın; böylece katalog, gösterim kullanıcıları oluşturulmadan yerine oturur. Ardından sayfayı yeniden yükleyin. Tohum yalnızca sağlayıcıları ve modelleri ekler; kimlik bilgilerini eklemek size kalır. Doğrulama: GET /models
denetim 1 başarısız olduğunda	`database-unreachable` (kritik)	Ağ geçidi veritabanına erişemiyor; dolayısıyla her liste görünür bir hata vermek yerine boş döner. Model kataloğu, boşluğu ürünü çalışmaz kılan liste olmasıyla ayrılır. Düzeltme: Ağ geçidinden PostgreSQL ya da Redis'e erişilemiyor yolunu izleyin, ardından kataloğu yeniden denetleyin. Doğrulama: tanılama · datastores.postgres.reachable = true
denetim 2 başarısız olduğunda	`schema-behind` (kritik)	Bekleyen geçişler, sağlayıcı ya da model tablolarında geçerli kodun seçtiği sütunların bulunmadığı anlamına gelir; sorgu bu yüzden başarısız olur ya da hiçbir şey döndürür ve katalog boş okunur. Düzeltme: Bekleyen geçişleri uygulayın ve ağ geçidini yeniden başlatın. Bkz. Bekleyen geçişler var. Doğrulama: tanılama · datastores.postgres.migrationsPending

Güncellemeler

Sistem Güncellemeleri sayfası 0.0.0 gösteriyor ya da düğmeler 500 döndürüyor

Eksik bir sürüm damgası, ayarlanmamış bir kanal, erişilemeyen bir kanal ve takılmış bir güncelleyici aynı sayfada ortaya çıkar ve birbirine benzer.

Çalışma kitabıupdates

Sistem Güncellemeleri sayfası 0.0.0 gösteriyor ya da güncelleme düğmeleri 500 döndürüyor

Şunları görebilirsiniz: **Sistem Güncellemeleri** sayfası sürümü 0.0.0 olarak gösteriyor · current version 0.0.0 (kurulu sürüm 0.0.0 görünüyor) · güncelleme denetimi 500 döndürüyor · install update → 500 (güncellemeyi kurma eylemi 500 döndürüyor)

Başlamadan önce

Kurulum sihirbazı tamamlandı mı? Tamamlanmadan güncelleme sayfası anlamlı değildir.tanılama · appliance.setupComplete = trueDeğilse, önce /install/setup-wizard sayfasına gidin.

Denetimler

1
Cihazın bildirdiği ürün sürümünü okuyun
tanılama · appliance.version = "0.0.0"
2
Bir güncelleme kanalının yapılandırıldığını doğrulayın
tanılama · appliance.channel
3
Sürüm kanalının son denemede yanıt verdiğini doğrulayın
tanılama · appliance.update.channelReachable = true
4
Bir güncelleme ya da ana makine onarımı isteğinin ana makine güncelleyicisini beklerken takılı kalıp kalmadığını denetleyin
tanılama · appliance.update.pendingIntent
5
Sayfanın sürümün yanında gösterdiği ana makine onarım durumunu okuyun
GET /admin/system-update/host-repair

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`version-file-missing` (uyarı)	Cihaz, kurulu sürümünü imaj derlemesinin yazdığı bir dosyadan okur. Bu dosya yoksa ya da okunamıyorsa sürüm 0.0.0'a geri düşer ve kanal manifestiyle yapılan her karşılaştırma bir sürüm düşürme gibi görünür — sayfanın aynı anda hem 0.0.0 göstermesi hem de güncelleme sunmayı reddetmesi bu yüzdendir. Düzeltme: Ayarlar → Sistem Güncellemeleri üzerinden ana makine onarımını çalıştırın; bu, cihazın sürüm dosyasını yeniden yazar. Ardından sayfayı yenileyin. Ana makine onarımı kullanılamıyorsa sürüm, kurulum programının sonlandırma adımı yeniden çalıştırılarak da geri getirilebilir; bkz. Güncellemeler. Doğrulama: tanılama · appliance.version = "0.0.0" Bu geçerli değilse: Destek paketini ekleyin. Ana makine onarımından sonra da süren bir 0.0.0, imajın sürüm damgası olmadan derlendiği anlamına gelir.
denetim 2 başarısız olduğunda	`manifest-url-unset` (uyarı)	Yapılandırılmış bir sürüm kanalı yoktur, dolayısıyla güncelleme denetiminin getireceği bir manifest de yoktur. API çağrıyı, eksik manifest URL'sinin adını veren bir 400 ile reddeder; sayfa bunu bir yapılandırma uyarısı olarak değil, başarısız bir düğme olarak gösterir. Düzeltme: Güncelleme kanalını Ayarlar → Sistem Güncellemeleri altında ayarlayın. Ağdan yalıtılmış bir cihazda bir URL göstermek yerine çevrimdışı kanalı seçin ve güncelleme paketini yükleyin. Doğrulama: tanılama · appliance.channel
denetim 3 başarısız olduğunda	`channel-unreachable` (uyarı)	Kanal yapılandırılmıştır ama manifest getirilemedi — ad çözümleme yok, dışarı çıkış yok ya da zorunlu olduğu hâlde yapılandırılmamış bir dış vekil var. Getirme hatası, güncelleme uç noktasından 500 olarak görünür. Düzeltme: Kanal ana makinesine dışarıya erişimi düzeltin, ya da cihazı çevrimdışı güncellemeye geçirin. Tanılama anlık görüntüsündeki DNS ve dışarı çıkış yoklamalarını ayrı ayrı okuyun: çözümlemenin başarılı olması HTTPS getirmesinin de başarılı olduğu anlamına gelmez ve yalnızca vekil üzerinden çıkan bir ağ, vekilin açıkça yapılandırılmasını ister. Doğrulama: tanılama · appliance.update.channelReachable = true
denetim 4 başarısız olduğunda	`updater-daemon-not-running` (kritik)	Kuyruğa bir istek alınmış ama onu çalıştıran hiçbir şey yok. Ağ geçidi yalnızca isteği kaydeder; işi ana makinedeki ayrıcalıklı güncelleyici arka plan süreci yapar. Bu süreç çalışmadığında istekler birikir ve sonraki her eylem takılmış ya da başarısız olmuş gibi görünür. Düzeltme: Cihazın ana makinesinde güncelleyici arka plan sürecini başlatın ve kuyruktaki isteğin kuyruk durumundan çıktığını doğrulayın. Çıkana kadar yeni istek eklemeyin; biriken kuyruk arızayı okumayı zorlaştırır. Doğrulama: tanılama · appliance.update.pendingIntent Bu geçerli değilse: Destek paketine ek olarak ana makinedeki güncelleyici arka plan sürecinin kendi günlüğünü ekleyin.
denetim 5 başarısız olduğunda	`host-agent-absent` (uyarı)	Ana makine onarımı uç noktası yanıt veremiyor, çünkü ana makine ajanı envanterini hiç yazmamış. Sayfanın o zaman sürümün yanında gösterecek ana makine tarafı verisi olmaz ve bu birleşim bozuk bir sayfa gibi okunur. Düzeltme: Cihazda ana makine ajanının envanter işini çalıştırın ve sayfayı yenileyin. Cihaz olmayan bir dağıtımda bu beklenen durumdur: orada hiç ana makine ajanı yoktur ve güncelleme sayfası desteklenen yükseltme yolu değildir. Doğrulama: GET /admin/system-update/host-repair

Cihaz hangi sürümü çalıştırdığını söyleyemiyor

Sürüm damgası geri gelene kadar kanal bildirimiyle yapılan her karşılaştırma anlamsızdır; her destek yanıtı da öyle.

Çalışma kitabıupdates

Cihaz hangi sürümü çalıştırdığını söyleyemiyor

Şunları görebilirsiniz: This box cannot say which release it is running (bu makine hangi sürümü çalıştırdığını söyleyemiyor) · Sistem Güncellemeleri sayfası 0.0.0 sürümünü gösteriyor · 0.1.0 olmayan bir makinede geçerli sürüm 0.1.0 görünüyor · güncelleme sayfası hiçbir şey sunmuyor ve sürüm göstermiyor

Başlamadan önce

Kurulum sihirbazı tamamlandı mı?tanılama · appliance.setupComplete = trueDeğilse, önce /install/setup-wizard sayfasına gidin.

Denetimler

1
Cihazın bildirdiği ürün sürümünü okuyun
tanılama · appliance.version = "0.1.0"
2
Sürüm damgasını yeniden yazan şey olan ana makine onarımı durumunu okuyun
GET /admin/system-update/host-repair

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`no-version-stamp` (uyarı)	Cihaz kurulu sürümünü, imaj derlemesinin ve güncelleyicinin yazdığı dosyalardan okur. Bunların hiçbiri okunamadığında sürüm bir yer tutucuya geri düşer ve kanal manifestiyle yapılan her karşılaştırma anlamsızlaşır — sayfanın hem açıkça yanlış bir sürüm gösterip hem de güncelleme sunmayı reddedebilmesinin nedeni budur. Bu düzeltilene kadar destek yanıtları tahminden ibarettir. Düzeltme: Ayarlar → Sistem Güncellemeleri sayfasından, cihaz sürüm dosyasını yeniden yazan ana makine onarımını çalıştırın, ardından sayfayı yeniden yükleyin. Ana makine onarımından sonra da duran bir yer tutucu, imajın sürüm damgası olmadan derlendiği anlamına gelir. Doğrulama: tanılama · appliance.version = "0.1.0" Bu geçerli değilse: Destek paketini ve kurulum programının açılış menüsü girdisinde adı geçen sürümü ekleyin.
denetim 2 başarısız olduğunda	`host-agent-absent` (uyarı)	Ana makine ajanı envanterini hiç yazmadığı için ana makine onarımı uç noktası yanıt veremez; dolayısıyla güncelleme sayfasının çizecek ana makine tarafı verisi yoktur ve sürüm dosyasını yeniden yazabilecek hiçbir şey kalmaz. Cihaz olmayan bir dağıtımda zaten ana makine ajanı yoktur ve bu sayfa desteklenen yükseltme yolu değildir. Düzeltme: Ana makine ajanının işini cihazda çalıştırın ve sayfayı yeniden yükleyin. Bu bir cihaz değil compose dağıtımıysa, bunun yerine sürüm imajlarını çekerek güncelleyin. Doğrulama: GET /admin/system-update/host-repair

Güncelleme kanalına erişilemiyor

İmzalı çevrimdışı bir paketten güncellenen, bilinçli olarak ağdan yalıtılmış bir cihazda beklenen bir durumdur. Bağlantılı bir cihazda ise güncelleme kılığına girmiş bir dışarı çıkış sorunudur.

Çalışma kitabıupdates

Güncelleme kanalına cihazdan erişilemiyor

Şunları görebilirsiniz: The update channel host is not reachable from inside the gateway (güncelleme kanalı sunucusuna ağ geçidinin içinden erişilemiyor) · **Check for updates** (güncellemeleri denetle) hiçbir şey yapmıyor · güncelleme denetimi 500 döndürüyor · cihaz hiçbir zaman yeni bir sürüm bulmuyor

Başlamadan önce

Bu cihazın güncellemeleri çevrimdışı bir paketten değil, çevrimiçi alması mı amaçlanıyor?tanılama · appliance.channel = "offline"Değilse, önce /install/updates sayfasına gidin.
Kurulum sihirbazı tamamlandı mı? Tamamlanmadan önce güncelleme sayfası anlamlı değildir.tanılama · appliance.setupComplete = trueDeğilse, önce /install/setup-wizard sayfasına gidin.

Denetimler

1
Herhangi bir güncelleme kanalının yapılandırılmış olduğunu doğrulayın
tanılama · appliance.channel
2
Kanalın son denemede yanıt verip vermediğini okuyun
tanılama · appliance.update.channelReachable = true
3
Cihazın erişmesi gereken sunucular için ad çözümleme sonuçlarını okuyun
tanılama · appliance.dns
4
Vekil zorunlu olan bir ağda, giden bir vekilin yapılandırılmış olup olmadığını okuyun
tanılama · appliance.proxy.configured = true

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`channel-unset` (uyarı)	Yapılandırılmış bir sürüm kanalı yoktur; dolayısıyla güncelleme denetiminin alacağı bir manifest de yoktur. API çağrıyı reddeder ve sayfa, bir şey yapılandırmanızı isteyen bir uyarı yerine başarısız olan bir düğme gösterir. Düzeltme: Güncelleme kanalını Ayarlar → Sistem Güncellemeleri altında ayarlayın. Ağdan yalıtılmış bir cihazda bir URL göstermek yerine çevrimdışı kanalı seçin ve imzalı bir paket yükleyin. Doğrulama: tanılama · appliance.channel
denetim 2 başarısız olduğunda	`channel-blocked` (uyarı)	Kanal yapılandırılmıştır ve alma işlemi başarısız olmuştur. Bilinçli olarak ağdan yalıtılmış bir cihazda bu beklenen durumdur ve hiçbir işlem gerektirmez; bağlantılı bir cihazda ise kanal sunucusuna giden HTTPS yolunun engellendiği, denetlendiği ya da cihazda olmayan bir vekili gerektirdiği anlamına gelir. Düzeltme: Tanılama anlık görüntüsündeki dışarı çıkış sonuçlarını okuyun ve başarısız olduğunu varsaydığınız testi değil, gerçekten başarısız olan testi düzeltin. Bkz. Cihaz dışarı çıkamıyor. Cihazın çevrimdışı kalması amaçlanıyorsa, bu hata bir arıza olarak bildirilmeyi bıraksın diye onu çevrimdışı kanala geçirin. Doğrulama: tanılama · appliance.update.channelReachable = true
denetim 3 başarısız olduğunda	`dns-cannot-resolve-channel` (uyarı)	Cihaz kanal sunucusunun adını çözemez; dolayısıyla alma işlemi ağa hiç ulaşmaz. Ad çözümlemenin başka yerde çalışması hiçbir şeyi kanıtlamaz: cihaz tarayıcının değil, bu ağın çözümleyicisini kullanır. Düzeltme: Kanal sunucusu için yanıt veren bir çözümleyici ayarlayın ve denetimi yeniden çalıştırın. Bkz. Ağ ön koşulları. Doğrulama: tanılama · appliance.dns
denetim 4 başarısız olduğunda	`proxy-missing` (uyarı)	Bu sahada her şey bir vekilden geçer ve cihazda yapılandırılmış vekil yoktur; bu nedenle alma işlemi doğrudan denenir ve zaman aşımına uğrar. Zaman aşımı da eksik bir ayar gibi değil, ölü bir kanal gibi görünür. Düzeltme: Cihazda giden vekili yapılandırın ve ayarı yeniden okuması için ağ geçidi kapsayıcısını yeniden başlatın. Doğrulama: tanılama · appliance.proxy.configured = true

Veritabanı ve şema

Bekleyen geçişler var

Yeni sütunları okuyan uç noktalar 500 döndürürken ürünün geri kalanı sağlıklı görünür.

Çalışma kitabıdata

Bekleyen geçişler var ve yeni sütunları okuyan sayfalar hata veriyor

Şunları görebilirsiniz: compiled migration(s) have never been applied to this database (derlenmiş geçişler bu veritabanına hiç uygulanmamış) · ürünün geri kalanı çalışırken tek bir sayfa 500 döndürüyor · column does not exist (sütun yok) · relation does not exist (tablo ya da görünüm yok)

Başlamadan önce

Ağ geçidi veritabanına hiç erişebiliyor mu?tanılama · datastores.postgres.reachable = trueDeğilse, bunun yerine datastore-unreachable çalışma kitabını uygulayın.

Denetimler

1
Veritabanına kaydedilmemiş derlenmiş geçişlerin listesini okuyun
tanılama · datastores.postgres.migrationsPending
2
Otomatik eşitlemenin kapalı olduğunu doğrulayın; açıkken uygulanmamış bir zinciri doğru görünen bir şemanın arkasına gizler
tanılama · posture.dbSynchronize = false
3
Ağ geçidinin yeniden başlamadığını doğrulayın; başarısız olan bir açılış geçişinin olağan sonucu budur
tanılama · containers[nestjs-core].restarts = 3

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`boot-migration-failed` (kritik)	Otomatik eşitleme kapalıyken kapsayıcı giriş noktası, derlenmiş geçiş zincirini her açılışta uygular. Açılmış bir cihazda boş olmayan bir bekleyenler listesi bu nedenle zincirin hiç çalışmadığı değil, o çalışmanın başarısız olduğu anlamına gelir. Ürün ayakta kalır: yalnızca yeni sütunları seçen uçlar 500 döndürür — tek bir sayfanın bozulup geri kalanın sağlıklı görünmesinin nedeni budur. Düzeltme: Başarısız açılışa ait ağ geçidi günlüğünü okuyun ve geçişin uygulanamama nedenini giderin: başka bir bağlantının tuttuğu bir kilit, geçişin yok saydığı bir nesne ya da veritabanı rolündeki bir yetki. Ardından zincirin yeniden çalışması için ağ geçidini yeniden başlatın. Geçişleri uygulanmış göstermek için geçiş geçmişi tablosunu elle düzenlemeyin; sütunlar yine de eksik kalır. Doğrulama: tanılama · datastores.postgres.migrationsPending Bu geçerli değilse: Destek paketini ve başarısız açılışı kapsayan ağ geçidi günlüğünü ekleyin.
denetim 2 başarısız olduğunda	`synchronize-masking-the-chain` (kritik)	Otomatik eşitleme şemayı varlık bildirimlerinden kurar; dolayısıyla tablolar doğru görünürken geçiş geçmişi boş kalır. Sonra her açılış, varlıkların bildirmediği her şeyi düşürür ve bekleyenler listesi hiçbir zaman temizlenmez. Düzeltme: Otomatik eşitlemeyi kapatın ve zincirin uygulanmasına izin verin. Bkz. Veritabanı şeması her açılışta otomatik eşitleniyor. Doğrulama: tanılama · posture.dbSynchronize = false
denetim 3 başarısız olduğunda	`migration-crashloop` (kritik)	Açılış sırasında hata fırlatan bir geçiş ağ geçidini de beraberinde götürür; kapsayıcı yeniden başlar, aynı geçişi dener ve yine başarısız olur. Başka hiçbir şey değişmezken yeniden başlatma sayısı tırmanır. Düzeltme: Kapsayıcıyı durdurun, başarısız olan tek bir açılışın günlüğünü baştan sona okuyun ve yeniden başlatmadan önce hatanın kendisini giderin. Aynı arızanın içine yeniden başlatmak yeni bilgi üretmez. Doğrulama: tanılama · containers[nestjs-core].restarts = 3 Bu geçerli değilse: Destek paketini ve başarısız olan geçişin adını ekleyin.

PostgreSQL ya da Redis'e erişilemiyor

Erişilemeyen bir veritabanı hata vermek yerine her listeyi boşaltır; erişilemeyen bir Redis ise hız sınırlamayı açık kalacak biçimde zayıflatır ve zamanlanmış işleri durdurur.

Çalışma kitabıdata

Ağ geçidinden PostgreSQL ya da Redis'e erişilemiyor

Şunları görebilirsiniz: Postgres is unreachable (PostgreSQL'e erişilemiyor) · Redis is unreachable (Redis'e erişilemiyor) · ECONNREFUSED (veritabanı portunda bağlantı reddedildi) · panodaki her liste boş geliyor

Başlamadan önce

Ağ geçidinin kendisi yanıt veriyor mu — yani arıza, ağ geçidinin önünde değil onunla veri deposu arasında mı?tanılama · services[nestjs-core].reachable = trueDeğilse, bunun yerine first-boot-no-dashboard çalışma kitabını uygulayın.

Denetimler

1
Ağ geçidinin PostgreSQL'e erişip erişemediğini okuyun
tanılama · datastores.postgres.reachable = true
2
Veritabanı kapsayıcısının durumunu okuyun
tanılama · containers[postgres].state = "running"
3
Ağ geçidinin Redis'e erişip erişemediğini okuyun
tanılama · datastores.redis.reachable = true
4
Veritabanını taşıyan dosya sisteminde yer olduğunu denetleyin; PostgreSQL yer kalmadığında yazmayı kabul etmeyi bırakır
tanılama · host.disks[/].freeGb = 2

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`postgres-down` (kritik)	Ürünün kalıcılaştırdığı her şey PostgreSQL'dedir: kiracılar, kimlik bilgileri, filtreler, tespitler, oturumlar ve olay günlüğü. Erişilemediğinde ağ geçidi yanıt vermeyi sürdürür ve veritabanına dayanan her sayfa boş kalır ya da hata verir; dolayısıyla arıza, aynı anda birbiriyle ilgisiz pek çok hata gibi okunur. Düzeltme: Veritabanı kapsayıcısını başlatın, sağlık denetiminin geçmesini bekleyin ve sayfayı yeniden yükleyin. Kapsayıcı çalışıyor ama hâlâ erişilemiyorsa ağ geçidinin kullandığı ana makine, port, veritabanı adı ve kimlik bilgilerinin veritabanının gerçekte sunduklarıyla eşleştiğini doğrulayın — yeniden dağıtımdan sonraki olağan neden, ortam dosyasında değişmiş bir paroladır. Doğrulama: tanılama · datastores.postgres.reachable = true
denetim 2 başarısız olduğunda	`postgres-container-not-running` (kritik)	Kapsayıcı çalışır durumda değildir, dolayısıyla dinleyen hiçbir şey yoktur. Yeniden başlatmadan sonra çıkmış bir veritabanı kapsayıcısının nedeni genellikle bellek tükenmesiyle sonlandırma ya da bozulmuş bir veri dizinidir; hangisi olduğunu kapsayıcı günlüğü söyler. Düzeltme: Veritabanı kapsayıcısının günlüğünü okuyun, bildirdiği sorunu giderin ve kapsayıcıyı yeniden başlatın. Kapsayıcı başlasın diye veri birimini silmeyin; bu, cihazdaki her tespiti ve her denetim kaydını yok eder. Doğrulama: tanılama · containers[postgres].state = "running" Bu geçerli değilse: Destek paketini ve veritabanı kapsayıcısının günlüğünü ekleyin.
denetim 3 başarısız olduğunda	`redis-down` (uyarı)	Redis, hız sınırı sayaçlarını ve küme kilidini tutar. Kapalıyken hız sınırlama açık kalarak zayıflar, kilit ise kapalı kalarak başarısız olur; dolayısıyla istekler işlenmeyi sürdürürken zamanlanmış işler durur. Ürün bu nedenle tarayıcıdan sağlıklı görünür ve yapması gereken her şeyi yapmıyordur. Düzeltme: Redis kapsayıcısını başlatın ve ağ geçidinin yeniden bağlandığını doğrulayın. Bellek sınırını da denetleyin: bellek baskısı yüzünden tahliye edilen bir Redis geri gelir ve aynı yük altında yeniden kaybolur. Doğrulama: tanılama · datastores.redis.reachable = true
denetim 4 başarısız olduğunda	`disk-exhausted` (kritik)	PostgreSQL, dosya sistemi dolduğunda yazmayı reddeder ve ağ geçidi bunu bir disk sorunu olarak değil veri deposu arızası olarak bildirir. Aylardır sorunsuz çalışan bir cihazda diskin dolmasının olağan nedenleri saklama ayarları ile döndürülmemiş bir olay günlüğüdür. Düzeltme: Yer açın ve veritabanını yeniden başlatın, ardından saklananı azaltın. Bkz. Bir dosya sistemi neredeyse dolu. Doğrulama: tanılama · host.disks[/].freeGb = 2

Şema her açılışta otomatik eşitleniyor

Otomatik eşitleme, varlıkların bildirmediği her nesneyi — geçişlerin oluşturduğu dizinler dahil — düşürür. Hiçbir şey hata vermez; cihaz yalnızca her yeniden başlatmadan sonra yavaşlar.

Çalışma kitabıdata

Veritabanı şeması her açılışta otomatik eşitleniyor

Şunları görebilirsiniz: DB_SYNCHRONIZE=true (otomatik şema eşitlemesi açık) · yeniden başlatmadan sonra indeksler kayboluyor · her yeniden açılıştan sonra arama yine yavaşlıyor · şema, hiçbir geçiş olmadan değişiyor

Başlamadan önce

Bu, üzerinde varlık geliştirmesi yapılan bir geliştirici makinesi değil de üretim ya da müşteri cihazı mı?tanılama · appliance.deploymentMode = "development"Değilse, önce /develop/getting-started/introduction sayfasına gidin.

Denetimler

1
Etkin otomatik eşitleme ayarını okuyun
tanılama · posture.dbSynchronize = false
2
Geçiş zincirinin tümüyle uygulandığını doğrulayın; otomatik eşitleme, uygulanmamış bir zinciri gizler
tanılama · datastores.postgres.migrationsPending

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`synchronize-enabled` (kritik)	Otomatik eşitleme, şemayı her açılışta varlık tanımlarına uydurur; yani varlıkların tanımlamadığı her nesneyi düşürür — geçişlerin oluşturduğu indeksler dahil. Ürün çalışmaya devam eder ve her yeniden başlatmadan sonra yavaşlar; hiçbir şey hata vermediği için kayıp sessizdir. Şemanın sahibi her dağıtımda geçişlerdir; eşitlemeyi yalnızca geliştirici katmanı açar. Düzeltme: Cihazın ortam dosyasında `DB_SYNCHRONIZE` değerini `false` yapın ve ağ geçidi kapsayıcısını yeniden başlatın. Bunun üzerine giriş noktası, derlenmiş geçiş zincirini açılışta uygular ve otomatik eşitlemenin kaldırdığı nesneler geri gelir. Sonrasında bekleyen geçiş kalmadığını doğrulayın. Doğrulama: tanılama · posture.dbSynchronize = false
denetim 2 başarısız olduğunda	`chain-never-applied` (kritik)	Otomatik eşitleme açıkken geçiş zinciri hiç çalışmamış olabilir; dolayısıyla kayıtlı geçiş geçmişi, önündeki şemayla örtüşmez. Zinciri uygulamadan eşitlemeyi kapatmak, sahibi hiçbir mekanizma olmayan bir veritabanı bırakır. Düzeltme: Bekleyen geçişleri uygulayın, sonra yeniden başlatın. Geçiş zincirinden eski bir veritabanında, ilk geçiş yeniden çalıştırılmak yerine kaydedilsin diye önce taban alın. Bkz. Bekleyen geçişler var. Doğrulama: tanılama · datastores.postgres.migrationsPending Bu geçerli değilse: Destek paketini ve geçiş durumu komutunun çıktısını ekleyin.

Servisler ve kapasite

Bir servise erişilemiyor ya da kendini sağlıksız bildiriyor

İlginç olan durum erişilebilir ama sağlıksız olmasıdır ve genellikle yüklenememiş bir model anlamına gelir.

Çalışma kitabıperformance

Bir servise erişilemiyor ya da servis kendini sağlıksız bildiriyor

Şunları görebilirsiniz: hap-guard-v2 is unreachable: no response (hap-guard-v2 erişilemez durumda: yanıt yok) · ocr-service answered but is not healthy (ocr-service yanıt verdi ama sağlıklı değil) · ml-detector is unreachable (ml-detector erişilemez durumda) · tespit servislerinden biri kapalı, diğerleri sorunsuz

Başlamadan önce

Hangi servis? Bulgu da sağlık tablosu da tek bir servisin adını verir — yanıt, bir tespit servisi, OCR servisi ve analist için farklıdır.beklenen · Tek bir servisin adını verebiliyorsunuz, örneğin hap-guard-v2 ya da ocr-service.Değilse, önce /troubleshoot/health-matrix sayfasına gidin.
Bu, her servisi birden değil tek bir servisi mi ilgilendiriyor?tanılama · services[nestjs-core].reachable = trueDeğilse, bunun yerine first-boot-no-dashboard çalışma kitabını uygulayın.

Denetimler

1
Adı verilen servisin sağlık uç noktasına hiç yanıt verip vermediğini okuyun
beklenen · reachable true. False olduğunda arıza model düzeyinde değil, ağ ya da kapsayıcı düzeyindedir.
2
Adı verilen servisin kapsayıcı durumunu okuyun
beklenen · state running, yeniden başlatma sayısı düşük ve oomKilled false.
3
Yanıt verip kendini sağlıksız bildiren bir servis için döndürdüğü hatayı okuyun
beklenen · Hata, neyin başlatılamadığını adlandırıyor — bir model dosyası, bir aygıt, bir bağımlılık.
4
Analist ile MCP sunucusu için, onları suçlamadan önce neye bağımlı olduklarını denetleyin
beklenen · Bağımlılık sağlıklı, dolayısıyla sağlıksız kararı bu servisle ilgili.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`not-reachable` (kritik)	Sağlık uç noktası hiç yanıt vermedi; dolayısıyla sorun uygulamanın altındadır: kapsayıcı çalışmıyordur, hâlâ başlıyordur ya da ağ geçidi yanlış adrese bakıyordur. Hiç dağıtılmamış bir servis, erişilemez olarak bildirilmek yerine anlık görüntüde hiç bulunmaz; bu nedenle erişilemez bir satır, orada olması gereken bir şeyin yanıt vermediği anlamına gelir. Düzeltme: Kapsayıcıyı başlatın ve sağlık denetimini bekleyin. Çalışıyorsa, ağ geçidinin kullandığı adresin kapsayıcının dinlediği portla eşleştiğini denetleyin — birkaç servis, ana makinede yayımlanandan farklı bir portu dinler ve bu eşleşmeyi genellikle elle düzenlenmiş bir ortam dosyası kaydırır. Doğrulama: beklenen · reachable ve healthy ikisi de true.
denetim 2 başarısız olduğunda	`container-not-running` (kritik)	Kapsayıcı çıkmış, yeniden başlıyor ya da ölü durumdadır. Tespit servisleri modellerini başlangıçta belleğe yükler; bu nedenle bellek baskısı altındaki bir makine önce bunları sonlandırır ve arıza, yetersiz boyutlandırılmış bir cihaz yerine bozuk bir servis gibi görünür. Düzeltme: oomKilled true ise Bir kapsayıcı bellek tükendiği için sonlandırıldı, değilse Bir kapsayıcı sürekli yeniden başlıyor yolunu izleyin. Doğrulama: beklenen · state running ve yeniden başlatma sayısı sabit.
denetim 3 başarısız olduğunda	`model-did-not-load` (uyarı)	Servis yanıt verir ve kendini sağlıksız bildirir; bu neredeyse her zaman yüklenememiş bir model demektir. Ağdan yalıtılmış bir cihazda olağan neden, model dosyaları olmadan oluşturulmuş bir imajdır: servis başlar, dosyaların olmadığını görür ve çökmek yerine arızayı bildirir. Düzeltme: Sağlık uç noktasının döndürdüğü hatayı okuyun, ardından o servisin çalışma kitabını izleyin. OCR servisi için bkz. Ağdan yalıtılmış bir cihazda OCR servisinin modelleri yok. Model dosyaları olmayan bir servisi yeniden başlatmak hiçbir şeyi değiştirmez. Doğrulama: beklenen · healthy true ve hiçbir hata yok. Bu geçerli değilse: Her servisin günlük kuyruğunu taşıyan destek paketini ekleyin.
denetim 4 başarısız olduğunda	`dependency-unhealthy` (uyarı)	Bazı servisler bozuk oldukları için değil, ihtiyaç duydukları bir şey kapalı olduğu için kendilerini sağlıksız bildirir. Yanlış olanı onarmak bakım penceresini harcar; üstelik bağımlılığın kendi satırı bunu zaten söyler. Düzeltme: Önce bağımlılığı çözün — MCP sunucusu için veritabanı, analist için MCP sunucusu ve yerel model — sonra bu servise dokunmadan önce anlık görüntüyü yeniden okuyun. Doğrulama: beklenen · Bağımlılık sağlıklı ve bu servis onu izliyor.

Bir kapsayıcı sürekli yeniden başlıyor

Yeniden başlatmayı bir kez daha denemeden önce bellek yetersizliği sonlandırmasını, servisin reddettiği bir yapılandırmadan ayırın.

Çalışma kitabıperformance

Bir kapsayıcı sürekli yeniden başlıyor

Şunları görebilirsiniz: has restarted 12 times (12 kez yeniden başladı — bir çökme döngüsünde) · container restarting (kapsayıcı yeniden başlıyor) · bir servis geri geliyor ve yeniden ölüyor · pano bir dakika çalışıyor, sonra hata veriyor

Başlamadan önce

Cihaz yaklaşık beş dakikadan uzun süredir açık mı? Tespit servisleri ilk başlangıçta modellerini yüklemek için zaman ister.beklenen · En az beş dakika geçmiş.
Hangi kapsayıcı yeniden başlıyor?beklenen · Servisin adını söyleyebiliyorsunuz.Değilse, önce /troubleshoot/diagnostic-snapshot sayfasına gidin.

Denetimler

1
Son sonlandırmanın bir çökme mi, yoksa bellek yetersizliği nedeniyle yapılmış bir sonlandırma mı olduğunu denetleyin
beklenen · oomKilled değeri false. True olduğunda bu bir çökme değil, boyutlandırma sorunudur.
2
Ana makinede ne kadar bellek kaldığını okuyun
tanılama · host.memFreeMb = 1024
3
Şemanın güncel olduğunu doğrulayın; çünkü açılışta başarısız olan bir geçiş ağ geçidini sonsuza dek yeniden başlatır
tanılama · datastores.postgres.migrationsPending
4
Kapsayıcının açılışta kendi yapılandırmasını reddedip reddetmediğini denetleyin
beklenen · Servis bir ayarı reddettiğini değil, başladığını ve dinlediğini bildiriyor.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`repeated-oom` (kritik)	Kapsayıcı çökmüyor: onu çekirdek sonlandırıyor ve yeniden başlatma politikası aynı koşulların içine geri getiriyor. İmzası 137 çıkış kodudur. Süreç uyarısız durdurulduğu için servisin kendi günlüğünde bunu açıklayan hiçbir şey bulunmaz. Düzeltme: Bir kapsayıcı bellek tükendiği için sonlandırıldı yolunu izleyin. Doğrulama: beklenen · oomKilled değeri false ve yeniden başlatma sayısı artmayı bırakmış.
denetim 2 başarısız olduğunda	`host-memory-exhausted` (kritik)	Ana makinede neredeyse hiç bellek kalmamıştır; bu nedenle çekirdek, baskının tepe yaptığı anda en büyük olan kapsayıcıyı sonlandırır. Ölen servis kusurlu olan servis değildir; yeniden başlatmalar arasında yeniden başlayan kapsayıcının yer değiştiriyormuş gibi görünmesinin nedeni budur. Düzeltme: Makineye daha fazla RAM verin ya da üzerinde çalışanı azaltın. Tam yığın 32 GB ister; belge ve görüntü işleyen bir dağıtım için 64 GB. Bkz. Makinenin RAM'i lisanslı paketin gerektirdiğinden az. Doğrulama: tanılama · host.memFreeMb = 1024
denetim 3 başarısız olduğunda	`boot-migration-loop` (kritik)	Ağ geçidi geçiş zincirini açılışta uygular. Hata fırlatan bir geçiş süreci de beraberinde götürür, kapsayıcı yeniden başlar, aynı geçiş yeniden çalışır ve başka hiçbir şey değişmeden yeniden başlatma sayısı artar. Düzeltme: Kapsayıcıyı durdurun, başarısız olan bir başlangıcı baştan sona okuyun ve o belirli hatayı giderin. Bkz. Bekleyen geçişler var. Doğrulama: tanılama · datastores.postgres.migrationsPending
denetim 4 başarısız olduğunda	`configuration-refused` (kritik)	Servis, kendisine verilen yapılandırmayla başlamayı reddeder ve bunu ilk günlük satırlarında söyler. Yer tutucu bir imzalama gizli anahtarı bilinçli olarak reddedilir; eksik bir model yolu, okunamayan bir sertifika ve yanlış bir veritabanı parolası da aynı biçimde davranır. Yeniden başlatma politikası sonra bu tek satırlık açık reddi kimsenin okumadığı bir döngüye çevirir. Düzeltme: Günlüğün adını verdiği şeyi düzeltin, ardından kapsayıcıyı bir kez başlatıp günlüğü yeniden okuyun; yeniden başlamaya bırakmayın. Ret imzalama gizli anahtarıyla ilgiliyse bkz. Token imzalama gizli anahtarı bir yer tutucu. Doğrulama: beklenen · Servis dinlediğini bildiriyor ve yeniden başlatma sayısı artmayı bırakıyor. Bu geçerli değilse: Destek paketini ve başarısız bir başlangıcın ilk yirmi satırını ekleyin.

Bir kapsayıcı bellek tükendiği için sonlandırıldı

137 çıkış kodu servisin değil çekirdeğin işidir. Yeniden başlatmak hizmeti geri getirir ve hiçbir şeyi değiştirmez.

Çalışma kitabıperformance

Bir kapsayıcı bellek tükendiği için sonlandırıldı

Şunları görebilirsiniz: was killed for running out of memory (exit 137) (bellek tükendiği için sonlandırıldı, çıkış kodu 137) · exit code 137 (137 çıkış kodu) · an OOM kill (exit 137) means this machine needs more RAM (bellek tükenmesi nedeniyle bir sonlandırma, bu makinenin daha fazla RAM'e ihtiyacı olduğu anlamına gelir) · tespit servisi yük altında ölüyor

Başlamadan önce

Ana makine ajanı bildirim yapıyor mu — yani anlık görüntüdeki bellek rakamları eksik değil, gerçek mi?tanılama · host.memTotalMb = 0Değilse, önce /troubleshoot/diagnostic-snapshot sayfasına gidin.

Denetimler

1
Ana makinenin toplam belleğini lisanslı paketin alt sınırıyla karşılaştırın
tanılama · host.memTotalMb = 32768
2
Ana makinede şu anda ne kadar bellek kaldığını okuyun
tanılama · host.memFreeMb = 2048
3
Sonlandırılan kapsayıcının beyan ettiği sınırı, kullandığı miktarla karşılaştırın
beklenen · Kullanım sınırın epey altında. Sınıra dayanmış bir kullanım, kısıtın ana makine değil sınırın kendisi olduğu anlamına gelir.
4
Bu makinede çalışan her servisin gerçekten kullanımda olup olmadığını denetleyin
beklenen · Çalışan her şey bu dağıtımın ihtiyaç duyduğu bir şey.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 1 başarısız olduğunda	`host-undersized` (kritik)	Tam yığın kullanımda yaklaşık 30 GiB olarak ölçüldü ve varsayılan profil, birkaç servis hiç beyan etmezken kabaca 38 GB kapsayıcı sınırı beyan eder. 32 GB'ın altında çekirdek, belleği en büyük süreci sonlandırarak geri alır; bu da her zaman model yükleyen bir tespit servisidir. Ölen servis kendi başına bir arıza değil, makinenin belirtisidir. Düzeltme: Makinenin belleğini en az 32 GB'a, belge ve görüntü işlenen yerlerde 64 GB'a çıkarın ve yeniden başlatın. Bkz. Makinenin RAM'i lisanslı paketin gerektirdiğinden az ve Gereksinimler ve boyutlandırma. Doğrulama: tanılama · host.memTotalMb = 32768
denetim 2 başarısız olduğunda	`no-headroom` (kritik)	Makine anma alt sınırını karşılıyor ve şu anda hiç payı kalmamış; dolayısıyla bir sonraki model yüklemesi ya da belge ayrıştırması bir sonlandırma tetikler. Bir sonraki bellek tükenmesini önceden söyleyen rakam toplam bellek değil, kullanılabilir bellektir. Düzeltme: Eşzamanlı çalışanı azaltın ya da bellek ekleyin. Sonlandırılan kapsayıcıyı yeniden başlatmak servisi geri getirir, sonucu değiştirmez — bir sonraki tepede yine bir şey sonlandırılır. Doğrulama: tanılama · host.memFreeMb = 2048
denetim 3 başarısız olduğunda	`limit-too-low` (uyarı)	Ana makinenin belleği yerinde ve kapsayıcı kendi beyan ettiği sınıra dayandı; çekirdek onu makine iyi durumdayken sonlandırdı. Bir servisin sınırını yükseltmenin dürüst gerekçesi budur — tek gerekçesi de budur, çünkü payı olmayan bir makinede sınırı yükseltmek sonlandırmayı yalnızca başka bir kapsayıcıya taşır. Düzeltme: O servisin bellek sınırını dağıtımın compose yapılandırmasında yükseltin ve kapsayıcıyı yeniden oluşturun. Uygulamadan önce ana makinede yeni sınır için pay olduğunu doğrulayın. Doğrulama: beklenen · oomKilled false kalıyor ve kullanım yeni sınırın altına oturuyor.
denetim 4 başarısız olduğunda	`unused-services-running` (bilgi)	Birkaç servis isteğe bağlıdır — OCR, belge ayrıştırma, kırmızı takım, yerel analist ve MCP sunucusu — ve her biri, dağıtım kullansın kullanmasın bellek tutar. Yetersiz boyutlandırılmış bir makinede kullanılmayanı kapatmak donanım değişikliğinden hızlıdır ve kullanımda olan hiçbir şeye mal olmaz. Düzeltme: Bu dağıtımın kullanmadığı servisleri durdurun ve hiçbir şeyin onlara bağımlı olmadığını doğrulayın. Neyi kapattığınızı belgeleyin: aksi hâlde sonraki bir özellik talebi hata olarak tanılanır. Doğrulama: tanılama · host.memFreeMb = 2048

Satır içi vekil sunucu ve inceleme

Her ICAP çağıranı aynı docker köprü adresiyle geliyor

CID222'nin yanında sanal makine olarak çalışan bir ağ geçidi, dinleyiciye kendi adresiyle ulaşmaz; bu nedenle oradaki bir kaynak IP izin listesi ya bütün çağıranları kabul eder ya da hiçbirini.

Çalışma kitabıinline-proxy

Her ICAP çağıranı aynı docker köprü adresiyle geliyor

Şunları görebilirsiniz: her SWG 172.19.0.1 olarak görünüyor · ICAP kaynak IP izin listesi vekillerimizi birbirinden ayırmıyor · allowed_source_ips değerinin hiçbir etkisi yok · izin listesini ayarladıktan sonra her çağıran engellendi

Başlamadan önce

Güvenli web ağ geçidi, LAN üzerinde fiziksel bir cihaz değil de CID222 ile aynı ana makinede çalışan bir sanal makine mi?beklenen · Hangisi olduğunu söyleyebiliyorsunuz. Yanıt, bir kaynak IP denetiminin hiç çalışıp çalışamayacağına karar verir.
Burada yalnızca API ağ geçidi yolu değil, gerçekten satır içi vekil denetimi mi dağıtılmış?beklenen · Denetim dağıtılmış durumda.Değilse, önce /deploy/inline-proxy sayfasına gidin.

Denetimler

1
ICAP dinleyicisinin çağıranları nasıl kabul ettiğini okuyun
tanılama · posture.inspectionSourceIpMode = "unrestricted"
2
Çağıranların kendi adresleriyle mi, kapsayıcı köprü adresiyle mi geldiğini denetleyin
beklenen · Kaydedilen kaynak adres, ağ geçidinin kendi adresi.
3
Açık bir izin listesi ayarlıysa, kabul edilmesi gereken her çağıranı listelediğini doğrulayın
beklenen · Her çağıran listede.

Nedenler ve düzeltmeler

Ne zaman ulaşılır	Neden	Açıklama, düzeltme ve doğrulama
denetim 2 başarısız olduğunda	`nat-rewrites-the-source` (uyarı)	CID222'nin yanında sanal makine olarak çalışan bir ağ geçidi dinleyiciye kendi adresiyle ulaşmaz. Hedef o alt ağın dışına çıkar çıkmaz sanal makine ağının kendi NAT (MASQUERADE) kuralı kaynağı yeniden yazar; laboratuvarda hem bir multipass hem bir libvirt misafiri aynı kapsayıcı köprü adresiyle gelirken ölçüldü. Bu, aynı ana makinedeki laboratuvarlara özgü bir durumdur: fiziksel bir LAN'daki ağ geçidi adresini korur ve denetim çalışır. Düzeltme: Aynı ana makinedeki bir sanal makine laboratuvarında kaynak IP izin listesine güvenmeyin — çağıranları birbirinden ayıramaz ve ayarladığınızda ya hepsini kabul eder ya hiçbirini. O ortamda bir izin listesini sınamak için MASQUERADE kuralının önüne, kapsayıcı alt ağının trafiğini döndüren bir kural ekleyin. Üretimde ağ geçidini cihazın ana makinesine değil ağa yerleştirin. Doğrulama: beklenen · Adres, kapsayıcı köprü adresi değil ağ geçidinin kendi adresi.
denetim 1 başarısız olduğunda	`unrestricted-admission` (uyarı)	Dinleyici eşini kimlik doğrulayamaz — tümleştiği hiçbir ürün bir kimlik bilgisi ya da özel başlık sunmaz — bu yüzden kabul yalnızca adrese dayanır ve kabul edilen bir eşe, her istekte iddia ettiği kullanıcı kimliğine kadar inanılır. Kısıtsız kabul, porta erişebilen her şeyin herhangi bir kullanıcıyı iddia edebilmesi demektir. Düzeltme: Dinleyiciyi, kendisini meşru biçimde çağıran ağ geçitlerinin adresleriyle sınırlayın ve portu yalnızca o ağ geçitlerinin erişebileceği bir segmente koyun. Asıl denetim olarak izin listesini değil ağ yerleşimini görün. Doğrulama: tanılama · posture.inspectionSourceIpMode = "unrestricted"
denetim 3 başarısız olduğunda	`allowlist-replaced-the-default` (kritik)	Açık bir izin listesi, özel aralık varsayılanını genişletmez; onun yerine geçer. Tek bir adres ayarlamak bu nedenle, bir an önce çalışanlar dahil diğer her çağıranın kabulünü kaldırır ve arıza, dinleyicide bir yapılandırma değişikliği olarak değil ağ geçidinde bir ret olarak görünür. Düzeltme: Yalnızca eklemekte olduğunuzu değil, kabul edilmesi gereken her çağıranı listeleyin, sonra her ağ geçidini yeniden sınayın. Bu denetim uygulanmaya başlamadan önce yazılmış değerler yükseltme sırasında temizlendi ve olay günlüğüne kaydedildi; dolayısıyla ayarladığınızı hatırladığınız bir değer artık yerinde olmayabilir. Doğrulama: beklenen · Hepsi kabul ediliyor.

Bunların hiçbiri uymuyorsa

Tanılama anlık görüntüsünü baştan sona okuyun. Bulgular bölümü, tetiklenen her kural için bir çalışma kitabının adını verir.
Sağlık tablosuna bakın — erişilebilir ama sağlıksız bir servis, ağdan yalıtılmış kurulumların tipik arıza biçimidir.
Destek paketini toplayın ve konuyu yükseltin. Kurulum kimliğini ve cihaz sürümünü ekleyin.

Rehberli çalışma kitapları

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce

Denetimler

Nedenler ve düzeltmeler

Başlamadan önce