unix config file formaten.

[Verwijderd]

Op UNIX systemen zijn er legio verschillende config file formaten. Ik ben benieuwd wat ieders favoriete config file formaat is, en waarom dat zo is.

Hier ff een korte opsomming met voorbeeld.

Samba style:

code:

# ohoh
[sectie1]
optie = iets
optie2 = iets anders
[sectie2]
optie3 = weer iets

Duidelijk, maar lastig met spaties voor en na de values. Geen nesting mogelijkheden.
Er is een vergelijkbaar formaat wat de regels wel afsluit met een semicolon.

Jabber style (XML):

XML:

<!-- Sluice component -->
<service id="sluice.localhost">
   <accept>
      <ip/>
      <ns>jabber:iq:search</ns>
      <ns>jabber:iq:register</ns>
      <port>5227</port>
      <secret>sluice_secret</secret>
    </accept>    
</service>

m.b.v. XSL kan er een mooie pagina van worden gemaakt!
Nesting is mogelijk en extra spaties voor of na values zijn meteen duidelijk.
Comments zijn een beetje omslachtig.
Een programma om de config file te editten/bekijken kan eenvoudig een sectie inklappen. (mozilla doet dit standaard)
d.m.v. een DTD kan er makkelijk een generiek programma gemaakt worden voor 't editten van verschillende XML config files.

enscript style:

code:

optionOne: value1
optionTwo: value2

Nogal basic...

fstab style:

code:

option1   value1   value2   value3
option2   value6   value5   value4

Mooie uitlijning. Maar spaties zijn problematisch.

passwd style:

code:

option1:value1:value2
option2:value3:value4

Goed, maar niet uitbreidbaar.

MRTG style:

code:

option1[section1]: value1
option2[section1]: value2

Rampzalig. Probeer maar is een section te hernoemen. Of ff een sectie 5x te kopieeren omdat je b.v. 5 routers hebt.

Binary config files zijn er ook nog....ik heb er nooit echt 't nut van ingezien. (behalve bij tripwire dan)

De slapd.conf van OpenLDAP is het slechtste config file formaat wat ik ken. De verschillende secties zijn niet duidelijk genoeg gescheiden. En met LDAP is er meestal een master en een (of meer) slave servers. De ACL's zijn bij die servers gelijk, maar de rest van de config niet. Bij elke wijziging in de ACL's moet er dus gecopypaste worden, terwijl als het een appart bestand was geweest het gewoon via scp of rsync had kunnen worden gekopieerd.

Belangrijke dingen bij logfiles.
Compatibiliteit met CVS, ARCH, SVN en cfengine. (mogelijkheid om met diff/patch enzo te werken, zonder syntax errors te introduceren. en zonderdat het full-file patches worden.)
Controle op syntax (b.v. parsing XML processor zoals mozilla)

Al met al lijkt XML me goed voor config files. Wat zijn de verdere voors en tegens van xml configs?

Moet er per applicatie een config zijn of moet het via includes enzo opgedeeld zijn in meerdere files?

[ Voor 30% gewijzigd door Verwijderd op 21-05-2004 14:51 ]

[Wilke]

Zie ook het stuk over Data File Metaformats in "The art of Unix programming" door Eric S. Raymond. Ook de rest van dat boek is zeker de moeite waard om te lezen overigens, als je je bezighoud met het ontwikkelen van software in Linux/UNIX.

[TheRookie]

Not Found
The requested URL /~esr/writings/taoup/html/ch05s02.htm was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

[Spider.007]

TheRookie schreef op 21 mei 2004 @ 15:03:
[...]

Google doet de truuk:

http://www.faqs.org/docs/artu/ch05s02.html

En even ontopic; mijn voorkeur heeft de "Samba style". Het enige gestelde nadeel is eenvoudig te omzeilen door quotes te gebruiken om de waarden. De blokhaken geven mooi de verschillende blokken aan; en er is goede indenting mee mogelijk om een duidelijke layout te maken:

[blok1]
	naam =		"waarde met spaties"
	naampjes =	waarde

[blok2]
	naam =		waarde

enzovoorts

[ Voor 52% gewijzigd door Spider.007 op 21-05-2004 15:08 ]

[Robtimus]

Ik geef toch de voorkeur aan XML. Je kan er zowel eenvoudige als ingewikkelde configs mee maken, en ook het parsen is eenvoudig: voor C heb je oa expat, voor Java oa SAX, DOM en JDOM, etc.
Voor vrijwel elke taal is er wel een lib voor, zodat je het niet zelf hoeft te schrijven.

[Verwijderd]

Spider.007 schreef op 21 mei 2004 @ 15:05:
mijn voorkeur heeft de "Samba style". Het enige gestelde nadeel is eenvoudig te omzeilen door quotes te gebruiken om de waarden.

Dat is voor als je iets van "waarde " wilt of " waarde" maar als je geen quotes hebt kan er een verborgen spatie achter een waarde staan. (niet dat dit ooit voorkomt, maar toch)

De blokhaken geven mooi de verschillende blokken aan; en er is goede indenting mee mogelijk om een duidelijke layout te maken:

[blok1]
	naam =		"waarde met spaties"
	naampjes =	waarde

[blok2]
	naam =		waarde

enzovoorts :)[/quote]
Het is idd een van de betere formaten. Maar het ondersteund geen nesting. Bij samba zou dit handig kunnen zijn om b.v. een groep met public shares te maken en een groep met private shares.

En om de syntax te checken is een speciaal programma nodig, bij XML alleen een validating parser.

Een XML editor kan uit een DTD de mogelijke opties van een XML config halen, Dit kan makkelijk zijn bij het maken van een GUI editor of http frontend.

Wat zijn de voordelen van dit formaat ten opzichte van XML?

[Verwijderd]

Verwijderd schreef op 21 mei 2004 @ 14:42:
De slapd.conf van OpenLDAP is het slechtste config file formaat wat ik ken. De verschillende secties zijn niet duidelijk genoeg gescheiden. En met LDAP is er meestal een master en een (of meer) slave servers. De ACL's zijn bij die servers gelijk, maar de rest van de config niet. Bij elke wijziging in de ACL's moet er dus gecopypaste worden, terwijl als het een appart bestand was geweest het gewoon via scp of rsync had kunnen worden gekopieerd.

offtopic:
huh?
je kan gewoon files includen in de config van slapd hoor
dus copypaste hoeft niet
uit de man page van debian-testing
slapd versie 2.1.23-1

include <filename>
Read additional configuration information from the given file
before continuing with the next line of the current file.

voor de rest: ik vindt het formaat
optie=waarde
voor handmatig editen het handigst
voor automatisch editten XML vanwege de porteer/transporteerbaarheid en het zelfbeschrijvend karakter van XML

[ Voor 8% gewijzigd door Verwijderd op 21-05-2004 15:39 ]

[Spider.007]

Verwijderd schreef op 21 mei 2004 @ 15:25:
[...]

Dat is voor als je iets van "waarde " wilt of " waarde" maar als je geen quotes hebt kan er een verborgen spatie achter een waarde staan. (niet dat dit ooit voorkomt, maar toch)

[...]
Het is idd een van de betere formaten. Maar het ondersteund geen nesting. Bij samba zou dit handig kunnen zijn om b.v. een groep met public shares te maken en een groep met private shares.

En om de syntax te checken is een speciaal programma nodig, bij XML alleen een validating parser.

Een XML editor kan uit een DTD de mogelijke opties van een XML config halen, Dit kan makkelijk zijn bij het maken van een GUI editor of http frontend.

Wat zijn de voordelen van dit formaat ten opzichte van XML?

Je voorbeeld van nesting is een goed punt van iets wat niet mogelijk is het dat formaat. Zoals je zelf al aangeeft is het hiernaast een van beter formaten.

Waarom dan geen XML? Ik vindt XML niet 'passen' als configuratiefile voor een UNIX applicatie. Ik denk dat dit puur een gevoel is over de manier waarom ik XML gebruik. Ik had een lijstje met nadelen opgesteld maar als ik er nog eens goed over nadenk zijn die eigenlijk allemaal op te lossen. Ik denk dat je je met hetzelfde achtergrondidee kunt afvragen waarom Samba-style nog niet overal gebruikt wordt Ik denk dat XML geen nadelen biedt als configuratiefile; maar nogmaals; ik vindt het eerder passen bij een webapplicatie oid.

Wat is trouwens het verschil tussen je 'speciale programma' en een XML parser? XML's met DTD's zijn ook geweldig natuurlijk; maar zorgen er wel voor dat de library nog meer functies moet gaan ondersteunen, en nog zwaarder wordt. Zijn de readers voor de huidige formaten trouwens al ondergebracht in generieke libraries, of zijn dit allemaal individuele implementaties?

[Wilke]

Spider.007 schreef op 21 mei 2004 @ 15:05:
Google doet de truuk:

De 'l' terugplakken achter de '.htm' deed de truuk ook (argh! zeker op backspace gedrukt ofzoiets)

[Verwijderd]

Volgensmij is het grootste probleem met XML configs dat de gemiddelde beheerder nog niet genoeg verstand heeft van XML.
_{Met versie 5 van php komt er ook eindelijke fatsoenlijke XML ondersteuning in PHP! Misschien dat er dan ook meer XML configs komen.}

[Bananenplant]

ik vind xml trouwens ook alles behalve prettig lezen. misschien dat het met syntax highlighting wat gemakkelijker is, maar ik vind voor het oog de redundantie wat groot als je snapt wat ik bedoel.

[Verwijderd]

ucchan schreef op 21 mei 2004 @ 19:31:
ik vind xml trouwens ook alles behalve prettig lezen. misschien dat het met syntax highlighting wat gemakkelijker is, maar ik vind voor het oog de redundantie wat groot als je snapt wat ik bedoel.

Dat is een goed punt. Lezen kan heel makkelijk met een editor met xml functies of een browser (en evt. XSL). Maar dat gaat in tegen de unix principes. Maar aan de andere kant, het is nog steeds een file en het kan nog steeds met een basic editor gemaakt of bewerkt worden. De 'overhead' is dus een nadeel, maar voor zo ver ik kan zien bijna het enige.

Het andere probleem is dit:

C:

<service>
  <interface="hme0">
    <port>389</port>
    <port>636</port>
  </interface>
  <interface="hme1">
    <port>636</port>
  </interface>
</service>

Dit is een best overzichtelijke en flexibele config, maar het grept zo lastig. (net als bij LDIF files, maar dat probleem heb ik opgelost.

offtopic:
Ben ik gek of heeft react geen XML highlighting? Ach, C highlighting ziet er ook leuk uit...

[CyBeR]

XML is absoluut klote om te parsen (je hebt er een fucking _library_ voor nodig). Bovendien leest het onprettig en is het, zoals hierboven gezegd, kut om doorheen te greppen.

Doe mij maar 'var=value'-style configs. Desnoods met [bla dingen] er bij. Standaard ondersteunt het geen nesting, maar daar valt zonder al te veel moeite omheen te werken. De enige reden dat ze op dit moment niet genest kunnen worden is dat de blokken afgesloten worden door een nieuw [bla] tag. Op te lossen met [end] tags.

[Verwijderd]

Wat greppen zou vergemakkelijken is een grep-xml:

code:

$ cat slapd.conf | grep-xml -t interface 636 
<interface="hme1">
  <port>636</port>
</interface>

En idd nesting is met samba style configs ook mogelijk als er ook een "[/global]" of ander soort end statement.

Nog wat interessante info:
http://www.unixreview.com...s=1238/urm0102c/0102c.htm
http://www.inaccessnetwor.../docs/configurator-v1.pdf

[ Voor 41% gewijzigd door Verwijderd op 22-05-2004 13:31 ]

[Verwijderd]

Spider.007 schreef op 21 mei 2004 @ 15:05:
En even ontopic; mijn voorkeur heeft de "Samba style". Het enige gestelde nadeel is eenvoudig te omzeilen door quotes te gebruiken om de waarden. De blokhaken geven mooi de verschillende blokken aan; en er is goede indenting mee mogelijk om een duidelijke layout te maken:

[blok1]
	naam =		"waarde met spaties"
	naampjes =	waarde

[blok2]
	naam =		waarde

enzovoorts

Het enige nadeel?

[Jan]
	vraag =		"Wat is "steunen"?"

[Piet]
	antwoord =	""Steunen" is stutten, helpen of kreunen."

[Jan]
	vraag =		"Mag ik nog eens?"

[Bananenplant]

Verwijderd schreef op 22 mei 2004 @ 12:56:
[...]

C:

<service>
  <interface="hme0">
    <port>389</port>
    <port>636</port>
  </interface>
  <interface="hme1">
    <port>636</port>
  </interface>
</service>

ten overvloede misschien: zelfs met de kleurtjes heb ik nog zo'n gevoel van: "hm, een blok characters, waar de fok moet ik beginnen met lezen?". net wanneer als ik een html-mail moet lezen in pine, dan haak ik ook af.

die andere configdingen, zoals samba, mja, dat lijkt wat meer op natuurlijke taal op een bepaalde manier... het lijkt meer op een boodschappenlijstje, kun je netjes overzichtelijk leesbaar maken met tabs, indenting en witregels enzo.

oh, trouwens, kun je die " desgewenst niet escapen ofzo?

[ Voor 26% gewijzigd door Bananenplant op 22-05-2004 15:01 . Reden: typo ]

[Verwijderd]

Stel in de config van een willekeurig programma moet iets veranderd worden. Hoe doe je dat dan?

Met XML:
Maak een kopie van de config.
Edit de config. (mogelijke opties zijn uit de DTD te halen.)
Haal de config door een validating parser.
Gooi de config evt. in cvs.
Zet de nieuwe config over de oude config heen.
Laat de daemon de config opnieuw inlezen, of start de applicatie opnieuw.
Test & evt. rollback.

Dit is een redelijk veilige, en makkelijk te automatizeren manier.

Overige configs:
Maak een kopie van de config.
Edit de config. (mogelijke opties staan in de manpage of in het commentaar)
Kijk de config nog eens goed na, en test evt. op een test server.
Gooi de config evt. in cvs.
Zet de nieuwe config over de oude config heen.
Laat de daemon de config opnieuw inlezen, of start de applicatie opnieuw.
Test & evt. rollback.

Dit is niet te automatizeren, en vereist een testserver. Voor sommige dingen zoals apache zijn er wel config tests, maar dat is niet voor alles zo, en deze tools zijn applicatie specefiek ontwikkeld.

Bij config file formaten was ik het beruchte formaat van Sendmail nog vergeten...iemand een voorbeeldje?

[ Voor 12% gewijzigd door Verwijderd op 22-05-2004 15:08 ]

[Spider.007]

Verwijderd schreef op 22 mei 2004 @ 14:34:
[...]


Het enige nadeel?

[Jan]
	vraag =		"Wat is "steunen"?"

[Piet]
	antwoord =	""Steunen" is stutten, helpen of kreunen."

[Jan]
	vraag =		"Mag ik nog eens?"

Tjah... het quotes binnen quotes probleem speelt, netzoals de niet unieke primaire waarden ook bij XML gewoon mee. Het eerste probleem is gewoon op te lossen door de quotes te escapen; het tweede probleem is in beiden formaten niet op te lossen

[Spider.007]

Verwijderd schreef op 22 mei 2004 @ 15:02:
Stel in de config van een willekeurig programma moet iets veranderd worden. Hoe doe je dat dan?

Met XML:
Maak een kopie van de config.
Edit de config. (mogelijke opties zijn uit de DTD te halen.)
Haal de config door een validating parser.
Gooi de config evt. in cvs.
Zet de nieuwe config over de oude config heen.
Laat de daemon de config opnieuw inlezen, of start de applicatie opnieuw.
Test & evt. rollback.

Dit is een redelijk veilige, en makkelijk te automatizeren manier.

Overige configs:
Maak een kopie van de config.
Edit de config. (mogelijke opties staan in de manpage of in het commentaar)
Kijk de config nog eens goed na, en test evt. op een test server.
Gooi de config evt. in cvs.
Zet de nieuwe config over de oude config heen.
Laat de daemon de config opnieuw inlezen, of start de applicatie opnieuw.
Test & evt. rollback.

Dit is niet te automatizeren, en vereist een testserver. Voor sommige dingen zoals apache zijn er wel config tests, maar dat is niet voor alles zo, en deze tools zijn applicatie specefiek ontwikkeld.

Bij config file formaten was ik het beruchte formaat van Sendmail nog vergeten...iemand een voorbeeldje?

Euh.. dit vindt ik dus echt onzin. Je zegt dus dat een formaat als XML met een DTD er automatisch voor zorgt dat changes direct op een productieserver doorgevoerd kunnen worden omdat je geen syntaxfouten meer kunt maken? DTD's zijn zeker een voordeel van XML configfiles; maar om nou te zeggen dat je je wijzigingen daardoor plotseling niet meer zou hoeven testen is nonsens. Sowieso zijn DTD's verschrikkelijk beperkt. Volgens mij zijn de volgende checks mogelijk:

• Zijn alle benodigde waardes ingevult
• Indien een waarde een IDREF is, controleer of ID ook bestaat als primaire sleutel van een andere waarde.

Meer kun je niet met DTDs. Je kunt niet controleren of iets een getal is; of iets een bepaalde lengte heeft enzovoorts.

[Robtimus]

*kuch* XML Schema *kuch*

[Verwijderd]

Spider.007 schreef op 22 mei 2004 @ 16:23:

Je zegt dus dat een formaat als XML met een DTD er automatisch voor zorgt dat changes direct op een productieserver doorgevoerd kunnen worden omdat je geen syntaxfouten meer kunt maken? DTD's zijn zeker een voordeel van XML configfiles; maar om nou te zeggen dat je je wijzigingen daardoor plotseling niet meer zou hoeven testen is nonsens.

Als het path van een samba share veranderd moet worden, dan zullen de meest mensen niet eerst de config op en testserver uitproberen. Door het gebruik van DTD of beter nog een XML Schema kunnen de meeste simpele fouten er iig uit worden gehaald. Het zou niet voor het eerste zijn dat iemand een kleine wijziging maakt, en een puntcomma vergeet, of b.v. paht tikt i.p.v. path.

Voor een compleet nieuwe config of een config met veel wijzigingen is het natuurlijk nog steeds zo dat dat uitvoerig getest moet worden.

Sowieso zijn DTD's verschrikkelijk beperkt. Volgens mij zijn de volgende checks mogelijk:

• Zijn alle benodigde waardes ingevult
• Indien een waarde een IDREF is, controleer of ID ook bestaat als primaire sleutel van een andere waarde.

Meer kun je niet met DTDs. Je kunt niet controleren of iets een getal is; of iets een bepaalde lengte heeft enzovoorts.

• of of test (noord of zuid of west of oost)
• check op syntax. (doet de xml parser, geen dtd voor nodig)

[Verwijderd]

Ik vind persoonlijk XML parsing nogal pijnlijk. Zal er wel aan liggen dat ik slechts gedeeltelijk ervaring met XML heb, maar ik volg toch echt de standaard gedocumenteerde code-voorbeeldjes. Tree-parsing is gewoon enorm painful. Veel te veel code nodig om iets simpels te bereiken.

Desondanks is XML toch by far the best: uitbreidbaar, en uitstekende support libraries beschkbaar voor Linux. En GNOME applicaties gebruiken gewoon GConf, da's tenminste makkelijk.