Kontrola verzí pro /etc pod *bsd?

Jaká řešení na klíč existují pro umístění /etc pod kontrolou verzí, pod různými unicy? Na klíč nutně neznamená součást základní instalace, ale následující funkce by byly fajn:

• zapojuje se do příkazů VCS pro správu metadat (vlastnictví, oprávnění);
• integrace se správcem balíčků (automatické spouštění před a po instalacích, inteligentní zpracování upgradů);
• zacházet s verzemi souborů proti proudu jako s větvemi;
• předvyplněný seznam ignorovaných;
• podpora několika základních VCS (zejména distribuovaných).

Používám etckeeper pod Debianem a deriváty. Má všechny výše uvedené funkce kromě toho, že nesleduje upstream verze. Rád bych se dozvěděl o alternativách, zejména o *BSD.

Přijatá odpověď:

Pod Gentoo nástroj pro správu změn vyvolaných balíčkem v /etc (nazývané dispatch-conf ) podporuje rcs pro sledování změn, ale to není moc výkonné.

Mám tendenci verzi /etc přes git , zejména proto, že pomocí různých větví mohu zachovat svůj /etc co nejpodobnější v různých distribucích a zároveň udržet co nejvíce věcí na jednom místě (pro některé oblasti, které zjevně selhávají, je například konfigurace Apache v různých distribucích opravdu odlišná). Funguje to takto:

• Mám svého master repo s mými výchozími konfiguračními soubory.

• Nyní přicházím do kontaktu s novou distribucí, takže vytvářím novou větev založenou na mém master větev na základě názvu distribuce (v tomto příkladu debian).

• Debian uchovává nějaký konfigurační soubor na jiném místě než můj master tak udělám git mv file new_loc . A všechno je v pořádku.

• Přepnu zpět na master a změňte tento soubor, protože jsem přidal nějakou specifickou konfigurační direktivu.

• Když sloučím master do mého debian větve se přesouvaný soubor změní, takže mohu v podstatě jen změnit většinu věcí ve svém master větev a musím sloučit změny v mých „distribučních“ větvích (obvykle bývají spíše mixem distribučních a účelových větví, debian server má samozřejmě určité rozdíly oproti pracovní stanici debianu, ale funkce stále fungují).

Takže v podstatě mám „obecnou konfiguraci“ v master a (řečeno v termínech objektově orientovaného programování) je zdědit do mých větví (které také mohou dědit jedna od druhé).

Kromě toho git 's mechanismy pro „cherry-pick“ commity (v tomto případě změny na /etc/ ) mi docela pomohl v době, kdy jsem potřeboval pouze části určité konfigurace.

Související:Spouštět příkaz unix přesně ve velmi krátkých intervalech BEZ hromadění časového zpoždění v průběhu času?

Nyní k některým z vašich nápadů:

• Kdybych potřeboval větší integraci správce balíčků, pravděpodobně bych k tomu použil obalovací skripty (v tuto chvíli ne).
• Zacházení s upstream verzemi jako s větvemi by fungovalo dobře s git , je to jen další větev, kterou občas sloučíte (částečně) do master
• Seznam ignorovaných v git je soubor .gitignore ve vašem úložišti, aby to bylo pokryto.