Bug 703813 - use /var/lib instead of /etc

9.7.2013 09:40 | Přečteno: 1368× | linux/unix

Tohle mě hned poránu pobavilo v bugzille NetworkManageru: Bug 703813 - use /var/lib instead of /etc.

William Jon McCann [reporter] [developer] 2013-07-08 18:18:50 UTC

There is a new emerging FHS that recommends storing writable state/configuration data into /var/lib/<id> instead of /etc/<id>. It would be nice for NetworkManager to do that as well and to leave /etc empty by default.

Or even better, just read system defaults from /usr/lib/NetworkManager/* or compile them in and not need a configuration file at all by default.

V tuhle chvíli nehodnotím návrh samotný. Spíš mi přijde, že kluci tak nějak zkouší znovu protlačit nový standard (změnu standardu) tou cestou, že se před implementátory tváří, že je to jasná věc a doufají, že ho pak protlačí na základě existujících implementací nebo tak něco.

Pokud jde konkrétně o NetworkManager, tak na něm je zajímavé to, že skutečně na základě administrátorských požadavků konfiguraci jednotlivých spojení běžně zapisuje a poskytuje plné prostředky pro její zapsání skrze API NetworkManageru. Přesun konfigurací spojení do /var/lib by tak mohl za určitých dávat smysl i beze změn FHS.

Já ale požadavek chápu tak, že by měly zmizet i věci jako /etc/NetworkManager/NetworkManager.conf. Tedy cokoliv změníte v tom souboru, tak by se mělo dít až po nakopírování do /etc. Z mého pohledu je to práce navíc a bordel, ale třeba mě časem někdo přesvědčí, že je to skvělý nápad.

Já jsem byl odkojený na takových těch podrobně komentovaných konfiguračních souborech, kdy člověk nemusel otevírat ani dokumentaci a měl jsem za to, že podobnou cestou se bude ubírat serverová konfigurace NetworkManageru (aspoň to vyplývalo z toho, co Danové diskutovali na IRC).

Co dodat, snad jen... Let the flame begin!        

Komentáře

[Ondrej 'SanTiago' Zajicek]

Nevim, jak presne to popisuje FHS, ale intuitivne mi je rozdil jasny - software by nemel zapisovat do souboru v /etc s vyjimkou situace, kdy nabizi ulozeni konfigurace na explicitni uzivatelovu zadost. Pokud napr. software umoznuje zmenit nastaveni, ty zmeny jsou nepersistentni, a obsahuje 'save coconfiguration' polozku, pak je OK, pokud se to v takovem pripade zapise do etc, pokud ale (i treba uzivatelem iniciovane) zmeny vnitrniho stavu pri beznem provozu jsou implicitne persistentni, tak ukladani takoveho stavu patri do /var/lib .

[jemen]

+1

[kavol]

zdá se mi, že právě popisuješ rozdíl mezi "state" a "configuration" ... je-li pointou toho bugu stáhnout oboje do jednoho místa, tak tedy potěš koště a RMS nás ochraňuj před takovými prdelomysliteli

p.s. jinak nemyslím si, že by uživatel nutně vždy musel explicitně klikat na "save configuration", vytváří-li ji s cílem nadále ji používat, ale to je vpodstatě kosmetická záležitost

[xkucf03]

+1

[xvasek]

Přesně tak, jaká změna standardu? Tak se to přece dělá roky, pokud NetworkManager něco zapisuje do /etc, tak bych to hodnotil taky jako bug.

[pavlix]

Proč začínáš větu „přesně tak“, když pak píšeš něco, co se se slovy předřečníka vylučuje?

[xvasek]

Já jsem si myslel, že s ním souhlasím...

[pavlix]

Ondra explicitně zápis do /etc podmíněně schvaluje. Neřeší se tedy obecně jestli zapisovat, ale za jakých okolností zapisovat.

[xvasek]

Já čtu "by nemel zapisovat do souboru v /etc" (s výjimkami), na to píšu "přesně tak".

[pavlix]

Už se asi motáme jen ve formalitách, ale mě v tomto případě ty výjimky přijdou jako zásadní část sdělení.

[pavlix]

Podle této logiky by konfigurace připojení patřila jednoznačně do /etc. Současné API to prezentuje trochu nešikovně, ale z našeho pohledu se jedná o explicitní úpravu diskové konfigurace a příští release to redefinuje jako úpravu běhové konfigurace s uložením na disk (přičemž v API přibude úprava běhové konfigurace bez uložení na disk).

[Ondrej 'SanTiago' Zajicek]

Rekl bych, ze tady hodne zavisi na uzivatelskem pohledu (coz je trochu problematicke u demona, ktery jen nabizi API a o uzivatelsky pohled se staraji frontendy). Proste /etc je neco, jehoz editace muze vyzadovat nezavislou soucinnost od uzivatele (napr. premountovani z readonly do rw ci update verzovaciho systemu) a proto by kazdy zapis softwarem mel byt jasne explicitni z uzivatelskeho pohledu (osobne bych to tedy omezil spis jen na ty explicitni 'save configuration' z menu nez na pripady, kdy k ukladani konfigurace dochazi soubezne se zmenou chovani).

[pavlix]

a proto by kazdy zapis softwarem mel byt jasne explicitni z uzivatelskeho pohledu (osobne bych to tedy omezil spis jen na ty explicitni 'save configuration' z menu nez na pripady, kdy k ukladani konfigurace dochazi soubezne se zmenou chovani).

Zde ti musí být jasné, že to můžeš vůbec zkoušet jen u software, který má oddělenou běhovou a uloženou konfiguraci, tedy až u příštího vydání.

Na druhou stranu i tam se může frontend chovat různě. Například může ukládat implicitně a runtime-only konfigurace se může řešit zvláštním přepínačem. Na druhou stranu vždy je možnost si udělat frontend vlastní, pokud ten existující nevyhovuje.

[Ondrej 'SanTiago' Zajicek]

Zde ti musí být jasné, že to můžeš vůbec zkoušet jen u software, který má oddělenou běhovou a uloženou konfiguraci, tedy až u příštího vydání.

Ano. Pokud software tohle nema rozlisene a kazda uzivatelska zmena se automaticky zapisuje na disk, tak mi mnohem spis dava smysl vyuzit na to /var/lib .

[pavlix]

O tom by se dalo dlouze polemizovat a diskutovat, když se jedná pořád o jeden a tentýž software, jen různé následující pohledy:

1) Změny se dělají přímým zápisem administrátora do konfiguračních souborů. To je skutečně jedno z nejběžnějších použití, protože nativní konfigurační formáty.

2) Změny se dělají explicitně konfiguračním nástrojem prostřednictvím API.

3) Git prozradí, že příští verze už běhovou konfiguraci rozlišovat bude.

A teď ještě legrace se zpětnou kompatibilitou, kdy spousta nástrojů bude zůstávat u pohledu #1, mnoho dalších nástrojů půjde cestou pohledu #2 a pouze nové nebo nově předělané nástroje začnou využívat #3.

Nicméně jsi buď mírně změnil názor, nebo se mi zdá tvůj pohled mírně nekonzistentní, protože z pohledu API je odeslání konfigurace jednoznačně operací save, tedy přesněji řečeno operací save & commit. Debata je tak jako tak čistě akademická, protože při upstreamovém vývoji vždy platí aktuální směřování projektu, což je pohled #3.

[snajpa]

... because we can. A protoze resit takovyhle sracky je vzdycky jednodussi, nez jit a udelat neco poradnyho, co nekomu actually pomuze.

[w4rr10r]

Co bys čekal od McCanna?

[Mrkva]

Démony do /usr/lib/? Šmarja proč?!

[raist]

FHS, LSB - nastesti existujou distribuce, ktery tyhle kraviny neresi. Dodrzovat "standardy", ktery jsou prevazne z dilny komercniho RH ? Bez sirsiho konsenzu ? Proc, kdyz tu je BSD struktura, ktera funguje desetileti bez problemu ?

Lahudky typu slucovani /usr/(bin|sbin) s /(bin|sbin), zavadeni /run nebo presouvani systemove konfigurace z /etc nekam do p*ele musi pochazet od retarda bez hlubsich znalosti a souvislosti nebo systematickyho sabotera. Jinak si to vysvetlit nedokazu.

[chrono]

Najvtipnejšie na tom je to, že tí istí ľudia, čo o FHS občas tvrdia, že je to nepoužiteľné/zastaralé/... (keď z akéhokoľvek dôvodu majú potrebu FHS porušovať) občas práve FHS obhajujú iné svoje zmeny.

[Bedňa]

Já jsem byl odkojený na takových těch podrobně komentovaných konfiguračních souborech, kdy člověk nemusel otevírat ani dokumentaci

Textovú konfiguráciu som si zamiloval od začiatku používania Linuxu, čo nastavenie, to riadok, alebo viac popisu, nech idú s tými XML, databázovými a binárnymi sprostosťami. do hája. Ja ich nepotrebujem a budem im to mazať! A s radosťou :)

[xkucf03]

Jistě, není nad takového lahůdky v konfiguraci, hlavně že to není to ošklivé XML

[pavlix]

Za tohle nemůže nepoužití XML ale absence návrhu.

[xkucf03]

To taky, ale XML¹ by zpříjemnilo používání a možná by to autory víc trklo a donutilo navrhnout formát líp. I když i v XML jsem viděl dost nešťastně navržené formáty…

_{[1] nebo jiný formát, kde lze strojově čitelně specifikovat formát a existuje infrastruktura pro validace a transformace}

[pavlix]

Teorie o všespásnosti XML mě nudí, zvlášť když je vymýšlíš jen proto, abys XML zpětně podpořil. Konkrétní problém, na který narážíš XML neřeší.

[xkucf03]

GOTO 22

Je mi celkem jedno, jestli to bude XML nebo něco jiného, ale opravdu bych uvítal…

Psal jsem, že se jiným jazykům nebráním – jde mi o funkcionalitu, ne o konkrétní implementaci.

[Bedňa]

Myslel som niečo takéto

#  Focus windows by clicking
# ClickToFocus=1 # 0/1

#  Focus windows when application requests to raise
# FocusOnAppRaise=0 # 0/1

#  Request focus (flashing in taskbar) when application requests raise
# RequestFocusOnAppRaise=1 # 0/1

#  Raise windows when focused
# RaiseOnFocus=1 # 0/1

#  Multiple click time
# MultiClickTime=400 # [0-5000]

Aké jednoduché, že? Komu chceš cpať to svoje XML

[xkucf03]

Dokud je ta struktura takhle plochá (klíč-hodnota), tak je to jakž takž použitelné, ale jakmile se tam objeví vnořené struktury nebo vícepoložkové hodnoty (seznamy, množiny), tak narazíš na limity těchto „jednoduchých“ formátů.

Další věc je, že i tady by se mohlo hodit schéma (XSD, RelaxNG atd.), protože pak si můžeš pomocí nástroje zkontrolovat, že jsi nenapsal třeba true místo 1 (nebo yes, ano, TRUE, enabled, on atd.). Tady tu informaci můžeš vyčíst z komentářů (pokud tam jsou a jsou aktuální), ale není to strojově čitelné, nedá se to automaticky zpracovávat.

A do třetice: dokumentace oddělená od konkrétní instance¹ konfiguračního souboru a umístěná ve schématu se může aktualizovat² společně s programem a zobrazovat se při editaci – můžeš tak mít vždy aktuální dokumentaci od autorů softwaru + vlastní poznámky si připíšeš do komentářů v konfiguráku.

Je mi celkem jedno, jestli to bude XML³ nebo něco jiného⁴, ale opravdu bych uvítal:

• formát pro konfiguráky s jednotnou syntaxí napříč různými programy (viz výše zápis booleovských hodnot + řetězce, escapování, kódování, stromové struktury, seznamy atd.)
• strojově čitelnou specifikaci formátu konkrétního konfiguračního souboru: struktura, jednotlivé volby, datové typy, rozsahy hodnot, výčtové typy atd. + ke všemu strukturovaná dokumentace
• nástroj pro validaci dle specifikace
• nástroj pro případnou transformaci do jiných formátů (např. do XHTML pro uživatelsky přívětivé zobrazení)
• editor (použitelný v konsoli + případně i nějaký v GUI), který bude
  • napovídat možné volby
  • provádět validaci, abych hned viděl případné chyby
  • zobrazovat dokumentaci – najedu na řádek s nějakou volbou a třeba v pravém panelu uvidím, co se tím nastavuje a jaké jsou přípustné hodnoty

_{[1] která může pocházet třeba z nějaké historické verze daného programu, prošla rukama mnoha správců a možná i nějakými automatickými konverzemi/upgrady
[2]opravy chyb, upřesněný význam voleb v nové verzi programu, nové hodnoty výčtových typů, upravené rozsahy hodnot…
[3] zatím se jeví jako nejvhodnější kandidát
[4] vedle psal třeba Bystroushaak něco o Lispu, i když nevím, jestli je to to pravé pro konfiguraci – může to být třeba i něco na bázi INI souborů}

[Radek Miček]

XML – zatím se jeví jako nejvhodnější kandidát

Už se těším až v konfiguraci místo 2 * x + 3 objevím

<sum>
  <prod>
    <const>2</const>
    <var>x</var>
  </prod>
  <const>3</const>
</sum>

nebo místo regulárního výrazu zapsaného jako [A-Za-z][A-Za-z0-9]* najdu třeba

<concat>
  <union>
    <range from="A" to="Z" />
    <range from="a" to="z" />
  <union>
  <star>
    <union>
      <range from="A" to="Z" />
      <range from="a" to="z" />
      <range from="0" to="9" />
    <union>
  </star>
</concat>

[xkucf03]

Už se těším až v konfiguraci místo 2 * x + 3 objevím …

To je podobně absurdní a vykonstruovaný příklad jako v tom článku¹ odkázaném vedle v blogu. Ukazovat nevýhody značkovacího jazyka na tom, že se v něm pokusíš psát program nebo sčítat, je přitažené za vlasy. Asi jako kdybych chtěl voláním céčkových funkcí poskládat HTML stránku nebo nějaký složitý strukturovaný dokument – ano, jde to, ale blbě se to čte i píše a nevidíš v tom na první pohled ten výsledek. I když někdy mohou mít taková využití smysl…

Jak moc do hloubky půjdeš a kolik toho popíšeš XML elementy a atributy a kolik toho už necháš uvnitř textu je na tobě – XML tě v tom nijak neomezuje a každému se může hodit něco jiného – někdo třeba napíše <jméno>Jméno</jméno><příjmení>Příjmení</příjmení> a někdo jiný <jméno-příjmení>Jméno Příjmení</jméno-příjmení>.

BTW: když chceš matematiku, v příští verzi Antu by mělo jít zapsat třeba:

<param name="p3" expression="64 * 64 div 128 + 10" type="xpath:number"/>

nebo místo regulárního výrazu zapsaného jako [A-Za-z][A-Za-z0-9]* najdu třeba

To samé. Běžně se píše např.

<xsd:pattern value="[A-Za-z][A-Za-z0-9]*"/>

BTW: co takhle regulární výraz pro kontrolu regulárních výrazů?

_{[1] který se tu mimochodem už párkrát objevil}

[Radek Miček]

Jak moc do hloubky půjdeš a kolik toho popíšeš XML elementy a atributy a kolik toho už necháš uvnitř textu je na tobě

Jenže pak to nebude splňovat váš požadavek:

formát pro konfiguráky s jednotnou syntaxí napříč různými programy (viz výše zápis booleovských hodnot + řetězce, escapování, kódování, stromové struktury, seznamy atd.)

---

To je podobně absurdní a vykonstruovaný příklad jako v tom článku1 odkázaném vedle v blogu. Ukazovat nevýhody značkovacího jazyka na tom, že se v něm pokusíš psát program nebo sčítat, je přitažené za vlasy.

To není absurdní. Když bych použil vhodnější značkovací jazyk – třeba (něco jako) Prolog, tak první výraz mohu zapsat normálně a druhý třeba takto:

[A-Z,a-z],[A-Z,a-z,0-9]*

když dodefinuji operátor * jako postfixový příkazem

op(100, xf, *)

BTW: co takhle regulární výraz pro kontrolu regulárních výrazů?

Pokud se v zápisu regulárního výrazu mohou objevit podvýrazy v závorkách a není omezeno jejich vnořování, tak je třeba silnější prostředek (za předpokladu, že regulární výrazy rozpoznávají regulární jazyky).

[Radek Miček]

Pokud by to byl Prolog, tak spíše takto:

['A'-'Z',a-z],['A'-'Z',a-z,0-9]*

[xkucf03]

Když bych použil vhodnější značkovací jazyk – třeba (něco jako) Prolog … když dodefinuji operátor * jako postfixový příkazem

Jenže to už se dostáváme za hranice značkovacích jazyků a přesouváme se k programování. A to je právě ta otázka (kterou už jsme tu asi taky kdysi řešili), jestli konfigurák má být neživým dokumentem, který je zpracováván, nebo jestli má být programem/skriptem, který sám něco dělá.

Nicméně přeskočil jsi to hlavní, co jsem se snažil říct – je jedno, jestli to bude XML nebo něco jiného, důležité je, jestli to nabídne ty možnosti: strojově čitelný popis formátu, validace a další, viz výše.

[Radek Miček]

Jenže to už se dostáváme za hranice značkovacích jazyků a přesouváme se k programování.

Můžete to chápat jako deklarativní popis vstupu.

[xkucf03]

Jenže pak to nebude splňovat váš požadavek

Regulární výraz by se psal jako regulární výraz (text) ve všech konfigurácích – stejně jako desítku bychom psali jako 10 a ne třeba X nebo 1010.

[Radek Miček]

Regulární výraz by se psal jako regulární výraz (text) ve všech konfigurácích

A jak bude probíhat kontrola syntaxe a validace pro regulární výrazy? Případně, jak to bude probíhat pro aritmetické výrazy? Případně pro nějaké jiné výrazy?

[xkucf03]

Zhruba stejně, jako třeba kontrola doménových jmen, IP adres nebo názvů měst – syntaxi domény zkontrolovat můžeš, odhalíš nesmysly typu example..com, nebo example,com, ale už nezjistíš, zda daná doména skutečně existuje (musel bys použít DNS), v případě IP adresy taky nezkontroluješ, zda takový stroj je připojený k síti a je dostupný (musel bys použít ping), v případě města můžeš odmítnout netisknutelné znaky, konce řádků, nebo vyžadovat nějakou omezenou abecedu (např. tam nebudeš chtít ty ikony/symboly, kterých je v unicodu plno, ale jen písmena/čísla různých národních abeced), ale opět nezkontroluješ, jestli existuje město Praaha (musel bys mít databázi všech měst).

Že se nedá zvalidovat úplně všechno (alespoň ve fázi parsování/načítání konfigurace) je zřejmé – ale to přece neznamená, že bychom měli rezignovat na validaci toho, co se zkontrolovat dá a celkem snadno (strojově čitelně deklarovat a pak automaticky zkontrolovat).

[Radek Miček]

ale to přece neznamená, že bychom měli rezignovat na validaci toho, co se zkontrolovat dá a celkem snadno (strojově čitelně deklarovat a pak automaticky zkontrolovat).

S tím souhlasím, a proto jsem se ptal, jak se zařídí validace regulárních výrazů, aritmetických výrazů apod. To je přeci něco, co jde strojově čitelně deklarovat a pak automaticky zkontrolovat, ne?

[xkucf03]

Zvalidovat regulární výraz je snadné, stačí ho zkompilovat. Akorát je potíž v tom, že existuje víc odrůd a to, co bude fungovat v Perlu, nemusí fungovat v Javě, grepu nebo naopak. S aritmetickými výrazy to bude ještě horší. XSDčko můžeš doplnit Schematronem a přidat další pravidla – a v nich by se dala zavolat funkce, která zkompiluje regulární nebo aritmetický výraz v určitém dialektu. Jazyk pro popis schémat by taky mohl umožnit zapsat libovolnou gramatiku a tou pak umožnit validovat textové uzly. Případně by mohl podporovat vkládání skriptů (třeba ECMAScript) a pomocí nich provádět libovolné kontroly (takže bys v tom skriptovacím jazyce mohl napsat třeba parser perlovských regulárních výrazů, matematických výrazů pro Octave nebo SQL dotazů pro PostgreSQL). Ale tohle je typické dilema mezi složitostí a funkcionalitou.

[Bedňa]

Nepresvedčil si ma, prax je úplne iná, pokúsiš sa nájsť hocijakú voľbu v Gnome XML a ja to isté v IceWM, mne stačí grep, čo budeš potrebovať ty? A keď porovnáme časy, tak to bude úplne inde. Pokiaľ sa bavíme o zložitých štruktúrach, tak to už hádam ani nieje konfigurák.

Dokumentácia oddelená od konfiguráku je nevýhoda, stačí mi hocijaký txt editor čo je všade a valím cez shh na druhú stranu zemegule. To že niekto neprepíše nápovedu vedľa voľby ktorú zmenil v programe, určite to spraví v dokumentácií.

To čo by si uvítal sa dá realizovať aj v texťáku a dlho tomu aj tak bolo, teda neexistuje nejaké zjednotenie.

Môžno keby ľudia v XML písali pre ľudí, tak by to šlo, ale to nebude nikdy, zrejme to vedie nepriamo k zhovadilosti, možno by sa na to dala vypracovať nejaké štúdia

[xkucf03]

To že niekto neprepíše nápovedu vedľa voľby ktorú zmenil v programe, určite to spraví v dokumentácií.

Ono to nepřepíše, protože ani nemůže – ta nápověda se nachází v komentáři v konfiguráku, který se nakopíroval na tvůj disk při instalaci verze 0.8 a ve verzi 0.9 tam přidali nové možnosti – třeba místo true/false tam jde napsat i inherit – ale to ty nevíš, protože do těch tvých komentářů upgradovací proces nezasahuje – ale může upravit XSDčko někde v /usr/share…

To čo by si uvítal sa dá realizovať aj v texťáku a dlho tomu aj tak bolo, teda neexistuje nejaké zjednotenie.

Bohužel neexistuje – už třeba taková banalita jako komentáře. Obvykle jsou uvozené # (nechme teď stranou, že někde se používá //, /*/, --, ; atd.), ale někde ten komentovací # musí být na začátku řádku a někde můžeš zakomentovat i něco od prostředka – což je celkem šikovné, ale na druhou stranu: co když budeš chtít zapsat skutečný # …

[Bedňa]

Pri upgrade sa ťa spýta, či chceš config v /usr/share... nahradiť novým, ponechať stávajúci, alebo zobraziť zmeny. No samozrejme o ~/.config sa už musíš postarať sám.

Kernelu to stačí, tak to musí stačiť každému Máš väčší projekt?

Nepchaj mriežky do konfiguráku ako hodnoty a máš po starostiach

[xkucf03]

Pri upgrade sa ťa spýta, či chceš config v /usr/share...

V /usr/share právě žádné konfiguráky nejsou, tam jsou statické soubory, součásti programu, které nemáš co měnit – např. ty XML schémata – takže je to prostě přepíše a na nic se tě to ptát nemusí.

Kernelu to stačí, tak to musí stačiť každému Máš väčší projekt?

Jádro je sice rozsáhlé, ale ty volby jsou dost jednoduché – obvykle jen zapnout/vypnout případně vybrat jednu z několika hodnot. V aplikacích bývají o dost složitější struktury, hierarchie, třeba nastavení e-mailového klienta: několik účtů, účty různých typů, každý účet může mít víc identit (jméno, příjmení, e-mail, patička atd.), můžou tam být vazby na jiné části konfigurace (např. pomocí kterého SMTP účtu se má odesílat), seznam odebíraných složek…

Nepchaj mriežky do konfiguráku ako hodnoty a máš po starostiach

Ano, většina problémů v IT se dá vyřešit jednoduše – přestat používat počítač.

[Bedňa]

Nielen IceWM tu má defaultný konfig /usr/share/icewm/, to isté samozrejme platí aj pre /etc/...

Hierarchia sa dá veľmi dobre vyriešiť adresárovou štruktúrov konfigurákov.

Ja sa ti len snažím vysvetliť môj postoj, vo väčšine prípadov je vhodný plaintext, verím že ti môže XML uľahčiť niekde život, ale prečo ho pchať všade

[xkucf03]

Nielen IceWM tu má defaultný konfig /usr/share/icewm/, to isté samozrejme platí aj pre /etc/...

Snažím se tu vysvětlit, že v XML je možné oddělit data (vlastní konfigurák) a jejich popis (schéma – XSD, DTD…), který obsahuje jak dokumentaci, tak strukturu, datové typy… Data dáš do /etc, popis do /usr/share a díky tomu si uživatel může upravovat a verzovat data a při upgradu mu pošleš aktuální popis (přepíše se v /usr/share) a díky tomu má uživatel nejnovější dokumentaci a má k dispozici nové volby/položky, aniž by musel něco někam kopírovat nebo dělat nějaké diffy.

Hierarchia sa dá veľmi dobre vyriešiť adresárovou štruktúrov konfigurákov.

To je jedna z možností, v podstatě využiješ souborový systém jako formát. Pak stačí adresáře a v nich jeden nebo víc souborů s plochou strukturou klíč=hodnota nebo klíčem bude název souboru a hodnotou jeho obsah. Akorát tu není standardní způsob, jak to zvalidovat nebo jak by ti editor napovídal možnosti, ale dalo by se to vymyslet… Vazby mezi položkami se dají udělat pomocí symbolických odkazů. A je to i docela unixové: „všechno je soubor“

vo väčšine prípadov je vhodný plaintext

A co je to vlastně „plaintext“? Takové INI soubory nebo běžné konfiguráky, které mají nějakou syntaxi¹ nejsou o nic víc „plaintext“ než XML, které má taky nějakou syntaxi.

_{[1] přiřazování = nebo :, struktury pomocí {}, odsazování, uvozovky nebo apostrofy pro zápis textových hodnot, zpětné lomítko pro escapování, křížek nebo // pro komentáře atd. atd.}

[Bedňa]

Máš pravdu, ale moja skúsenosť je, spravíme hierarchiu, potom zistíme že toto by malo patiť do tejto vetvy ale už to tam nedáme, aby sme neporušili kompatibilitu a vznikne niekoľko vetiev čo by mali byť v jednom strome, ale niesu a zrazu prichádza XML hell Teda musím uznať že si ma trochu nalomil, ale ja zatiaľ ostanem u klasiky. Pretože keď by sme chceli zaviesť štandart, ono by sa dali vymyslieť nástroje aj na tie texťáky a tá jednoduchosť mi príde super.

S tým plaintext to bol fail, mal byť text Jasne že syntax existuje a je chyba, že nie jedna. Teda chyba, no je to problém pre vytvorenie univerálnych nástrojov, čo je u XML asi lepšie.

[pavlix]

+1

Taky mám z toho dojem ukrutně krásné teorie ale o poznání slabší praxe.

[xkucf03]

Proč to podle tebe nefunguje v praxi?

[Ivan]

Jak se rika: "Velbloud je kun navrzeny komisi". Vetsinu tvych pozadavku splnuji napriklad Windowsi registry. Otazka je jestli je potreba na kazdyho vrabce potreba ten nejvetsi kanon.

PS: snad nejsilenejsi konfigurak (z pohledu parseru) ma bind ale i to se da zvladnout. Pokud ma nejaka aplikace sileny konfigurak, tak nakonec cast konfigurace skonci v nejaky databazi.

Na XML je sileny to, ze do nej klidne muzes napsat nejaky tagy, ktery bude aplikace vesele ignorovat. Napriklad proto, ze z google vypadnul navod pro predminulou verzi formatu. To se tyka napriklad konfigurace fontu. XSD a DTD je hezka vec ale kdo to doopravdy pouziva?

[xkucf03]

Vetsinu tvych pozadavku splnuji napriklad Windowsi registry.

Mají schéma? Windows nepoužívám, ale když jsem to viděl posledně, tak tam bylo možné nacpat cokoli (vytvořit si další atributy a přihrádky nebo jak se to jmenuje). Dále mi pak vadí ta centralizace a nemožnost pořádného verzování. Oproti XML mi to přijde hodně slabé a nenabízí to snad žádné výhody.

Otazka je jestli je potreba na kazdyho vrabce potreba ten nejvetsi kanon.

Souhlas. Někdy by stačil třeba javovský properties soubor, někdy INI případně YAML… Ale zase když se jednou naučíš obsluhovat kanón, je najednou jednodušší ho používat na všechno, než používat třeba praky, které jsou jednoduché, ale každý se obsluhuje jinak a má svoje specifika (což je ve výsledku složitější, než všechno řešit tím kanónem).

cast konfigurace skonci v nejaky databazi

To je celkem rozumné řešení, relační databáze – takové databáze mívají schéma, můžeš v nich dělat různé struktury (formou propojených tabulek), máš tam datové typy, API… Jedna z mála nevýhod bude, že se to špatně verzuje – obvykle je to binární soubor (ale dají se verzovat třeba SQL dumpy)

XSD a DTD je hezka vec ale kdo to doopravdy pouziva?

Řada aplikací je asi tolerantní (až moc) a naběhnou i když konfigurák neodpovídá schématu, takže validaci si musí udělat uživatel ručně. Nicméně vytvořit schéma (ať už v jakémkoli formátu), když definuji nějaký XML formát, je samozřejmost (může chybět u nějakého prototypu nebo alfa verze, kde se ještě neví, jak to všechno bude vypadat).

[pavlix]

snad nejsilenejsi konfigurak (z pohledu parseru) ma bind

C-style bloky mi zrovna náramně vyhovují a konfigurák bindu mi tím pádem přijde jako jeden z nejsrozumitelnějších.

Na XML je sileny to, ze do nej klidne muzes napsat nejaky tagy, ktery bude aplikace vesele ignorovat.

To platí u všech formátů stejně.

[xkucf03]

To platí u všech formátů stejně.

Stejně ne – spíš bych řekl, že se to bude dost lišit. Parser může fungovat tak, že načte konfigurák do nějaké hashmapy a z ní si to pak zbytek programu podle potřeby tahá (tudíž přebytečné položky jsou ignorovány). Ale taky to může fungovat tak, že parser prochází konfigurák a na základě každé jeho položky volá nějakou metodu a když narazí na neočekávanou položku, vyhodí výjimku nebo vypíše varování. Konfigurák taky může mít nějak hezky popsanou gramatiku a nepodporované volby nebudou této gramatice odpovídat a nepůjde to vůbec načíst. A nebo to může být XML parser a ty mu prostě jen nastavíš cestu ke schématu a řekneš, aby už během parsování validoval. Chybnou konfiguraci to opět (jako u té gramatiky) odmítne načíst a opět ti to vypíše, na kterém řádku a na kterém slovu/znaku máš chybu.

[rADOn]

Vymýšlíš si neexistující problém. Nezapisovat do /etc věci které se často mění je rozumná politika která ušetří práci při balení na systémech kde /etc není zapisovatelný. Když se podívám u mě, vidím třeba že dhcp si tam drží leasy, alsa stav mixeru, kerberos tickety etc cetera… Nic víc v tom není.

[pavlix]

Vymýšlíš si neexistující problém.

Smím se zeptat jaký? A pokud možno zkus reagovat výše na santiaga, který se k rozdílu mezi stavem a konfigurací přímo vyjadřoval, narozdíl ode mě.

[rADOn]

Tenhle:

Já ale požadavek chápu tak, že by měly zmizet i věci jako /etc/NetworkManager/NetworkManager.conf

Já tohle chápu jako vymyšlený důvod k nadávání, ten ticket se nejmenoval "úplné zrušení /etc". Santiago to popsal výborně a není moc co k tomu dodat. V NetworkManager.conf nejsou žádné stavové informace nebo konfigurace kterou by bylo nutné často měnit.

[rADOn]

Beru vše zpět. Ten ticket sice popisuje v podstatě jak se /var/lib používá odnepaměti (pravda, to mě mělo varovat), ale teď si čtu ten "standart" a je to fakt pakárna. O /etc se tam píše následující:

• Should only be used for components required to bring up a running system or for legacy components that cannot be modified
• Default configuration files deployed in rpm packages should live in /usr/lib/<id> or be compiled in.
• Host specific configuration and data files should live in /var/lib/<id>.

Výchozí konfigurace v /usr/lib je imo pro většinu balíků overkill a zbytečná práce ale ničemu to neškodí – gentoo podobným způsobem slučuje konfiguraci v portage se systémovou. Ale třetí bod opravdu implikuje úplný přesun všeho co není potřeba k nabootování do /var/lib.

Jsou tam i rozumně znějící věci (balíčkovací systém se opravdu nemusí srát do /boot) a nějaké bezúčelné přestavování nábytku a mezi tím jeden detailíček podle kterého mi svitlo – spojování bin a sbin. Ano, modří už vědí – je pod tím podepsán Kay Sievers. Takže asi tak.

[pavlix]

Beru vše zpět.

Já jsem si říkal.