Czym jest gitosis i o czego będzie nam potrzebne?

Cóż, podobnie jak sam git, gitosis jest zestawem skryptów ułatwiającym prace z repozytorium. Zestaw tych skryptów odpowiedzialny jest za kontrolę dostępu do repo jak i za sam dostęp do niego.

Jak działa gitosis?

„Integruje” się ono z serwerem SSH, „integruje się” to za wiele powiedziane, bo sshd wykorzystywane jest tylko do autoryzacji użytkowników oraz transferu danych z i do repo. Samo gitosis nie uruchamia dodatkowego daemona, jak już wspomniałem korzysta z sshd.

Jak przebiega proces autoryzacji ?

Podobnie jak w GitHub‘ie najpierw trzeba dodać nasz klucz publiczny, żebyśmy mogli zostać z autoryzowani, następnie przy każdej próbie połączenia z repo będzie on wykorzystywany do przeprowadzenia autoryzacji … nie ma w tym żadnej wielkiej filozofii, dorzycamy nasz klucz i wszystko po prostu działa.

Ok, więc może w końcu do sedna … zaczynamy od zainstalowania pakietu gitosis w systemie:

apt-get install gitosis

Proces instalacji sam utworzy w systemie konto użytkownika (standardowy login to gitosis), założy mu katalog domowy (standardowo: /srv/gitosis). Jeżeli bardzo chcemy to możemy to zmienić korzystając ze standardowej komendy usermod dla uproszczenia ja będę się posługiwał standardową nazwą użytkownika. Pozostaje nam tylko inicjalizacja i konfiguracja:

sudo -H -u gitosis gitosis-init < id_rsa.pub

Gdzie id_rsa.pub jest naszym kluczem publicznym używanym przez naszego klienta ssh … fajnie to brzmi ale co to właściwie jest ? Dokładny opis jak taki klucz sobie wygenerować (i co z nim zrobić) znajduje się tutaj. Generalnie powinien być to klucz który będzie identyfikował naszą maszynę z której będziemy się łączyć do repozytorium (tj. klucz prywatny i publiczny powinny być zapisane w katalogu ~/.ssh na twoim desktopie/laptopie, tylko klucz publiczny w celu instalacji go w konfiguracji gitosis powinieneś skopiować na serwer na którym instalujesz repozytorium). Powyższa komęda powinna zainicjalizować repozytorium git/gitosis oraz dodać wskazany klucz publiczny jako klucz administratora. Jeżeli mamy szczęście to po wykonaniu poniżeszej komędy na naszym desktopie/laptopie (tj. na tym na którym znajduje się para ~/.ssh/id_rsa i ~/.ssh/id_rsa.pub):

git clone gitosis@adres_serwera:gitosis-admin.git

Jeżeli powyższa komenda nie wykona się poprawnie (jak to było w moim przypadku) zmuszeni jesteśmy skonfigurować gitosis ręcznie. W tym celu udajemy musimy przeedytować plik /srv/gitosis/.ssh/authorized_keys (tak wiem, że nie powinno się go edytować … ale co nam pozostaje ?) i zmienić „domyślny” login na identyczny z tym podanym w komentarzu do naszego klucza prywatnego (to jest to co podaliśmy za przełącznikiem -C podczas jego tworzenia), wartość klucza publicznego (to jest ten dziwny ciąg znaków za ssh-rsa) oraz na samym końcu ponownie wstawiamy wartość z naszego komentarza. Po wykonaniu tych zmian i ich zapisaniu ponownie próbujemy sklonować repozytorium z konfiguracją (czyli jeszcze raz wydajemy poprzednią komendę) … jeżeli znowu nie wykona się poprawnie … cóż czasem trzeba sobie radzić samemu

Ok, zakładam że w końcu uda się pobrać z serwera konfigurację z serwera … tak, na prawdę gitosis przechowuje swoją konfigurację w formie jednego z repozytoriów. Jest to dość wygodne, gdyż nie wymusza na nas logowania się na serwer celem zmiany konfiguracji (w wypadku dodania użytkownika repozytorium, czy też nowego projektu). W każdej chwili możemy sobie ta konfigurację pobrać, zmodyfikować, „wepchnąć” z powrotem i usunąć jak dla mnie bomba .

Co do samej konfiguracji to składa się ona z 2 rzeczy:

• pliku z konfiguracją (znajdują się tam definicje repozytoriów, grup i praw dostępu)
• katalogu z kluczami publicznymi użytkowników

W katalogu keydir/ znajdują się klucze publiczne użytkowników, w postaci:

uzywany_login.pub

najczęściej login ma postać adresu email, więc przykładowy plik dla użytkownika wlodek@luksza.org będzie się nazywał wlodek@luksza.org.pub … jest to niezmiernie skomplikowane, nieprawdaż

W przypadku kiedy chcemy dodać nowego użytkownika bądź repozytorium musimy przeedytować plik gitosis.conf, jego opis można znaleźć tutaj. W przypadku użytkowników należy pamiętać o zgodności nawy użytkownika z nazwą pliku zawierającą jego klucz publiczny. Dodatkowo warto wspomnieć o tym, że dla każdego repozytorium możemy zdefiniować właściciela (parametr owner ) oraz opis (description), są to przydatne parametry zwłaszcza podczas eksploracji repozytorium przy użyciu cgit‘a czy też gitweb‘a.

Kiedy już wykonamy wszystkie zmiany commit’ujemy je do lokalnego repo, a potem wypychamy do głównego:

git commit -a
git push

W ten prosty sposób administrujemy repozytorium git’a zarządzanym przez gitosis

BTW. Chyba szykuje się nam zmiana na miejscu domyślnego repo Eclipse Fundation możliwe, że nowe repo będzie obsługiwane przez git’a, „pierwsze” takie przesłanki można znaleźć tutaj.

Moje oczekiwania od takiego repo są następujące:

• dostępność do repo z każdego zakątka świata (czyli serwer musi być dostępny szeroko pojętej sieci)
• możliwość dostępu do repo tylko dla wybranych użytkowników
• możliwość przeglądania repo z poziomu www
• bezpieczeństwo stosowanego rozwiązania (https, ssh)

Jakie wybrałem oprogramowanie ?

• systemem bazowym będzie Debian (znany, lubiany i standardowy linux)
• gitosis (prosty soft do hostowania repozytorium git’a z równie prostą kontrolą dostępu, IMO rozwiązanie w sam raz do moich potrzeb)
• lighttpd (mały i szybki httpd)
• mod_ssl oraz mod_auth do wyżej wymienionego httpd
• cgit odpowiednik gitweb’a ale moim zdaniem ładniejszy i bardziej przejrzysty

We własnym zakresie trzeba zadbać o system bazowy, oraz jego konfigurację . Zakładam, że Debian jest już zainstalowany, skonfigurowany, zabezpieczony oraz podpięty do sieci.

Zaczynamy od instalacji i konfiguracji lighttpd

apt-get install lighttpd apache2-utils

Pakiet apache2-utils będzie nam potrzebny do wygenerowania hash‘a hasła potrzebnego do mod_auth (swoją drogą system pakietowania debiana coraz bardziej mnie zadziwia … nie rozumiem po co w zależnościach do tego pakietu znajduje się libmysqlclient …). Po zainstalowaniu włączamy dwa interesujące nas moduły:

lighttpd-enable-mod auth
lighttpd-enable-mod ssl

Oraz przechodzimy do konfiguracji zarówno httpd jak i modułów. Zaczniemy od mod_auth, czyli edytujemy pliczek /etc/lighttpd/conf-enabled/05-auth.conf, w którym to wybieramy backend (czyli algorytm szyfrowania haseł oraz miejsce ich zapisu) oraz konfigurujemy miejsca do których dostęp będzie strzeżony hasłem. Po modyfikacjach plik konfiguracyjny powinien wyglądać mniej więcej tak:

## Authentication for lighttpd
##
## Documentation: /usr/share/doc/lighttpd-doc/authentication.txt.gz
##                http://www.lighttpd.net/documentation/authentication.html
server.modules                += ( "mod_auth" )
# htdigest jest najmocniejszym dostepnym "algorytmem" szyfrujacym
auth.backend                   = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd-htdigest.user"
 
auth.require                 = ( "/" =>
                                     (
                                       "method"  => "digest",
                                       "realm"   => "secure content",
                                       "require" => "valid-user"
                                      )
                                )

Opcja auth.require zawiera tylko jeden element, którym jest root serwera httpd, czyli dostęp do dowolnego pliku na serwerze będzie chroniony hasłem. Warto tutaj wspomnieć, że hash hasła zostanie posolony wartością w realm, dzięki temu uzyskujemy prosty mechanizm kontroli dostępu (tj. gdybyśmy mieli dwa zasoby z różnymi wartościami w realm, każdego użytkownika który powinien posiadać dostęp do obu powinniśmy dodać osobno). Teraz wystarczy tylko dodać użytkownika:

htdigest -c /etc/lighttpd/lighttpd-htdigest.user 'secure content' user_name

Po wydaniu tej komendy zostaniemy poproszeni o podanie oraz potwierdzenie hasła dla tego użytkownika.

Po skonfigurowaniu mod_auth przechodzimy do konfiguracji mod_ssl, w tym celu edytujemy /etc/lighttpd/conf-enabled/10-ssl.conf. Ja zdecydowałem się udostępniać usługę http tylko na porcie 443 z szyfrowaniem (czyli popularny https ), więc w konfiguracji mod_ssl wskazałem na którym dokładnie adresie IP oraz na jakim porcie ma nasłuchiwać daemon; plik konfiguracyjny wygląda mniej więcej tak:

## lighttpd support for SSLv2 and SSLv3
##
## Documentation: /usr/share/doc/lighttpd-doc/ssl.txt
##      http://www.lighttpd.net/documentation/ssl.html
 
#### SSL engine
$SERVER["socket"] == "111.222.3.4:443" {
ssl.engine                  = "enable"
ssl.pemfile                 = "/etc/lighttpd/server.pem"
}

następnie generujemy certyfikat self-signed dla naszego serwera:

openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes

Który to kopujemy do /etc/lighttpd/server.pem.

Ostatnią częścią konfiguracji lighttpd będzie ogólna konfiguracja serwera, czyli edytujemy plik
/etc/lighttpd/lihttpd.conf. W którym to odkomentowujemy tylko linie:

server.bind = "localhost"

Spowoduje to, że port 80 zostanie otwarty tylko na interfejsie loopback, co w konsekwencji prowadzi do tego, że wszystkie połączenia (z sieci) do portu 80 będą odrzucane (za to akceptowane będą połączenia do portu 443, zgodnie z konfiguracją w pliku 10-ssl.conf).

Na razie to wszystko w kwestii konfiguracji lighttpd, wrócimy jeszcze do niej podczas konfiguracji cgit’a. W następnej części zajmiemy się konfiguracją gitosis.

PS. Tutaj jest część druga.

Jako, że serwer jest dostępny publicznie, a hostować ma nie publiczne projekty przydało by się go trochę zabezpieczyć … z administrowaniem serwerami nie miałem wiele wspólnego, ale od czego jest Google

W sieci znajduje się kilka opisów co można poprawić w standardowym Debianie żeby zwiększyć jego bezpieczeństwo. Oprócz samych zabezpiczeń warto tez być na bierząco informowanym o stanie systemu. Informacje takie możne nam dostarczyć program logcheck (wraz z logcheck-database), tylko ze jakoś te informacje muszą do nas trafić, tutaj z pomocą przychodzi … poczta elektroniczna, czyli popularne e-maile .

Wszystko było by fajnie gdyby nie to, że w momencie wysyłania wiadomości Debian usilnie korzysta z lokalnego MTA (tj. mail transport aget … domyślnie jest to exim4), co nie do końca jest fajne (jest to osobny daemon, dodatkowe otwarte porty itp.) zwłaszcza jeżeli tuz obok stoi dedykowany serwer pocztowy.

W tej sytuacji instalujemy heirloom-mailx, programik ten (po odpowiednim skonfigurowaniu) pozwala używać dowolnego zewnętrznego serwera pocztowego podczas wywoływania systemowej komendy /usr/bin/mail. Potrzebna konfiguracje umieszczamy na końcu pliku /etc/nail.rc (nie mylić z /etc/mail.rc) … kiedy chcemy żeby dany użytkownik posiadał odrębną konfiguracje, to musimy wymedytować plik ~/mail.rc

set smtp-use-starttls
set from=user@jakis.host.org
set smtp=smtp.jakis.host.org
set smtp-auth-user=user@jakis.host.org
set auth-login=user@jakis.host.org
set smtp-auth-password=supertrudneitajnehaslo
set ssl-verify=ignore

Teraz możemy przetestować nasza konfiguracje wywołując:

mail nasz-adres@nasz-server.org

Jeżeli coś nie działa to zostaniemy o tym poinformowani stosownym komunikatem … BTW. jeżeli chcemy sobie debugować możemy wykorzystać przełącznik -d (jak debug ) , z tym ze należy tutaj wspomnieć, że dodanie tego przełącznika powoduje wypisanie na ekran wiadomości i … nie powoduje jej wysyłania (sic!).

Dlaczego o tym pisze ? Bo dziś zmarnowałem ładnych parę godzin(sic!) żeby się do tego dogooglac … najpierw żeby znaleźć ta paczkę, potem zęby odpowiednio skonfigurować (tutaj szczególne podziękowania należą się przełącznikowi -d …).

Parę dni temu chłopaką z UbuntuForums.org, a udało się uruchomić gruba’a na Mac’ach z 4Gb pamięci ram (czyli problem który mnie zatrzymał ostatnio został rozwiązany). Działającą wersje 64-bitowego grub.efi (wraz z modułami) można pobrać z tąd.

Wydaje mi się że warto w tym miejscu przytoczyć parę features które dostępne są w wersji 2. IMHO najważniejsze są dwa:

• mini bash – w czasie bootowania mamy możliwość przejścia w trym shella (domyślnie wciskając klawisz „c”) tam możemy np. wylistować partycje na dysku czy zawartość katalogu, możemy oczywiście też zabootować jądro. Dostępna jest również historia poleceń … bardzo przydatna w przypadku wszelakich literówek
• wygodniejsza edycja ustawień systemu podczas boot’owania. Chodzi mi tutaj o możliwość zmian w grub.conf/menu.list tuż przed uruchomieniem systemu. We wcześniejszej wersji grub’a trzeba było najpierw wybrać linie którą chcemy edytować, potem przejść w tryb edycji wciskając „e”, po dokonaniu zmian zatwierdzić to enterem i całość potwierdzić jeszcze naciskając „b”. W nowym grubie opcje uruchomienia edytujemy jak w nano, nie trzeba już wybierać linii i podwójnie potwierdzać dokonanych zmian, wystarczy tylko ctrl+x i system sie zaczyna boot’ować albo ctrl+c żeby anulować zmiany

To na tyle jeżeli chodzi o nowego grub’a … wracając do sedna sprawy …

Skoro jest już działający bootloader, to wypadało by też  mieć działające jądro … co niestety nie okazało się takie proste jak by się to mogło wydawać.

Jak też można się spodziewać aktualnie używane jądro (2.6.28-gentoo-r1) nie ruszyło (nie wstała w ogóle grafika grafika, brak żadnego promt’a itp …) … i tak zaczęły się poszukiwania działającego jądra … na szczęście nie trwały długo, z pomocą przyszedł nie dawno co opublikowany Debian Lenny. Dystrybucyjne jądro 2.6.28 ruszyło bez problemów, ale zaraz potem się zbuntowało i nie wiadmo z jakich powodów nie chciał zamontować rootfs’a.

Kolejne jądro jakie testowałem pochodziło również z Debiana Lenny, ale tym razem z dystrybucji live. Wraz z dołączonym obrazem initrd mogło wystartować mój system … sytuacja była trochę komiczna bo wykożystywałem jądro i obraz initrd z Debiana do odpalenia Gentoo, ale czego nie robi się żeby osiągnąć cel . Po udanym zalogowaniu udało się mi nawet bez większych problemów odpalić X’y ;>

Następnym etapem było pozyskanie pliku konfiguracyjnego tego jądra. Na pierwszy rzut poleciało

cat /proc/config.gz

niestety bez skutku (koś tego nie wkompilował). Skoro nie da się w ten sposób to trzeba poszukać w google’u. Poszukiwania te też nic nie dały gdyż akurat w tym momencie serwer i strona http://merkel.debian.org/~jurij/ leżały … co za pech :/ … Na szczęście okazało się, że konfig starym dobrym sposobem leżał sobie w /boot … najprostsze rozwiązania są najlepsze, tylko nie zawsze się na nie szybko wpada …

Mając działającą konfigurację jądra można zabrać się za próbę rekompilacji. Jako pierwsze do boju stawiło się 2.6.28 (z patch’ami Gentoo). Kolejne parę godzin walki, kilkanaście reboot’ów i kompilacji … rezygnacja, cóż to może 2.6.27 (tym razem vanilla) … po paru godzinach status taki sam co z 2.6.28, czyli bez efektów. Ostateczność: 2.6.26 (też vanilla) … działa. Kolejne godziny walki i próby zmuszenia 2.6.28 (bazując ciągle na konfigu z 2.6.26) do działania spełzły na niczym …

Tak właśnie spędziłem sobie część soboty, prawie całą niedziele i 3h w poniedziałek na rekompilacjach i reboot’ach … tylko po to żeby dojść do wniosku, że coś pomiędzy 2.6.26, a 2.6.27 zostało skopane w EFIFB i/lub w FrameBuffer’rze, ale co gdzie i jak to ja nie mam zielonego pojęcia, w tym miejscu kończą się moje możliwości … co gorsze, poprawy nie widać nawet w 2.6.29-rc5, jeszcze gorsze jest to, że nie mam żadnych danych które mogły by pomódz developerą kernela … a może brak mi raczej odwagi żeby napisać na LKML

Nic to, trzeba pokornie czekać na poprawki … a tym czasem nie postrzeżenie zaczął się nowy semestr

OM2008.09: czyli stabilniejsza wersja OM2008.08, powiem tylko tyle że jest jest stabilne … bo przez te prawie 2 tygodnie się tam nic nie zmieniło poza 2 pakietami.

Debian: experimental, czyli sporo zmian, nowe FSO, python, mathbox, xorg … numerki poleciały w górę ale namacalnych efektów nie widać … przynajmniej bez karty SIM.

Podsumowując, moko rozwija się ale jakoś nie widać żeby szybko było dostępne dla ZU

Sam proces instalacji odbywa się automatycznie, jedyne o czym musiałem pamiętać (przy drugiej instalacji, gdyż po pierwszej poprawiałem ten błąd ręcznie), to zmiana systemu plików partycji z uImage (z ext2 na vfat, bo mój FR nie akceptowal ext2 na partycji z boot’em). Po instalacji i ponownym uruchomieniu (cytując wiki Debiana):

From there on, there is nothing special about your telephone any more – it’s a Debian system!

osobiście bym się z tym nie zgodził, bo ile telefonów może działać na Debianie i dawać dostęp do konsoli i ssh ?

Razem z Debianem dostajemy FSO … i tu mały haczyk, wersja która jest w repozytoriach Debiana nie działa u mnie, tj. po wpisaniu pinu można było go zaakceptować i czekać w nieskończoność. Błąd ten jest znany … i nawet dorobił się quick fix’a (mojego autorstwa ;>)

To by było na tyle … it’s nothing special – it’s a Debian