Üzemeltetői felület-referencia

Minden hálózati port, socket és fájl, amit ez az átjáró megnyit vagy tárcsáz, alrendszerenként egy szakaszban, mindig ugyanabban a három részben: hol állítódik be az érték, mit foglal az érték, és melyik parancs méri.

Annak a három portnak, amit az ISG maga nyit meg — az admin felület, a CA megújítási végpontja és a diagnosztikai figyelő —, alapértelmezése van a kódban, és az alábbi számok ezek az alapértelmezések. Ezen az oldalon minden más port egy olyan értékből származik, amit egy operátor írt be egy konfigurációs fájlba. Azokra nincs idézhető alapértelmezés, ezért ami helyettük szerepel, az ebben a telepítésben szokásos érték, így is jelölve. Ha bármelyiket alapértelmezésnek olvasod, az az egyetlen mód, ahogy ezt az oldalt félre lehet használni.

Minden szakasz táblázatban nevezi meg a kulcsait és a flagjeit, nem mondatokban, szándékosan: azokat a cellákat a make operations-check veti össze a kóddal, egy bekezdésbe hegesztett értéket pedig egyetlen kapu sem talál meg.

webUI

A böngészős admin felület: jóváhagyások, munkamenetek és az audit-nyomvonal. HTTPS-t szolgál, ha az isg ca init lefutott, mert az állítja ki a kiszolgáló-tanúsítványát; anélkül sima HTTP-t szolgál loopback bindon, és bármi máson megtagadja az indulást.

Képernyőkép: referencia-környezet (env1), 2026-10-17.

Hol állítódik be

Az ldap.yaml url-je azért van ezen a listán, mert az dönti el, hogy a felület kér-e egyáltalán bejelentkezést: konfigurált címtárral a felület űrlapos hitelesítésű, anélkül nyitva fut. Ha van sso.yaml, a belépő oldal a jelszó-űrlap mellett az identity providert is kínálja (web: optional), vagy csak azt (web: required); a címtár mindkét esetben kötelező, mert amit a provider visszaad, az csak egy keresőkulcs abba — lásd lentebb: SSO (OIDC identity provider). A webui_base_url az a cím, amire egy JIRA-jegy visszalinkel — ugyanaz a felület, valaki más böngészőjéből nézve.

A tls.yaml két kulcsa a kilépés abból, hogy ennek a portnak a tanúsítványát az ISG CA adja — lásd lentebb: Kiszolgáló-tanúsítvány. Ezen a lapon ez az egyetlen két kulcs, amelyek HIÁNYA maga a dokumentált alapértelmezés: a fájl nélkül az ISG CA állítja ki a tanúsítványt, ahogy minden telepítés tette, mielőtt ez a fájl létezett.

Mit foglal

A tanúsítványnak két lehetséges forrása van, és az isg system check webui_cert_source sora mindig megmondja, melyik van használatban.

Az ISG CA (az alapértelmezés). tls.yaml nélkül az isg serve induláskor az átjáró saját X.509 CA-jából állítja ki ennek a portnak a tanúsítványát, a ca/server/server_<ui-hostname>.crt fájlba. Nem kell hozzá PKI a te oldaladon, és az első futásra működik; az ára az, hogy minden böngészőnek, ami ezt a felületet eléri, bíznia kell a pub/x509_ca_cert.pem-ben.

Ez az ár az, ami megszorítja a CA-t. Egy tanúsítvány-tárba importált CA kulcsa bármely névért helytállni tud, amire aláírhat, ezért egy ÚJ X.509 CA csak úgy jön létre, hogy ez a halmaz ki van mondva: az isg ca init --permitted-dns <name> --permitted-ip <CIDR> ezeket írja a tanúsítványba nameConstraints-ként, és egyik kapcsoló nélkül sem hoz létre a parancs semmit. Az eredményt utána két dolog jelenti: az x509_ca_name_constraints sor megmondja, meg van-e szorítva ez a CA és mire — megszorítás nélkül WARN, soha nem FAIL, mert az egyetlen javítás egy új CA, és egy CA cseréje minden általa aláírt tanúsítványt érvénytelenít —, a kiállítás pedig megtagadja a halmazon kívüli hostnevet, ahelyett hogy olyan tanúsítványt gyártana, amit minden láncot ellenőrző kliens elutasít.

A saját PKI-d (tls.yaml). Nevezz meg egy tanúsítványt és egy kulcsot, amit egy olyan CA adott ki, amiben a géppark már bízik, és ez a port azt fogja kiszolgálni — nincs importálandó ISG-gyökér sehol. A cert_file a leafet tartalmazza elöl, utána a köztes tanúsítványokat; a key_file módja 0600 legyen, tulajdonosa a daemon fiókja. A párt az indulás ellenőrzi a név ellen, amin ezt a listenert hívják, és egy jelen lévő, de használhatatlan tls.yaml megtagadja az indulást — csendes visszaesés az ISG CA certjére nincs, mert az egy működő felületet adna egy böngésző-figyelmeztetéssel, és soha nem mondaná meg, hogy a konfigurációdat figyelmen kívül hagyták.

A külső pár cseréjéhez nem kell újraindítás: a daemon újraolvassa a fájlokat (legfeljebb 30 másodpercenként egy stat), és a következő kézfogás már az új tanúsítványt kapja, egy WEBUI_CERT_RELOADED audit-bejegyzéssel. Az a csere, ami ugyanazokon az ellenőrzéseken elbukik, elutasításra kerül, a korábbi tanúsítvány marad kiszolgálva, és ezt a WEBUI_CERT_RELOAD_REJECTED meg egy piros webui_cert_source sor mondja ki.

Amit az ISG nem ellenőriz, az a lánc: a te gyökered nincs nála, tehát hogy egy böngésző elfogadja-e a tanúsítványt, csak kliensről válaszolható meg.

Hogyan mérd

• isg system check --verbose
• webui_cert_source — melyik forrás van használatban, egy külső pár kiadója és SAN-jai, és hogy egy csere elutasításra került-e
• ISG CA-forrás: curl -sS -o /dev/null -w '%{http_code}\n' --cacert $ISG_HOME/pub/x509_ca_cert.pem https://<ui-hostname>:8765/
• külső forrás: ugyanaz a curl, csak --cacert <customer-root.pem> — az ISG-gyökérnek itt semmi szerepe, az importálása semmit nem bizonyít
• magának a kiszolgáló-tanúsítványnak a lejárata: a server_cert_expiry a ca/server/ alatti, ISG által kiadott készlet a lemezen, a webui_cert_expiry pedig az, amit ez a port ténylegesen felmutat. Külső párral a kettő különböző tanúsítványokról szól, és a külsőnek a határidejét a webui_cert_source jelenti
• ISG CA-forrás — a cseréje kézi művelet, és semmi nem végzi el helyetted: az isg ca server-cert renew --hostname <name> friss tanúsítványt és kulcsot ír a ca/server/ alá, az isg serve-t pedig újra kell indítani, mielőtt ez a port felmutatná őket — az újraindításig a server_cert_expiry és a webui_cert_expiry szándékosan eltér, és ez az eltérés az, amiből ez az ablak látszik

CA renew

Az az mTLS-végpont, amit egy szolgáltatás-gép ügynöke hív a hozzáférési tanúsítványa megújításához. Ez az egyetlen ISG-port, ami alapból minden interfészre köt, mert a megújító gépek definíció szerint nem ezek; a védelme a kölcsönös TLS, nem a bind-cím.

Hol állítódik be

Az első két kulcs a szolgáltatás-gépen él, nem az átjárón: ezek ennek a végpontnak a kliens-fele, és a ca_renew_url az a hely, ahol a fent leírt portszámot meg kell ismételni.

Mit foglal

Hogyan mérd

• isg agent status — a szolgáltatás-gépen, a saját tanúsítványa ellen
• isg system check --verbose — az átjárón, magának a CA-nak a lejáratára

Web Access

A listener, ami a webes konzolokat az ISG-belépés mögé teszi, és a kapcsolatai a konzolok felé. Ki van kapcsolva, ha nincs apps.yaml; hogy egy kérés milyen úton jár, az a hogyan működik a Web Access lapon áll.

Hol állítódik be

Mit foglal

Az alkalmazás-munkamenetek és a jóváhagyások a rekord-tárban élnek, mint az SSH-munkamenetek; egy kind: form fiók upstream munkamenet-sütijei csak a kiszolgáló bróker memóriájában, és egy újraindítással elvesznek (a következő kérés újra belép).

Hogyan mérhető

• isg system check --verbose — az apps.yaml sor (a fájl betölt), a Web Access listener sor (figyel, a tanúsítvány minden alkalmazás hosztnevét lefedi, az utolsó újratöltés), a Web Access credentials sor (minden közös fiók titka olvasható).

• Egy kliensről, az alkalmazás hosztnevével és a listener portjával — egy ismeretlen hosztnév 421-et kap, egy ismert az alkalmazás-munkamenet nélküli böngészőt a webUI belépéséhez küldi:

  curl -sI https://<app host>:<port>/
  

Diagnosztika és metrikák

Az egészség- és metrika-figyelő: életjel egy orkesztrátornak, készenlét egy terheléselosztónak, és egy Prometheus-formátumú scrape. Ki van kapcsolva, amíg be nem kapcsolják, és loopbackre köt, hacsak mást nem mondanak neki — egy másik gépen futó scraper kimondott döntés, nem a funkció bekapcsolásának mellékhatása.

Hol állítódik be

Mit foglal

Az auth_token, ha be van állítva, a /readyz-n és a /metrics-en kötelező, a /healthz-n soha.

Hogyan mérd

• curl -fsS http://127.0.0.1:8767/healthz
• curl -fsS -H "Authorization: Bearer <token>" http://127.0.0.1:8767/readyz
• curl -fsS http://127.0.0.1:8767/metrics
• isg system check --verbose

Egy mérés, három felület. Az isg system check nem magától mér: a futó daemontól kéri a jelentést a session-socketen, és a választ jeleníti meg. Ugyanaz a jelentés, amit az admin felület /system oldala mutat, és ugyanazok az ellenőrzések, amelyeknek egy vetületét a /readyz adja — a daemon saját bemeneteivel mérve —, így a kimenet nem függ attól, melyik fiók futtatja a parancsot. A jelentés első sora ezt ki is mondja (Measured by the daemon (pid N, user isg) over /run/isg/session.sock). Aki a socketet megnyithatja, az kérheti; semmi több nem kell hozzá.

Daemon nélkül — nem fut, ebből a fiókból nem érhető el, vagy túl régi ahhoz, hogy ismerje a kérést — a parancs ugyanazzal a kóddal helyben mér, és a Measured locally as user … sorral nyit, megnevezve az okot; a --local ezt az utat kényszeríti ki összehasonlításhoz. A helyi úton azok a sorok, amelyek csak a daemon által olvasható fájlokat olvasnak — a rekord-tár hitelesítő fájlját a Lockout store, Revocation list, Login state store, Broker version skew és Retention artifact integrity sorok mögött — azt mondják: not measurable from this account, és WARN-t adnak: a nem-mért sosem hamis zöld. Soha nem FAIL-ek a hívó saját jogosultságai miatt, és soha nem tűnnek el.

A színt kérni kell, nem kitalálni. A riport a [OK ], [WARN] és [FAIL] jelölőit csak valódi terminálon színezi, így a cső, a fájl és a cron megkapja az escape-mentes, soronként-egy-sor alakot, amit a parse-olók olvasnak. Egy másik gépről az ssh gateway isg system check alakkal olvasva sincs távoli terminál, tehát az a kimenet is színtelen — a --color=always mégis kéri a színt, és pont ez kell egy naplózott, nem interaktív futáshoz, a másik út pedig az ssh -t; a --color=never terminálon is elutasítja. A szín soha nem hozza magával a tördelést: a --color=always csövön is soronként egy sort ad. Az alap auto módban a NO_COLOR (bármilyen értékkel jelen van) erősebb a CLICOLOR_FORCE-nál (bármi, csak nem 0), az pedig erősebb a terminál-vizsgálatnál.

Rekord-tár (PostgreSQL)

Itt élnek a munkamenet-rekordok, a bróker-bérletek, a bejelentkezési állapot, a kizárási számlálók és a visszavonások, ha egynél több bróker osztozik rajtuk. A kapcsolati sztringet fájlból olvassuk, nem a konfigból, hogy a jelszó soha ne üljön egy mindenki által olvasható YAML-ben.

Hol állítódik be

Mit foglal

Hogyan mérd

• isg system brokers
• isg system check --fleet
• isg system check --verbose

Objektumtár (S3)

Ide kerül egy lezárt munkamenet felvétele. Az üres endpoint az igazi AWS S3-at jelenti, és az SDK feloldja a régió saját címét; bármi más egy S3-kompatibilis szolgáltatás címe, és azt a címet a port is hordozza.

Hol állítódik be

Mit foglal

Hogyan mérd

• isg storage verify
• isg storage verify --deep

Titok-tár (OpenBao)

Akkor olvassuk, ha a tanúsítvány-aláírás delegálva van — abban a módban az SSH CA privát kulcsa sosem ezen a lemezen van, és minden tanúsítvány, amit az ISG kiad, ezen a kapcsolaton át íródik alá —, akkor, ha a többfaktoros titkok a KV-tárában vannak a lokális totp/ könyvtár helyett, és akkor, ha egy Web Access-alkalmazás közös fiókot használ (identity: credential), amelynek a titkát minden belépéskor vagy kéréskor a KV-tárból olvassuk. Az X.509 CA-t ez nem érinti, az lokális marad.

Hol állítódik be

A ca.yaml signer-je és az mfa.yaml store-ja a két kapcsoló: a beépített aláíróval és a fájl-alapú titok-tárral a vault.yaml-t soha nem nyitjuk meg, és ebből a szakaszból semmi nem érvényes.

Mit foglal

Hogyan mérd

• isg system check --verbose

SSO (OIDC identity provider)

A szervezet OIDC identity providere mint belépés két felületen: a böngészős belépés az admin felületre (Authorization Code PKCE-vel), és az átjárós bejelentkezés az ssh isg-login@gateway úton (az RFC 8628 device flow — a daemon kiír egy kódot és egy URL-t, az operátor a saját böngészőjében hagyja jóvá, Enter után a daemon pollol). Amit a provider eldönt, az az, hogy ki lép be. Amit nem dönt el, az az, hogy az a személy létezik-e itt, és hogy mit tehet: a username_claim értéke egy keresőkulcs, amit a címtárnak fel kell oldania, a szerepkör, a csoportok és a jóváhagyói jog pedig továbbra is a címtárból jön.

Hol állítódik be

Az issuer az, ahonnan a discovery olvasódik, és HTTPS kell legyen. A client_secret_file egy 0600 módú fájl — maga a titok sosincs a YAML-ban. A redirect_url-nek /login/sso/callback végűnek kell lennie, és bájtra egyeznie kell azzal, amit a provider regisztrált. A web és a cli független tengelyek: mit kínál a belépő oldal, és mit csinál az SSH-bejelentkezés promptja.

SAML 2.0 az OIDC helyett

Ha a protocol értéke saml, a böngészős belépés SAML 2.0-t beszél, és csak a böngészős belépés: az SSH-bejelentkezés jelszó plusz az átjáró saját második faktora marad, ezért a cli értéke csak off lehet. A fenti OIDC-kulcsokat ilyenkor a betöltő nem olvassa.

A saml_idp_metadata_url (HTTPS) és a saml_idp_metadata_file közül pontosan az egyik nevezi meg a provider metaadatát, amiben kell lennie egy aláíró tanúsítványnak és egy HTTP-Redirect belépési végpontnak. A saml_acs_url-nek /login/sso/saml/acs végűnek kell lennie. Csak az ezen az átjárón indított belépést fogadja el, és magának az assertionnek aláírtnak kell lennie. A felhasználónév a saml_username_attribute által megnevezett attribútum értéke (alapértelmezés uid), vagy a NameID, ha a saml_use_name_id be van kapcsolva. mfa: idp mellett az assertion AuthnContextClassRef értékének a saml_idp_mfa_authn_context egyikének kell lennie, különben a helyi második faktor fut. Az átjáró a saját metaadatát a /sso/saml/metadata címen teszi közzé, hogy a provider adminisztrátora importálhassa.

Mit foglal

A böngésző saját forgalma a provider felé nem az átjáróé, és nincs ebben a táblában.

Hogyan mérd

• isg system check --verbose — az SSO (OIDC) sor: discovery és JWKS; protocol: saml mellett helyette az SSO (SAML) sor: a provider metaadata és az aláíró tanúsítványának lejárati dátuma
• az auditnapló: LOGIN_SSO_START, LOGIN_SSO_OK és LOGIN_SSO_FAILED, mindegyik webui vagy gateway értékű surface-szel és oidc vagy saml értékű protocol-lal; egy elutasított átjárós bejelentkezés a sso_denied, sso_expired vagy sso_unavailable egyikét nevezi meg, egy elutasított SAML-belépés a bukott lépést, például audience, in_response_to vagy replay

Az induláskor elérhetetlen provider nem végzetes: a daemon SSO nélkül indul — a jelszó-űrlap web: required mellett is megjelenik, és a cli: required továbbra is jelszót kér —, és az ellenőrzés sora piros marad, amíg a provider újra elérhető nem lesz. Hogy bárki beléphet-e egy futó átjáróba, az nem múlhat azon, hogy egy JSON-dokumentum letölthető-e.

LDAP

Az elsődleges identitásforrás: ki egy felhasználó, mely csoportokban van, és — az admin felület bejelentkezéséhez — egy jelszavas bind. Enélkül az átjáró egy lokális identitásfájlra esik vissza, ami támogatott mód, nem hiányosság.

Hol állítódik be

Mit foglal

A 636 a szabványos LDAPS-port, és ez a javasolt üzemmód; a 389 a szabványos sima port, ami csak start_tls: true-val hordoz biztonságosan jelszavakat. A referencia-környezet a privilegizált portot a címtár-hoszton ip_unprivileged_port_start sysctl-lel köti be rootless módon, amit az isg_directory Ansible-role maga állít be — csak lefelé, és soha nem egy már alacsonyabb küszöb fölé. Sysctl nélkül egy rootless konténer jellemzően magas porton ül, pl. 1389-en. Mindegyik az operátor url-ben álló értéke, nem egy szám, amit az ISG választ.

A címtár oldalán van egy fél, amit az átjáró nem tud kikényszeríteni: az a címtár, amelyik a sima portján továbbra is válaszol, ezt a transzportot a hálózaton bárki másnak is elérhetővé hagyja. Ez a telepítés ezért a 636-ot ajánlja ki a flottának, a sima portot pedig csak a címtár-hoszton belülről hagyja elérhetőnek, azoknak a komponenseknek, amelyek ott futnak, és még nincs saját TLS-útjuk.

A kapcsolat titkosított, vagy a daemon nem indul el. Egy ldaps:// url, vagy egy ldap:// url start_tls: true-val, a két normál alak; a tls_ca_file a kiadó CA PEM-jét nevezi meg, ha az nincs a gép trust-storéjában. Egy ldap:// url egyik kulcs nélkül megtagadja az indulást, az allow_plaintext: true pedig a kimondott, WARN-ként jelentett engedély a titkosítatlan bindra — és ez itt azért számít, mert ez a kapcsolat nem csak a szolgáltatásfiók, hanem az operátorok jelszavát is hordozza. Az isg system check az ldap.yaml sorában kimondja a transzportot, a LDAP bind sorában pedig a valódi kézfogást és a tanúsítvány lejáratát is megméri; a teljes szabály a hozzáférési modell lapon áll.

A bind-fiók CSAK OLVASÓ. Az ldap.yaml minden brókeren 0660 isg:isg-operators módban áll — a gépen minden operátor elolvassa, és az is, akinek egy mentése van róla. A benne álló bind_dn ezért egy dedikált, csak olvasó szolgáltatás-fiók legyen, sosem a címtár adminisztrátora: az admin bindjával az a fájl a teljes címtár írási jogát adja — jelszó-csere, csoport-tagság átírás, bejegyzés-törlés.

Egy csak olvasó bindhoz két dolog kell, és a második könnyen marad el: a fiók, és egy ACL-szabály, ami olvasni engedi. Ebben a címtár-image-ben a gyárilag szállított ACL egy sima kötött fióknak csak önmagát adja, tehát a szabály nélkül a fiók bindol, aztán nulla bejegyzést olvas — a telepítés zöld marad, miközben az identity-feloldás és az IdP felhasználó-importja üres. A szabály helye dönt a többiről: a címtár userPassword-szabálya ELŐTT a fiók a fában minden jelszó-hasht elolvas, a catch-all szabály UTÁN pedig néma no-op.

A referencia-telepítésben mindezt az Ansible-role-ok birtokolják: a fiókok és az ACL-szabály a futó címtárba kerülnek (isg_directory), a renderelt ldap.yaml a csak olvasó bindot hordozza, és a gateway verify-ja minden brókeren megméri, hogy a bind DN ez a fiók, és hogy a címtár adminisztrátorának jelszava a fájlban SEHOL nem szerepel. A címtár-oldalt két irányból mérjük — a fiókkal kötve ÉS rootként a címtár saját socketjén —, négy állítással: annyit olvas, amennyi a fán van; jelszó-hasht nem kap vissza; egy valódi írási kísérletet 50 Insufficient access utasít el; és a szolgáltatás-fiókok nem jelennek meg a felhasználók között. Részletek: ansible/README.md, „Csak olvasó LDAP-bind".

Hogyan mérd

• isg system check --verbose

SMTP

Az MFA-kód kézbesítési csatornája. Ha nincs, a kód helyette egy lokális kimenő-fájlba íródik, ami fejlesztői mód, és az ellenőrzés kimenete ki is mondja.

Hol állítódik be

Mit foglal

Az 1025 a lokális teszt-továbbító. Egy termelési továbbító az 587 STARTTLS-es beküldéshez, vagy a 25 sima esetén; az érték mindkét esetben a port.

Hogyan mérd

• isg system check --verbose

JIRA

A jegy-integráció: egy munkamenettől megkövetelhető, hogy jegyet nevezzen meg, és az átjáró ellenőrzi, hogy az a jegy létezik. A hitelesítőadat-fájl csak a tulajdonosnak olvasható, tehát egy operátori shell kevesebbet mér itt, mint a daemon — a sorok ezt kimondják, nem csendben mennek át.

Hol állítódik be

Mit foglal

Hogyan mérd

• isg jira verify
• isg system check --verbose

Audit-export (syslog)

Minden auditbejegyzés opcionálisan bekapcsolható másolata, egy SIEM felé továbbítva RFC 5424 syslogként, TCP-n, TLS-sel. A másolat másolat: egy sikeres küldés nem elégíti ki a szigorú audit-garanciát, és a lemezen lévő fájl marad a hivatalos audit.

Ettől függetlenül, és a SIEM-exporttól elkülönítve, ez az átjáró fogadni is tud továbbított break-glass naplósorokat a célgépektől. Az a fogadó egy, a csomagolással szállított rsyslog drop-in, nem ISG-figyelő, és emiatt jelenik meg egy második port az alábbi táblában.

Hol állítódik be

Mit foglal

Hogyan mérd

• isg system check --verbose

Licenc

Mely modulokban nyithat az átjáró új munkamenetet: ssh_broker és web_access. Licencfájl nélkül az átjáró 30 napos értékelési módban fut, minden modullal; utána, illetve egy licenc 14 napos türelmi ideje után új munkamenet nem indul. A futó munkamenetek, a break-glass és a /readyz sosem érintettek. A fájlt az Inshipia adja ki és írja alá; változatlanul kell telepíteni, és az átjáró 30 másodpercen belül, újraindítás nélkül felveszi.

Hol állítódik be

Ansible-es telepítésnél a fájl a repóban a környezet konfigurációs könyvtárába kerül, a policy.yaml mellé; a playbooks/config-src.yml viszi a config-forrásba, a playbooks/site.yml a brókerekre.

Mit foglal

Hogyan mérd

• isg license show
• isg system check --verbose — a License sor
• az isg_license_state, isg_license_expiry_timestamp_seconds és isg_license_named_users metrika

Brókerek

Egy több-brókeres telepítésben minden átjáró ugyanazt a daemont futtatja egyetlen közös rekord-táron, egyetlen közös név mögött. Itt semmi nem nyit új portot az átjárón — az alábbi SSH-port az operációs rendszer saját sshd-jéé, ami előbb indult, mint az ISG.

Hol állítódik be

Mit foglal

Hogyan mérd

• isg system brokers
• isg system check --fleet
• isg system check — a Broker version skew sor minden élő bróker-bérlet FLOTTA-KOMPATIBILITÁSI SZÁMÁT veti össze ennek a binárisnak a számával; csak közös (PostgreSQL) rekord-táron létezik. A verziók is ki vannak listázva, de a v0.476.0 óta azok bizonyítékok, nem az ítélet.
• isg system check — a Broker target list sor a statikus servers.yaml (alapértelmezett szint és hoszt→szint párok) ujjlenyomatát veti össze, amit minden élő bróker INDULÁSKOR BETÖLTÖTT, ahogy a bérlete hirdeti: OK, ha mind egyezik; WARN, brókerenként a hosztok számával és a digesttel, ha eltérnek; és külön mondat, ha ennek a hosztnak a saját fájlja a restart óta változott. A fájl brókerenkénti és kézzel karbantartott — semmi nem szállítja és nem szinkronizálja —, a daemon pedig induláskor egyszer olvassa, ezért a javítás a fájl igazítása az eltérő brókeren és annak újraindítása. Ugyanaz a tár-kapu, mint a fenti soré.

Vegyes verziók gördülő frissítés alatt. A brókerek bármilyen sorrendben frissíthetők. Két mért tulajdonság teszi ezt biztonságossá: a PostgreSQL-séma additív (minden migráció egy CREATE TABLE IF NOT EXISTS a saját indexeivel és szekvenciáival, és a make migrations-check elutasít minden DROP-ot, RENAME-et, oszlop-újratípusozást és DEFAULT nélküli NOT NULL oszlopot), és egy rekord azon tagjai, amelyeket egy régebbi bináris nem ismer, változatlanul túlélik annak olvas–módosít–visszaír körét (internal/recordjson, rekordcsaládonként egy teszt). Mindkettő addig tart, amíg a brókerek egyetértenek a közös állapotról, és a v0.476.0 óta ezt az egyetértést egy kimondott szám méri, nem a kiadások közti távolság: a FLOTTA-KOMPATIBILITÁSI SZÁM (internal/fleetcompat), amit ember emel, ha a brókerek közös állapota vagy a bróker–bróker protokoll változik, és amit semmi más nem emel. Az isg --version második sora, az isg_build_info compat címkéje és a bróker-bérlet fleet_compat mezője publikálja. Két bróker ugyanazon a számon akárhány minor távolságra lehet; a Broker version skew sor ott OK, WARN, amíg a flotta EGY kompatibilitási lépést fog át (folyamatban lévő gördülő frissítés — ennek rövidnek kell lennie), vagy ha egy bróker verziója nem értelmezhető, és FAIL egy lépésen túl, vagy ha két bróker a major verzióban tér el — a majoron át semmi nincs megígérve. Egy v0.476.0 előtt írt bérlet nem hordoz számot, és azokra a sor a régebbi N-1 minor-szabályra esik vissza, és ezt kimondja. A migrációt az elsőként induló új bináris futtatja, advisory lock alatt, egy tranzakcióban.

Web Access az app-azonosítós frissítésen át (B491). Ettől a kiadástól egy alkalmazásra az azonosítója (apps.yaml id) hivatkozik a neve helyett. Kompatibilitási lépés nélkül elfogadva: amíg régi és új brókerek egymás mellett szolgálnak ki, a félkész Web Access-belépés (átadási kód, alkalmazás-munkamenet) és a név szerint beadott, még függő jóváhagyási kérelem újrakezdést kér. Az alkalmazásnévre tett incidens-zár tovább hat, és a név szerinti policy.yaml http_rules-elem is illeszkedik még, betöltéskor figyelmeztetéssel.

Firewall

Ezt a szakaszt egyetlen kapu sem méri. A make operations-check portszámokat, kulcsneveket és parancssorokat vet össze a kóddal; arról, hogy egy tűzfalat ténylegesen mire kértek meg, semmiképp nem tudhat, és ezt a repó egyetlen olvasata sem árulhatná el neki. A táblát a szándéknak tekintsd, a tűzfal saját konfigurációját pedig a ténynek.

Az irány ennek az átjárónak a szemszögéből van írva. Egy Ansible-role-okkal telepített környezetben ezek a bejövő szabályok nem kézzel íródnak: egy baseline role telepíti és elindítja a firewalldot, és minden portot az a role nyit, amelyiké — egyetlen környezeti fájl címtartományaira szűkítve (ansible/README.md, „Tűzfal-baseline (isg_firewall)"). Ott az üres forráslista azt jelenti, hogy a port zárva marad, nem azt, hogy mindenkinek nyitva.

A nyolc szám nélküli sor szándékosan szám nélküli: a portjuk az, amit az operátor a fenti szakaszokban megnevezett konfigurációs kulcsokba írt, és egy ide írt szám arra hívna, hogy valaki azt nyissa ki a helyett, amit a saját telepítése ténylegesen használ.