Dotaz: jak udržet pořádek v configuráccíh?

[1john2]

Dobrý večer,

zajímalo by mně jak udržujete pořádek ve svých konfiguračních souborech ať už na desktopu, nebo serveru? Postupem času mi přibývá (nejen) v /etc přibývá souborů typu _back_datum, _back_datum1 atd... a je čím dál těžší udržet pořádek a přehled o změnách.

Jak toto řešíte vy? verzovacím systémem? zálohovacím nástrojem? jakými?

co bych od toho očekával já:

- verzování souborů

- popisky

- zálohování!!! nejlépe na dvd

- možnost porovnání jakýchkoli dvou verzí a výpis změn

- instalace z .deb (asi nebude problém)

Díky za nápady

Odpovědi

[pupu]

Na serverech tenhle problem nemam. Server se nainstaluje, nastavi a pak jede, dokud se nezrusi. Na notebooku mam zase relativne kratkou dobu zivotnosti distribuce, takze reinstalace cca jednou za rok to jisti. Jina otazka nastava v okamziku, kdy se ma clovek starat o desitky, pripadne stovky serveru. Pak nastupuji nastroje typu cfengine.

[1john2]

vzhledem k tomu ze ja mam doma server na kterem se ucim, menim jeho cfg docela casto a v pripade problemu se spatne hleda chyba, nebo hisotrie zmen.

Psane poznamky jsem zkousel ale kam je psat?

do jednoho souboru? jak ho clenit?

do kazdeho souboru kde delam zmenu? jak pak najit konkretni zmenu... tudy imho cesta nevede...

cfengine asi nebude to prave pokud je pro mnoho serveru, ale mrknu diky aspon za nejaky tip..

[Heron]

Psane poznamky jsem zkousel ale kam je psat?

Zkus lokální wiki (já používám klasickou mediawiki). Velmi snadno vytvoříš nový zápisek, třeba stylem co služba to článek. Můžeš vytvářet odkazy na neexistující články, tento seznam pak může sloužit i jako todo. Články to má verzované, i to se hodí. Nakonec z toho máš soukromou knowledge base. Nejhorší je se přinutit to tam poctivě psát. S tím ti to nepomůže.

Pro často měněné configy (u mě firewall) jsem si zařídil svn repositář. Pokud člověk dodržuje zásady commitu (commit by měl být co nejmenší a měl by obsahovat jednu ucelenou část, každý commit musí mít komentář), dost to pomůže udržovat pořádek v konfigu samotném.

Celé /etc denně zálohuji pomocí rsnapshot. Můžeš těch verzí mít pak třeba tisíc, spotřebované místo je minimální. Já to používám spíš jako ochranu proti nechtěnému smazání.

[xkucf03]

 

Zkus lokální wiki (já používám klasickou mediawiki).

 

Já si zase tyhle poznámky píšu do blogu – nezobrazuji je na titulní stránce, protože by toho tam bylo moc, ale dávám je pod štítek Taháky a snadno se k nim dostanu odkudkoli A možná na ně občas zabrousí i někdo jiný.

[1john2]

poctivě psát se přinutím, stačí si vzpomenout na ten bordel co v tom mám teď a brzo mě přejde chuť neudržovat to..

poznámky sem v tomhle případě myslel spíš popisy změn v těch cfg...

jak je to s mediawiki a přikládáním souborů? dají se v tom držet i ty configy? nebo ty mít v svn/git/ap? rád bych jedno řešení...

správu todo, odkazů a vykopírovaných kousků textu z netu bych teď už do toho netahal.. to měl být příští dotaz, až rozjedu tohle:)

[Heron]

jak je to s mediawiki a přikládáním souborů? dají se v tom držet i ty configy? nebo ty mít v svn/git/ap? rád bych jedno řešení...

Určitě bych to držel oddělené. Stejně potřebuješ místo, kam si psát různé HOW-TO, poznámky, než se ti to dostane do krve. Hezky bod za bodem. Na toto se ti právě bude hodit ta wiki. Je to formátovaný text, vypadá to hezky, dá se to tisknout.

Do wiki lze přikládat i soubory, též jsou tam verzované. Ale jako náhrada za VCS je to nepoužitelné.

[1john2]

díky za inspiraci, mám ušetřený jeden dotaz:) ale teď si poznámky z oživení (zatím) naházím do souboru...

[daeltar]

 a nebo místo wiki třeba backpack (http://backpakit.com)

[vlk]

na to pouzivam git

[1john2]

někam sem asi vnitřně směřuju, můžete napsat nějaké praktické poznámky, názory, postřehy?

řešil jste různé verzovací systémy? proč zrovna tenhle?

jak zálohujete? snapshoty?

jakou v tom máte strukturu? co všechno s tím udržujete?

[NN]

-Nainstaluju cistej system.

-Nainstaluju SW.

-Kazdou zmenu konfigurace systemu i SW ukadam do root-a.

-Jednou za cas pozalohuju celou "konfiguraci".

-Kdyz se server zrusi vratim se do bodu 1 a pouziju zalohovanou konfiguraci.

-Stale dokola.

NN

[1john2]

co popisy změn? nepotřeboval jste někdy zjistit jaké kroky jste dělal za sebou? jak ukládáte? všechny změny do jednoho souboru, nebo několik "odatumovaných" souborů?

já to teď řeším tak, že jednou za čas odkopíruju

/etc, /var/lib, ~/bin

ale vzhledem k tomu, že mám podobné configy na serveru i na ntb(oboje debian) je to nepřehledné, nevím jaké změny se udály mezi jednotlivými verzemi..

[NN]

Myslite komentar..do konfiguraku, nekdy.

Jake kroky?

Zalohuju pouze to co jsem sam zmenil.

NN

[frEon]

Tohle vsechno ti vyresi prave ten git. Zalohovani muzes vyresit hookem, kdy ti git hned po commitu odlije soubory do zalohy.

[1john2]

dík za ten tip na hook:) jdu zjistit co je to zač

je nějaký důvod, proč zrovna git, oproti třeba svn?

[frEon]

svn moc neznám, takže nejsem dost povolaný na nějaké porovnání. Git mám radši, je jednoduchý a dobře se mi s ním pracuje.

[vlk]

git pouzivam len nad /etc/ kde je asi najviac vsetkej konfiguracie.

dovody su:

- jeho repozitar je ulozeny v jednom adresari .git, narozdiel od svn, ktory si uklada uplne vsade .svn podadresare a repozitar musi byt niekde inde, tiez je rychly a cely archiv zabera ovela menej nez svn

- je mozne repozitar synchronizovat aj s nejakym inym sietovym (git remote, git push, ...) koli zalohovaniu

- vyuzivam to najma aby som vedel co kedy sa zmenilo, takze po aktualizaciach alebo zmenach vzdy zmeny commitnem (git commit), pripadne este predtym pridam nove subory do repozitara (git add .)

- mozem si robit znacky (git tag ...)

- pozriet si zmeny suborov medzi jednolivymi verziami (git diff....)

... jednoducho klasicky verzovaci system ktory je aj jednoduchy a pride mi jednoduchsi nez svn, alebo cvs (ostatne som neskusal). pouzivam ho najma na programatorske projekty, ale aj na /etc

a ma parkrat aj zachranil ked som si rozbil nejaku konfiguraciu. skvele je ze vobec nemusim vytvarat nejake .bak, ... v ktorych po case aj tak clovek ma len bordel

 

[1john2]

dík přesně tohle sem chtěl slyšet jdu zkusit git a pak napíšu něco do blogu jak sem pochodil:)

[vlk]

ziadna veda:

 cd /etc
 git init
 git add .
 git commit -a -m "initial release"

[pht]

A jak se to chová k citlivým souborům (shadow) ?

[xkucf03]

viz můj komentář – musíš ochránit celé úložiště (git, mercurial…), aby k němu mohl jen root.

[Heron]

Tyhle 4 řádky jsou o gitu všude.

U svn mám repositář na jednom místě. Každý commit (odkudkoliv) ta data tlačí právě tam. Stačí mi zálohovat toto jedno místo. Když to někdo udělá naznačeným způsobem v gitu tak musí zálohovat tuhle /etc/.git, támhle /var/named/.git atd. Pokud totiž bude chtít mít centrální gití repos, tak musí po každém commitu udělat jestě git push.

[xkucf03]

U svn mám repositář na jednom místě.

Tohle moc nechápu – vždyť subversion přece vytváří .svn v každém adresáři – v tom  se mi víc líbí hg/git, kde takový adresář je jen jeden – v rootu daného úložiště. Centrální úložiště by se dalo řešit tak, že bys ten init udělal v rootu souborového systému a složky jako /usr, /home, /tmp … bys dal do .hgignore (nevím, jak se to jmenuje v gitu) – pak by stačilo zálohovat /.hg (resp. /.git), kde by bylo všechno na jednom místě.

[Heron]

To .svn je pouze pracovní adresář, není to úložitě pro repositář. Commit jde vždy na server (ať již přes file, svnrepo, webdav), který je pro fci svn klíčový.

Toto jde u gitu udělat druhým repositářem, který se prohlásí za server. Zde je ale nutné po každém commitu u klienta udělat git push. Snad to píšu dobře, s gitem si vyloženě nerozumím.

[xkucf03]

Jo už rozumím – je to jedna z výhod nedistribuovaných verzovacích systémů (jednodušší práce, jen commit, místo commit+push).

[frEon]

Toto jde u gitu udělat druhým repositářem, který se prohlásí za server. Zde je ale nutné po každém commitu u klienta udělat git push. Snad to píšu dobře, s gitem si vyloženě nerozumím.

Ten push po commitu jde pohodlně udělat pomocí hooku

[1john2]

hmm zálohovat více lokací se mi nechce, nadruhou stranu, stejně to bude v cronu, tak je celkem jedno jestli jedno místo, nebo několik...

co konkrétně udělá git push? vezme třeba /etc/.git a zazálohuje do nějakého centrálního repa?

[Heron]

co konkrétně udělá git push? vezme třeba /etc/.git a zazálohuje do nějakého centrálního repa?

Git je distribuovaný systém správy versí. Tedy můžeš mít hlavní repositář (říkejme mu teď server), z něj si uděláš clon do /etc (tomu říkejme klient). Pokud chceš všechny commity klienta mít i na serveru musíš za každým commitem udělat i push.

To co radí kolega výše, tedy vytvoření repa v /etc není napojeno na server. Tedy ty si můžeš ukládat verze konfigů, ale smazáním /etc/ přijdeš i o ten git repositář a tedy i o veškerou historii.

Musel bys tedy pravidelně zálohovat celé /etc včetně toho repositáře.

svn pracuje jinak. Tam potřebuješ server vždy. Tedy commit v /etc ti data vždy pošle na server. Tento jeden server můžeš použít pro ukládání všeho. Konfigů, svých dokumentů, projektů do školy apod. Při smazání /etc/ pak stačí pouze udělat svn checkout. Stačí ti zálohovat jeden server.

[1john2]

tohle už zavání otázkou jakou zvolit strukturu toho repa?

jedno velké na vše a do toho adresáře? co když budu chtít verzovat dva stroje? dva repozitáře nebo pořád jeden, třeba i včetně věcí do školy?

spoustu malých repozitářů? asi se bude blbě zálohovat.. jde přenést historie z toho klonu repozitáře v /etc na server?

začíná mi připadat, že svn bude pro mě vhodnější...

[Heron]

Jde to tak i tak. Já mám na každou kravinu zváštní repo. Někdo cpe vše do jednoho. Rekl by, že na tom moc nezáleží. Objem dat je stejný. Rychlost asi taky.

[1john2]

co bezpečnost vůči učícímu se uživateli? sou potenciálně likvidační  příkazy pro repo?

když pro začátek udělám malé repa, a později je budu chtít sloučit co pro to bude vhodnější? svn nebo git? když budu mít mnoho rep, dá se jednoduše zjistit na čem sem dělal řekněme za poslední týden?

[Heron]

Uživatel zničit repo svými příkazy nemůže.

Repo lze pouze zničit administrátorskými zásahy na svn serveru. Ať již klasické rm -rf, nebo nesprávným použitím svnadminu. Ale od toho jsou zálohy.

když budu mít mnoho rep, dá se jednoduše zjistit na čem sem dělal řekněme za poslední týden?

Musel bys projít všechna a zjistit cos tam kdy udělal.

Co se týče git vs svn, raději si to projdi sám. K svn je někde velmi pěkné PDF. Po oběde najdu a hodím to sem.

[1john2]

není to tohle? Má to 1.6M a je to moc velké pro přílohu na ábíčku..

btw: taky Vám nejde odstranit přílohu k příspěvku? po vybrání přílohy, chybové hlášce ábíčka o velikosti už nešlo smazat cestu k souboru a musel jsem vytvořit nový příspěvek.. iceweasel 3.0.9-1 debian squeeze 64bit, plugin vimperator

[Heron]

Je.

[1john2]

vzpomněl jsem si, že to mám schované ve složce linux, kdyby to někdy bylo potřeba jdu se na to mrknout...

každopádně díky moc za pomoc a cenné rady honza

[Heron]

Rádo se stalo. Sice jsem ještě nebyl na tom obědě, ale našel jsem URL, kde to roste:

http://svnbook.red-bean.com/

[1john2]

díky, přeju dobrou chuť a ať je na ten oběd čas co nejdřív...

[1john2]

jak se zálohuje úložiště git/svn? můžu ho vzít a zkopírovat jinam? někde jsem četl něco jakože repozitář nesmím zkopírovat jinam, ale možná si to s něčím pletu/blbě sem to pochopil

[Heron]

svnrepo umožnuje udělat dump. Denně budeš zálohovat dumpy ze svn serveru, v případě havárie je pak obnovíš. Je to velmi podobně jako záloha DB.

svn repositář by se neměl kopírovat po souborech. Může nastat problém s verzemi svn. Data máš ze staré, chceš to dát na novou. Dump funguje spolehlivě.

[Andrej Herceg]

Pri každom systéme sú nástroje, ktorými sa tie dáta zálohujú (takže ich má aj git, ale technicky stačí skopírovať adresár .git).

[Andrej Herceg]

Když to někdo udělá naznačeným způsobem v gitu tak musí zálohovat tuhle /etc/.git, támhle /var/named/.git atd.

Toto by sa dalo vyriešiť tak, že by sa kontroloval root adresár a do .gitignore by sa dalo pravidlo, aby sa všetky podadresáre ignorovali a povolili by sa tam len tie potrebné.

PS: Samotný adresár .git sa môže umiestniť kamkoľvek (nemusí byť v tom root adresári).

[1john2]

hmm tohle mi připadá že bych z nulových zkušeností s verzováním měl skočit docela hluboko do konfigurace...

našel jsem seriál o gitu na root.cz jdu se na něj mrknout

[Andrej Herceg]

Okrem "čistého" git sa dá použiť aj napr. etckeeper. Etckeeper podporuje okrem git aj iné VCS a dokáže automaticky uložiť zmeny po inštalovaní nejakého balíku (ale pravdepodobne len na systémoch s apt).

[1john2]

apt není problém jsem na debianu...

má etckeeper nějaké výhody oproti normálnímu git?

[1john2]

krom těch apt změn

[Andrej Herceg]

VCS sa zvyčajne príliš nestarajú metadáta súborov (zvyčajne sa maximálne zaujímajú o to, či má ten súbor execute príznak a ostatné atribúty, vlastník, skupina... ich nezaujíma). Ak ide len o archivovanie zmien v tých súboroch, tak to ale vadiť nemusí. Etckeeper tieto údaje ukladá a tiež ukladá informácie o prázdnych adresároch (keďže git a napr. aj mercurial prázdne adresáre ignorujú).

Takže v závislosti od toho, čo presne sa má ukladať môže, ale aj nemusí, stačiť aj samotný git.

Inak podobných nástrojov ako je etckeeper existuje viac, momentálne mi ešte napadá etcgit.

[1john2]

můžu se zeptat co je to vcs? z gl vypadlo tohle, ale nedává mi to smysl..

jdou nástroje jako etckeeper nastavit pro zálohování adresářů i mimo /etc? například ~/bin /var/lib ap.

[Andrej Herceg]

můžu se zeptat co je to vcs? z gl vypadlo tohle, ale nedává mi to smysl..

wikipedia:VCS

jdou nástroje jako etckeeper nastavit pro zálohování adresářů i mimo /etc? například ~/bin /var/lib ap.

Predpokladám, že asi nie (aspoň nie jednoduchým spôsobom). Navyše, podľa mňa, v /bin, /usr/var/lib nie sú súbory, pri ktorých by malo zmysel archivovať si zmeny.

[1john2]

Predpokladám, že asi nie (aspoň nie jednoduchým spôsobom). Navyše, podľa mňa, v /bin, /usr/var/lib nie sú súbory, pri ktorých by malo zmysel archivovať si zmeny.

nemluvil jsem o /bin ale o ~/bin což jsou moje skripty

ve /var/lib jsou například dhcp leases(sleduju kdo je na síti, než udělám něco lepšího), nebo tor fingerprint a keys, které bych chtěl mít zálohovány stejným způsobem jako zbytek věcí ve stroji

[Heron]

Aby nedošlo k mýlce. Verzovací systémy nejsou určeny na obecnou zálohu. Ten server musíš zálohovat tak jako tak. VCS ti dává pouze možnost mít historii souborů, nic víc.

[1john2]

dobré vědět já doufal, že to použiju i jako zálohu, no co už zálohování vyřeším posléze

[xkucf03]

Ono to jde použít i místo záloh – např. když máš webový server, více méně čistý Linux, verzuješ /etc, /var/www a textový dump z databáze. Samozřejmě verzuješ na nějaký jiný stroj (nebo přinejmenším disk). Když se celý server zhroutí, stačí znovu nainstalovat Linux, nainstalovat pár balíčků (chce to mít jejich seznam, aby je člověk nemusel lovit z paměti nebo znovu vymýšlet) a obnovit z verzovacího systému nastavení, weby a databázi.

Potíž při tomhle přístupu je akorát při velkých objemech a často se měnících datech – u zálohy se snadno smaže stará verze a člověk si může udržovat jen aktuální verzi – zatímco verzovací systém uchovává celou historii (i ty verze, o které už nestojíš).

[xkucf03]

Používám mercurial (hg) – verzovací systém. Víš, co jsi kdy měnil, můžeš si psát poznámky, vracet se zpátky. Taky poznáš, co se přesně změnilo během instalace aktualizace balíčků.

Akorát je potřeba dát pozor na práva k adresáři .hg (pro git platí totéž) – vlastníkem je root a nikdo jiný k těm souborům nemá přístup – jinak by si totiž obyčejný uživatel mohl „naklonovat“ toto mercurialové úložiště a dostat se k souborům, které jsou normálně chráněné přístupovými právy (např. soukromé šifrovací klíče, certifikáty).

[1john2]

nějaká výhoda mercurialu oproti git?

[xkucf03]

Nevím. Jsem zvyklý na Mercurial

Ale teď jsem si stahoval nějaké zdrojáky v gitu a jsou si hodně podobné.