Fejlesztőink olyan programot írnak, ami módosítani tudja egyes szoftverek konfigurációs fájljait. A rendszer üzemeltetőjeként...

Szoftver

csak az átlátható (olvasható, jól tagolt) konfigurációt fogadom el, nem vagyok hajlandó kompromisszumot kötni.
56% (103 szavazat)
kisebb tagolási hibákat még hajlandó vagyok elnézni (szóközök/tabulátorok hiányoznak, indokolatlan üres sorok generálódnak le).
25% (46 szavazat)
nagyobb tagolási hibákat is hajlandó vagyok elnézni (sorok összefolynak, nehéz olvasni, nem látni egyből mi tartozik mihez).
3% (6 szavazat)
ez egyáltalán nem érdekel, módosítsa a fájljokat, ahogyan akarja, az én feladatom az üzemeltetése!
16% (30 szavazat)
Összes szavazat: 185

( thomasrc | 2018. 10. 25., cs – 15:51 )

FAQ: Mire kell gondolni az olyan program alatt?

- Webes control panelre, amit az ügyfelek elérnek és módosítani tudják rajta keresztül a nyújtott szolgáltatás paramétereit: VPN, webhosting, szerver hosting cp, ilyesmi.

- Lényeges, hogy a program nem az alaprendszer fájljait módosítja, hanem a rá telepített szoftver(ek) fájljait! Az alaprendszert továbbra is kénye-kedve szerint simogathatja a sysadmin, nem kell tartania attól, hogy egy külső program belegányol. Már ha valakinek egyáltalán számít ez...

( hunyadym | 2018. 10. 27., szo – 09:04 )

Nyilván a konkrét helyzetet nem látom, de szerintem a legtöbb esetben viszonylag triviális dolog szoftverrel helyes formátumú konfigurációt generálni; ha ez a fejlesztőnek nem megy, akkor elég valószínű, hogy a konfigurációval nem csak a formázása lesz problémás...

Nem érződik, de a kérdés teoretikus. :) Az apropója az volt, hogy végignéztem egy tucat control panelt és többnél is azt láttam, hogy igénytelen outputot hánytak a fájlokba, amikbe belenyúltak. Felmerült bennem a kérdés, hogy vajon az üzemeltetőket ez nem zavarja? Ha házon belüli fejlesztés lenne, akkor mikortól szólnának a fejlesztők felé, hogy ez így nem okés?...

( ivanov | 2018. 10. 27., szo – 09:56 )

Minek még egy text editor? :D

Az ilyen admin tool-oknál az output formázása _kellene_ legyen a legkisebb gond.

Én erre szavaznék: Szólok, hogy beszállnék a fejleszésbe és bízzák rám az output előállítását. Kapok egy interface-t amit úgy implementálok, ahogy szeretnék.

Amúgy milyen config? Mert a json, yaml, xml pretty print nem kellene, hogy nagy hiszti legyen.

___________________________
http://lorem.hu
Az emberi tudás mindenkié!

Nem ezt szerettem volna mondani, hanem azt, hogy léteznek lib-ek amik ezt elintézik és nem kell vele foglalkozni.

Btw a yaml a json supersetje, szóval a valid json az elvileg valid yaml is, így nem mindid érzékeny rá de igazából kb. mindegy, hogy melyik formátum mire érzékeny ha a pretty print requirement.

__________________________
http://lorem.hu
Az emberi tudás mindenkié!

"Amúgy milyen config? Mert a json, yaml, xml pretty print nem kellene, hogy nagy hiszti legyen."

YAML és hasonlók megkövetelik a formázást, azokkal nincsen gond. De sok linuxos szoftver (webszerver, vpn, ftp, nemtudommi) saját szintaktikát használ a konfigurációhoz és ezeknél igazából kis túlzással tök mindegy, hogy hogyan van formázva, csak legyen meg a nyitó és záró tag. Előfordulhat, hogy template fájlokból generálódik a config, ami tele van if()-ekkel, mert lehet, hogy bizonyos sorok csak akkor kellenek, ha a felhasználó bejelöl egy opciót a panelben. A template fájlban szépen megvan formázva minden, de amikor legenerálódik, akkor mégis rossz ránézni, mert a kimaradó if()-es sorok elrondítják. Ilyenkor mit lenne helyes tenni? Fektessen extra órákat a formázásba? Dolgozzák át a template rendszert? Vagy hagyják úgy, mert különben sem kell kézzel nyúlkálni benne, az üzemeltető meg ne foglalkozzon a látvánnyal?

Imho igen, fektessen bele extra órákat. (Az első pontra szavaztam)

Én is csinálok ilyen generálásokat, pl. powershellből bash kódot és konfigurációt generálok ki, és amikor az aktuális konfig file-t amit be source-lok (de gány hunglish) megnézem, jól esik, hogy még a kommentet is bele generálom, mert így szép a munkám.

Már elmúlt, de volt hogy python kódot generáltam, ott az általad is írt if -ekre külön figyelni kellett, mert hogy hány szóközzel kezdődik, és hogy mi hol van lezárva, az ugye nagyon nem volt mindegy.

Jelenleg is van olyan scriptem ami végiggyalogol majd 200 gépen, és az ott tapasztaltak alapján kiköp egy xml -t. Szépen indentálva írom ki, pedig mezítlábas bash kód, nem egy kész importált függvény egy vastagabb nyelvből. (Illetve írtam egy bash függvényt ami tudja, hogy hol tartunk a mélységben, és eszerint rak be sor eleji tabokat. Nem egy kimondott rakétatudomány, egy printf egy %* -al, aki ennyit sem képes vagy akar gépelni, hogy amit csinál arra büszke lehessen, az inkább ne rontsa le azoknak a gépeknek a minőségét amikért én (is) tartom a hátam.)

Könnyen olvasható formázás nélkül magamat szivattam volna amikor írtam és debuggoltam. Márpedig mindig van debug, mert az entrópia nem áll le, a kedvencem amikor a gyártott csv fileom eltörik, mert az AD-ból lekért ssh kulcs attribútumot valaki úgy vitte fel, hogy hagyott a végén egy entert. (Mondjuk ez szegénységi bizonyítvány is, mert úgy kellett volna megírnom, hogy kikapdossam belőle az entert is. Na mindegy.)

Ja, a sok if -es dolgot egyébként én úgy oldottam meg, hogy amikor nem kellett egy-egy blokkot beleraknom, akkor ennek a tényét az adott helyre belekommenteltem, így minden if else ágán is volt kimenetem a fileba, csak ott a komment volt, igy a python file szerkezete szép maradt.

Azt nem várom senkitől, hogy mindig minden tökéletes legyen, de ahol könnyen lehet szépet alkotni, ott szerintem elvárható, hogy szép legyen a produktum.

Az szomorú. :(
Templating helyett tudsz "serializálni" de azt meg szívás implementálni, cserébe egyszer kell nyelvenként. Vagy template és post process formatting ami viszont megint szívás. Common config format ftw! :)

___________________________
http://lorem.hu
Az emberi tudás mindenkié!

Dolgozzák át a template rendszert?

Hát ha egyszer nem jó a template rendszer... amúgy komolyan: xml-t, yaml-t, json-t nem template-ből generálunk, hanem libbel, szoftverből. Ha kellően buta a config fájl struktúrája (pl. windows .ini fájl), na ott szóbajöhet a templatesdi is.

( sigellef | 2018. 10. 27., szo – 20:19 )

Először: minek?
Másodszor: ha már csinál valamit egy program, akkor csinálja rendesen.
Harmadszor: egy jó dokumentum az adott szoftver konfigurálásáról százszor többet ér egy konfigurációszerkesztőnél.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( st3v3 v | 2018. 10. 28., v – 10:27 )

hagyja békén az indenteket stb, keressen-csereberéljen, de csak ott ahol kell. Ha én kézzel módosítok valamit majd a csudi program felülvágja a saját comment-emet attól ideges lennék :D. Azt és csak azt csinálja amire való.

( gabrielakos v | 2018. 10. 28., v – 10:58 )

Nem írogat rendszer konfigba semmi. Saját konfig file-t generál én meg megoldom, hogy összeálljon a kettő.
A saját konfigja szintaktikailag pontosan azokat a szabályokat kell kövesse mint a rendszeré.

--
Gábriel Ákos

( Dolphy | 2018. 10. 28., v – 18:50 )

Nem egészen értem, hogy a rendszer üzemeltetőjeként pontosan miért is van neked beleszólásod ebbe.