Flotta-telepítés

Ez a lap a menetrend: melyik playbookot mikor kell indítani, melyik gépeken, milyen kapcsolókkal, és mi mondja meg, hogy sikerült. Annak szól, akinek a gépek már megvannak — brókerek, megosztott tár, címtár, célgépek —, és ISG-flottát telepít vagy üzemeltet rajtuk a termékkel szállított Ansible-automatikával.

Nem ez a role-referencia. Az automatika a saját referenciáját is hordozza, ami azt írja le, mit csinál egy-egy role, milyen döntéseket hoz és mik a változói. Ez a lap afölött áll: azt nevezi meg, amit az üzemeltető beír, abban a sorrendben, ahogy beírja, és azt, aminek a futás kimenetében meg kell jelennie, mielőtt a következő lépés indul.

Egyetlen átjáró egyetlen gépen ebből semmit nem igényel. Az az út — egy bináris, egy unit, egy identitás-forrás — az első lépések lapon áll. Ez a lap a flottáról szól: több brókerről egy közös cím mögött, megosztott tárral, címtárral.

Amit minden futásra tudni kell

Hol futtatod. Minden lenti ansible-playbook parancs a vezérlőn fut — azon a gépen, amelyik az inventoryt és a playbookokat tartja, és SSH-n eléri a flottát. A vezérlő nem a flotta egyik gépe, és a „Hol fut" oszlop azt nevezi meg, melyik gépeket célozza egy play, nem azt, hogy hol írod be.

Az inventory és a környezet neve. Minden lenti parancs a referencia-környezet alakjában áll, env1-ként — vagyis az -i inventory/env1.ini -e isg_env=env1 kapcsolókkal. A saját környezetednél az inventory-fájl és a környezetnév a sajátod; a parancssorban semmi más nem változik.

A -e isg_env= KÖTELEZŐ. Ez választja ki a környezet változó-fájlját. Nélküle, vagy elgépelt környezetnévvel a környezet-kapu (_env-guard.yml, amit minden playbook importál) az első playben megáll. A kapu azért van, mert a hiba egyébként néma: az Ansible szó nélkül átugorja a feloldhatatlan vars_files bejegyzést, tehát a kapu nélkül a play elindulna, csak a közös változókkal, és ami nem olvas környezeti változót, az lefutna a gépeken.

A config-forrás. A -e isg_config_src_dir= egy vezérlőn álló könyvtárat nevez meg, amiből a role-ok a konfigot és a titkokat a gépekre viszik. Nem kézzel összerakott könyvtár: az alábbi 1. lépés gyártja le, és minden későbbi play, amelyik titkot vagy konfigfájlt szállít, ugyanezt az utat kapja meg. Ez az út a tiéd, ezért a lenti parancsokba nincs beírva — ahol egy futásnak kell, ott a kapcsoló prózában áll a parancs mellett. Egy helyőrzőt hordozó parancssor másolhatónak látszik, és nem az. Egy kapcsoló (isg_config_src_pki_enabled) ezt a lépést arra is ráveszi, hogy a környezet saját gyökerét állítsa ki, és abból adja az identitás-szolgáltató meg az admin-felület tanúsítványát (pki/root.crt, tls/webui.crt, tls.yaml) — így a kliensen pontosan egy tanúsítványban kell bízni, és az nem az ISG CA. Alapból ki van kapcsolva: ahol az ügyfél már PKI-t üzemeltet, ott a saját párjuk kerül a config-forrásba.

A become-jelszó. Egy playbook, amely egy gépen emel, a jelszót maga kéri, első lépésként, és a prompt (sárgával) megnevezi, melyik jelszót várja — például a környezet gépein az admin-fiók sudo-jelszavát. Utána minden gépen kipróbálja, ahol emelni fog, és rossz jelszónál, egy nem válaszoló sudo-nál vagy egy elérhetetlen gépnél ott megáll, írás előtt, és újra megnevezi a várt jelszót. A nevek a környezeti változófájl isg_become_labels szótárából jönnek. A prompt helyett a -e isg_become_password_file= egy úttal egy fájlból olvassa a jelszót a vezérlőn — a frissen telepített gépek első futása ezzel adja a konzol-jelszót. A -K nem kell; ha mégis ott van, nem árt, mert a playbook saját promptja nyer. Terminál nélküli futás (egy timer) nem kap kérdést, és a root nélkül futó lépések (a tár mentése) sem kérdeznek.

Telepítési sorrend

Minden lépésnek van lenti alfejezete, ugyanebben a sorrendben: a teljes leírás, a parancs, az előfeltétel, és az, amiből látszik, hogy sikerült.

1. A config-forrás legyártása — playbooks/config-src.yml

Legyártja a config-forrást a vezérlőn: sablonokat a környezet változóiból, szabály- és dokumentumjellegű fájlokat a repóból, titkokat a futás alatt. Meglévő titkot soha nem ír felül, és a flotta gépeihez egyáltalán nem nyúl.

• Hol fut: vezérlő
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/config-src.yml — és a -e isg_config_src_dir= a config-forrás útjával a vezérlőn
• Előfeltétel: a környezeti fájl isg_cfg_ értékei ki vannak töltve; ahol egy hiányzik, a role megnevezi és megáll
• Siker jele: failed=0; a verify visszaméri a jogosultságokat (0600 / 0644 / 0700), a titok-párok egyezését, és azt, hogy a sablonok check-módú újrarenderelése nem változtat semmit

2. A gépek ellenőrzése — playbooks/preflight.yml

Csak olvasó előfeltétel-ellenőrzés: telepíthetők-e a gépek? Hosztonként egy táblázat — a become, az OS, az óra, a névfeloldás, a csomagforrás, az admin-lista, a szabad hely és az eszközök. Semmit nem változtat.

• Hol fut: minden flotta-gép
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/preflight.yml
• Előfeltétel: a gépek futnak és elérhetők
• Siker jele: minden hoszton 0 FAIL. A firewalld WARN-ja a 3. lépés előtt elfogadott: a firewalld telepítése és indítása a tűzfal-baseline dolga, a preflight csak jelenti. Hogy a WARN is buktassa a futást, arra van kapcsoló

3. A flotta telepítése — playbooks/site.yml

A telepítés. Minden role egyetlen futásban, kötött sorrendben (lent felsorolva). Minden role a végén a saját verify-ját futtatja.

• Hol fut: minden flotta-gép
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/site.yml — és a -e isg_config_src_dir= a config-forrás útjával
• Előfeltétel: az 1. lépés (a config-forrás) és a 2. lépés (preflight, 0 FAIL); és egy, a vezérlőn a repóból épített gateway-bináris (make build) — a gateway-role a telepítés előtt megáll, ha a bináris verziója nem a repó git describe-ja. A szándékos eltérést ki kell mondani az isg_binary_expect_version-nel
• Siker jele: failed=0, és a második futáson changed=0 — így mérjük a telepítés idempotenciáját, nem külön lépésben. Zöldmezőn az (A) play az elsődleges brókeren ca init-tel hozza létre a közös CA-t, és maga gyártja a vezérlő CA-seedjét: a seed megléte nem előfeltétel

4. A brókerek közös címének felhúzása — playbooks/keepalived.yml

A brókerek közös címe: aktív-passzív VIP keepalivedből, és annak mérése, hogy a VIP-nek pontosan egy gazdája van.

• Hol fut: brókerek
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/keepalived.yml
• Előfeltétel: a 3. lépés zöld — a VIP a brókerek zöld telepítése után kerül fel (a tűzfal-szabálya viszont már a 3. lépésben a helyén van)
• Siker jele: failed=0; a flottán pontosan egy gazda. A failover-próba kézi, jegyzőkönyvezett lépés, és szándékosan nem a verify része

5. A telepítés auditja — playbooks/verify.yml

Audit-mód: csak a role-ok verify task-fájljai, változtatás nélkül. A dokumentáció acceptance-szakaszait méri; minden assert megnevezi a szakaszt, amit sért.

• Hol fut: minden flotta-gép
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/verify.yml
• Előfeltétel: a 4. lépés
• Siker jele: failed=0 és changed=0 (a csak olvasó parancsok --check alatt is futnak)

6. A termék öndiagnosztikája — isg system check (nem playbook)

A termék saját, daemon-mediált öndiagnosztikája a brókeren: a telepítés utolsó szava nem az Ansible-é, hanem a terméké. A vezérlőről, operátorként futtatva a kimenet alapból színtelen — egyetlen SSH-hívásba írt távoli parancs nem foglal távoli terminált, a csövezett alak pedig szándékosan a monitoring által parse-olható forma. Színhez vagy foglalj terminált (ssh -t), vagy kérd kimondva (--color=always); utóbbi naplózott, nem interaktív futáshoz is jó, és a szín nem hozza magával a sortördelést.

• Hol fut: bróker (operátorként)
• Parancs: — (a termék parancsa, nem playbook)
• Előfeltétel: az 5. lépés
• Siker jele: a kilépési kód 0, és a „Measured by the daemon" fejléc alatt egyetlen FAIL sor sem áll

Amit a site.yml tesz, sorrendben

A playbook saját fejléce a sorrend indoklását is hordozza; a lenti lista magát a sorrendet.

1. perzisztens systemd-journal minden hoszton (baseline, saját előfeltétele nincs);
2. tűzfal-baseline — benne a VIP VRRP-szabálya, aminek a keepalived előtt kell állnia, különben az első hirdetést a társ tűzfala eldobja, és mindkét gép MASTER lesz;
3. megosztott tár (Postgres / RustFS / OpenBao — a brókerek erre épülnek);
4. OpenBao init/unseal — ha a környezet kimondta; egy friss gépen a tár-play e nélkül szándékosan pirosan állna meg a nem inicializált vagy zárt tárolón;
5. címtár, identitás-szolgáltató és levél;
6. az identitás-szolgáltató TLS-kibocsátója a brókerek OS trust-store-jába — szándékosan a bróker- és gateway-playek előtt. Az identitás-szolgáltató tanúsítványa a fenti lépésben áll elő; az a bróker, ami ezt a kibocsátót még nem ismeri, a termék öndiagnosztikájának SSO-során x509: certificate signed by unknown authority-vel bukik, és mivel a gateway-role saját verify-ja ezt a sort méri, a gép minden későbbi playből kiesik — az alábbi SSO-szállításból is. A kibocsátó előbb szállítása a gateway verify-ját pontosan olyan szigorúnak hagyja, amilyen volt. Zöldmezőn itt semmi nem indul újra: a daemont a következő play indítja el, már az új bizalommal;
7. E1 brókerek (A) — az elsődleges bróker bootstrapja. A közös CA valakinek elsőnek kell legyen, és azt a gateway-role ca init-je hozza létre: zöldmezőn az elsődleges CA-ja itt születik, és ez a play gyártja a vezérlő CA-seedjét is (a bróker-role tölti fel oda). A seed tehát nem előfeltétele ennek a lépésnek, hanem az eredménye. A szerepet az isg_e1_primary mondja ki (isg_gateway_ca_primary); ha az elsődlegesen nincs CA, de a vezérlőn már van seed, a play hangosan megáll — az egy újraépített elsődleges, ahol egy friss ca init második CA-t verne;
8. E1 brókerek (B) — az összes bróker, a CA-seeddel (az elsődlegesen ez a futás már changed=0);
9. gateway (az izolált-CA elrendezés, a unit);
10. SSO-konfig szállítása a brókerekre (OIDC vagy SAML 2.0);
11. break-glass napló-fogadó a brókereken (rsyslog-fogadó a 20514-es TCP-porton, minden brókeren) — szándékosan minden olyan play előtt, ami egy célgépet forwardolásra bírhat. Abban a pillanatban, ahogy a break-glass baseline felkerül egy célgépre, annak az rsyslogja küldeni kezd; egy olyan portra küldött sort, amin senki nem hallgat, a küldő retry-queue-ja eldobja, és az egyetlen tünet egy hetekkel későbbi „nem mért" figyelmeztetés lenne. A saját playén belül a tűzfal nyílik legutoljára, ugyanezért: mire a szabály felkerül, a fogadó már felveszi az első sort;
12. célgépek — a gateway publikus CA-kulcsát és a gateway-en kiadott host-certet kapják, ezért ez a sorrend nem cserélhető; ha a gateway még nem jutott el a CA-ig, a célgép-play a gateway-t és a pontos utat megnevezve áll meg, nem egy névtelen fájlhibával;
13. break-glass B baseline a célgépeken;
14. node-exporterek minden flotta-gépen, majd a monitoring-stack (megfigyel, nem előfeltétel, ezért ez az utolsó).

Lebontás

A bontás a felépítés fordítottja. Az alábbi egy playbook a termék-role-okat veszi vissza, és a saját kapcsolóival megy.

A parancs abban az alakban áll, amit az automatika saját referenciája hordoz — a referencia-környezetében, az inventory-fájlját kimondva. Magát a futást a referencia-környezetben még nem mértük meg; az inventoryt és a környezetnevet a fentiek szerint helyettesítsd a sajátoddal.

playbooks/remove.yml

A termék-role-ok visszavétele, a telepítés fordított sorrendjében — azzal a kivétellel, hogy a legelső play a brókerek VIP-je: a szolgáltatás címe menjen le, mielőtt a brókerek bomlani kezdenek. Az állapot (a CA-kulcs, az audit-napló, a felvételek, a tár adata, a fiókok, a monitoring adata) alapból marad, és a playbook ezt futás közben kiírja. A perzisztens journal és a napló a purge-öt is túléli.

• Hol fut: minden gép
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/remove.yml — végleges törléshez ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/remove.yml -e isg_purge_state=true
• Előfeltétel: a termék oldalán semmi; ha maguk a gépek is bontásra kerülnek, az ez után jön
• Siker jele: failed=0, a második futáson changed=0, és zöld verify_absent mérés

Üzemeltetési runbookok

Ezek a playbookok nem telepítési lépések: egy már létező környezeten futnak. Minden parancs kimondja az inventoryját: az automatika alapértelmezett inventoryja hermetikus, gép nélküli, tehát egy elfelejtett -i nem találhat el élő gépet. Ahol a futást a referencia-környezetben még nem mértük meg, azt a playbook alfejezete kimondja.

Azok a playbookok, amelyeknek a neve -check.yml-re végződik, egyik lista lépései közt sem állnak. Ők az automatika saját hermetikus kapui: a vezérlőn futnak, gép nélkül, és a role-ok logikáját mérik.

playbooks/bao-init.yml

Ugyanaz a role, amit a site.yml a tár-play után futtat, önmagában. A tipikus eset az újraindulás utáni unseal: a tároló minden indulásakor zárva jön fel (reboot, crash utáni újraindítás, konfigváltozás), és amíg nincs nyitva, a brókerek sem aláírni, sem TOTP-titkot olvasni nem tudnak. A vezérlő init-fájljából nyitja, kulcs nélkül a parancssoron.

• Hol fut: tár-hoszt
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/bao-init.yml — és a -e isg_config_src_dir= a config-forrás útjával
• Előfeltétel: a site.yml már inicializálta a tárolót (az init-fájl a vezérlőn van)
• Siker jele: failed=0, a tároló nyitva. Már inicializált tárolót nem inicializál újra, és meglévő init-fájlt vagy bróker-tokent nem ír felül — mindhárom hangos megállás

playbooks/sso.yml

Az SSO-konfigot szállítja a brókerekre — OIDC-t a kliens-titkával, vagy SAML 2.0-t (protocol: saml, titok nélkül) —, majd újraindítja a webUI-t és megvárja a daemont. A role nem generál konfigot: a forrás az operátoré. Az identitás-szolgáltató oldala kézi lépés, mert a role az IdP-t nem éri el: OIDC-nél minden bróker átirányítási URI-ját fel kell venni a kliensbe; SAML-nál az IdP-nek a szolgáltató (SP) entity ID-ja és az assertion-fogadó URL-je kell (/login/sso/saml/acs), mindkettőt az ISG az SP-metaadatában teszi közzé (/sso/saml/metadata). SAML-lal csak a webes belépés megy az IdP-n át: a parancssor jelszó és az ISG második faktora marad (cli: off), mert a SAML-nek nincs device flow-ja.

• Hol fut: brókerek
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/sso.yml — és a -e isg_config_src_dir= a config-forrás útjával. A referencia-környezetben mindkét protokollal mérve (2026-10-18), mindkétszer élő webes belépéssel
• Előfeltétel: a config-forrás sso/ alkönyvtára ki van töltve
• Siker jele: failed=0, a második futáson changed=0; a verify a fájlokat, a visszatérési címet (az OIDC átirányítási URI-t vagy a SAML assertion-fogadó URL-t — ez a brókeré) és azt méri, hogy a termék öndiagnosztikájának két SSO-sora (sso.yaml és SSO (OIDC) vagy SSO (SAML)) közül egyik sem FAIL

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

playbooks/monitoring.yml

A monitoring önállóan: előbb a node-exporterek minden flotta-gépen, aztán a stack a monitoring-hoszton (a stack verify-ja minden targetet futóként vár, tehát az exportereknek előbb kell futniuk).

• Hol fut: flotta és monitoring-hoszt
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/monitoring.yml — a referencia-környezetben még nem mért
• Előfeltétel: a stack titkai a config-forrás monitoring/ alkönyvtárában
• Siker jele: failed=0, a második futáson changed=0. Az első futás a kézzel felhúzott konténereken megáll, és kiírja az átvétel kapcsolóját

playbooks/upgrade-rolling.yml

Gördülő frissítés drainnel, brókerenként: egy bróker egyszerre, és ha egy bróker elbukik, a következő nem indul. Az előfeltétel-kapuk a drain előtt futnak — verzió-távolság, a flotta többi tagjának állapota, a gateway-role bemenetei —, hogy semmit ne draineljünk egy eleve bukó futásért.

• Hol fut: brókerek
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/upgrade-rolling.yml — és a --limit egy brókerrel futásonként és a tár-hoszttal (a futás előbb az OpenBao ACL-policyt hozza a kiadás szerinti állapotra, mielőtt bármelyik bróker újraindulna; ha a tár nincs a limitben, a drain előtt megáll), valamint a -e isg_config_src_dir= a config-forrás útjával; a megengedett verzió-távolság átlépéséhez -e isg_upgrade_allow_skew=true. A referencia-környezetben még nem mért
• Előfeltétel: a vezérlőn a repóból épített bináris (make build) — a role a drain előtt megáll, ha a bináris verziója nem a repó git describe-ja (régi artifactra visszalépéshez azt a verziót ki kell mondani az isg_binary_expect_version-nel); és zöld flotta
• Siker jele: failed=0; a telepített verzió a vezérlőé, a termék öndiagnosztikája 0-val tér vissza, a drain eltűnt, és a readiness-végpont 200-at ad

playbooks/backup.yml

A megosztott tár mentése. A mentés maga a repó mentő-szkriptje — egy forrás, ugyanaz, amit a fejlesztőgép-mentés is hív: a playbook felviszi a tár-hosztra, a store-userként lefuttatja, az archívumot a vezérlőre hozza, és ott méri, hogy az, aminek mondja magát.

• Hol fut: tár-hoszt és vezérlő
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/backup.yml — és a -e isg_config_src_dir= a config-forrás útjával (a tároló tokenje ott áll); a root nélküli futáshoz a -e isg_backup_become=false, ahol a tár-oldali lépések a becsatlakozott ssh-felhasználóként dolgoznak, nem a rooton át
• Előfeltétel: a token-fájl létezik, és a raft-snapshot képességgel bír; a root nélküli futáshoz az ssh-felhasználó maga a tár-felhasználó (az első lépés ezt id -un-nel megméri, és megáll, ha nem az)
• Siker jele: failed=0; az archívum listája hordozza mind az öt kötelező tagot, és a kicsomagolt tartalom ellenőrzőösszegei egyeznek a manifesttel

playbooks/backup-schedule.yml

Ezt a mentést ütemezi a vezérlőn. Egy systemd user timert telepít — nem cron-sort —, hogy a futások nyoma a naplóban legyen, és hogy egy futás, amit a gép átaludt, utólag behozódjon. A timer a mentést root nélkül futtatja: egy ütemezés csak így létezhet, mert egy felügyelet nélküli futástól nem lehet sudo-jelszót kérdezni, a mentés tár-oldali lépései viszont amúgy is a tár-felhasználó saját fájljain dolgoznak. A timer egy külön, kiadott tagre rögzített git worktree-ből fut, mert ezen a vezérlőn a fő munkafa a fejlesztői fa is — enélkül az kerülne a tár-hosztra, ami hajnali háromkor épp ki van checkoutolva. Ez a playbook mentést magától nem indít: az első futás a timeré.

Egy második timer a legfrissebb mentés korát méri. Naponta 09:00-kor lefuttatja a playbooks/backup-age.yml-t, ami a vezérlő mentés-könyvtárában a legfrissebb archívum nevének UTC-bélyegét olvassa. 26 óra fölött — vagy ha archívum egyáltalán nincs — levelet küld az isg_cfg_upstream_notify_to címzettjeinek a meglévő SMTP-úton, és a saját futása piros. A 26 óra egy sikeres éjszaka (09:00-kor hat óránál fiatalabb archívum) és egy kimaradt (közel 30 órás) közé esik, így a riasztás még aznap reggel megjön. Amit nem fog meg: az álló vezérlőt, vagy a lingerét vesztett user-managert — akkor ez a mérés sem fut, és azt csak egy külső figyelő látná.

• Hol fut: vezérlő
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/backup-schedule.yml — és a -e isg_config_src_dir= a config-forrás útjával, valamint a -e isg_backup_schedule_worktree= a worktree útjával és a -e isg_backup_schedule_ref= a taggel, amin áll; az ütemezés levételéhez (mindkét timer) -e isg_backup_schedule_state=absent. A referencia-környezetben még nem mért
• Előfeltétel: a vezérlő-felhasználónak van lingere (loginctl enable-linger — enélkül a user-manager, és vele a timer, kijelentkezéskor leáll), a tár-hoszt ssh-agent nélkül is válaszol (a timernek nincs), a mentés-token fájlja a helyén, a tag létezik helyben, és az isg_cfg_upstream_notify_to legalább egy címzettet megnevez (különben a telepítés megáll)
• Siker jele: failed=0; mindkét timer enabled ÉS active, és a futás kiírja, mikor szólalnak meg legközelebb. Egy mentés kézi indítása: systemctl --user start isg-backup-env1.service; a naplója journalctl --user -u isg-backup-env1.service. A kor-mérés kézzel: systemctl --user start isg-backup-age-env1.service

playbooks/backup-restore-drill.yml

Visszaállítási drill: az RTO mérése eldobható példányokban. Egy kész archívumot állít vissza a tár-hoszton, friss konténerekbe, és megméri a részidőket. Az élő példányokhoz nem nyúl: assert az elején, hogy a drill-nevek nem az élők, és a végén, hogy az élő unitok aktívak.

• Hol fut: tár-hoszt
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/backup-restore-drill.yml — alapból a mentés-könyvtár legfrissebb archívuma; máshoz a -e isg_drill_archive= az archívum útjával. A referencia-környezetben még nem mért
• Előfeltétel: egy kész archívum a vezérlőn, és a tároló init-kimenete (csak a drillhez)
• Siker jele: failed=0; a visszaállított adatbázis sor-számai egyeznek a manifesttel, a tároló mount-listája a helyén, és az összefoglaló kiírja a három RTO-részidőt

playbooks/ca-rotate.yml

CA-kulcs rotáció öt fázisban, operátori kapukkal. Minden fázis a saját tag-jével fut, és a végén kiírja a következő pontos parancsát — a fázisok között ember dönt (a kettős-trust ablak addig marad nyitva, amíg a 4. fázist el nem indítod). Tag nélkül a play mind az öt fázist egyben viszi: csak eldobható környezetben.

• Hol fut: gateway és célgépek (a vault-ágon a brókerek)
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/ca-rotate.yml --tags phase1; a 2–5. fázis ugyanez a parancs a saját tag-jével és a -e isg_ca_rotation_id= a rotáció azonosítójával, amit az 1. fázis kiírt. A 3. és a 4. fázis között make ansible-cert — a transzport certje már az új CA-val. A referencia-környezetben még nem mért
• Előfeltétel: az 1. fázis zárt-halmaz kapuja zöld: nincs árva élő cert a régi CA alatt
• Siker jele: fázisonként failed=0, és a fázis végén kiírt következő parancs. A 4. fázis mérése: a régi CA certje elutasítva, az újé belép

playbooks/verify.yml (absent)

Ugyanaz az audit-mód, de az eltávolítás mérésére: a role-ok verify_absent task-fájljai.

• Hol fut: minden gép
• Parancs: ansible-playbook -i inventory/env1.ini -e isg_env=env1 playbooks/verify.yml -e isg_state=absent — a referencia-környezetben még nem mért
• Előfeltétel: a remove.yml lefutott
• Siker jele: failed=0 és changed=0

A telepítés után: első lépések

A telepítés akkor kész, amikor a fenti 6. lépés zöld. Ez a szakasz annak szól, aki ezután elsőként kipróbálja a flottát: mi kell egy kliensgépre, hogyan zajlik az első belépés, egy jóváhagyásra váró parancs, és hol érhetők el a flotta böngészős komponensei. Az alábbiakban a <public name> a brókerek közös neve (isg_e1_public_name), amelyen a közös cím válaszol.

Ami a kliensre kell

A kliens lehet Linux vagy Windows; a feltételek ugyanazok.

• OpenSSH-kliens. Linuxon a disztribúció OpenSSH-kliens csomagja. Windows 10-en és 11-en a beépített OpenSSH-kliens (opcionális Windows-szolgáltatás), PowerShellből vagy parancssorból.

• Névfeloldás a közös névre. A brókerek host-tanúsítványa és a webUI tanúsítványa is a közös névre szól, ezért a kliensnek ezen a néven kell elérnie a brókereket — DNS-ből, vagy egy sorral a hosts-fájlban. IP-címre az SSH-kliens és a böngésző egyaránt figyelmeztet.

• Egy @cert-authority sor a known_hosts-ban. Minden bróker az ISG CA által aláírt SSH host-tanúsítványt mutat fel, a principáljai között a közös névvel, így egyetlen sor mindegyiket hitelesíti:

  @cert-authority <public name> <a CA publikus kulcsa>
  

  A CA publikus kulcsa az, amit az isg ca pubkey kiír egy brókeren (ugyanaz, mint a $ISG_HOME/pub/ca_key.pub). A sor nélkül az első belépés feltesz egy „megbízol-e ebben a kulcsban" (TOFU) kérdést — és mivel minden brókernek saját host-kulcsa van, egy későbbi belépés, amely a közös név mögött egy másik brókerre jut, megváltozott host-kulcsra figyelmeztet; pontosan erre figyelmeztetne egy valódi közbeékelődő támadás is. Ha valaki egy brókerhez a saját nevén is kapcsolódik, azt a nevet vegye fel a sor vesszővel elválasztott host-listájára.

• A böngésző bizalma a webUI-ban. Alapértelmezésben a webUI tanúsítványát az ISG X.509 CA adja ki: ennek a CA-nak a tanúsítványát ($ISG_HOME/pub/x509_ca_cert.pem egy brókeren) importálni kell a kliens tanúsítványtárába. A tls.yaml-lal a tanúsítvány máshonnan jön: az ügyfél PKI-jából, amelyben a kliens rendszerint már megbízik, vagy — az isg_config_src_pki_enabled kapcsolóval — a környezet saját gyökeréből (pki/root.crt a config-forrásban), és ekkor ez az egyetlen tanúsítvány, amit a kliensre importálni kell. A tanúsítvány minden esetben a közös névre szól, nem a brókerek saját nevére.

• A második faktor. A mfa.yaml mfa_mode beállításától függően: hitelesítő alkalmazás (totp, egyszer regisztrálva az isg mfa enroll-lal), a kódot fogadó postafiók (email), vagy bármelyik a kettő közül (totp-with-email-fallback).

Az első belépés

ssh isg-login@<public name>

A gateway ebben a sorrendben kérdez: Target host, Username, Password, MFA code. Ha a parancssori SSO be van kapcsolva (sso.yaml, cli: optional), az üres jelszó helyette az identitásszolgáltató device flow-ját indítja — mindkét utat az identitások, csoportok és zárolás lap írja le.

A hozzáférési döntés az MFA-kód UTÁN jelenik meg, nem előtte. Aki minden kérdésre válaszolt, azt is elutasíthatja a gateway — no_matching_rule okkal, ha egyetlen human_access szabály sem engedi arra a gépre. Ez a hozzáférési modell működése, nem sikertelen belépés.

Az első parancs és egy jóváhagyás

A belépés után minden parancs külön házirend-döntés és külön audit-bejegyzés. Az a parancs, amelyre egy require_approval szabály illeszkedik, még nem fut le: a kérés megjelenik a webUI-n (https://<public name>:8765/), és a kérelmezőtől KÜLÖNBÖZŐ személy dönt róla — a saját kérését senki nem hagyhatja jóvá. A kérés a szabály timeout_seconds értékéig vár (alapértelmezésben 300); a döntés nélküli kérés lejár, és a parancs nem fut le (hibaelhárítás).

A teljes kör kipróbálása: lépj be a webUI-ra egy második, jóváhagyásra jogosult felhasználóval (approver_group), dönts a kérésről, majd keresd meg a munkamenetet az admin nézetben. Egy interaktív munkamenethez ott terminál-felvétel is tartozik, visszanézhetően.

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

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

Böngészős komponensek

A portok a role-ok alapértékei. Jelszó soha nem jelenik meg lapon vagy parancssorban: a tábla a config-forrás (isg_config_src_dir, a vezérlőn) azon fájlját nevezi meg, amelyik tartalmazza.

• A Prometheust egyedül a tűzfal védi. A Grafanához hasonlóan a portja csak az admin-források (isg_net_admin_sources) felé nyitott. A Web Access-szel (lent) mindkettő az ISG-belépés mögé kerül.
• Az objektum-tárnak nincs böngészős felülete. A RustFS hoz konzolt, de a role a portját (9001) nem publikálja, és a tűzfalon sem nyitja: a telepítésben semmi nem használja. A tárat az S3-API-n (9000) egyedül a brókerek érik el.
• Az OpenBao-nak nincs böngészős felülete. A UI-ja ki van kapcsolva (isg_shared_store_bao_ui), a portja (8200) csak a brókerek felé nyitott. A root tokenje a vezérlőn álló init-fájlban van (isg_bao_init_file), offline.
• Az identitásszolgáltató admin-konzolja az ügyfél identitásszolgáltatójáé, nem az ISG-é.
• A mellékelt címtár-hoszt. Ha a flotta a mellékelt címtárat futtatja (az isg_directory role), a feltöltött felhasználók jelszavai a config-forrás directory/users.env fájljában vannak. Az ügyfél saját címtáránál a jelszavak az ügyfélé.

Web Access: webes konzolok az ISG-belépés mögött

A Web Access a webes konzolokat — Grafana, Prometheus, egy levélgyűjtő, egy BMC API-ja — ugyanazon belépés, csoportok, jóváhagyások és audit mögé teszi, mint az SSH-t. A szállított Ansible-ben a kapcsoló az isg_cfg_apps: a playbooks/config-src.yml megírja az apps.yaml-t és a listener tanúsítványát, a playbooks/site.yml kiviszi őket, és a brókerek az isg_apps_port-on figyelnek (alapból 8444). Minden, ami hozzá tartozik — az Ansible-változók, a listener, a DNS, a három identitás-mód, a webUI-n felvett alkalmazások — a Web Access szekcióban áll: alkalmazások beállítása, Web Access-policy és egy webes konzol előkészítése.