Apakah mungkin menggunakan penjaga dll dengan repositori git tunggal yang dibagikan?


9

Saya perhatikan bahwa beberapa orang merekomendasikan menggunakan etckeeper untuk menerapkan kontrol versi ke direktori / etc saya.

Tampak bagi saya bahwa instalasi default menempatkan repositori pada mesin yang sama dengan / etc yang Anda coba kelola. Ini berfungsi dengan baik untuk kontrol versi, tetapi tidak memberikan manfaat tambahan untuk membuat cadangan di luar server file - atau memungkinkan saya untuk menggandakan bagian dari / etc dari satu mesin sumber ke yang lain.

Apakah mungkin untuk berbagi repositori git tunggal pada mesin admin pusat, sehingga penjaga etc pada setiap server menyimpan datanya di tempat yang sama?

(Saya melakukan hal yang sama sekarang dengan svn dan beberapa skrip khusus untuk melakukan dan mengembalikan file, tetapi saya harus ingat untuk melakukan mereka ketika saya membuat perubahan.)

Jawaban:


8

Pertama, gunakan install etckeeper, dikonfigurasi untuk git di /etc/etckeeper/etckeeper.conf. Ikuti metode pemasangan dllkeeper untuk distro Anda atau dari sumber.

Segera, Anda akan memiliki /etc/.git

Sekarang di server Anda, pastikan Anda memiliki repo (aman) untuk mendorong ke ...

 # ssh faruser@farhost     
 # mkdir somedir cd somedir && git init && chmod 700 .git    
 # exit

Sekarang di host awal, dorong repo lokal Anda ke server melalui ssh:

# cd /etc && git push faruser@farhost:somedir

Somedir tentu saja bisa relatif dalam hal ini (mengikuti konvensi ssh)

Lakukan ini setiap kali Anda melakukan perubahan yang mempengaruhi / etc (dan dimasukkan ke /etc/.git oleh etckeeper) dan Anda akan memiliki repo lokal dan off-mesin untuk mesin Anda.

Atau atur passwordless ssh dan buat hook di /etc/etckeeper/commit.d/ sehingga terjadi secara otomatis jika mesin selalu terhubung.


2
Ini terlihat hebat. Apakah ada cara agar repositori lokal disimpan dalam subdirektori yang jauh? Saya ingin melakukan sesuatu yang serupa, menggunakan repositori jarak jauh tunggal untuk menyimpan konfigurasi (terpisah) untuk beberapa server.
Andrew Ferrier

dapat git pushbekerja ke git repo yang Anda buat? mungkin Anda perlu membuat repo telanjang di somedir hook di bawah commit.d adalah ide yang sangat bagus, saya menyukainya
larrycai

3

Dimungkinkan untuk menambahkan konfigurasi cabang jarak jauh untuk memetakan cabang utama repositori etckeeper dari setiap server ke cabang pada repositori jarak jauh. Untuk melakukan itu, Anda dapat menjalankan perintah berikut di setiap server:

cd /etc
git branch -m master $HOSTNAME
git remote add origin git@git.example.com:path/to/single/repo.git
git push -u origin master:$HOSTNAME

Setelah pengaturan ini, selanjutnya git pushakan mengirim perubahan dari setiap cabang master server ke cabang server khusus pada repositori pusat.

Meskipun cabang tidak memiliki titik awal yang sama, ini memungkinkan untuk dengan mudah membandingkan file yang sama dari dua cabang yang berbeda, mewakili dua server yang berbeda, dengan menjalankan:

git diff origin/server1 origin/server2 -- file

Ini dapat dikombinasikan dengan pengaturan otomatis yang disarankan oleh jojoo .


git push -u master asal: $ HOSTNAME tidak berfungsi di sini. Remote repo adalah repo kosong kosong. kesalahan: src refspec master tidak cocok dengan apa pun.
Bertl

1

Cara melakukannya secara otomatis, cerita lengkapnya:

Buat file /etc/etckeeper/commit.d/60-push (jangan lupa untuk chmod + x itu) pada klien.

#!/bin/sh
git push central_server:/var/git/client_name.git master

central_server didefinisikan dalam konfigurasi ssh, lihat di bawah. /var/git/client_name.git adalah direktori di server pusat, berisi repo git.

~ / .Ssh / config dari root (!) Harus berisi sesuatu seperti ini:

host central_server
Hostname 192.168.0.1
User etckeeper #a user on the central server 
IdentityFile ~/.ssh/custom_key # key is in authorized_keys in
             #etcpeeper@central_server:~/.ssh/authorized_keys

Maka Anda perlu init git repo di central_server

mkdir /var/git/client_name.git
su etckeeper
cd /var/git/client_name.git
git --bare init

Uji dengan edit kecil di / etc dan kemudian penjaga etc melakukan "test push'ing".


1

Itu bukan intinya. Jika Anda ingin mendistribusikan konfigurasi secara luas, Anda mengatur repositori lain sebagai tambahan dari repo lokal masing-masing mesin, dan minta setiap mesin memilih dari yang diperlukan. Apa yang dilakukan adalah memungkinkan setiap mesin untuk menyimpang (cabang, sebenarnya) dan mempertahankan kontrol revisi.


Tidak yakin bagaimana melakukan ini (repositori kedua). Bisakah Anda menguraikan?
Brent

Anda mungkin perlu mengkloning salah satu repo ke "repo sentral" Anda; kamu hanya perlu satu. Dari sana Anda dapat membuat perubahan, dan kemudian masing-masing server dapat memilih patch yang disimpan dalam revisi. Bagaimana Anda mengaturnya pada awalnya bervariasi antara DSCMs. Untuk git, lihat kernel.org/pub/software/scm/git-core/docs/gittutorial.html
jldugger

-2

Anda benar-benar tidak ingin membuat dan lain-lain menjaga kebijakan cadangan Anda. Walaupun memiliki salinan file konfigurasi Anda akan menyenangkan, itu hampir tidak cukup untuk memenuhi syarat sebagai rencana pemulihan bencana.

Fokuslah untuk memiliki cadangan nyata dari sistem Anda sebagai gantinya. Simplist bisa menjadi cronjob untuk memberi makan tarball untuk direkam ... oh, benar. Tidak ada yang menggunakan kaset lagi. Oke, cronjob untuk rsync semua file Anda ke NAS khusus . Untuk solusi cadangan yang lebih kuat, lihat Amanda dan Bacula .

Dan untuk kasus akademisi, saya bisa mendorong repo penjaga restoran saya ke github sama seperti repo git lainnya.


Tidak ada yang berbicara tentang menjadikan ini kebijakan cadangan. Tetapi dalam pengalaman saya, nyaman untuk memiliki segalanya di satu tempat, di server yang lebih aman.
Brent

1
Lalu saya salah paham. Jika yang benar-benar Anda cari adalah cara untuk secara terpusat menyimpan dan mendistribusikan konfigurasi sistem Anda, maka mungkin Puppet ( reductivelabs.com/products/puppet ) akan sangat membantu di sana.
Shazburg

sebagai contoh: kami mendorong semua konfigurasi kami ke satu host. ada menjalankan trac, yang digunakan untuk memvisualisasikan perubahan konfigurasi (dan tentu saja menulis tiket, jika sesuatu tidak berfungsi, ...) imo itu super-convinient, saya dapat misalnya membandingkan crontab dari semua host kami dengan beberapa klik.
jojoo
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.