Jak si udržovat historii /etc v gitu

7.7.2007 13:15 | Přečteno: 2012× | Software |

V dnešní době již nebývá nedostatek diskového prostoru a nebývá tedy potřeba šetřit každý bajt. Jedním ze způsobů, jak "plýtvat" úložným prostorem je zaznamenávat si, jak se některé soubory měnily v čase. Když si pak člověk omylem smaže, přepíše, nebo změní špatným směrem některé z nich, má možnost se vrátit v čase zpátky.

Pokusím se ukázat nezbytné minimum z používání gitu ke správě například historie svého /etc. Git je v repozitářích většiny běžných distribucí a tak by neměl být problém jej z nich nainstalovat. Tento zápisek se vztahuje k verzi 1.5.1.6, ale snad by měl být relativně nadčasový.

Skáčeme po hlavě

Git pracuje s jednotlivými repozitáři, jejichž data bývají často umístěny v adresáři .git v nejvyšším adresáři daného repozitáře. Tento adresář si vytvoříme jednoduše tak, že se přesuneme do daného adresáře a napíšeme

#git init
Initialized empty Git repository in .git/

Tímto máme inicializovaný repozitář, ale ještě do něj nepatří žádné soubory. To snadno napravíme tak, že nejdříve řekneme, že budeme chtít přidat vše v tomto adresáři

#git add -- .

A poté commitneme (zapíšeme do repozitáře) avizované změny (pomocí git add)

#git commit

Tento příkaz nám spustí náš oblíbený editor z proměnné prostředí EDITOR a bude po nás chtít, abychom v něm napsaly popis udělaných změn. Tento popis změn slouží čistě pro naši orientaci a tudíž je na každém z nás, co si napíše, datum zapsání, rozdíly, přidané/odebrané soubory lze samozřejmě vyčíst odjinud, takže by mělo jít o jakésy shrnutí, k čemu to bylo.

Rutina

Zatím máme repozitář, ve kterém máme uložený výchozí stav. Nicméně by asi bylo dobré také zaznamenávat jednotlivé změny. Pro vypsání změn oproti uloženému stavu slouží příkaz git-status, jehož výpis je velmi samopopisující se.

Pakliže chceme provedené změny zaznamenat do repozitáře, nejdříve musíme gitu říct, jaké změny budeme chtít sledovat, v případě /etc budeme pravděpodobně chtít sledovat všechny soubory a tudíž zavoláme

#git add -- .

čímž řekneme, že budeme chtít zapsat stav všech souborů v daném adresáři (včetně doposud nesledovaných). Poté zavoláme

#git commit -a

Tímto příkazem sice částečně překrýváme funkci git add -- ., aneb připravení zapsání změn již sledovaných souborů, nicméně git add -- . navíc připraví zapsání vytvoření zatím nesledovaných souborů, a parametr -a u commitu zase navíc oproti add zaznamená v repozitáři případné smazání sledovaných souborů. Pakliže jsme líní a nechceme pokaždé lézt do editoru pro zapsání commit message, můžeme ji specifikovat parametrem -m při commitu, např. pokud bychom chtěli mít v cronu naplánováno jednou za čas automaticky zapsat změny v /etc, můžeme použít sekvenci příkazů

cd /etc && git add -- . && git commit -a -m "cron automated commit"

A dál?

Zatím jsme tedy schopni zaznamenávat historii změn, a jak se jí procházet? Nejméně náročné je asi použít nějaké klikátko stylu qgit, či git-gui, které bývá přibaleno v balíku přímo s gitem. Jelikož mne přestává bavit psát, milovníky příkazové řádky budu muset odkázat na zkoumání dokumentace

Bezpečnost

Nesmíme ovšem zapomenout, že v /etc je několik souborů, které by neměl přečíst nikdo, krom roota a tudíž doporučuji k danému git repozitáři zakázat přístup kohokoliv jiného, než vlastníka (roota)

#chmod 700 /etc/.git

       

Komentáře

[KS]

Díky za článek, fakt dobrý. O verzování konfiguráků jsem párkrát uvažoval. Mohlo by se to dostat do distribucí jako běžná věc.

[Georgo10]

Taktéž děkuji -- O nějaké záloze /etc jsem vždycky uvažoval, ale nápad použít verzovací systém, mi hlavou nebleskl Určitě vyzkouším, ještě jednou díky

[Josef Kufner]

To by nemuselo být špatné... ale jsem moc líný, takže by to chtělo napojit na apt, aby se to ukládalo samo. Nejlépe vždy před a po nějaké instalaci/upgrade/čemkoliv.

[Petr "Glubo" Sýkora]

Naprosto souhlasím, sám přemýšlím, jak nejlépe to napojit na portage, zatím to řeším cronem daily (uvedený kombo příkaz je copy&paste z mého cronu), což mi přijde jako dostatečné, nikoliv však ideální řešení. Dokonce se git chová tak, že pokud není nic ke commitnutí, ignoruje commit a tudíž nevzniká tisíce zbytečných commitů, což mne mile překvapilo

[David Watzke]

Mně se /etc zálohuje každej den ráno na server a docela to stačí...

[Josef Kufner]

Ono tady jde spíš o tu historii a možnost kouknout se, co se vlastne kdy změnilo. V tom mají nástroje na správu verzí precejen nějaké ty výhody oproti hromádce adresářů...

[Petr "Glubo" Sýkora]

No já si zase mohu jedním příkazem vypsat histrorii změn v jednom souboru/adresáři pomocí git-whatchanged -p soubor, což mi vypíše kdy se ten soubor měnil a diffy jednotlivých změn.

[disorder]

a komu venujes ten /etc/shadow kazde rano?

[Käyttäjä 11133]

A není to jedno, jaká je šance že ty hashe rozlousknou? Moc velká asi ne. Teda pokud nemá lehce uhodnutelná hesla. Nebo útočník pár s390 ve sklepě :)

[disorder]

radsej poloz otazku, aka sanca bude zajtra/o tyzden/etc...

[Käyttäjä 11133]

No správný paranoik mění hesla každý týden

[disorder]

a to je nejaka prekazka tomu, ze ti to niekto zajtra moze rozlusknut za 30 sekund?

[David Watzke]

Teda pokud nemá lehce uhodnutelná hesla

nbusr123

[David Watzke]

Je to u Zdendy na serveru (klenot.cz) a adresář backup má přístupový práva 700. Můžu být v klidu

[disorder]

no bodaj by si tomu nedal 700, to uz by bol naprosty vysmech bezpecnosti :D

v kazdom pripade by si z toho mohol mazat hashe, to nie je problem...

[Josef Kufner]

A nebo to během přenosu na server šifrovat.

[disorder]

ja by som to v plaintexte neukladal ani na vlastny server...

[onion]

Jeste doplnim, ze prikazem

git-config color.diff auto

bude vystup z git-whatchanged (a vsech ostatnich diffu) pekne barevny. Chvilku mi trvalo nez jsem na to prisel, takze tim treba nekomu ulehcim praci :D

[User682]

zdravim,

git nejaky mesic pouzivam. Skvely nastroj. Ale par veci jsem nerozlousknul.

Nepouzivate nahodou nekdo git na vice projektu, ktere maji zcasti stejny zaklad ?

Neco delam asi spatne nebo nechapu filosifii uzivani gitu. Nebo je to mozna mimo moznosti gitu.

Dam priklad:

testuji ruzne kernely a pripadne hledam zmeny a chyby. Dovedu si vyexportovat aktualni zdrojaky, najit zmeny, udelat nejaky bisect, pripadne si zmergovat zmeny.

Ale zda se mi trochu neefektivni mit specielne na kernel 2 ruzna uloziste.

Mam:

- linus-uv kernel

- mm-kernel

- thinkpad-acpi

A ted jak si usporadat uloziste (repositare) ?

Mit vse v jednom reposiraci nebo mit 3 repositare ?

Jak na to ? A jak se pripadne prepinat mezi repositari a vyexportovat si konkretni zdrojaky k danemu datu ?

Tato vec mi vcelku brani dostat se dale.

Jak by jste toto resili? Predem diky.

Pavel Kysilka

[michich]

Nevím, jestli to má cenu dělat i s -mm kernely, protože Andrew Morton je udržuje pomocí quiltu a git strom je až sekundární reprezentace. Já je tahám zvlášť pomocí ketchupu.

Ale s tím thinkpad-acpi jsem si to teď zkusil. Vlezu do adresáře, kde mám Linusův strom a pár svých místních větví. Řeknu gitu, že budu chtít sledovat další vzdálený repozitář:

git-remote add ibm-acpi \
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

Stáhnu si ho k sobě:

git-fetch ibm-acpi

Podívám se, jaké větve tam mají:

git-branch -r

Budu chtít pracovat s větví devel, tak si udělám místní větev, která jí bude odpovídat (a git-pull mi ji bude umět aktualizovat):

git-branch --track ibm-acpi ibm-acpi/devel

Přepínám se pomocí git-checkout.

Nevím, jestli je to ideální způsob. Jestli to někdo děláte jinak a lépe, tak by mě to zajímalo.

[User682]

Co se tyce mm-kernelu, tak bych rad redukoval primerene traffic a nerad bych tahal cele tarbally. Vcelku je pro me mm-kernel dulezity - hodne chyb se najde drive nez v linus-kernelu.

Nicmene podle Vaseho navodu pujde tahat primo z git:// zdroje mm-kernel.

Kazdopadne diky, s timto se pohnu hodne dale. Kdybych prisel na neco zajimaveho nebo vylepseneho, tak dam vedet.

Pavel Kysilka

[michich]

Ten ketchup, co na -mm používám, je docela chytrý. Netahá pokaždé znovu celé tarbally. Když už má nějakou předchozí verzi staženou, tak tahá diffy. Ve Fedoře i v Debianu se balíček jmenuje ketchup.

[Jiří Lisický]

Na jednoduché verzování konfiguráků používám systém rcs. Řekl bych, že balíček bude součástí téměř všech distribucí.

[Petr Tomášek]

Na tohle mi prijde jako idealni svn. Git ma podle me smysl az ve chvili, kdy je potreba predavat changesety z jednoho repositare do druheho...

[Petr "Glubo" Sýkora]

Asi jsem zaslepen buhví čím, ale v čem je svn lepší na tento úkol, než git? Zrovna u takto "nenáročného" úkolu mi přijde, že by svn mělo být srovnatelně vhodné.

[Josef Kufner]

Mno, spíš naopak. Git je vhodnější, protože není potřeba vytvářet repositář.

[Jiří (BoodOk) Kadeřávek]

Jeno pro upřesnění. Jedná se totiž stejně jako u např. Bazaar o tzv. decentralizovaný/distribuovaný systém správy verzí, narozdíl od centralizovaného systému jakými je např. SVN, CVS a další.

http://en.wikipedia.org/wiki/Revision_control
http://en.wikipedia.org/wiki/Git_(software)
http://en.wikipedia.org/wiki/Bazaar_(software)
http://en.wikipedia.org/wiki/Subversion_(software)

[Josef Kufner]

Ono ani nejde o to, že by byl decentralizovaný -- to jen souvisí s tím, že součástí pracovního adresáře je i kompletní repositář. Klíčovou vlastností gitu je to, že necpe do každého adresáře bordel jako to dělá svn a cvs. Protě bude jen /etc/.git a to je všecko. Ony adresáře .svn by dělaly problémy při změnách adresářů balíčkovacím systémem -- adresář není prázdný a tak ho nelze smazat...

[Jiří (BoodOk) Kadeřávek]

Takhle máš repository spolu s projektem. A naučit se pracovat a ovládat systém správy verzí není úplně triviální záležitost, tudíž rozhodně s ohledem na portabilitu u menších projektů (rozuměj 1-5 lidí) preferuji decentralizovaný model. Případné merge nejsou navíc v takové skupině až tak složité.