Jakiś czas temu pomyślałem że przydałoby zacząć używać jakiegoś softu do kontroli wersji. Od czasu do czasu napiszę jakiś program, większość z nich służą jako “ułatwiacze” w mojej pracy admina, niektóre za to tworzone są tylko dla rozrywki i czasami giną w mroku dziejów.
Z ciekawszych wspomnę mini sieć p2p napisaną przeze mnie w w perlu i netcacie (byłem wtedy takim noobem ze nie potrafilem używać TCP/UDP spod perla), która nawet działała, potem ją popsułem a że nie miałem żadnego VCS (version control system) to zaginęła. (Część druga)

Ale do rzeczy. Po przejrzeniu netu uznałem że GIT będzie dla mnie najlepszy, wyglądał sensownie i (podobno) ma dużo plusów w porównaniu do CVS/SVN. Po krótkim googlowanku zdecydowalem się na serwer Gitosis.

Jako że jest to serwer gita to jest także hostowany na gicie, więc instalujemy klienta gita ( w debianie git-core ) i gitosis
# git clone git://eagain.net/gitosis.git
# cd gitosis
# ./setup.py install

(soft jest w pythonie w debie wymaga python-setuptool. Lub można po prostu zainstalowac gitosis także z paczki)

Tutaj powinienem chyba napisać jak działa gitosis. Otóż gitosis używa ssh i autentykuje się z klientami przez klucze publiczne, działa to tak:

1.Gitosis ma swoje konto w systemie i klient loguje się przez autentykacje kluczem publicznym (~/.ssh/authorized_keys jest automatycznie zarządzane przez gitosis)
2.następnie na podstawie tego który klucz został użyty klient ma odpowiednie prawa do repozytorów

System w sumie prosty ale niezbyt trudny do zarządzania i skuteczny ;]. Ale idziemy dalej,
Tworzymy konto systemowe:
adduser --system --shell /bin/sh --gecos "Gitosis" --group --disabled-password --home /home/git git

Oczywiście równie dobrze możemy nazwać konto “ciastko”. Na konto nie będzie można się “normalnie” (–disabled-password) zalogować, tylko poprzez su albo klucz publiczny (ale gitosis dodaje je w taki sposób że dozwolone jest tylko odpalenie gitosis przez tak zalogowane konto).

Od tej pory będzie nam potrzebny nasz własny klucz publiczny(ssh-keygen -t rsa).

# su git
$ cd
$ gitosis-init < /nasz/pubkey.pub Initialized empty Git repository in /home/git/repositories/gitosis-admin.git/ Reinitialized existing Git repository in /home/git/repositories/gitosis-admin.git/ $ chmod 0755 ~/repositories/gitosis-admin.git/hooks/post-update

Ostatnia linijka jest ważna! Z jakiegoś powodu ten plik nie ma +x domyślnie a bez tego config nie chce się aktualizować przez git.
w tym momencie mamy stworzone repo z configiem i działający serwer, teraz tylko dodać inne repa ;]. Jako że config jest jednocześnie repozytorium, odpalamy na lokalnym (z zainstalowanym git-core) kompie:

$ git clone ssh://git@some.whe.re/gitosis-admin.git
Initialized empty Git repository in /home/xani/gitosis-admin/.git/
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 0), reused 5 (delta 0)
Receiving objects: 100% (5/5), done.

powstanie nam katalog z plikami konfiguracyjnymi gitosis, plik gitosis.conf odpowiada za uprawnienia do repo, wygląda on tak:

[gitosis]
[group gitosis-admin]
writable = gitosis-admin
members = xani@death


[group configwatch]
writable = configwatch
members = xani@death some.other@key @somegroup



[repo configwatch]
description = Some Repo
owner = Some Company

Kursywą zaznaczyłem przykładowe dodane repo. w [group] writable oznacza gdzie dana grupa może pisać, [members] ofc oznacza członków grupy, a gdy zaczyna się od @ oznacza inna grupę. Oprócz tego żeby dodac nowego usera trzeba też zapisać jego klucz publiczny w configu, zapisujemy go pod keys/nazwa@host.pub. Ok, teraz update configa.

$ git add gitosis.conf
$ git add "keys/some.other@key.pub"
$ git commit
[master dad67d6] added user
2 files changed, 8 insertions(+), 0 deletions(-)
create mode 100644 keydir/xani@hydra.pub
$ git push
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 462 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To ssh://git@devrandom.pl/gitosis-admin.git
58ab44a..dad67d6 master -> master

Pierwsze dwie linijki dodają pliki do commita (i repo), kolejna wysyła zmiany do lokanego repo ( i pyta się o komentarz), a na końcu git push wysyła zmiany na serwer. W git push dostaniesz tez prawd. warning, zrób więc git config push.default current

Ok, mamy już nowego userka i uprawnienia, czas stworzyć wreszcie repo. Zrobimy to przez utworzenie repa lokalnie a następnie wysłanie go na serwer

$ mkdir configwatch
$ git init
Initialized empty Git repository in /home/xani/configwatch/.git
$ git commit --allow-empty
$ git remote add origin ssh://git@devrandom.pl/configwatch.git
$ git push origin master
Initialized empty Git repository in /home/git/repositories/configwatch.git/
Counting objects: 2, done.
Writing objects: 100% (2/2), 161 bytes, done.
Total 2 (delta 0), reused 0 (delta 0)
To ssh://git@devrandom.pl/configwatch.git
* [new branch] master -> master

I to tyle (na razie), w następnej części opis podstawowych komendter

Related Posts: