Kurulum programının açılışı ile trafiğe hizmet veren lisanslı bir cihaz arasında yaşanan hatalar ve her biri için çalışma kitabı.

Kurulum programının açılışı ile trafiğe hizmet veren lisanslı bir cihaz arasındaki her şey. Belirtinizi tablodan bulun, ardından altındaki çalışma kitabını uygulayın.

Ürün çalışmaya başlayana kadar ürüne dair hiçbir şey toplanmaz; bu nedenle sağlama sırasında yaşanan hatalar, kurulum programının kendi konsol iletilerinden ve /var/log/cid-firstboot.log kaydından tanılanır. İlk açılıştan sonrası için bunun yerine tanılama anlık görüntüsüyle başlayın.

Belirtinizi bulun

Ne görüyorsunuz	Aşama	Çalışma kitabı
Kurulum, 6/8 adımında kayıt defterinin adını veren kırmızı bir hata satırıyla duruyor	Kurulum	Sağlama 6/8'de duruyor
Makinenin adresi yok ya da yalnızca bağlantı yerel bir adresi var	Kurulum	Bu ağda DHCP yok
Kurulum programı, bellek ya da boş disk değerini göstererek hiçbir şey indirmeden duruyor	Kurulum	Kaynak denetimi başarısız oluyor
Ad çözümleme çalışıyor ama dışarıya hiçbir şey çıkmıyor	Kurulum	Cihaz dışarı çıkamıyor
Kurulum bitti ama tarayıcı boş sayfa gösteriyor ya da bağlantıyı reddediyor	İlk açılış	Pano yüklenmiyor
Sihirbazın bağlantı adımı sunucu hatası döndürüyor	İlk açılış	Bağlantı adımı 500 döndürüyor
Sihirbaz tamamlanıyor ama cihaz yeniden kurulum istiyor	İlk açılış	Sihirbaz döngüye giriyor
Kaydettiğiniz ayarlar yeniden başlatmadan sonra kayboluyor	İlk açılış	Kaydedilen durum kalıcı olmuyor
Sihirbazın sağlayıcı adımı boş liste gösteriyor	İlk açılış	Sağlayıcı adımı boş
Yüklenen lisans, imza hatalı diye reddediliyor	Lisanslama	Lisans yüklemesi 400 ile başarısız oluyor
Cihaz yalnızca deneme sürümünü çalıştırabiliyor	Lisanslama	Lisans güven çıpası yok
Kurulum biter bitmez her ürün yolu 402 yanıtı veriyor	Lisanslama	Kurulumdan hemen sonra 402
Lisans çalışıyordu, şimdi ürün kilitli	Lisanslama	Lisansın süresi dolmuş
443'te hiçbir şey yanıt vermiyor	TLS	443'te hiçbir şey dinlemiyor
Tarayıcı sertifikanın süresinin dolduğunu bildiriyor	TLS	Sertifikanın süresi doluyor
Güncelleme sayfası açıkça yanlış bir sürüm gösteriyor	Güncellemeler	Sürüm bilinmiyor
Güncelleme denetimi hiçbir şey bulmuyor ya da başarısız oluyor	Güncellemeler	Kanala erişilemiyor
Tarihler yanlış: geçerli bir lisans süresi dolmuş, geçerli bir sertifika geçersiz görünüyor	Her aşama	Saat senkron değil

Kurulum

Sağlama 6/8 kapsayıcı imajı adımında duruyor

Kurulum bozuk değildir: makinenin kayıt defterine çalışan bir yolu yoktur. Hata satırının üzerindeki girintili satırı okuyun — o satır indirme aracının kendi iletisidir ve engellenmiş bir portu bozuk bir çözümleyiciden, eskimiş bir kimlik bilgisinden ve incelenen bir TLS bağlantısından ayıran şeydir.

Ç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

Varsayılan açılış girdisi gözetimsizdir ve kendisine bir adres sunulmasını bekler. Adres sunmayan bir segmentte, diske dokunmadan önce adresi 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.

Kaynak denetimi başarısız oluyor

Kurulum programı, hiçbir şey indirmeden önce belleği ve boş diski ölçer; aksi hâlde yetersiz boyutlandırılmış bir makine bir saat sonra ayakta kalmayan kapsayıcılar biçiminde başarısız olur. Programı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. Kurulum başarısız olurken bunların her biri rutin olarak geçer; "bu ağın tam internet erişimi var" cümlesinin genellikle iyi niyetle söylenmesi ve genellikle başka bir yolu anlatması bundandır.

Ç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.

İlk açılış

Pano yüklenmiyor

ISO'dan kurulan bir cihaz yalnızca HTTPS sunar ve ön yüz, kullanamadığı bir sertifikayla bozuk hizmet vermektense hiç başlamamayı seçer. Bu nedenle boş bir sayfa, reddedilen bir bağlantı ve kısa süreli bir yukarı akış hatası üç farklı nedene ve tek bir sayfaya karşılık gelir.

Ç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, cihazın 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 yeniden kurulum istiyor

Sihirbazın tamamlanma bilgisi bir dosyaya yazılır ve bu yazma, hatayı kaydedip devam eden bir işleyicinin içindedir. Yazılamayan bir dizin bu yüzden şu sonucu doğurur: sihirbaz tamamlanır, ürünün kilidini açar ve sonraki yeniden başlatmada ürün yeniden kilitlenir.

Ç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

Kaydedilen durum kalıcı olmuyor

Aynı kök neden, diğer yönden görünüşü: kurulum durumu, lisans, güncelleme istekleri ve tanılama aktarımı tek bir dizinin altında durur ve bu dizine yazılamadığında dördü de 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ş

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

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 imza hatasıyla 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üklemeye çalışmadan önce. Zorunluluk kapalıyken cihaz deneme sürümünü sessizce çalıştırır; bu nedenle eksiklik çoğu zaman ancak deneme süresi bittiğinde fark edilir.

Ç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"}

Kurulumdan sonra her istek 402 döndürüyor

Lisans zorunluluğu açıktır ve hiçbir lisans geçerli olarak çözümlenmez. Cihazın bir kurtarma yordamı olmadan lisanslanabilmesi 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ş

Çalışan ve şimdi ürün yollarını engelleyen bir cihaz. Yenileme istemeden önce saati denetleyin: kayan bir saat geçerli bir lisansı erkenden eskitir ve tam olarak bu durumu üretir.

Ç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

443'te hiçbir şey dinlemiyor

Reddedilen bir bağlantı sertifika hatası değildir; buna karşın ikisi beklediğinizden daha sık aynı nedeni paylaşır: ön yüz, kullanılamayan bir sertifikayla bozuk hizmet vermektense hiç başlamamayı seçer.

Ç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ş

Tarayıcılar süresi dolmuş bir sertifikayı doğrudan reddeder ve bu cihaza güvenecek biçimde yapılandırılmış istemciler zayıflayarak değil kapalı kalarak başarısız olur — yani 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"

Güncellemeler

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

Sürüm bilgisi, imaj derlemesinin ve güncelleyicinin yazdığı dosyalardan gelir. Hiçbiri okunamadığında sürüm bir yer tutucuya geri düşer ve kanalla yapılan her karşılaştırma anlamsız hâle gelir.

Ç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 ve zararsız 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

Her aşama

Ana makine saati senkron değil

Lisans bitişi, sertifika geçerliliği, token ömürleri ve her tespit zaman damgası bu saate göre belirlenir. 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"

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 — yanıt verip kendini sağlıksız bildiren bir servis genellikle yüklenememiş bir model anlamına gelir.
Destek paketini toplayın ve kurulum kimliği ile cihaz sürümünü ekleyerek konuyu yükseltin.

Kurulum ve etkinleştirme sorunları

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

Bu sayfada