Názory k článku Správa DNS zónových souborů v Gitu

Mělo by to závislost na konkrétním shellu. Ten se taky nepoužívá všude stejný a už jen příkaz echo se chová diametrálně odlišně v různých shellech. Díval jste se, co všechno se v tom hooku řeší? Má to přes 500 řádků, k tomu je navíc asi 350 řádků testů. Takhle složité skripty v shellu jsou jen těžko udržovatelné.

Google například píše: „If you are writing a script that is more than 100 lines long, you should probably be writing it in Python instead. Bear in mind that scripts grow. Rewrite your script in another language early to avoid a time-consuming rewrite at a later date.“

> Co som ale videl boli bezne veci - spustanie 3rd patry binariek, praca s ich vystupom, praca s datumom, ... vsetko co sa bezne da spravit v shell scripte.

To zní jako výzva. Já jsem psaní shellové verze hooků vzdal, když jsem chtěl:

1. vyzvednout obsah souboru ze staging ( git show :path/to/file)
2. zjistit jméno zóny analýzou obsahu a názvu souboru
3. obsah souboru předat na vstup named-compilezone
4. standardní výstup zahashovat (libovolnou hashovací funkcí), výstup hashe uložit do proměnné
5. ve standardním chybovém výstupu vyhledat sériové číslo zóny a uložit ho do proměnné
6. uložit standardní chybový výstup do proměnné

Tohle všechno bez dočasných souborů a se striktním oddělením programu a dat. Když o tom tak přemýšlím, ani mě nenapadá, jak se dá v shellu hashovat bez vynucení závislosti na OpenSSL nebo něčem podobném.

> Pritom nainstalovat napr. bash je trochu ine ako nainstalovat python.

V čem konkrétně je to jiné?

Shell se hodí na command line a tam to prakticky končí. Vždycky, když jsem psal něco v shell, tak to skončilo na různém nedokonalém parsování zdrojů, nespolehlivém otvírání souborů, neschopností spolehlivě zachytit chybu (set -e něco řeší, ale pak je třeba opačný handling) atd. Navíc byl například problém s paralelizací. Naprostá většina shell kódu navíc spolehá na neexistenci mezer v hodnotách proměnných, na to, že nezačínají pomlčkou atd.

Po překlopení do Perl (nebo Python či cokoliv jiného podle preferencí) pracuju na úrovni funkcí, které mají jasný výstup, jasné chybové kódy nebo exceptions. Mám k dispozici vysokoúrovňové datové struktury. K tomu mám spolehlivé nástroje na parsování strukturovaných dokumentů jako XML, JSON, kde dostanu celý objekt, takže nemusím duplikovat parsování například. Zároveň je můžu spolehlivě modifikovat. Testování je pak samostatná kapitola.

Dočasné soubory v shellu typicky zvyšují čitelnost a nejsou obecným zlem! Dokud nejsou v dočasných souborech citlivá data, tak jsou nejen rozumným prostředkem pro napsání programu, ale navíc umožňují ladění po krocích libovolnému nově příchozímu uživateli/adminovi. Co ale je v shellu zlo, je detekce a ošetřování chyb a potom ještě udržování většího množství strukturálních dat.

Moje 3 důvody kdy opustit shell podle důležitosti:
1. detekce a ošetřování chyb (každého příkazu, včetně aritmetiky a validace vstupů) začnou být příliš složité
2. zpracování strukturálních dat (použití jazyka který alespoň umožňuje vkládat do sebe hashe a pole zvyšuje čitelnost)
3. příliš velký počet identifikátorů (proměnných nebo dočasný jmen souborů) - v takovém případě potřebuju něco "statičtějšího", v případě pythonu nejprve prohnat "mypy" (aby odhalil překlepy v atributech objektů). Pokud se to nemusí měnit in-place tak třeba go nebo C.

Moje důvod kdy jít do shellu:
1. časté spouštění dalšíh programů, obzvlášť pak v pipelinách.
2. "přenositelnost" mezi uživateli/admi­nistrátory

Hashovat bez závislosti na openssl? Co takhle zkusit spustit externí program? Třeba sha256sum?

Taky tam píší:

If you find you need to use arrays for anything more than assignment of ${PIPESTATUS}, you should use Python.

Což nezní moc rozumě. Spíš to psal někdo, kdo nesnáší shell :-)

Mne osobne sa namiesto push spôspbu ukladania zón do gitu pull. POužívam 2 koncepty.

Koncept 1 je založený na http://dotat.at/prog/nsnotifyd/. Je nutné iba upraviť iba hidden master, tak aby posielal notify aj na server, kde beží nsnotifyd.

Koncept 2 je založený PowerDNS a supermaster a SQL backend, kde je pare tabuľku s RR záznamami trigger aby z8znam odložil aj do archívnej tabuľky pri zmene.

Výhody riesšní

• jednoduchosť implementácie
• nie je nutnosť meniť spôsob editovania zóny

Nevýhody riesšní
Pri DNSSEC je v revízii každý podpis zóny z dôvodu vypršania platnosti kľúčov, aj keď sa nič nezmenilo.

Díky, to je moc pěkný nápad. Co se týká DNSSEC, to se dá snadno vyřešit tak, že se podepisovač vloží až za archivátor.

V článku popsané řešení má ale ještě jednu výhodu, git ukládá metadata o tom, kdo, kdy a proč commit vytvořil, takže tyhle informace není nutné psát do zónového souboru (kam nepatří) a je možné podle nich snadno vyhledávat nástroji jako git blame.

Existuje ždy viacejmožností ako vyriešiť daný problém, užívateľ nech si vyberie.

Mój koncept vzišiel z predpokladu, že nemám dosah nad editovaním obsahu zóny, to si má vyriešiiť užívateľ sám. Ja poskytujem iba revíziu zmien. Vyriešil som týmto aj zone split view v BIND. kde by zasa asi bolo vhodnejšie práve popisované riešenie.

Něco na ten způsob tam je, když se místo sériového čísla použije (nestandardní) direktiva $UNIXTIME a na straně serveru se nastaví smudge filtr, který direktivu nahradí za aktuální timestamp. Jiné formáty sériových čísel jsou trochu problém, protože závisí na předchozím stavu – tohle se také může rozbít, pokud se sejdou dva commity v jednu sekundu.

Určitě by to tak šlo udělat, asi by to ani nebylo příliš těžké. Já se zatím spokojil s tím, že háček pre-commit automaticky sériové číslo zvyšuje (v souladu s používaným schématem), takže stačí commitnout poprvé, nechat si vynadat a hned commitnout podruhé. Tohle automatické zvyšování sériového čísla se mimochodem rozbije v červnu 2034, kdy timestamp bude vyšší než sériové číslo utvořené podle YYDDMMnn ;)

Uplně nesmyslné to není, pokud dovolíte anglické zkratky i na místě českých adjektiv. Když DNS server přečtete jako "doménový server" tak to smysl dává.