Hosting beberapa repositori (svn, hg, git)

8

Saya baru-baru ini memperoleh server khusus, dan perlu memindahkan beberapa repositori ke server itu dari layanan hosting sumber kontrol. Tidak memiliki banyak pengalaman dalam administrasi server namun saya tidak tahu bagaimana mengaturnya secara efektif. Apa yang saya cari -

  1. svn.host.com, hg.host.com, subdomain git.host.com yang akan menjadi root untuk repo yang berbeda, melalui kunci SSH
  2. pembuatan repositori baru yang mudah
  3. otentikasi menggunakan server unix daftar pengguna, tetapi dengan izin berdasarkan per proyek, juga akses publik hanya-baca opsional untuk beberapa repo

Sayangnya, istilah pencarian apa pun yang saya coba di Google mengarahkan saya ke solusi yang diinangi secara komersial, dan bukan panduan tentang cara menggulung sendiri. Saya membutuhkan sesuatu seperti solusi host yang dihilangkan tetapi tanpa perlu memiliki pengguna dapat membuat repo sendiri.

Adakah saran, tutorial, atau solusi tertulis tentang tempat memulai penelitian? Solusi open source untuk antarmuka administratif untuk menangani itu (atau setidaknya untuk beberapa akan sempurna ...

hosting  svn  git  mercurial 
— Kornel Kisielewicz
sumber

Jawaban:

6

Saya hanya menggunakan Git, jadi saya akan mencoba setidaknya untuk membantu Anda dengan itu:

Jika Anda tidak melihat ada masalah dalam mengelola repo Anda melalui baris perintah, gitosis harus melakukan trik dengan cukup baik.

Jika Anda benar-benar membutuhkan antarmuka web, Anda bisa melihat di repo.or.cz ( http://repo.or.cz/w/girocco.git ) atau gitorious ( http://gitorious.org/gitorious ) . Repo.or.cz lebih jelek, tetapi cara ini lebih mudah untuk diinstal (gitorious adalah open-source, tetapi juga perangkat lunak yang mendukung gitorious.org - mereka tidak memiliki banyak insentif untuk menulis instruksi yang bagus)

Berikut adalah daftar opsi yang lebih komprehensif: https://git.wiki.kernel.org/index.php/GitHosting

Siapa pun dari opsi itu akan memberi Anda pembuatan repositori baru dengan mudah.

Sekarang, satu kata peringatan: Anda tidak boleh, PERNAH, menggunakan daftar pengguna server unix untuk izin repositori. Cukup mudah untuk mengacaukannya, dan hasilnya mudah sekali (gitosis menggunakan konfigurasi file sederhana, dan kunci ssh. Harus melakukan trik untuk Anda).

Hal lain, saya tidak mengerti mengapa Anda perlu memiliki repositori subversi, HG dan Git. Sebagian besar proyek hanya menggunakan salah satu opsi itu. Peduli untuk menjelaskan mengapa?

— Tiago Fassoni
sumber
Saya punya beberapa proyek, diadakan di beberapa repositori. Banyak komisioner tidak terlalu paham teknologi dan karenanya hg dan git akan menjadi masalah bagi mereka, jadi saya tetap svn untuk proyek yang lebih terbuka. Secara pribadi saya menggunakan HG sebagai SCM pilihan saya. Saya juga menjadi tuan rumah beberapa proyek untuk teman-teman saya dan beberapa dari mereka menggunakan git sebagai SCM pilihan mereka. Tidak ada cara untuk menyenangkan semua orang seperti yang terlihat :)
— Kornel Kisielewicz
1
Juga, bisakah Anda menguraikan lebih lanjut tentang bahaya menggunakan daftar pengguna unix untuk izin repo?
— Kornel Kisielewicz
3
Mengapa menggunakan daftar pengguna unix untuk repositori adalah hal yang buruk: kehilangan rincian, kehilangan portabilitas. Jika Anda perlu mengubah repo ke server lain, Anda harus memindahkan seluruh daftar pengguna unix. Jika Anda ingin mendelegasikan izin admin, Anda harus memberikan izin root. Sekarang, pada gitosis, jika Anda ingin mengubah server, Anda hanya perlu mengkloning repo. Jika Anda ingin mendelegasikan izin admin, Anda hanya perlu menambahkan pengguna ke grup admin-gitosis.
— Tiago Fassoni
just_testing, setuju, poin valid :)
— Kornel Kisielewicz
2

SVN dapat dilakukan dengan Apache WebDAV, di vhost, menggunakan otentikasi unix dan ACL tingkat pengguna subversi sendiri. Saya tidak tahu apa-apa tentang lincah atau git, tetapi saya berharap mereka bisa terhubung ke DAV juga.

— draeath
sumber
1

Ketika Anda ingin menggunakan SSH , maka pada dasarnya Anda harus membatasi kunci dengan mengedit authorized_keysfile di server. Untuk Mercurial, cara utama untuk melakukan ini adalah:

  • Anda dapat menggunakan contrib/hg-sshskrip untuk membatasi perintah yang dapat dijalankan orang saat masuk dengan SSH. File tersebut berisi tajuk untuk menjelaskan cara menggunakannya, tetapi pada dasarnya Anda menambahkan

    $ command="hg-ssh path/to/repo"

    di depan kunci dalam authorized_keysfile. Itu membatasi kunci sehingga hanya bisa digunakan untuk mendorong dan menarik ke repositori yang ditunjukkan.

  • Anda juga dapat menggunakan alat server-server pihak ketiga jika Anda menginginkan sesuatu seperti gitois . Ini memungkinkan Anda mengelola pengguna dan hak aksesnya dengan mengedit file di repositori admin khusus.

Lihat wiki Mercurial untuk beberapa alat serupa lainnya untuk SSH.

Untuk HTTP , ada

  • Built-in hgweb(Fast) CGI atau WSGI script yang datang dengan Mercurial. Itu menangani push dan pull, tetapi tidak memungkinkan pembuatan repositori baru - login ke server untuk itu.

  • Proyek RhodeCode pihak ketiga . Ini memberi Anda front-end web seperti Bitbucket untuk Mercurial di mana Anda dapat mengonfigurasi pengguna dan hak akses mereka. Ini mendukung otentikasi LDAP, sehingga Anda dapat menghubungkannya ke basis data pengguna Unix yang ada.

Lihat halaman tentang penerbitan repositori untuk informasi lebih lanjut.

— Martin Geisler
sumber
1

SCM-Manager mungkin sempurna untuk kebutuhan Anda:

Cara termudah untuk berbagi dan mengelola repositori Git, Mercurial, dan Subversion Anda melalui http.

  • Instalasi sangat mudah
  • Tidak perlu meretas file konfigurasi, SCM-Manager sepenuhnya dapat dikonfigurasi dari Antarmuka Web-nya
  • Tidak ada Apache dan tidak diperlukan instalasi basis data
  • Pengguna pusat, grup, dan manajemen izin
  • Dukungan out of the box untuk Git, Mercurial dan Subversion
  • API Layanan Web RESTFul Lengkap (JSON dan XML)
  • Antarmuka Pengguna yang Kaya
  • API Plugin Sederhana
  • Tersedia plugin yang berguna (fe Ldap-, ActiveDirectory-, PAM-Authentication)
— alexandrul
sumber
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.