Vlákno názorů k článku Linuxu chybí univerzální konfigurační systém od David Jaša - Celé je to utopie, pokud jednotlivé konfigurační moduly...
-
David Jaša (neregistrovaný)Celé je to utopie, pokud jednotlivé konfigurační moduly nebudou psát sami upstream autoři programů a standardizace API se nechytne někdo jako freedestop.org nebo Linux Foundation. Dost věcí k tématu bylo řečeno už v tomto flejmu - doporučuju vyhledat příspěvky uživatelů Michal Kubeček, unchallenger a twofish.
-
David Jaša (neregistrovaný)Fakt, růtí RS mě nechal poslat prázdný odkaz, to jsou mi věci...
http://www.abclinuxu.cz/zpravicky/show/70303 -
Jan Molič (neregistrovaný)Toho se chytnou, ale až tehdy, bude-li čeho se chytnout. Položky ve virtuálním adresáři /sys jsou často taky spíš "evolucí" a teprve, ukáže-li se, že jsou často používány, pak jsou někam přemístěny a přejmenovány.
Byl bych rád, kdyby ty moduly psali především autoři programů sami, ale platí totéž - dokud nebude ten daemon (framework) pro jejich psaní, nebudou je psát.
A pro tvůrce konfiguračního daemonu zase platí, že je fajn, když se rozvine diskuse, z níž nejdřív vyplyne, co vše by měl daemon umět. Nejhorší je pustit se do jeho programování hned a pak zjistit, že v některých případech je nutné ho "ohnout".
Ostatně, nejnutnější je udělat prototyp a pak se o něm pobavit :-D Už to mám v todo listu... Jo a varování: Jestli to někdo z Vás nenapíše dřív, pak se těšte, že to bude v Ruby :-D -
Jan Molič (neregistrovaný)Nemám nic proti C, přesto si myslím, že na prototypování je mnohem rychlejší skriptovací jazyk, který především umožňuje dělat změny rychle. Teprve tehdy, je-li vše ustáleno, je vhodné to přepsat do C. Taky pokud to má nějaký přínos.Nakonec, Ruby FUSE binding je knihovna v C, Ruby samotné je taky v C :-D
-
Pro prototyp cokoliv s FUSE bindingem vyjma C. Pro provoz vyhradne C. Minimalne pro klasicke konfiguraky (MySQL, Apache, Pg) je to z 80% o regularech si dovolim tipnout. A to by v C byla neskutecna otrocina - nehlede na to, ze jen import modulu ve scriptovacim jazyce je jeden include a v C relativne dost kodu, kdyz se to ma udelat poradne.
Jestli se nekam dostanes, dej vedet. Pridam ti podporu postgresu. -
Jan Molič (neregistrovaný)
Právě že ta svoboda jazyka je u modulů nutná, jakmile by měly být jedině v C, tak je většina lidí nebude umět napsat, ačkoli mohou být dobrými programátory. Osobně preferuji unixový přístup STDIN-STDOUT, a to zvláště proto, že by se tak moduly velmi dobře testovaly (třeba CUPS backendy jsou také běžné spustitelné soubory, které mají definované argumenty+vstup+výstup; když cups netiskne, je kolikrát fajn, že lze spustit backend ručně, případně i přes strace).
Pod pojmem "modul" myslím adresář, který by obsahoval jak spustitelné, tak nespustitelné soubory. Ty spustitelné by mohly být napsány třeba v C nebo by to mohly být i skripty (díky shebang hlavičce je to jedno). Jejich úkolem by bylo provádět akce na základě čtení či zápisu do virtuálního filesystému. Statické soubory by byly různá metadata.
Daemon by pak, podle přístupu do virtuálního filesystému, rozhodl, na který spustitelný soubor je virtuální cesta namapována, spustil by ten program a provázal jeho stdin/stdout s virtuálním souborem.
Daemon by se rozhodoval podle mapy "virtuální cesta - program". Tato mapa by mohla být definována jak ve statických souborech, tak i generována dynamicky - například pro virtuální cestu /setup/network/eth0. Ačkoli většina mapování by šla zvládnout regulárními výrazy.
Příklad:
cat /setup/pgsql/current_locks
- daemon se podívá do modulu zaregistrovaném jako "pgsql"
- modul obsahuje mapování na program "curlocks"
- daemon spustí program "curlocks", což je BASHový skript a prováže jeho stdin-stdout s virtuálním souborem "/setup/pgsql/current_locks" (program může virtuální cestu dostat třeba jako argument)
- program zpracuje požadavek a zapíše výstup na stdout
Někdo, kdo by měl jinou verzi Postgresu, by měl pod klíčem "pgsql" registrován odlišný modul. Též by provedl "cat /setup/pgsql/current_locks", ale odlišný modul by, samozřejmě, provedl jinou činnost.
---
Co se týče uživatelského rozhraní, o němž jsem psal, že by mohlo být generováno i automaticky, součástí modulu by tedy byla metadata pro tvorbu formulářů. Tento soubor by daemon exportoval stejně jako jiné soubory, třeba jako /setup/network/ui.xml. Záleželo by pak na aplikaci, zda definice využije nebo ne.
Zdá se mi, že to vlastně vůbec nebude složité ;-)
Ještě je nutné vyřešit zámky při přístupu do souborů, práva či stream (tj. že by program z modulu zůstal spuštěn a zpracovával by více požadavků, jako server). A určitě pár dalších věcí.
---
pozn. Proč by tohle nemohlo být tak, že by místo FUSE byly na těch místech přímo spustitelné programy? a) nebylo by to dynamické, b) nebylo by to použitelné přes síť
-
me se to FUSE libi. Je to docela dobry interface.
s cim bych si dovolil nesouhlasit jsou jednoucelove skripty. Chce to najit nejaky rozumny kompromis. Nebudu preci psat 50 skriptu pro 50 voleb postgresu. Pri monitoringu pak stejne vetsina uzlu v podstate odpovida jednomu sql dotazu a formatovani na text. Jinak moznost komunikace muze byt docela dobre prostrednictvim sys promennych. Pak radu tech skriptu muzes napsat v bashi. -
Jan Molič (neregistrovaný)Samozřejmě bys nemusel psát 50 skriptů. Klidně by šlo na 50 virtuálních souborů namapovat jediný skript. Jak jsem již někde psal, tento skript by virtuální cestu dostával například jako svůj argument. Systémové proměnné by též šly použít, aspoň by nebyly ty argumenty vidět v ps. Tímhle bych řešil dynamické cesty, jako je /setup/net/eth0/ip, kdy eth0 je zcela dynamická záležitost. Takový skript by řešil vše okolo sítě.
-
Ano s tím by se dalo souhlasit. Jenže mám takové obavy, zda by po tom až by skončila fáze "prototypování" nebylo příliž složité celý projekt převést. Nehledě na to do něj můžete zanést spoustu chyb. Ruby je sice napsaná v C, ale již je to další uroveň abstrakce nad ním. Mám obavu zda by, to bylo opravdu (v tomto případě) přínosem.
