Il modo migliore per mantenere i file di configurazione sotto SVN?

Question

Qual è il modo migliore per mantenere i file di configurazione (ad esempio httpd.conf, my.cnf, .bashrc ...) sotto controllo di versione? In aggiunta al vantaggio della versione, voglio che la soluzione funzioni anche come backup, così posso portare un nuovo server e fare il checkout (o esportare) i file di configurazione direttamente da SVN

Un buon tocco sarà per memorizzare anche il percorso originale del file di configurazione.

Answer 1

Lo faccio per diverse macchine, che vanno dai vecchi Solaris 8 scatole di Mac OS X, e ho davvero un layout semplice:

Nel mio archivio ho il seguente:

<root>/common 
    /.emacs.d 
    /.bash_common 
    /scripts # platform-independent binary tools 

<root>/linux 
    .bashrc 
    .emacs 
    ... 

<root>/solaris 
    .bashrc 
    .emacs 
    ... 

<root>/osx 
    .bashrc 
    .emacs 
    ... 

Ogni dei homedirs del sistema operativo ha un riferimento svn: externals a .emacs.d, .bash_common e script, quindi quelli non sono duplicati.

Inoltre, ho un .bash_hostconfig nelle directory linux e solaris con configurazione del percorso specifico dell'host e tale, perché ho un setup molto diverso sul lavoro rispetto a quello che faccio a casa (FC5-8 e RHEL3-5, dipende da dove mi trovo).

Quindi, tra queste cose, ho un processo piuttosto semplice per essere installato e funzionante su una nuova macchina: controllo semplicemente la piattaforma/$ in una directory temporanea, quindi sovrascrivo tutto in $ HOME con quei file. Non ho bisogno di memorizzare il percorso originale, perché è sempre relativo a $ HOME in questo modo.

Answer 2

I revision-control i miei file di configurazione, ma io uso git invece di svn (che è più facile quando si hanno più macchine). Ho uno script di bash (chiamato install.sh), anch'esso sotto il repository, che copia o symlinks i file nella posizione appropriata su una macchina.

Quindi, se ho bisogno di installare su una nuova macchina, faccio solo un clone git del repository (che è equivalente a un checkout svn) ed eseguo il mio install.sh per impostare i miei file di configurazione nelle posizioni appropriate. Avere install.sh significa che sto anche memorizzando il percorso originale dei file di configurazione, come hai indicato che desideri.

Answer 3

Utilizziamo CVS per memorizzare le configurazioni in una struttura di directory che sia il più piatta possibile. Questa tecnica è facilmente estendibile a SVN.

allora abbiamo un Makefile impostato per l'uso CVS esportazioni verso:

1. creare una copia della struttura di directory CVS senza i componenti CVS,
2. creare la struttura di directory necessaria per il computer di destinazione nella vostra directory locale come se foste nella directory root sul computer di destinazione, ad es ./my_cvs_dir/etc/ .. e ./my_cvs_dir/usr/local/newapp/..,
3. copiare i file dalla struttura CVS alla struttura di directory di destinazione,
4. creare un archivio tar per la struttura di directory di destinazione, e
5. distribuire il tarball sul computer di destinazione.

Abbiamo anche questi tarball impostati in crescente specializzazione, ad es. Sol10, Apache, app specifiche, ecc.

HTH

applausi,

Rob

Answer 4

Beh è possibile memorizzare tutti i file di configurazione in una specifica struttura di directory, un sotto-directory per ogni applicazione. Poiché la maggior parte delle applicazioni dovrebbe avere una direttiva per specificare il percorso di configurazione, questa è l'unica cosa da modificare (o se si hanno file di configurazione hard codificati, forse qualcosa come include è supportato) per server.

E questo albero potrebbe quindi essere controllato in qualsiasi VCS che ti piace.

Per l'implementazione è possibile scrivere uno script di shell o qualcosa che inizializzi tutto per utilizzare l'albero del file di configurazione.

Answer 5

Questo è quello che ho implementato:

Ho un server che fa rsync di tutte le configurazioni in una directory (per esempio/data/configs/hostname/{etc, httpd}

ho. un rsync in esecuzione ogni ora per trasferire le modifiche non appena rsync è completo, vi è uno script svnautocommit che fa l'autocommit delle modifiche.Questo modo, posso tornare a qualsiasi modifica o qualsiasi versione che voglio.

Potrebbe essere necessario pianificare la struttura della directory SVN in base alle proprie esigenze.

Answer 6

Come si desidera comunque un negozio centrale, si può optare per qualcosa di leggermente più complicato come Slack. L'amministrazione e la versione controllano i file su un server push, quindi li rsync ai client. Lo explanation of subroles ha alcuni esempi su come strutturare l'albero.