controllo versione per / etc in * BSD

Quali soluzioni chiavi in ​​mano esistono per mettere /etcsotto controllo delle versioni, sotto vari sistemi? Chiavi in ​​mano non significa necessariamente parte dell'installazione di base, ma le seguenti funzionalità sarebbero utili:

• si aggancia ai comandi VCS per gestire i metadati (proprietà, autorizzazioni);
• integrazione con il gestore pacchetti (eseguito automaticamente prima e dopo le installazioni, gestire gli aggiornamenti in modo intelligente);
• tratta le versioni dei file upstream come un ramo;
• un elenco ignorato pre-compilato;
• supporto per diversi VCS sottostanti (specialmente quelli distribuiti).

Uso etckeeper sotto Debian e derivati. Ha tutte le funzionalità di cui sopra, tranne per il fatto che non tiene traccia delle versioni upstream. Mi piacerebbe conoscere le alternative, in particolare su * BSD.

Sotto Gentoo lo strumento per gestire le modifiche indotte dal pacchetto a / etc (chiamato dispatch-conf) supporta rcs per tenere traccia delle modifiche ma non è molto potente.

Tendo a versione mio / etc via git, soprattutto perché usando diversi rami posso mantenere il mio / etc il più simile possibile su diverse distribuzioni possibile, mantenendo quante più cose in un posto il più possibile (per alcune aree che ovviamente falliscono, configurazione di Apache per esempio è molto diverso tra le diverse distribuzioni). Funziona così:

Ho il mio masterrepository con i miei file di configurazione predefiniti. Ora vengo in contatto con una nuova distro, quindi creo un nuovo ramo basato sul mio masterramo in base al nome della distribuzione (in questo esempio debian). Debian mantiene alcuni file di configurazione in una posizione diversa dalla mia, masterquindi faccio un git mv file new_loc. E va tutto bene. Torno indietro mastere cambio quel file perché ho aggiunto una specifica direttiva di configurazione, quando unisco masternel mio debianramo il file spostato viene cambiato, quindi posso sostanzialmente cambiare la maggior parte delle cose all'interno del mio masterramo e devo solo unire le modifiche nella mia "distribuzione" rami (di solito tendono ad essere più di una combinazione di rami di distribuzione e di scopo, un server debian ha ovviamente delle differenze rispetto a una stazione di lavoro debian ma le funzionalità funzionano ancora).

Quindi fondamentalmente ho una "configurazione generica" mastere (per dirla in termini di programmazione orientata agli oggetti) eredito quelli nei miei rami (che possono anche ereditare gli uni dagli altri).

A parte questo, giti meccanismi di "cherry-pick" di commit (in questo caso le modifiche a / etc /) mi sono stati di grande aiuto in momenti in cui avevo solo bisogno di parti di una certa configurazione.

Ora ad alcune delle tue idee:

• Se avessi bisogno di una maggiore integrazione del gestore pacchetti, probabilmente userei gli script wrapper per questo (al momento non lo faccio).
• trattando le versioni upstream come un ramo funzionerebbe bene git, è solo un altro ramo in cui a volte unisci (parzialmente)master
• L'elenco ignore in git è il file .gitignore nel tuo repository in modo da essere coperto.

Ho usato fossilper questo con un certo successo. Vedi il mio post su Fossil per maggiori informazioni. Ho anche usato uno strumento chiamato etcupdateche è più per lo spostamento tra gli aggiornamenti che il rilevamento delle modifiche. Credo che freebsd-updatea un certo punto doveva essere uno strumento complementare . Non sono sicuro del suo stato al momento, ma funziona sui miei RELEASE-8.*sistemi.

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

C'è uno strumento chiamato etckeeper Non ho idea di quanto sia bello.

etckeeper è una raccolta di strumenti per lasciare / etc in un repository git, mercurial, darcs o bzr. Si collega a apt (e ad altri gestori di pacchetti tra cui yum e pacman-g2) per eseguire automaticamente il commit delle modifiche apportate a / etc durante gli aggiornamenti del pacchetto. Tiene traccia dei metadati che i sistemi di controllo revison normalmente non supportano, ma questo è importante per / etc, come i permessi di / etc / shadow. È abbastanza modulare e configurabile, pur essendo semplice da usare se si comprendono le basi per lavorare con il controllo di revisione.

Inoltre, non so se può essere fatto funzionare su * BSD, sospetto, ma che non sarà supportato con le porte predefinite.