Disklessová infrastruktura - administrace
V současné době leží vše ohledně konfigurace disklessové infastruktury na administrátorech.
Ti připravují základní systém a jednotlivé vrstvy. Testují chování sendviče a v kooperaci s vyučujícími rozhodují o tom, co se v laboratorním systému octne, odlaďují chyby, a případně doplňují potřebné funkcionality.
Tím se ovšem základní systém rozrůstá o další a další softwarové vybavení, které je nutné do budoucna udržovat (závislosti, licence, lokální úpravy, aj.) a při větším počtu instalací různých linuxových systémů v rámci disklessové infrastruktury je neúnosné spoléhat na to, že si to někdo bude pamatovat.
Bylo by určitě vhodné vytvořit (ideálně webový) konfigurátor, který byl ohlídal:
- Závislosti vrstev – linuxové distribuce mají svá specifika, proto by se měl navrhnout systém kódového značení, který by to usnadnil. Při instalaci (a zavedení) nového základního systému by se měl tento objevit jako další položka. U vrstvy by měla existovat možnost nastavit kladným či záporným číslem úroveň vrstvy – výchozí 0 (úroveň base systému), záporná (potenciálně konfliktní či nebezpečná vrstva, kterou je nutné posadit na nižší úroveň) a kladná (vrstva musí být na vyšší úrovni). Asi by to mělo vypadat jako rolovací seznam vrstev s checkboxy, generovaný na základě kompatibility s base vrstvou – pro každou base vrstvu samostatný seznam – ve kterém by se změnou pořadí vrstev měnilo také pořadí pro sendvič u cílové konfigurace.
- Jejich aktuálnost – záznam by měl obsahovat konkrétní údaj do kdy se má vrstva udržovat, kdo si ji vyžádal a kdo bude v budoucnu oprávněn rozhodnout o to, jestli se má vrstva zrušit, nebo ne. Platnost od – do + textová poznámka. Vrstva, které by vypršela platnost by se generovala v seznamech podbarvená rudě.
- Testovací vrstvy – vrstvy u kterých by platnost od předcházela aktuální datum – v seznamech by se podbarvovaly zeleně.
Mělo by jít o webovou aplikaci, běžící na vyhrazeném virtuálním stroji, který by měl přístup ke konfiguraci NFS serveru a exportovaným adresářům.
- Přístup může být pasivní (RO), ovšem pak by nebylo možné přes ni editovat soubory v
.desc
- Pokud by se přes ni měl nastavovat (a rušit) také NFS export či konfigurace DHCP, je třeba vyřešit vhodný mechanismus – jako ideální se mi jeví nějaký shellový wrapper (agent), se kterým by aplikace komunikovala přes ssh ověřované klíčem. Ten by mohl vkládat, komentovat či rušit záznamy v v konfiguračních souborech, a každou změnu pushovat do lokálního git repozitáře. Tím pádem by bylo snadné zjistit poslední změny i přes ssh konzoli, aniž by bylo nutné se přihlašovat přes web.
Schéma - návrh
- Karta DHCP – každá infrastruktura může používat jiný DHCP server a u některé ho může být mimo správu administrátora disklessové infrastruktury
- Karta Vrstvy – rodná karta vrstvy
- Vrstvy by se před toto GUI neměly zakládat, ale detekovat z nastaveného adresářového stromu na straně NFS serveru. Za vrstvu by se považoval první adresář s podadresářem .desc
- Typ vrstvy určený číslem, by určoval její prioritu v rámci sendviče. Base vrstva vždy 0. Záporné číslo by měly aplikační vrstvy které nespravuje administrátor infrastruktury. A kladné číslo by měly vrstvy konfigurační a aplikační spravované administrátorem.
- Závislost vrstvy na base systému – roleta s base vrstvami (s hodnotou 0) a checkboxy – ty zaškrtnuté by se braly jako kompatibilní.
- Období platnosti vrstvy, od – do. Vrstva, které by ještě nezačalo období platnosti by byla podbarvena zeleně. Naopak vrstva po období platnosti podbarvena rudě.
- Popis vrstvy, by se natahoval z adresáře
.desc
- Karta Sendviče – Sendvič zástupné jméno pro konfigurační soubor, se kterým by se pracovalo v kartě PXE.
- Sendvič tvoří jedna base vrstva + vrstvy konfigurační a aplikační. Podle typu overlaye (aufs či overlayfs) by se natahovaly příslušné init skripty, které by bylo možné individuálně v rámci karty PXE u sendviče vypínat.
- Karta PXE – hotové sendviče nabízené přes PXE
- Sendvič by bylo možné přiřadit buď na základě hostname, IP, brány nebo skupiny.