kontrola wersji dla / etc pod * BSD

Jakie są rozwiązania „pod klucz”, które można poddać /etckontroli wersji pod różnymi jednorożcami? Pod klucz niekoniecznie oznacza część instalacji podstawowej, ale przydatne byłyby następujące funkcje:

• przechwytuje polecenia VCS w celu zarządzania metadanymi (własność, uprawnienia);
• integracja z menedżerem pakietów (uruchamiane automatycznie przed i po instalacji, inteligentnie obsługuj aktualizacje);
• traktuj wcześniejsze wersje plików jako gałąź;
• wstępnie wypełniona lista ignorowanych;
• obsługa kilku bazowych VCS (szczególnie rozproszonych).

Używam etckeeper pod Debianem i pochodnymi. Ma wszystkie powyższe funkcje, z wyjątkiem tego, że nie śledzi wcześniejszych wersji. Chciałbym dowiedzieć się o alternatywach, szczególnie na * BSD.

W Gentoo narzędzie do zarządzania wywołanymi przez pakiet zmianami w / etc (zwanym dispatch-conf) obsługuje rcs do śledzenia zmian, ale to nie jest tak naprawdę potężne.

Mam tendencję do wersjonowania mojego / etc poprzez git, szczególnie, że używając różnych gałęzi mogę utrzymać mój / etc tak podobny, jak to możliwe, w różnych dystrybucjach, jak to możliwe, jednocześnie utrzymując jak najwięcej rzeczy w jednym miejscu, jak to możliwe (dla niektórych obszarów, które najwyraźniej zawodzą, konfiguracja apache na przykład różni się w zależności od dystrybucji). Działa to tak:

Mam moje masterrepozytorium z moimi domyślnymi plikami konfiguracyjnymi. Teraz nawiązuję kontakt z nową dystrybucją, więc tworzę nową gałąź na podstawie mojej mastergałęzi na podstawie nazwy dystrybucji (w tym przykładzie debian). Debian przechowuje plik konfiguracyjny w innej lokalizacji niż moja, masterwięc robię git mv file new_loc. I wszystko w porządku. Przełączam się z powrotem masteri zmieniam ten plik, ponieważ dodałem jakąś konkretną dyrektywę config, kiedy scalam masterz moją debiangałęzią, przenoszony plik jest zmieniany, więc mogę w zasadzie po prostu zmienić większość rzeczy w moim masteroddziale i po prostu scalić zmiany w mojej „dystrybucji” gałęzie (zwykle są one raczej połączeniem gałęzi dystrybucji i gałęzi celu, serwer debian ma pewne różnice w stosunku do stacji roboczej debian, ale funkcje nadal działają).

Tak więc w zasadzie mam „ogólną konfigurację” masteri (mówiąc to w obiektowych terminach programistycznych) dziedziczę je do moich gałęzi (które również mogą dziedziczyć od siebie).

Poza tym gitmechanizmy zatwierdzania „cherry-pick” (w tym przypadku zmiany w / etc /) były dla mnie bardzo pomocne w czasach, gdy potrzebowałem tylko części określonej konfiguracji.

A teraz niektóre z twoich pomysłów:

• Gdybym potrzebował większej integracji z menedżerem pakietów, prawdopodobnie użyłbym do tego skryptów opakowujących (na razie nie).
• traktowanie wcześniejszych wersji jako gałęzi działałoby dobrze git, jest to po prostu kolejna gałąź, do której czasami się scalasz (częściowo)master
• Lista ignorowanych plików w git to plik .gitignore w repozytorium, który jest objęty.

Wykorzystałem fossilto z pewnym powodzeniem. Zobacz mój post o Fossil, aby uzyskać więcej informacji. Użyłem również narzędzia o nazwie, etcupdatektóre służy raczej do przechodzenia między aktualizacjami niż do śledzenia zmian. Uważam, że freebsd-updatew pewnym momencie miało to być narzędzie towarzyszące . Obecnie nie jestem pewien jego statusu, ale działa na moich RELEASE-8.*systemach.

http://lists.freebsd.org/pipermail/freebsd-current/2010-June/017927.html http://people.freebsd.org/~jhb/etcupdate/

Istnieje narzędzie o nazwie etckeeper. Nie mam pojęcia, jak dobre jest.

etckeeper to zbiór narzędzi do przechowywania / etc w repozytorium git, mercurial, darcs lub bzr. Łączy się z apt (i innymi menedżerami pakietów, w tym yum i pacman-g2), aby automatycznie zatwierdzać zmiany wprowadzone w / etc podczas aktualizacji pakietów. Śledzi metadane plików, które zwykle nie są obsługiwane przez systemy kontroli rewizji, ale jest to ważne dla / etc, takich jak uprawnienia / etc / shadow. Jest dość modułowy i konfigurowalny, a jednocześnie łatwy w użyciu, jeśli rozumiesz podstawy pracy z kontrolą wersji.

Nie wiem też, czy można go uruchomić na * BSD. Podejrzewam, że tak, ale nie będzie obsługiwany z portami po wyjęciu z pudełka.