Dariusz [LocK] Łuksza

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.

W dniach 20-21 listopada odbyła się druga Szczecińska Konferencja OpenSource (de facto pierwsza edycja nazywała się: Szczecińska Konferencja OpenSolaris ale to już jest w kwestii organizatorów ). Ogólna tematyka konferencji w większości poświęcona była OpenSolarisowi, pomiędzy prezentacje o zonach, zfs (… czyli to co jak powiedział Damian Wojsław: każda porządna konferencja o OpenSolarisie powinna posiadać) itp. wpleciono dość zgrabnie aspekty prawne dotyczące OpenSource, Sambe4, systemy biblioteczne, XEN’a, Firefoxa i PostrgreSQL.

Pierwszego dnia kulturalnie się spóźniłem kilka minut i ominą mnie początek pierwszej prezentacji o OpenSolarisie, na szczęście na pozostałych prezentacjach byłem już obecny w całości, tak więc po kolei. Druga prezentacja Piotra Jasiukajtisa bardzo ładnie prezentowała wykorzystanie mechanizmów które są dostępne tylko w *Solarisie (należy pamiętać o tym że wszystkie omawiane technologie istnieją również w innych systemach ale nie zawsze są odpowiednikami 1 do 1 w stosunku do prezentowanych). Ogólnie prezentacja bardzo przypadła mi od gustu, gdyż w przeciwieństwie do tego co było rok temu, pokazywała jak praktycznie są wykorzystywane zony, zfs i mechanizm wirtualizacji. Dla mnie jako osoby która na co dzień nie ma styczności z *Solarisem nie jest ważne to jak skonfigurować zfs’a, zone czy cokolwiek innego, tylko gdzie to można użyć, jakie problemy rozwiązać. Dzięki tej prezentacji wiem, że mechanizm snapshot’ów w zfs’ie na prawdę jest przydatny oraz jest praktycznie jedynym rozwiązaniem jeżeli chodzi o backup dużej porcji danych które się cały czas zmieniają. To samo dotyczy zon. Takie podejście do mnie trafia

Kolejna prezentacja nt. aspektów prawnych Rafała Malujdy była równie cennym doświadczeniem. Przede wszystkim dla tego, że w końcu zobaczyłem że OpenSource nie tylko dostrzegany jest przez środowisko IT oraz pasjonatów/hobbystów informatyki ale też przez inne grupy zawodowe oraz że jest on postrzegany jako równie interesujący. Cieszę się bardzo, że ten temat został poruszony na tej konferencji oraz, że prelegent jest ze Szczecina .

Samba 4 … przed tą prezentacją wiedziałem tylko że jest jakaś samba, do czego służy oraz jak mniej więcej powstała. Po prezentacji TomLee’go (tj. Tomasza Woźniaka) wiem dużo więcej o ciekawej (moim zdaniem) historii tego projektu, o tym jak jest rozwijany … a co konkretnie będzie w kolejnej wesji to szczerze mówiąc jest dla mnie miej istotne

RBAC i OpenSolaris, czyli dostęp oparty o role w w/w systemie. Prezentacja rzeczowa i przyjemna, szkoda tylko że ograniczona tylko do OpenSolarisa … rozumiem, że tam jest to zrobione najlepiej ale moim zdaniem warto by też wspomnieć więcej o innych systemach i dostępnych tam implementacjach. AFAIK i nie czegoś nie pomieszałem to dla linuxa dostępne są trzy implementacje RSBAC, SeLinux, grsecurity … to takie moje małe wtrącenia jako sympatyka linuxa

Drugi dzień konferencji również obfitował w wykłady o OpenSolarisie które poruszały już bardziej zaawansowane tematy które jakoś nie specjalnie mnie … aktualnie programistę, a nie admina … porwały . Za to wszystkie tematy nie związane z OpenSolaristem były bardzo ciekawe

Wegług kolejności pierwszy był Firefox prezentowany przez Roberta Partykę . Muszę przyznać, że nie wiedziałem iż ta przeglądarka posiada takie możliwości. Tak wiem, spora ilość pluginów może o tym świadczyć. Prezentacja była bardzo rzeczowa (aczkolwiek można by trochę popracować nad jej kolorystyką i wielkością czcionki ), na prawdę zrobiła na mnie spore wrażenie … do tego stopnia, że przesiadłem się ponownie z Opery na Firefox’a. Swoją drogą jestem ciekaw dlaczego ktoś jeszcze nie pokusił się (a przynajmniej nic mi o tym nie wiadomo) o pisanie plugin’ów do firefox’a z wykorzystaniem GWT … przecież to JavaScript, a w Javie przecież jest wygodniej

Ostatnio mognym tematem jest wirtualizacja … może z powodu kryzysu w którym to tnie się koszty . Nie mogło jej zabraknąć również na tej konferencji, najpierw Marcin Weksznejder mówił o wirtualizacji pod OpenSolarisem, potem Sebastian Szary mówił o XENie. Prezentacja mocno ukierunkowana była na praktyczne wykorzystanie tej technologii. O wirtualizacji z wykorzystaniem XEN’a mówił na GeeCon’ie oraz JAVArsovii mówił również Waldemar Kot … w sumie były to prezentacje o wirtualizacji JVM, a nie całego systemu operacyjnego

Hitem całej konferencji okazała się prezentacja Piotra Wejmana o systemie bibliotecznym … głównie dzięki niesamowitemu prowadzącemu który w poprowadził tą prezentację (mógł bym porównać poziom tej prezentacji do poziomu Jacka Laskowskiego). Prezentacja ta była kolejnym dowodem, że oprogramowanie OpenSource coraz aktywniej bierze udział w walce rynkowej oraz, że coraz częściej jest postrzegane jako właściwy wybór/kierunek. O samej aplikacji Koha nie będę się rozwodził, jedyne co mogę napisać to to, że na podstawie zaprezentowanych screenshot’ów rzeczywiście bije na głowę zamkniętą konkurencję.

Pod przewrotnym tytułem kolejnej prezentacji “Słonie w akcji”, poprowadzonej znowu przez Roberta Partykę ukrywała się PostgreSQL. Kolejna świetna prezentacja na wysokim poziomie. Dzięki tej prezentacji wiem jak sporo jeszcze nie wiem o PostgreSQL oraz, że w miarę możliwości będę wybierał ten system bazodanowy, a nie MySQL’a . Robertowi należą się spore brawa za przygotownie dwuch na prawdę dobrych i interesujących prezentacji, jestem pod wrażeniem jego wiedzy oraz umiejętności jej przekazania jak i umiejętności prowadzenia prezentacji … na prawdę jest z kogo brać przykład

Ostatnia prezentacja dotyczyła wykorzystania wolnego oprogramowania w firmie. TomLee przedstawił kilka przykładowych scenariuszy oraz listę zamienników dla płatnych aplikacji … szkoda tylko, że na audytorium nie było ludzi którzy mogli by z tej wiedzy skorzystać … cóż, są sobie sami winni …

Po konferencji odbyło się nie oficjalne wspólne spotkanie przy nie pasteryzowanym piwie w PetitParis w czasie którego poruszane były przeróżne tematy kto nie był ten niech żałuje ;P

Cieszę się, że w Szczecinie odbywają się takie imprezy. Jest to już druga konferencja informatyczna odbywająca się cyklicznie w tym mieście (pierwsza jest Java4People ), mam nadzieje że za rok będę mógł powtórzyć to zdanie (tj. że obie konferencje się znowu odbędą ). Jest jedna rzecz która mnie trochę martwi … słaby sponsoring tych imprez, nie wiem dlaczego Szczecińskie (i chyba nie tylko firmy) nie widzą w tym jakiejś formy promocji, czy też kontaktu z nowymi pracownikami (warto tutaj wspomnieć, że na JAVArsovi organizowana była wśród uczestników rekrutacja …)

BTW. Trójmiejska Grupa Użytkowników Linuksa (TLUG) organizuje zimowisko linuksowe w Pucku, można się rejestrować pod adresem: http://zimowisko.linux.gda.pl/. ;>

PS. Z góry, chcę przeprosić jeżeli przekręciłem czyjeś nazwisko, gdyby ktoś coś takiego się jednak zdarzyło proszę o informacje … tak samo jeżeli ktoś chciał by podlinkować swojego bloga

Ponad rok temu wspominałem tutaj o blogu Mariusz Lipińskiego w kontekście SCJP. Od wspominanego wpisu minął ponad rok. W tym czasie Mariusz zdążył uzyskać certyfikat, a nawet opublikować dwa wydania własnej książki (pierwsze jest całkowicie darmowe, a drugie można kupić tutaj), dodatkowo na łamach bloga krótko opisuje każdy rozdział z Sun Certified Programmer for Java 5 Stury Guide.

Ja w tym samy czasie próbowałem moich sił z  Sun Certified Programmer for Java 6 Stury Guide (SCJP6SG), cóż ukazał się dokładnie jeden post o tym temacie (w sumie to nie ma się czym chwalić ), a natłok obowiązków związanych ze studiami i pracą nie pozwolił mi kontynuować tą serię wpisów.

Wspomniałem już wcześniej o książce Mariusza w formie drukowanej, dziś właśnie dotarł do mnie jeden jej egzemplarz. Objętościowo jest on nie do porównania z SCJP6SG. Jeszcze nie zagłębiałem się dokładnie w Przygotowanie do certyfikacji SCJP6 ale zakładam, że jest to odpowiedni wstęp jak i repetytorium przed i po zapoznaniem się z SCPJ6SG.

W tym roku nie ma już raczej szans żebym przystąpił do egzaminu … ale za to postaram się to zrobić w przyszłym

Kiedyś ktoś stwierdził, że “mamy” (my jako Polacy) wielu wspaniałych specjalistów, naukowców, informatyków … programistów, tylko że wielu z nich “nie potrafi się sprzedać”, co powoduje że razem ze swoim geniuszem lądują w tłumie “szaraczków” i mimo swoich wybitnych zdolności tam pozostają. Karierę zawodową robią nie ci najzdolniejsi, ale ci którzy są w elastyczni, komunikatywni i mimo swoich wad znają i potrafią się cenić.

Tak to już jest skonstruowany ten świat i “komercyjny magiel”, że nie wystarczy już tylko być zdolnym ale trzeba też umieć komuś “wmówić”, że jesteśmy “zdolni”. Pierwszym krokiem żeby się umieć sprzedać jest dostrzeżenie tego problemu, potem mamy już do wyboru kilka możliwych ścieżek … drogie szkolenia, czytanie książek lub też nauka na własnych błędach.

Jest takie miejsce w “polskim internecie” gdzie takowych nauk udziela się za darmo. Miejsce w którym liczy się każde zdanie, miejsce gdzie każdy ma prawo (możliwe nawet że i nie pisany obowiązek) wypowiedzi na dany temat. Takim miejscem dla mnie jest Blog Alexa.

Nie pamiętam już w jak odkryłem tą kopalnie wiedzy o życiu, biznesie, podejściu do siebie i innych … nie jestem też w stanie określić dokładnie kiedy to się stało. Wiem tylko tyle, że na prawdę warto tam zaglądać … choć sam muszę się przyznać, że przez ostatni rok nie gościłem tam prawie w ogóle. Nic to, czas to nadrobić, aktualnie jestem na postach z maja 2009 więc już nie długo będę już na bieżąco

W myśl zasady Alexa “podaj dalej”, podaję i polecam wszystkim lekturę jego bloga … jeżeli tylko chcesz skorzystać z darmowej skarbnicy wiedzy i poprawić siebie

Kilka dni temu JetBrains udostępniło okrojona wersje (ładnie nazwaną Community Edition) swojego IDE dla Javy. Jako że nigdy nie miałem do czynienia z InteliJ postanowiłem zassać ową darmową wersję i sprawdzić jak się spisuje.

Niestety, używam dość egzotycznego window managera który zwie się Awesome. Posiada on funkcjonalność auto organizacji okien na pulpicie co jak się okazuje nie podoba się Javie 1.5 wzwyż. Winę za to ponosi zmieniony w JRE 1.5 backend do komunikacji z X-Window, JRE do wersji 1.4 korzystało z Motif, natomiast w późniejszych z Xtoolkit/XAWT które to nie jest kompatybilne z ICCCM (cokolwiek to znaczy ). Warto tutaj wspomnieć ze pośrednio może tutaj tez być winne JetBrains gdyż ciągle korzystają z AWT, a nie Swing‘a …

Rozwiązania ?
Są dwa. Pierwsze bardziej drastyczne uruchamiać InteliJ z wykorzystaniem JRE 1.4 – tego nie próbowałem ale teoretycznie powinno zadziałać. Drugie rozwiązanie posiada pewien haczyk, gdyż (jak się domyślam) 64-bitowa wersja Javy nie posiada wsparcia dla Motif; osoby posiadające 64-bitowe maszyny i systemy operacyjne z 64bitowa maszyna wirtualna ustawiona jako domyślną muszą dodatkowo zassać i gdzieś umieścić wersje 32-bitowa JDK/JRE. Oprócz 32-bitowej maszyny wirtualnej musimy dodać zmienna środowiskową AWT_TOOLKIT ustawiona na MToolkit. Ja zmodyfikowałem sobie plik bin/idea.sh dodając w linii 59 taki oto fragment:

# fixes for Awesome WM
export AWT_TOOLKIT="MToolkit"
IDEA_JDK="/ścieżka/do/jdk-x86"

Mimo, ze oficjalne ogłoszenie wyników GSoC09 odbyło się prawie dwa miesiące temu, dla mnie google’owe lato z kodowaniem zakończyło się dopiero parę dni temu kiedy to kurier dostarczył do mnie paczkę z koszulka i certyfikatem.

Co do samego projektu, to niestety nie udało mi się go skończyć w wyznaczonym terminie. Osobiście stopień zaawansowania oceniam na 75-80%. Mimo to Reinhard (mój mentor) uznał, że wykonałem na tyle dobrą pracę że ukończyłem pozytywnie GSoC.

Koniec Summer of Code nie oznacza dla mnie końca współpracy z developerami Cocoon’a, zwłaszcza, że nie wykonałem w pełni stawianych sobie celów. Dodatkowo na horyzoncie pojawiły się nowe interesujące pomysły na rozwój modułu monitorującego trzecią wersję Cocoon‘a.

Ostatnio pisząc o Summer of Code wspominałem o artykule traktującym o Spring JMX, miał on się ukazać w ciągu 2-3 tygodni … cóż nie udało się ale nie wydaje mi się by jego los był przesądzony . Wszystko jest ciągle kwestią czasu … jest to jedna z rzeczy którą chciałem zrealizować w czasie GSoC i ciągle pozostaje na mojej (dość, długiej(sic!) już) liście TODO.

Zapomniałem o jednej bardzo ważnej rzeczy … 90% napisanego przeze mnie kodu podczas GSoC znajduje się już w repozytorium ASF, a dokładniej mówiąc to jest tutaj. Natomiast całość kodu dostępna jest w archiwum znajdującym się pod koniec tej listy.

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

Today I publish newest version of cda2mc on github.

This version contains 2 new features:

1. it is possible to add CD information manually if CDDB does not contains information about it
2. if CDDB contains multiple entry’s for that particular CD you can chose one from list with one you want to use

Ogólnie z opisem naszej firmowo-JUG‘owej wyprawy na JAVArsovię ubiegł mnie już Filip ale nic z tego, niczym nie zniechęcony, opiszę moją wersję zdarzeń

Czytaj więcej…