Dariusz Łuksza

I think that every one knows GitHub and as you should know that we can host there for free ours open source project’s but if we want to have a private repository we should pay for it. It seams fair … but what if I don’t want to pay ? I can setup my own server somewhere or … use one of on-line file hosting service like dropbox (for free we get here 2GB, this is lots of space for git repositories ).

How it is possible? It is only about files. As we all know git keeps everything inside .git folder, therefore we can put it in dropbox. To do it we only need to have an account and configured dropbox-folder on ours hard drive, and here is recipe:

1. First of all we should add new remote to our git remote configuration, I’ll call it dropbox:

   git remote add dropbox file:///home/lock/path/to/dropbox-folder/project.git

2. Now we should create folder project.git
3. Launch a terminal and enter project.git folder
4. Run:

   git init --bare

5. Go back to yours project directory and push into dropbox:

   git push dropbox

Viola! Dropbox daemon will automatically synchronize with remote “repository”. And there is another feature of this solution, you can share this folder with yours friends!

But there are also some disadvantages:

1. No access control – if you share yours project with friend she (or he) have full access and can even delete everything … but you always have yours local copy
2. No web interface – this obvious … I think

This solution I figure out few minutes ago and use it to backup my BS project, and it seams to be working very well

UPDATE:

As Tim said it is also possible to have a free Git hosting on bettercodes.org. To be honest I didn’t check it because solution with dropbox meets my needs.

NEXT UPDATE:

According to Machu’s comment, there is also assembla.com that gives 2GB for SVN or Git repository.

I don’t know exactly when we hit a Google Summer of Code 2010 midterm date … time runs so fast, few weeks ago I was writing that I’ve got accepted in this year’s program edition, and now we hit a midterm evaluations. This is a quite good time to sum up this short period of time.

Starting from the begging … estimating a project; now I know that initially I was very, very (and even more very, very ) optimistic about project time line. According to my initial estimation I should now start working on stashing support in JGit … but for now I’m “stuck” in synchronize view. Even more because now I see that I’ll need two or more weeks to make it ready for 0.9.0 release, now it has two major issues that I would like to solve before upcoming release. I even  don’t want to think where I would be right now if Remy didn’t made initial contribution …

OK, so what is project current status? Well we had an synchronize action and it works quite well. It shows upcoming, outgoing and conflicting changes … but there are few issues in current implementation. First of all common ancestor isn’t calculated properly (according to bug: 317371). Next issue is that we always use HEAD as a ‘local’ in three-way-compare, to be honest this seams to be an Team Framework limitation because ‘local’ is always instance of IResource .. btw. I should raise an issue for this . Last thing (for now) that in my humble opinion should be included in 0.9.0 is support for change set’s (bug: 3318473) because Git works on repository state changes not on file changes. Additionally there is one small feature that also should be included in 0.9.0: merging support from synchronization view, but (for now) it seams to be a simple thing to achieve.

What are my plans? Fix for bug 317371 currently wait for approvement in Gerrit, so I thing that this is rather a closed thing. For now I’ll focus on change set support. In case of popper handling of source branch setup I’ll wait for any hints on eclipse forum thread, then I thin that I’ll try to implement it somehow. If I fail in this task, I thing that we should disable source branch selecting and set it by default to HEAD.

Some statistics and numbers:

• Add preliminary synchronization support within Eclipse for branches. – based on Remy Suen work
  32 files changed, 2902 insertions(+), 10 deletions(-)
• Refactored UI tests
  15 files changed, 434 insertions(+), 393 deletions(-)
• Fixes strange result set in Synchronize view on Windows
  1 files changed, 26 insertions(+), 19 deletions(-)
• Fix NPE when deleting project used in Synchronize View
  1 files changed, 14 insertions(+), 8 deletions(-)
• Show repository path in Synchronize View
  4 files changed, 14 insertions(+), 6 deletions(-)
• Simplify API of GitSynchronizeData class.
  5 files changed, 33 insertions(+), 72 deletions(-)
• Prevent from NullPointerException’s
  2 files changed, 24 insertions(+), 8 deletions(-)
• Add tests for integration with Synchronize view
  13 files changed, 2249 insertions(+), 12 deletions(-)
• Fixes obtaining common ancestor in Synchronize view – wait for code review
  22 files changed, 1499 insertions(+), 1329 deletions(-)

In my humble opinion this is quite good result for around 7 weeks of work

Yesterday Matthias Sohn, my mentor in Google Sumer of Code, ask me would I like to talk about EGit on Poznan Eclipse DemoCamp. After a moment’s reflection I’ve decided that this a great opportunity for me to get more involved in Eclipse community.

There are not much time for preparation, but I’m not a guy that prefer to have everything fixed, I’m rather prefer to improvise and let thing just happed . So I’m plan to have a quick introduction in Git, briefly describe differences between CVS/SVN and Git. Then I’ll move to describe features that we have in EGit 0.8 (that was released yesterday ). Last one but not least part would be a live demo covering some day to day use cases, describing how we, our company can benefit from distributed version control system.

btw. This would be my first public speak so I’m feeling stressed … I hope that everything went well during presentation

P.S. I’ll be speaking in Polish of course

Na początku tego roku zastanawiałem się czy wziąć ponownie udział w Google Summer of Code … jak widać po tytule zdecydowałem się wystartować, a nawet mój projekt został zaakceptowany … YEAH! Drugi raz znalazłem się w elitarnym gronie 10001025 studentów z całego świata.

W tegorocznej edycji będę współpracował z Matthias’em Sohn’nem przy rozwoju EGita i JGita (było to do przewidzenia po moich ostatnich wpisach). Dokładniej rzecz ujmując mój projekt obejmuje integrację EGit’a z Synchronization View oraz implementację wsparcja dla schowka (git stash). W tak zwanym między czasie czyli Community Bonding Period chcę zaimplementować UI dla tworzenia tag’ów w EGit’cie, już poczyniłem nawet ku temu pierwsze kroki.

W sumie będzie to dla mnie pewna odmiana w stosunku do Web Developmentu z którym miałem do czynienia do tej pory … zapowiada się ciekawy okres, oj będzie się działo ;> ;D

BTW. W tym roku Wydział Informatyki ZUT ma wyjątkowo wyjątkowo silną reprezentaję. Z moich infromacji wynika, że do SoC zakwalifikowały się jeszcze dwie osoby:

• Tomasz Oponowicz do Apache Software Fundation
• Adam Rakowski do KDE

Nie będę ukrywał, że jestem fanem zarówno Eclipse‘a jak i Git‘a. Idealnym połączeniem obu faktów jest projekt EGit, czyli (jak by ktoś jeszcze nie wiedział albo się nie domyślał) wtyczka dodająca obsługę repozytoriów Git’a do Eclipse’a.

Jakiś czas temu opisywałem EGit’a. Wtedy to już zauważyłem brak kilku opcji w UI. Jedną z nich była np. obsługa tagowania … ale już tak nie jest (a właściwie to nie będzie), gdyż wczoraj wysłałem do Code review efekt kilku godzin mojej pracy. Jeżeli patch zostanie zaaplikowany to w najnowszej wersji EGit’a będzie można już swobodnie tagować i zmieniać nazwy tagów prosto z UI.

BTW. Nie jest to mój pierwszy patch w tym projekcie, kilka dni temu zostały zaakceptowane moje poprawki do jednej z klas w EGit’cie W zanadrzu mam jeszcze coś … ale o tym za jakiś czas dopiero ;>

Podczas prac nad moją pracą inżynierska mam przyjemność używać git’a jako systemu kontroli wersji. Żeby współpraca układała się „zgrabniej” używam wtyczki do Eclipse‘a EGit znajdującej się w inkubatorze Eclispe Fundation (kilka dni temu zdarzyło się mi popełnić mały artykuł na temat EGit’a).

W naszej współpracy brakowało mi pewnych dwóch małych wodotrysków w dialogu do wybierania gałęzi, mianowicie reakcji na podwójne kliknięcie w nazwę gałęzi oraz poruszania się po drzewie za pomocą kursorów. Pomyślałem sobie, że warto by było chłopaków wesprzeć w pracy, w końcu odwalili kawał dobrej roboty … tak więc stworzyłem odpowiednią poprawkę. Niby nic wielkiego … do czasu … okazuje się projekt ten używa rozbudowanego narzędzia do przeglądania (review) i współtworzenia (conribute) kodu no i właśnie tutaj znajduje się problem … ale do rzeczy.

Gerrit, jest rozbudowanym (przynajmniej z mojego punktu widzenia) narzędziem do zarządzania rozproszonym projektem. Wymusza on pewien system pracy. Każdy patch musi zostać przejrzany oraz oceniony zanim trafi do głównego repozytorium. Nad każdą poprawką odbywa się głosowanie; dopiero po uzyskaniu odpowiedniej liczby głosów (od osób uprawnionych) zostanie ona włączona do głównej gałęzi kodu. Dodatkowo każdą linie poprawki można skomentować co ułatwia współpracę w rozproszonym zespole, zwłaszcza z nowymi jego członkami. Wprowadzane poprawki do poprawki ( ) np. na podstawie komentarzy, są widoczne w jednym miejscu. Całość od strony interfejsu wygląda ładnie i przejrzyście (osobiście nie miałem najmniejszych kłopotów żeby się „połapać” w tym web’owym interfejsie).

Projekt EGit udostępnia dokumentację ułatwiającą rozpoczęcie współpracy z Gerrit’em. Bezproblemowo przez nią przebrnąłem, stworzyłem potrzebne konto, dodałem klucz publiczny, odpowiednio skonfigurowałem Git’a dodając hook‘i … więc można zaczynać zabawę. ;>

Szybkie ogarnięcie w kodzie, lokalizacja odpowiedniej klasy, chwila google’ania o SWT … i gotowa jest poprawka. Szybki commit do lokalnego repo, potem wypchnięcie tego do Gerrit’a … i oczekiwanie na werdykt developerów ;>

Minęły 3 dni … jest pierwszy werdykt … -1 . Z mojego pośpiechu wkradły się dwie literówki błąd dość infantylny … no i nie trzymam standardów formatowania (nie potrzebnie ujmuję w klamry jedno-instrukcjowe linie w if’ach i else’ach). Trzeba to poprawić … no i tutaj właśnie zaczęły się strome schody …

Zrobiłem poprawkę, commit, push … Gerrit zamiast dodać tą poprawkę do już istniejącej wyodrębnił to jako zupełnie osobną zmianę … nie tak się umawialiśmy, nie tak miało być.

Jak się po chwili okazuje, EGit nie wspiera hook’ów … w ogóle ich nie używa tak więc w moim commit’cie zabrakło jednej bardzo ważnej linii:

Change-Id:

Teraz muszę to jakoś ręcznie połączyć …

Nie równa walka trwała dwie czy trzy godziny … w tym czasie za-spamowałem trochę skrzynki mailowe commit‘erą, bo dostają maila o każdej nowej poprawce zgłoszonej do systemu, a ja takich nie prawdziwych poprawek podczas walki wprowadziłem :/. Na szczęście całość zakończyła się sukcesem. Tak więc co zrobić jeżeli wypchniemy do Gerrit’a naszą zmianę bez Change-Id i chcemy do niej wprowadzić poprawkę ?

Najpierw musimy się na pewno znajdować w odpowiednim miejscu historii Git’a. Tak więc na początku tworzymy sobie nową gałąź i przełączamy się na nią (oczywiście wszystko robimy z linii poleceń):

git branch fixes
git checkout fixes

Za pomocą git log znajdujemy commit który wypchnęliśmy do repozytorium, niech to będzie np. f4a33b1 (wystarczy 6 pierwszych znaków z SHA-1) i cofamy się w czasie:

git reset –hard  f4a33b1

Dokonujemy potrzebnych zmian, za pomocą git add dodajemy nasze zmiany do commit’a i (ważne), poprawiamy ostatni commit (czyli ten f4a33b1):

git commit –amend

Najlepiej w samej treści wiadomości dołączonej do commit‘a nic nie zmieniać, zatwierdzamy commit wychodząc z edytora. Teraz ponownie odpalamy git log i zapisujemy/zapamiętujemy 6 pierwszych znaków z nowego commit’a (na pewno będą różne od poprzednich), np. ee421a. Wypychamy naszą poprawkę do repozytorium

git push ssh://username@egit.eclipse.org:29418/egit.git ee421a:refs/for/master

Po chwili powinniśmy dostać maila potwierdzającego wprowadzenie zmian.

Uff, to na tyle. Być może jest na to lepszy sposób … ale ten na pewno działa (a nie chcę wystawiać cierpliwości developerów EGit’a na zbyt dużą próbę).

BTW. Ten post starałem się pisać bez zbędnych anglikanizmów … wyszło to raczej średnio, nie mogłem skojarzyć odpowiedniego polskiego odpowiednika dla commit oraz hook.

Jakiś czas temu projekty jgit (czyli implementacja git‘a w java’ie) oraz egit (plugin do eclipse’a dodający wsparcie dla git’a) znalazły się w inkubatorze fundacji Eclipse. Dawno temu wyczytałem nawet, że git ma zastąpić CVS‘a na miejscu domyślnego systemu kontroli wersji w IDE … ale zanim to nastąpi upłynie pewnie jeszcze sporo czasu … nie mniej jednak już teraz można podejrzeć jak się mają rzeczy, co też właśnie w uczynię .

Może na początek kilka numerków 3.5.2 oraz 0.6.0.201002030558, nie nie są to numery dużego lotka . Pierwszy oczywiście opisuje aktualną wersje stabilną Eclipse, drugi zaś jest numerem wersji egit/jgit.

Pierwotnie stroną domową obu projektów było jgit.org (tutaj też znajduje się update site dla eclpse‘a) ale po przejściu projektu pod skrzydła Eclipse Fundation dostępne są dwie stronki eclipse.org/egit/ oraz eclipse.org/jgit/ na obu w sekcji download znajdziemy ten sam link do update site’u:

http://download.eclipse.org/egit/updates

Ja używam ciągle starego update site‘u:

http://www.jgit.org/updates

Z tego co sprawdziłem to podana wcześniej wersja jest dostępna tylko w drugim repo, możliwe że jest to jakiś nightly build czy coś “nie stabilnego” … nie wiem, u mnie działa ;>

W tym wpisie chciał bym omówić jak “podłączyć” nowy projekt pod git SCM (zakładając, że wcześniej nie współdzieliliśmy go w żadnym SCM‘ie). Jeżeli chodzi natomiast o dodanie istniejącego już projektu podpiętego pod jakieś git‘owe repo to robi się to przez File -> Import, nie ma do tego nowej perspektywy wszystko robią wizard‘y.

Tak więc dla przykładu zakładamy sobie nowy projekt GitTest, dodajemy tam jedną klasę Main z “standardowym”

System.out.println("Hello git!");

Następnie na tak spreparowanym projekcie klikamy prawym myszy i wybieramy po kolei Team -> Schare Project… z dostępnej listy oczywiście wybieramy git. Jeżeli plugin znajdzie w jakimś katalogu nadrzędnym katalog .git (czyli miejsce gdzie git przechowuje swoje metadane) to zasugeruje podpięcie się pod już istniejące repo. W moim przypadku taka sytuacja nie występuje.

Zaznaczmy nasz projekt, klikamy w Create Repository, następnie w Next i oto wykonaliśmy odpowiednik git init … sam nie wiem co jest prostsze, chyba jednak wolał bym to zrobić z “palca”.

Skoro już zainicjalizowaliśmy nasze repo trzeba by je czymś wypełnić, czyli wykonać odpowiednik git add. Spokojnie, wszystko można wyklikać tak wiec zaczynajmy klikać ;>. Parawym myszy na pliku/katalogu który chcemy dodać (w moim wypadku jest tylko jeden katalog src) i poklei Team -> Add to version control.

Kolejny krok to git commit. Znowu to wyklikamy ;> Team -> Commit. Możemy teraz dodać komentarz do commit‘a jak również odznaczyć pliki które nie chcemy dodać do repo. Po kliknięciu w Commit nasze zmiany zostaną zapisane w repozytorium.

Jako że przez pomyłkę na dodałem cały projekt do commita (Team -> Add to version control) również “nie chciane pliki” takie jak .setting, .classpath oraz .project dodały się co commit‘a. W takim wypadku odpalamy widok Navigator i na każdym takim pliku wykonujemy po kolei operację Team -> Remove from version control, Team -> Add to .gitignore. Tak powstały plik .gitignore dodajemy do git‘a i commit‘ujemy (czyli: Team -> Add to version control, Team -> Commit).

Pora zrobić coś bardziej szalonego … zmieńmy zawartość Main.java ! Żeby za bardzo nie szaleć ja dodałem dodatkowy wykrzyknik na końcu “Hello git!” ;>. Zapisujemy zmiany. Eclipse automatycznie (podobnie z resztą jak to ma miejsce podczas korzystania z CVS‘a) informuje nas o tym, że względem repozytorium nasz plik jest zmieniony. Jak sprawdzić zmiany ? Nie ma czegoś takiego jak Synchronize with repository … ale jest za to: Compare with -> Git index. Moje „szalone zmiany” są widoczne jak na dłoni … albo jak kto woli “jak na CVS’ie”

Niestety na chwilę obecną nie dopatrzyłem się żadnych możliwości porównania całego projektu, jak to jest możliwe w CVS’ie. Trzeba porównywać każdy plik z osobna … jest to trochę męczące ale mam nadzieje, że w kolejnych wydaniach taka funkcjonalność zostanie “jakoś” zaimplementowana oraz dodana.

Po sprawdzeniu jakie zmiany, względem repo, wprowadziliśmy w naszym projekcie możemy śmiało wyklikać Team -> Commit na naszym zmienionym pliku. W ten sposób moje repo zawiera już 3 commit‘y ;>

Może teraz sobie po-branch‘ujemy. Prawie standardowo klikamy na projekt i wybieramy Team -> Branch… wyskakuje nam okienko w którym możemy dodać nową gałąź, zmienić jej nazwę oraz przełączyć się na wybraną gałąź. Aktualna gałąź jest pogrubiona oraz dodatkowo oznaczona przypisem (current). Klikamy w New branch nazwa jest praktycznie dowolna, ja nazwałem nowy branch jako “awesome-changes” , akceptujemy zaznaczamy nowo dodany branch i klikamy Checkout, żeby się na niego przełączyć. Prawda, że proste ?

Teraz jeżeli klikniemy na projekt prawym myszy i z menu wybierzmy Team -> Show in Resource History widzimy historię zmian w naszym projekcie.

Niestety na chwilę obecną plugin nie pozwala merge‘ować branch‘y … szkoda, trzeba to robić ręcznie z linii poleceń czyli git merge <target> <source>.

Dostępna jest natomiast opcja nadpisywania poczynionych zmian. Przez Team -> Reset można wykonać reset wprowadzonych zmian do poziomu w wskazanej gałęźi.

To tyle mojego małego przeglądu, więcej informacji można znaleźć w User Guide EGit‘a.

Prace nad programem do inżynierki zaszły już tak “daleko”, że wypadało by gdzieś ten kod przetrzymywać dla bezpieczeństwa. Dobrym dodatkowym feature’m byla by też możliwość jego wersjonowania … jako, że jakiś temu postawiłem sobie własne repo git’a (dwie (1, 2) z zamierzonych trzech części opisu instalacji zostały już opublikowane) wybór był oczywisty.

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://gitosis@server.z.gitem.org/gitosis-admin.git

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://gitosis@server.z.gitem.org/nazwa-nowego-repo.git

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

UPDATE:
Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y

UPDATE2:
Dziś git też mnie pokonał … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ) i go opublikować.

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.

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.