Monthly Archives: December 2009

Christmasing-Holidaying po raz drugi i 100 wpisów w jednym

Nie tak dawno obchodziłem rocznicę powstania bloga. Urlop może w tym roku jakoś specjalnie mi nie wyszedł (nie mógł, spędziłem go remontując mieszkanie), ale za to święta po prostu muszą.

Wpis ten jest nie tylko kartką z życzeniami, ale także okrągłą okazją. Albowiem jest to 100 wpis na blogu!!!. Bardzo miła koincydencja i naprawdę oby takich było jeszcze więcej. Chciałbym podziękować z tym miejscu wszystkim czytelnikom bloga, komentującym moje poczynania, podrzucającym dobre rady w komentarzach czy mejlach. Największym prezentem gwiazdkowym byłoby podwojenie, albo potrojenie Waszej liczby w przyszłym roku. Choć w sumie zależy to tylko ode mnie 🙂 Jeszcze raz wielkie dziękuję!

Co do świąt – są tacy co lubią, są tacy co nienawidzą. Jak już pisałem rok temu każdy ma swoją wizję tychże, że o sposobie spędzania nie wspomnę. Ja tylko życzę każdemu, aby był on przyjemny przynajmniej w takim samym stopniu, jak mój. By prezenty były trafione, bliscy nam ludzie w tym dniu jeszcze bliżej niż zazwyczaj, a ufajdany winem obrus czy ewentualnie padający deszcz okazały się nieistotnymi przeszkodami.

Jak zawsze na święta wyjeżdżam do domu rodzinnego. Zatem do stycznia raczej nic nowego nie napiszę, projekty zawieszone, odpoczywam. Rzecz jasna czasem tu zajrzę – wszak internet do dobro dość obecnie powszechne. Tym razem nie jadę na narty zatem wrócę wraz z żoną w całości i bez większych kontuzji. No może poza kilkoma kilogramami nadwagi zdobytymi na domowym wikcie.

Na sam koniec zaś zdjęcie mojej choinki – po raz pierwszy w życiu mam żywe drzewko – i wiem, że na pewno będzie tak już zawsze. Wesołych Świąt.

Debian jako serwer Javy – Serwery, bazy i routing

Po przygodach z przenoszeniem aplikacji z Jetty na Tomcata serwer ostatecznie stoi. Jest to całkowicie mój VPSik. Pierwotnie działał na nim Gentoo, jednakże nigdy nie bawiłem się z tą dystrybucją w związku z czym trochę szkoda mi było kilku tygodni na rozkminienie o co w tym wszystkim chodzi. Dlatego też decyzja o zainstalowaniu na nim Debiana, dystrybucji dojrzałej, sprawdzonej i szeroko znanej. No i jak wiadomo – support dla niej to cała rzesza linuxowych geeków.

Wstęp

Cel był prosty – stworzyć system, na którym będą działały moje aplikacyjki. Nie wymaga on zatem tuningowania jak wielkie produkcyjne serwisy, ale podstawowe kwestie dotyczące stabilności oraz bezpieczeństwa wypadałloby na nim zrobić. Docelowo na serwerze miały działać następujące usługi:

  • Apache Tomcat
  • bazy danych (MySQL na start, potem doinstaluję Postgresa)
  • języki skryptowe – choćby do wygodnego używania PHPMyAdmin, czy tego typu rozwiązań
  • no i jakiś serwer WWW, by te języki skryptowe mogły gdzieś śmigać

To był plan 0. Otrzymałem Debiana z już zainstalowanym SKD dla Javy, a także ze śmigającym Tomcatem. Instalacja samego kontenera nie jest specjalnie skomplikowana – po prostu ściągamy go poprzez apta i tyle. Jeżeli jednak musimy zaczynać z “gołym” systemem to z pewnością ten link będzie bardzo pomocny. UWAGA!!! Dodam tylko, że występuje tam mały błąd – po instalacji SDK w pliku /etc/profile należy dopisać:

export $JAVA_HOME

Zaś na listingu występuje zapis bez znaczka $. Bez tego nasze aplikacyjki dostarczone z Tomcatem nie ruszą. Wypadałoby też zobaczyć czy na pewno używamy Javy 6. W konsoli:

java -version

Jeśli mamy tam jakieś wersje <1.6 to znaczy, że można też odwiedzić wątek na pewnym forum. Na chwilę obecną zakładam, że wszystko jest dobrze poinstalowane plus używamy najnowszej wersji Javy.

W zależności od potrzeby serwer obsługujemy poleceniami:

/etc/init.d/tomcat-6 start|stop|restart

Konkretna nazwa skryptu może się różnić (w podanym przeze mnie linku jest to /etc/init.d/tomcat). Domyślnie nasz kontener działa na porcie 8080 – jego zmianą zajmiemy się za chwilkę. Uruchamiamy kontener i powinniśmy pod adresem http://localhost:8080 zobaczyć taką oto stronę:

Tomcat jest dostarczany bynajmniej nie jako ‘out-of-the-box’ i trzeba trochę pogrzebać w plikach konfiguracyjnych, aby spełniał w pełni swoją rolę. Domyślnie też jest dostarczany z 2 aplikacjami, które umożliwiają zarządzanie serwerem poprzez interfejs WWW. Pozostawianie ich dostępnych na serwerze produkcyjnym nie jest zbyt dobrym pomysłem (z powodów bezpieczeństwa), ale na etapie stawiania systemu mogą okazać się bardzo przydatne. By jednakże otrzymać do nich dostęp należy edytować plik /var/lib/tomcat6/conf/tomcat-users.xml. U mnie wygląda on tak:

<tomcat-users>
 <role rolename="manager"/>
 <role rolename="admin"/>
 <user username="nasztajnylogin" password="mojetajnehaslo" roles="admin,manager"/>
</tomcat-users>

Oczywiście user i hasło są zmyślone 🙂 W tym pliku XML mamy taki kontenerowy ACL – tworzymy jednocześnie zarówno role jak i użytkowników. Dzięki temu uzyskujemy dostęp do 2 aplikacji zarządzających kontenerem. Są one o tyle istotne na etapie tworzenia serwera, że można szybko i wygodnie poprzez stronę WWW zarządzać serwerkiem. Ja jednakże postanowiłem pobawić się plikami konfiguracyjnymi, zatem usunąłem dostęp do tych aplikacji, a je same wyrzuciłem z serwera.

Baza danych MySQL

Podstawą dla wszystkich aplikacji sieciowych jest baza danych. HowToJava powstała z użyciem MySQLa, podobnie póki co jest i z ProgramBash. Wypadało zatem zainstalować ten RDBMS by mieć na czym operować. W pakietach Debiana znajduje się najnowsza (w miarę) wersja zatem wystarczy użyć apta i jesteśmy w domu. Problemy mogą wystąpić przy próbie połączenia z bazą z zewnątrz – dla przykładu z naszego lokalnego komputera. W moim przypadku Hibernate rzucał wyjątkiem o niemożliwości połączenia się z powodu Connection refused. Innymi słowy – już sam serwer nie chciał mojego requestu. Rozwiązanie jest proste – należy edycji poddać plik /etc/mysql/my.cnf i parametrowi bind-address nie nadawać wartości localhost lub 127.0.0.1, ale IP naszego serwera. Wtedy bez najmniejszych problemów będzie można połączyć się z lokalnej maszyny. Nalezy także pamiętać o utworzeniu użytkownika z odpowiednimi prawami (łączącego się z określonego hosta). Na koniec zabaw ze zmianą uprawnień wydajemy polecenie:

flush privilages;

Bez tego można kląć na potęgę dlaczego nasze zmiany w uprawnieniach nie są widoczne.

Routing lub też proxy jak kto woli

Domyślnie Tomcat (choć dotyczy to w sumie wszystkich serwerów/kontenerów Javy z jakimi miałem okazję pracować) działa na porcie 8080 lub okolicach. Rzecz jasna w przypadku podpinania domeny pod nasz serwer takie rozwiązanie nie za bardzo wchodzi w grę – wszak nie można ustawić w routingu domen docelowego portu. Przyjęło się, że w użyciu mamy port 80 – tam przeglądarki standardowo wysyłają swoje żądania. Cóż zatem zrobić, aby wykupiona domena wskazywała na nasze pliki z aplikacjami Javy (u mnie to WARy) i wyglądało to transparentnie? Mamy kilka rozwiązań:

  • ustawienie portu w konfiguracji Tomcata na numer 80. Proste, ale absolutnie niezalecane ze względów bezpieczeństwa!!!
  • forwardować ruch poprzez odpowiednią konfigurację firewalla. Iptables to dobre narzędzie do tego.
  • postawić nasz serwer/kontener Javowy za zwykłym serwerem WWW, który będzie działał jako proxy.

Powyższe rozwiązania zostały dokładnie omówione w tym miejscu, a i z pomocą Gogla, można dowiedzieć się wszystkiego. Ja również pierwotnie myślałem o postawieniu Apache i zastosowaniu connectorów, jednakże moi mili admini wyperswadowali mi takowy pomysł i stanęło na podobnym rozwiązaniu, ale w oparciu o szybki serwer WWW – nginx. Oficjalna stronka znajduje się pod adresem http://nginx.org/. Sam serwer ma swoje plusy i minusy, by się z nimi zapoznać zapraszam do artykułu w Wikipedii. Sam serwer posłuży też do obsługi PHP – konkretniej do narzędzi zarządzających bazą danych (wygodny jestem), a także być może w przyszłości hostowania tego bloga.

Instalacja nginxa jest banalnie prosta:

sudo apt-get install nginx

I nasz serwerek jest już zainstalowany. Całkiem przyzwoity materiał o tym serwerze można znaleźć u Riklaumina, ja ograniczę się na razie do pierwszego jego uruchomienia. Tuningiem i bliższym poznaniem zajmę się w kolejnych artykułach. Przede wszystkim należy przejśc do katalogu /etc/nginx/conf.d. Cokolwiek znajdzie się w tym katalogu zostanie domyślnie potraktowane jako plik konfiguracyjny. Należy utworzyć nasz podstawowy plik konfiguracyjny:

cd /etc/nginx/conf.d
touch default.conf

Edytujemy stworzony plik i wrzucamy w niego na przykład taki oto kod:

 server {
        listen       80;
        server_name  WPISUJEMY_NASZE_IP DOMENA1 DOMENA2 DOMENA3;

        # Main location
        location / {
            proxy_pass         http://127.0.0.1:8080/;
            proxy_redirect     off;

            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

            client_max_body_size       52m;
            client_body_buffer_size    128k;

            proxy_connect_timeout      3600;
            proxy_send_timeout         3600;
            proxy_read_timeout         90;

            proxy_buffer_size          4k;
            proxy_buffers              4 32k;
            proxy_busy_buffers_size    64k;
            proxy_temp_file_write_size 64k;
            proxy_cache_valid 5m;
        }
    }

To baaaaardzo podstawowa konfiguracja. Ale na pewno osiągnęliśmy jedno – wszystkie requesty domyślnie lecące na port 80 zostaną przekierowane na port 8080, gdzie będzie na nie już oczekiwał nasz Tomcat. Można odpalić nginxa poleceniem:

/etc/init.d/ngninx start

Być może trzeba będzie po raz pierwszy zrobić to z poziomu konta administratora. Jak widać sam serwer zainstalował skrypt, ktory uruchamia go przy starcie systemu (w katalogu /etc/init.d/).

Tomcata musimy odpowiednio poinformować o istnieniu czegoś takiego jak subdomeny. I tutaj właśnie pobawimy się plikami konfiguracyjnymi (choć będzie to dość szybka zabawa). Docelowo mój serwerek zainstalował się w katalogu /var/lib/tomcat6/. W tymże katalogu znajduje się również podstawowy katalog dla naszych aplikacji – webapps. Dla naszych aplikacji, które zamierzamy wdrożyć należy przygotować pliki dystrybucyjne – ja pozostaję od samego początku wierny plikom WAR. Teraz musimy wyedytować plik konfiguracyjny Tomcata. W naszym ulubioym edytorku bierzemy na tapetę plik /var/lib/tomcat6/conf/server.xml.

 <Host name="SUBDOMENA_Z_DOMENA" appBase="webapps/NAZWA_SUBDOMENY" unpackWARs="true" autodeploy="true"></Host>

Restart Tomcata i należy udać się pod powyżej wpisany adres. Oczywiście serwer nie znalazł ani katalogu, ani pliku o wskazanej nazwie (jeszcze nic nie wysłaliśmy na serwer), zatem przekierował nas na główną stronę w domenie. Jednakże póki co wszystko działa poprawnie – nie dostaliśmy od serwerów po drodze błędu 404. Do testów maszyny najlepiej na szybko stworzyć maksymalnie prosty projekt w Javie (ja użyłem przykładowego projektu JSF). Generujemy dla niego plik WAR i łączymy się z serwerem dowolnym klientem FTP/SCP/SSH (w zależności co lubimy i co mamy/odpaliilśmy na serwerze). Przesyłamy do katalogu webapps nasz plik WAR i tworzymy dla niego katalog. Dla ułatwienia stworzyłem subdomenę example.chlebik.pl jak i odpowiedni katalog. Do niego wrzuciłem plik WAR. Uwaga!!! Można naciąć się na uprawnieniach do katalogów lub plików. Podążając tropem aktywności mojego Tomcata wszystkie pliki i katalogi przypisuję do użytkownika tomcat6 oraz grupy o tej samej nazwie. Przynajmniej nie dostaję ukochanego komunikatu – Permission denied.

Powyżej w pliku server.xml ustawiliśmy, że ta konkretna aplikacja ma być deployowana na starcie serwera, a także ma mieć rozpakowany plik WAR (dla zwiększenia szybkości działania). Ponownie odwiedzamy adres naszej subdomeny – i nic. Dalej jesteśmy przekierowywani na główną stronę domeny. Cóż się stało? Ano taka dziwna cecha Tomcata – wystarczy nasz plik WAR znajdujący się (u mnie) w katalogu webapps/example/, przemianować na webapps/example/ROOT.war. Restart serwera i co? Hip-Hop, hurrra. Dostajemy miły komunikat od JSF i Facelets, że nasza aplikacja działa. Można z ciekawości zajrzeć do tego katalogu – został tam rozpakowany w podkatalog o takiej samej nazwie jak plik WAR cały kod naszej aplikacji. Dlaczego w ten sposób? Uważam, że w katalogu z aplikacjami powinny być inne katalogi, a nie stado plików WAR lub inszych, które zaciemniają obraz. Każda aplikacja ma swój katalog i niech w nim dzieje się co chce.

PHP i Fast-CGI

Na koniec został mi do zainstalowania PHP. O ile w przypadku pierwotnie planowanego Apache rzecz jest banalna, o tyle nginx wymaga trochę zabawy. Należy bowiem doinstalować specjalny moduł do obsługi języków skryptowych poprzez Fast-CGI. Tutaj korzysta się z dobroci serwera lighttpd, ale o tym można już poczytać sobie w artykule. Dodam tylko by odpowiednio skroić nasz plik default.conf z nginxa – można połączyć konfig FCGI z PHP z istniejącą konfiguracją, ale można też zastosować podejście opisane w powyższym tutorialu. Co więcej – nginx jest tak fajnym narzędziem, że przy restarcie waliduje swoje pliki konfiguracyjne – jeśli coś jest nie tak wówczas od razu zostaniemy o tym poinformowani bez konieczności przeglądania logów serwera.

Co dalej?

Mam nadzieję, iż trochę ułatwiłem początkującym adminom życie (jakbym ja miał 10 lat doświadczenia :). W ramach możliwości postaram się kontynuować tak mile rozpoczęty cykl wpisów o administracji serwerem dla programistów. Jeśli znalazłeś jakikolwiek błąd w powyższym materiale lub masz jakieś sugestie – rzecz jasna zapraszam do kontaktu lub komentowania. Gdyby ktoś był zainteresowany VPSem lub hostingiem tam gdzie ja to należy pisać na ten adres email. Przy okazji możecie wspomnieć, że to dzięki mnie wiecie o usłudze 🙂

Tak na koniec

Na sam koniec dobra rada dla wszystkich programisto-administratorów 🙂 Jakiekolwiek operacje na sewerze (dedyku, VPSie czy w ogóle czymkolwiek) lepiej wpierw przetestować na VirtualBoxie. Produkt firmy SUN świetnie się do tego nadaje. Nie będę opisywał tutaj procesu instalacji i tak dalej, dam tylko kilka szybkich rad dla uruchamiania wirtualizacji systemu w Windows XP:

1. Używana przestrzeń dyskowa na system linuxowy powinna być wrzucona na partycję z systemem plików innym niż FAT32!! Inaczej dostaniemy błędy podczas instalacji, albo użytkowania, gdyż ten format nie obsługuje istnienia plików powyżej 2 GB.
2. W świetle powyższego – skonfigurować wirtualną maszynę by miała rozszerzalne miejsce na partycji. Często coś tam się doinstaluje, odinstaluje lub chce pobawić i nagle BUM – nie ma miejsca.
3. Jeżeli naszego linuxa instalujemy wraz ze środowiskiem graficznym należy ściągnąć VBoxLinuxAdditions. Jest to obraz płyty, który po instalacji naszego systemu należy podpiąć i następnie uruchomić z poziomu linuxa. U mnie wymagało to doinstalowania kilku rzeczy (nagłówków jądra linuxa i czegoś jeszcze). Kiedy to wszystko już zrobimy uruchamiamy po prostu skrypt .sh dla linuxa i stosownej architektury. Dzięki temu będziemy mogli rozszerzać ekran z wirtualizowanym systemem, grafika przestanie się ciąć i w ogóle będzie lepiej.
4. RZECZ BARDZO ISTOTNA!!! Dość często ludziom zdaża się, że uruchomienie VBoxa nawet z czystą konsolą (bez fajerwerków KDE czy GNOME) powoduje zżarcie przez VBoxa jakiś 50-90% procesora. Strasznie to wkurzające – dzieje się tak niezależnie od przydzielonej ilości RAMu. Rozwązaniem jest wyłączenie antywirusa!! U mnie działa darmowy AVG – jego wyłączenie automatycznie zredukowało zasobożerność VBoxa. Domyślam się, że chodzi o monitorowanie wirtualnego połączenia internetowego. Z tego co wyczytałem w sieci również niektóre fiewalle zachowują się w podobny sposób.

VPS gotowy

W tym jakże pięknym choć mroźnym dniu nadejszła wielkopomna chwila – mój VPS oficjalnie zostaje zaprezentowany światu.

Punktem wejścia jest domena chlebik.pl, gdzie znajduje się mini-portfolio z linkami, które prowadzą do aplikacji i bloga. Od dziś aplikacje stworzone przeze mnie i działające online będą podpinane pod kolejne subdomeny. Na razie zatem mamy http://programbash.chlebik.pl oraz http://howtojava.chlebik.pl.

Na VPSie działa Tomcat, który okazał się o wiele bardziej przyjazny dla moich aplikacji niż Jetty. Jak serwer proxy przed nim został postawiony superlekki Ngix, zaś system to sprawdzony od lat Debian. Zaniedługo pojawi się pierwszy wpis dotyczący sposobu skonfigurowania takiego serwera, a w przyszłości wpisy na temat optymalizacji oraz zabezpieczania serwera. Na razie to tyle – zapraszam do odwiedzin.

Upgrade NetBeans i co z tego wynikło

Pojawiła się kolejna wersja IDE Netbeans. Jak to zawsze bywa – bardzo lubię updatować swój soft, zatem nie zastanawiałem się długo nad tym faktem. I obiecuję – to już ostatni raz.

Sam proces przebiega bezboleśnie. Wszystko się ściąga, instaluje, po uruchomieniu wita nas fajny screen i ogólnie cud marzenie. Problemy zaczęły się przy skanowaniu projektów. ZONK. W przypadku HowToJava problemów nie było. Wszystko działa. Problemem okazał się ProgramBash, który wpadł w spiralę rzekomych braków bibliotek. Pomimo spędzenia dobrych kilku dni na szukaniu pomocy u wujka Google, nie udało mi się rozwiązać problemu – nagle dziwnym trafem wyparowały zależności i pliki bibliotek, które w wersji 6.8 po prostu wyleciały z dostępnych. Nie wiem na ile to moja wina i brak porządku w bibliotekach i ich wspieraniu, ale dlaczego IDE cokolwiek brzydko się zachowało (jakieś powiadomienie, że biblioteki stare zostaną zmienione/usunięte by się przydało)?

Ostatecznie zatem musiałem utworzyć nowy projekt i ręcznie przepinać kod źródłowy. Przynajmniej osiągnąłem tyle, że ProgramBash będzie powstawał dalej na JSF w wersji 2. Zostawiłem poprzednią wersję Hibernate i wszystkich innych używanych bibliotek. Co prawda dalej przy lokalnym starcie Glassfisha dostaję jakieś zapomniane błędy, ale póki co aplikacja wydaje się działać. Choć co prawda dodawany upload plików na razie wysypał mi błędami (brak UploadFilter, gdyż sypał mi Class not found), mam nadzieję, że niedługo przyjdzie czas na kolejny wpis poświęcony tej aplikacji.

Chlebik leży i kwiczy

Kwiczy i leży. Trwają prace nad przeniesieniem aplikacji na VPS  z Tomcatem na pokładzie. Dlatego niestety wszystkie aplikacje, które stworzyłem edukacyjnie wraz z wpisami na blogu są nieaktywne. Stan ten utrzyma się jeszcze przez kilka dni niestety. Ale pewnie będę mógł napisać kilka ciekawych wpisów o konfiguracji Debiana do pracy jako serwer dla Javy.