Controllo della versione per /etc Sotto *bsd?

Quali soluzioni chiavi in ​​mano esistono per inserire /etc sotto il controllo della versione, sotto vari unice? 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 di pacchetti (esegui automaticamente prima e dopo l'installazione, gestisce gli aggiornamenti in modo intelligente);
• tratta le versioni dei file a monte come un ramo;
• un elenco da ignorare precompilato;
• supporto per diversi VCS sottostanti (soprattutto 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 a monte. Vorrei conoscere le alternative, in particolare su *BSD.

Risposta accettata:

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

Tendo a eseguire la versione del mio /etc tramite git , soprattutto perché usando rami diversi posso mantenere il mio /etc il più simile possibile su diverse distribuzioni, pur mantenendo quanta più roba possibile in un posto (per alcune aree che ovviamente falliscono, la configurazione di Apache, ad esempio, è davvero diversa tra le diverse distribuzioni). Funziona così:

• Ho il mio master repository con i miei file di configurazione predefiniti.

• Ora vengo in contatto con una nuova distribuzione, quindi creo un nuovo ramo basato sul mio master branch basato sul nome della distribuzione (in questo esempio debian).

• Debian conserva alcuni file di configurazione in una posizione diversa dal mio master quindi faccio un git mv file new_loc . E va tutto bene.

• Torno a master e cambia quel file perché ho aggiunto una specifica direttiva di configurazione.

• Quando unisco master nel mio debian branch il file spostato viene modificato, quindi posso sostanzialmente cambiare la maggior parte delle cose all'interno del mio master branch e devo solo unire le modifiche nei miei rami di "distribuzione" (di solito tendono ad essere più un mix di distribuzione e rami di scopo, un server Debian ha alcune differenze rispetto a una workstation Debian ovviamente, ma le funzionalità funzionano ancora).

Quindi in pratica ho una "configurazione generica" ​​in master e (per dirla in termini di programmazione orientata agli oggetti) eredita quelli nei miei rami (che possono anche ereditare gli uni dagli altri).

A parte questo, git I meccanismi di 's per i commit "cherry-pick" (in questo caso cambia in /etc/ ) mi è stato molto utile nei momenti in cui avevo bisogno solo di parti di una determinata configurazione.

Correlati:eseguire il comando unix con precisione a intervalli molto brevi SENZA accumulare ritardi nel tempo?

Passiamo ora ad alcune delle tue idee:

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