Posts Tagged → Debian

Prywatne repo git’a cz.2

W poprzednim poście de facto mało zajmowaliśmy się git’em … szczerze powiedziawszy to skonfigurowaliśmy tylko lighttpd które to później będzie nam potrzebne do uruchomienia cgit‘a czyli interfejsu www w którym będziemy mogli obejrzeć sobie nasze repo. Dziś za to zajmiemy się instalacją i konfiguracją gitosis.

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.

Prywatne repo git’a cz.1

Jakiś czas temu pisałem jak za pomocą git’a i pendirve’a można w łatwy sposób zabezpieczyć się przed utratą projektu. Dziś przedstawię bardziej skomplikowane podejście, a mianowicie postawimy repozytorium git’a na serwerze. W moich założeniach takie repozytorium nie będzie dostępnie publicznie (w przeciwieństwie do rozwiązania jakie na starcie proponuje GitHub; mają też rozwiązanie płatne w którym to możemy mieć  prywatne repo, ale ja wole mieć je u siebie ;)).

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.

Jak zmusić Debiana do korzystania z zewnętrznego MTA

Cala historia zaczęła się parę dni temu, kiedy to zapragnąłem sobie mieć prywatny serwerek do hostowania własnych nie publicznych projektów (do publicznych używam już github‘a).

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 …).

Moko po 20 dniach przerwy.

Ponieważ, tuż przed awarią mac’a kupiłem motke v8, cały okres kiedy mac był w serwisie OM leżało odłogiem. Teraz kiedy mam chwilę wolnego czasu sprawdzam co sie zmieniło w repozytoriach przez czas mojej nie obecności.

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 😐