Vlákno názorů k článku Linuxu chybí univerzální konfigurační systém od Jan Molič - Nejde mi o konkrétní ukládání konfigurace, jestli do...
-
Jan Molič (neregistrovaný)Nejde mi o konkrétní ukládání konfigurace, jestli do XML nebo do čehokoli (snad prosím, jen ne LDAP :-D ) Jde mi o daemon, k němuž se budou připojovat konfigurační nástroje a tento daemon bude konfiguraci upravovat. Nikoli jako dnes, kdy konfigurační nástroje upravují konfiguráky přímo.
Používal jsem Gentoo, používal jsem GoboLinux, používal jsem Ubuntu. GNU/Linux mám rád, ale už jsem vyrostl z toho se v něm po večerech vrtat. Asi k tomu každý po nějaké době dojde, že ho přestane bavit opravovat banality, které opravoval již stokrát předtím. Jako že "to zase netiskne", "se to zase neuspává", "zase nefunguje opengl", atd. Dostane se do stavu, kdy chce počítač používat především k jiné práci než spravovat jeho samého. Proto si nakonec nainstaluje Ubuntu, neboť očekává, že se tam již nebude muset zabývat těmito banalitami.. Ale ouha, bude muset - a dohledávání problémů tam, je daleko obtížnější, než třeba v Gentoo.
Článek jsem napsal proto, že očekávám od distribucí typu Ubuntu právě tu spolehlivost, kterou, bohužel nenacházím. Měl jsem tu čest porovnat práci na Mac a jeho konfiguračních nástroje jsou prostě dobré. To neznamená, že chci na Mac přejít. Jen mě mrzí, že takovou spolehlivost nemám ve své distribuci, ačkoli by to bylo technicky možné. Místo toho nacházím uživatele, kteří mi poradí "tak používej vi". Super. Takovou reakci ale považuji jenom za bagatelizaci jasného problému. Řešení existuje, ale shazováním věcí ze stolu se nic nevyřeší. -
Ten problém se nevyřeší bagatelizací a nevyřeší se ani debatou. Nevěřím, že by se dal vyřešit jednotně, přechodem na jiný formát. Na to už jsou velké distribuce příliš rozšířené. Docela dobře si ale dovedu představit, že bych měl ke každému konfigu soubor s metadaty, který by popisoval skutečné umístění konf souboru, jeho metadata, jazyk, případně validační skript. Nad těmito soubory už by mohl běžet démon který by vytvářel hierarchickou souborovou strukturu, třeba
/aplikace/klic/hodnota .. jako je proc, který mi přijde úžasný.
Postupem času bych měl metacfg k MySQL, PostgreSQL,Apachi, a pár dalším aplikacím. To by bohatě stačilo. Kolik se reálně edituje konf. souborů. Nejsem admin. Ale je jich míň než 20. Nad tím už by se mohla vybudovat další vrstva. A nebylo by to ani tolik práce. A je to docela i v Unix duchu. Nevím jestli to přišlo od tebe - virtuální filesystem nad konf. mi přijde jako super nápad. Je to krok vpřed, ale neblokuješ zkušené uživatele. -
Jan Molič (neregistrovaný)Nechci přecházet na XML / LDAP / cokoli. Pro mne je podstatné, aby konfigurační nástroje v GUI neupravovaly konfiguraci přímo, protože ta může být fyzicky uložena různě (text. soubory, XML, LDAP). Co tu právě chybí, je ta mezivrstva mezi fyzickou konfigurací a GUI. Také si myslím, že to je reálné, že těch konfiguráků není zase tolik. A samozřejmě by bylo nejlepší, kdyby se to udělalo co možná nejunixovější cestou, takže bych se nebránil tomu, aby ten daemon vytvářel jakýsi virtuální systém nad fyzickou konfigurací, která, ještě jednou opakuji, může být uložena jakkoli a kdekoli.
-
Naprosto rozumím. Docela by to zjednodušilo tvorbu klikacích dialogů, který by se staraly opravdu jenom o vykreslení obrazovky, a odpadlo by parsování a zápis, což může být 80-90%. Teď to jenom napsat :). Docela mne by to zajímalo, jak by takový meta soubor vypadal pro pg, s FUSE by to nemuselo dát až tolik práce.
-
Jan Molič (neregistrovaný)Vpodstatě těmi tvými metadaty jsem myslel moduly konfiguračního systému. Jejich součástí by totiž měly být i skripty, díky nimž by šlo nejen editovat jednotlivé parametry, ale provádět i celé složité akce. S tím virtuálním filesystémem by to bylo opravdu výborné, například
echo "domena.cz" > /setup/apache/add_virtualhost echo 1 > /setup/apache/reload if cat /setup/apache/virtualhosts | grep "domena.cz"; then echo ok ; else echo fail;
Totéž by mohl provést člověk přes konzoli, GUI i TUI aplikace. Pokud by bylo možné připojit virtuální systém po síti, pak i na dálku. Vůbec bychom nemuseli vědět, že na jednom stroji bylo provedeno deset fyzických akcí, na jiném dvacet - záleželo by na použitém modulu, cesty ve virtuálním filesystému by byly identické. Daemon konfiguračního systému, by byl velice jednoduchým frameworkem, který by na základě registrovaných modulů pouze vyráběl virtuální filesystém a staral by se o vzájemnou komunikaci, řešil zachycování chyb, logování a podobně. Zejména to unifikované logování by bylo velkým přínosem. -
Jan Molič (neregistrovaný)Pokud by FS měl zprostředkovávat jen klíč-hodnoty, pak bychom, podle mě, brzy narazili, proto je nutné tam mít ještě ty podpůrné skripty. A ještě něco: ve zmíněném příkladu přidávání virtuální domény do apache, co kdyby se šlo ještě dál, a to tako? ;-)
# mkdir /setup/apache/virtualdomains/domena.cz # ls /setup/apache/virtualdomains/domena.cz aliases ip rewrite_rules access_rights
-
Nemuselo by to sloužit jen pro konfiguraci. Dovedu si představit, že bych tam mohl mít i monitorovací uzly:
postgresql/default/config/shared_buffers
nebo
postgresql/default/current_activity
postgresql/default/current_locks
případě
postgresql/default/mojedb/current_locks
a další
p.s. default ve smyslu instance .. přeci jen těch aplikací tam může běžet víc. Myšlenka je to hezká - a není vůbec daleko od Garudy jestli si vzpomínáš. -
Jan Molič (neregistrovaný)Přesně tak ;-)
cat postgresql/default/mojedb/current_locks
Prakticky si pod tímhle představuji, že daemon spustí nějaký skript z modulu, který je registrován pod klíčem "postgresql". Skript získá informace a vráti je daemonu zpět. Daemon je pak vystaví jako soubor current_locks na virtuálním FS. Ještě hezčí přístup by byl# ls postgresql/default/mojedb/current_locks/ # lock1 lock2 lock3 lock4 # cat postgresql/default/mojedb/current_locks/lock2
Pak je ovšem nutné vyřešit, aby šlo pracovat nejen s jednorázovými požadavky typu "zápis do souboru - čtení souboru", ale i se streamem, tj. stálým propojením vstupu a výstupu nějakého toho skriptu s položkou ve virtuálním FS. Taktéž je nutné vyřešit zamykání, protože při přístupu "zápis do souboru - čtení ze souboru" se může stát, že v mezidobí přijde jiný proces, který data přečte. Možností je víc, třeba uchovávat, který proces zapsal a jen ten by mohl přečíst (pak je ale problém s vlákny, to už by si asi proces musel řešit sám). Nebo duplikovat výstup pro víc "čtenářů", atd. Nebo by daemon mohl vyrobit unixový socket, ale to není úplně user-friendly a navíc by pak takový virtuální FS nešlo používat vzdáleně. -
"Jde mi o daemon, k němuž se budou připojovat konfigurační nástroje a tento daemon bude konfiguraci upravovat."
Což by vlastně znamenalo vzít jen systémovou část kcontrolu (nebo yast) a rozseknout ho na dvě části: knihovnu + GUI. Vedle GUI pro Qt by se dalo napsat i GTKčkové nebo webové. Neříkám, že by to nebyl pokrok, ale v podstatě by to byla jen hezká fasáda nad kopou sraček (současné různorodé konfiguráky). Ale nějaký užitek by to přineslo, o tom nepochybuji. BTW: ani by to nemusel být démon, stačila by knohovna, která by jednotlivé konfiguráky zpřístupnila jako objekty (v OOP) a front-endová aplikace by s nimi pracovala (četla hodnoty, nastavovala atributy, pole, další vnořené objekty...) -
zrovna toto uz existuje
http://openwbem.org/
a dalsi projekty o kterych jsem psal, to se mi docela dost libi, nicmene je fakt, ze se tyto projekty nijak zvlast neuchytily. -
O něco ještě jednoduššího, co by mělo šanci se rozšířit i mimo SuSE :). Jedna vrstva by neškodila. OOP nástroje sice vypadají elegantně, ale jejich výsledkem jsou mamuti. Někdo má rád rubby, další perl, python, C nebo bash - a jejich jediný jmenovatel je souborový systém - objekty jsou až o patro výš - přičemž dokážu vidět eleganci, preciznost WBEM nebo YaSTu. Ale z bashe to nepoužiju - už neskriptuji, už musím programovat :(
-
Rejpal (neregistrovaný)
SCR agenty AFAIK nejsou objektové. V podstatě se jedná o několik funkčních volání, z nichž některá přijímají cesty podobné CIMu. Nevidím kupříkladu zásadní problém v tom, aby z Bashe šlo přistupovat přímo k SCR. V úplně nejhorším případě se do Bashe dá načíst malá dynamická knihovna, ale samotné SCR agenty by měly být samostatné programy, které lze patřičným způsobem spustit z čehokoli. (Z hlavy tohle bohužel přesně neřeknu, musel bych se podívat, od které úrovně je standardizované jejich rozhraní, ale jak říkám, malá knihovna v Cčku načítaná do Bashe to jistí, to rozhraní nemůže být nijak složité.) Jak vidíte na uvedené stránce, po objektech (ve smyslu OOP) ani památky - zavoláte funkci a případně jí předáte nějaké ty parametry. :-) Pravda je, že na některých místech mohou nastat problémy, hlavně proto, že Bash nemá například hash tables. Některá SCR volání nevracejí jen skalární hodnoty, třeba agent pro .etc.passwd vrací "seznam slovníků" (v pythoní terminologii).
V současnosti je SCR agentů poměrně dost. Něco jsou věci specifické pro SUSE, ale spousta by jich asi fungovala všude out-of-the-box nebo jen s mírnými úpravami. V případě potřeby se dají dopsat další. Co agenty neošetřují, to je transakční vrstva. Ta je v hierarchii vrstev YaSTu trošku výše. Nicméně i tak mi přijde, že je to přinejmenším docela zajímavá inspirace. :-)
ČLÁNKY DO MAILU