Quali soluzioni esistono per consentire l'uso del controllo di revisione per i file di configurazione del server? [chiuso]


85

In un ambiente con più amministratori di sistema, vedo alcuni vantaggi nell'aggiungere i file di configurazione del server in un sistema di controllo delle revisioni. I più importanti sono la capacità di tracciare i cambiamenti, chi li ha fatti e, naturalmente, essere in grado di tornare alle configurazioni di lavoro conosciute.

Sono principalmente interessato alle soluzioni Unix / Linux, ma sarei curioso anche per le implementazioni di Windows.


Sembra duplicare o essere molto legato a questa domanda serverfault.com/questions/3852/…
Zoredache,

Risposte:


52

Ho provato questo a casa (~ 3 host) da qualche tempo, provando diversi scms (RCS, Subversion, git). Il setup che funziona perfettamente per me in questo momento è git con il setgitpermsgancio.

Cose che devi considerare:

Gestione delle autorizzazioni e della proprietà dei file

  • RCS: lo fa nativamente
  • Subversion: l'ultima volta che ho provato, ti serviva un wrapper svnper farlo
  • git: l' setgitpermshook lo gestisce in modo trasparente (necessita però di una versione abbastanza recente di git con supporto per gli post-checkouthook)

Inoltre, se non vuoi avere tutto il /etccontrollo sotto versione, ma solo i file che hai effettivamente modificato (come me), avrai bisogno di uno scm che supporti questo tipo di utilizzo.

  • RCS: funziona comunque solo su singoli file.
  • Subversion: l'ho trovato complicato.
  • git: nessun problema, inserisci " *" nel .gitignorefile di livello superiore e aggiungi solo i file che desideri utilizzaregit add --force

Infine, ci sono alcune directory problematici sotto /etcdove i pacchetti possono cadere frammenti di configurazione che vengono poi letti da qualche programma o demone ( /etc/cron.d, /etc/modprobe.d, ecc). Alcuni di questi programmi sono abbastanza intelligenti da ignorare i file RCS (ad es. Cron), altri no (ad es. Modprobe). Stessa cosa con le .svn directory. Ancora una volta un grande vantaggio per git (crea solo una .git directory di livello superiore ).


1
Subversion necessita di asvn svn.collab.net/repos/svn/trunk/contrib/client-side/asvn . L'archivio SVN (asvn) consentirà la registrazione di tipi di file non normalmente gestiti da svn. Attualmente questo include dispositivi, collegamenti simbolici e proprietà / autorizzazioni dei file.
Cristian Ciupitu,

Hai una scrittura da nessuna parte che mostra come impostare i ganci che hai usato, ecc.?
Grufftech,

Una breve recensione è qui: jottit.com/jg8h7
8jean

Ecco un post sull'impostazione di qualcosa del genere in Arch Linux ARM, che dovrebbe valere altrettanto bene qui. zduck.com/2012/storing-your-raspberry-pi-config-in-git
silent__thought

28

L'ho fatto in modo informale con git, ma c'è anche il progetto etckeeper che è un'implementazione più completa e dettagliata.


4
etckeeper è davvero buono: gestisce i permessi di ripristino (non supportati da git, hg, ecc.) e supporta il tuo backend preferito (inclusi git, hg, bazaar, ecc.). Ha anche l'integrazione in APT in modo tale che ogni volta che si esegue un'operazione apt-get, il repository / etc viene eseguito il commit e lo esegue durante la notte. L'ho usato per un po 'e nel complesso è molto meglio dell'uso di un VCS vaniglia, se non altro per la funzionalità dei permessi.
RichVel,

23

Un'altra opzione è quella di utilizzare uno strumento di configurazione del server automatizzato come Puppet o Cfengine per creare script delle configurazioni del server in un linguaggio dichiarativo.

È un lavoro extra sul front-end, ma l'utilizzo di un'utilità come Puppet consente di ricostruire e configurare automaticamente un server con un intervento umano molto limitato.


5
Sì, ma dovresti anche controllare la revisione delle tue configurazioni Puppet / CFengine. Sono anche un fan del controllo di revisione dell'output in modo da poter rispondere alla domanda "qual è stata la configurazione alla data x?" così come "che cosa avrebbe dovuto essere la configurazione in base al pupazzo?" e ​​correlare gli input con gli output per la risoluzione dei problemi del sistema di gestione della configurazione.
Rob Chanter,

10

Ho sperimentato etckeeper che sembra funzionare abbastanza bene. Non ho bisogno di un server centralizzato, che può essere importante in alcune situazioni. Puoi utilizzare diversi backend DVCS diversi, in modo da poter scegliere quello con cui hai più familiarità. Sembra funzionare molto bene per me, ma non ho ancora provato a trovare gli altri tecnici dove lavoro per iniziare ad usarlo.


6

Ho cercato Chef di recente. Non solo mantiene le configurazioni templatable (.erb) nel controllo versione, ma consente di eseguire azioni (come riavviare un servizio dopo aver caricato le configurazioni sul nodo). Chef aiuta nella gestione dei pacchetti in modo da poter verificare le dipendenze con qualsiasi nodo con cui si interfaccia (cioè deve avere installato il pacchetto sudo). Lo chef sembra essere facilmente estensibile in Ruby, quindi se hai processi personalizzati puoi semplicemente scriverlo all'interno del framework fornito.

Ma non l'ho ancora provato e devi installare Ruby sul client e sul server con le gemme appropriate (questo non è poi così difficile). Nel complesso sembra davvero facile gestire molti server contemporaneamente.


Utilizziamo pesantemente Chef (oltre 60 server) abbastanza efficacemente. Tutte le ricette e i file di configurazione sono controllati in Subversion.
Organicveggie,

3

Sono in procinto di implementare Puppet attraverso la nostra infrastruttura ed è molto favorevole a mantenere i suoi dati nel controllo della versione.

Preferisco Mercurial poiché è solo una raccolta di file con alcuni metadati memorizzati in directory nascoste (facile da gestire, facile da capire, facile da usare).

I miei file Puppet sono in / usr / local / etc / puppet / (FreeBSD 7.1). Tutto ciò che è stato necessario per aggiungere Mercurial ad esso:

> cd /usr/local/etc/puppet
> hg init

Tutte le modifiche vengono eseguite con un semplice "commit hg". Se una modifica genera qualcosa, posso ripristinare ogni singolo server su una determinata versione del file (diciamo, sudoers) con un solo comando.

Ottima introduzione a Mercurial


3

Ho usato Subversion sui server che gestisco. Funziona bene. Ho anche impostato un'istanza Trac , quindi abbiamo una visualizzazione della sequenza temporale, un sistema di ticketing, navigazione, ecc.

Utilizzando symlink, cron e subversion ho anche impostato la distribuzione automatica della configurazione basata sul repository subversion, in cui ogni server Linux aggiorna un repository utilizzando svn updatecon script (ad esempio script firewall).


2

Ecco un caso d'uso reale: usato Subversion per gestire i file di configurazione su 4 server diversi. Consiglio di utilizzare il controllo versione per i file di configurazione per lo stesso motivo per cui li useresti con il codice: è un backup e un pulsante Annulla tutto in uno. Se stessi gestendo un numero molto più grande di server e fossero molto più vicini in termini di configurazione, userei qualcosa come Puppet come dettagliato nella risposta di berberich.

L'idea è che è possibile disporre di un repository in cui è possibile effettuare il checkout di cartelle specifiche sui server (ad es. / Var / named /), quindi entrambi ho una cronologia e un backup dei file di configurazione (il backup è un vantaggio se si commette l'errore di utilizzare un'applicazione di configurazione della GUI che cancella la tosse aggiunta a mano Server Admin in Mac OS X Server tosse ). È quindi facile testarlo su un server di prova e successivamente aggiornare il server di produzione con file che funzionano senza copiare manualmente i file.


1

Ho creato un progetto qualche anno fa per fare esattamente questo: Savon

Usa la sovversione per archiviare i file e ha alcune funzionalità aggiuntive, come il monitoraggio della proprietà, le autorizzazioni e il contesto SELinux. Inoltre, consente di dividere logicamente le modifiche del file system in livelli, ad esempio è possibile tenere traccia delle modifiche che dovrebbero andare separatamente a tutti i server Web.



0

La maggior parte delle modifiche viene gestita con il nostro sistema di Help Desk, anche per le attività di manutenzione ordinaria. Abbiamo lentamente spostato la nostra documentazione in una wiki per nostro uso e ciò che pubblichiamo per gli utenti finali. Pubblicare le modifiche alla configurazione e la discussione alle spalle, è bello averlo aperto sulla nostra intranet.


0

Per molti anni ho usato rcs per i file che ho iniziato a modificare, ma un paio di anni fa ho iniziato a mettere l'intero / etc sotto controllo git. Richiede un po 'di lavoro per il check-in dei file in blocchi granulari (a volte ricorro a un enorme check-in "vari aggiornamenti"), e ho scritto alcuni script per aiutare con questo, ma etckeeper menzionato sembra molto interessante, lo proverò immediatamente.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.