Posts Tagged kompilacja

Kompilacja serwera aplikacji JBoss AS 5.1 ze źródeł (aktualnych)

Sty 11

Posted by Łukasz Stelmach in JBoss AS | 3 komentarze

Wersja społecznościowa (community) serwera aplikacji JBoss jest wydawana co jakiś czas w wersji stabilnej i na tym kończy się wsparcie ze strony Red Hata. Można to łatwo zauważyć na przykładzie wersji 5.1 serwera. Została ona wydana 23.05.2009 (czyli ponad półtora roku temu) i następną wersja stabilna, która się pojawiła do wersja 6.0 wydana pod koniec grudnia. W międzyczasie nie została opublikowana żadna wersja pośrednia.

Oczywiście, nie oznacza to że serwer nie posiada żadnych błędów. Jest to raczej związane z polityką firmy Red Hat, która poprawki do poszczególnych wersji wydaje tylko w ramach subskrypcji. Pozostają więc takie możliwości:

  1. Wykupić wsparcie w Red Hacie i mieć dostęp do wszelkich aktualizacji (generalnie najlepsza opcja).
  2. Pobrać aktualne źródła serwera aplikacji JBoss i samodzielnie je skompilować.

Przy pierwszym wariancie dużo do roboty nie ma, i w razie problemów zawsze można zawracać głowę firmie Red Hat. Zapewni to dostęp do przetestowanej aplikacji i da gwarancje, że wszystkie elementy działają poprawnie.

Jeżeli nie zdecydujemy się wykupienie wsparcia, pozostaje samodzielna kompilacja aplikacji. Pojawia się tutaj pytanie: po co w ogóle kompilować serwer aplikacji? Czy nie wystarczy po prostu używać opublikowanej aplikacji?

Poniższe polecenia będzie można wykonać samodzielnie po pobraniu źródeł serwera aplikacji.

Lista wszystkich zmian w repozytorium od momentu wydania wersji stabilnej JBossa 5.1:

svn log -r {2009-05-24}:BASE

Możemy sprawdzić, ile było poszczególnych zmian w kodzie źródłowym:

svn log -r {2009-05-24}:BASE | grep  ^r[[:digit:]] | wc -l

W moim przypadku wyszło 866 zmian w kodzie źródłowym.

Można także sprawdzić, ile usunięto zgłoszeń w systemie śledzenia błędów:

svn log -r {2009-05-24}:BASE | grep JBPAPP- | wc -l

W moim przypadku wyszło 502 zgłoszenia.

Jak widać, prace nad wersją JBossa 5.1 cały czas trwają.

Konfiguracja systemu

W moim przypadku cały proces kompilacji odbywa się na maszynie z systemem Ubuntu 10.10. Na szczęście system nie ma podczas tego procesu dużego znaczenia (poza detalami związanymi z instalacją pakietów).

Wymagania początkowe:

  • dostępność JDKw wersji co najmniej 1.5 (ja testowałem na JDK 1.6.22)
  • instalacja klienta Subversion
    sudo aptitude install subversion
  • instalacja aplikacji patch:
    sudo aptitude install patch

Kolejnym krokiem jest utworzenie odpowiedniego katalogu przeznaczonego na źródła serwera JBoss a następnie pobranie źródeł przy użyciu klienta Subversion:

mkdir JBoss-5.1
svn co http://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_5_1/ JBoss-5.1

Teraz pozostaje odczekać, aż źródła zostaną pobrane.

Jeżeli w przyszłości będziemy chcieli zaktualizować źródła, wystarczy wejść do katalogu z nimi (w moim przypadku do katalogu JBoss-5.1) i wydać polecenie:

svn update

Kompilacja źródeł

Pozostaje teraz skompilować serwer aplikacji. Jest to czynność stosunkowo łatwa, sprowadza się do uruchomienia jednego skryptu:

cd build
./build.sh

Podczas pierwszego uruchomienia zostaną pobrane wszystkie niezbędne do kompilacji i działania serwera biblioteki (przy użyciu aplikacji Maven). Proces ten może trwać dość długo. Po zakończeniu pobierania bibliotek źródła zostaną skompilowane i pliki binarne można będzie znaleźć w katalogu build/output.

W moim przypadku znalazł się tam katalogu jboss-5.1.1.Branch, co jak widać jest wersją nowszą niż ostatnia wersja społecznościowa serwera aplikacji JBoss 5.1.

Kompilacja ta jest także bardzo podobna do wersji komercyjnej serwera:

  • znajdziemy w niej profil production
  • w profilach jest także wyłączony dostęp do konsol zarządczych, użytkownik admin jest wyłączony w plikach konfiguracyjnych

Jeżeli z jakiś powodów wolimy wersję podobną do wersji społecznościowej, należy uruchomić na binarnym serwerze odpowiednie pliki przy użyciu polecenia patch. Dokładne instrukcje można znaleźć w pliku build/REDME.

Na zakończenie mały skrypt, który wywoła kompilację serwera JBoss, ale zapisze ją w katalogu zawierającym numer wersji repozytorium. Pozwoli to w łatwy sposób oznaczyć wersje źródeł, co może przydać się podczas testowania, czy aktualna wersja działa poprawnie i może zostać użyta na serwerach produkcyjnych.

Skrypt nazwa się build_jboss.sh i należy wywołać go z nazwą katalogu w którym znajdują źródła serwera JBoss:

./build_jboss.sh JBoss-5.1

Skrypt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/bin/bash

if [ ! -n "$1" -o ! -d "$1" ]; then
        cat <<EOF
Prosze podac katalog ze zrodlami serwera JBoss:

$0 jboss-svn
EOF
        exit 1
fi

JBOSS_DIR="$1"
BUILD_DIR="build"

echo -n "Numer wersji repozytorium: "

cd $JBOSS_DIR
REVISION=$(svn info | grep Revision | cut -c 11-)
echo $REVISION

cd $BUILD_DIR

echo "Kompilacja"
./build.sh -Dversion.tag=$REVISION

echo Kompilacja zakonczona, sprawdz katalog $JBOSS_DIR/build/output
echo

exit 0

Źródła

Tags: ,

Aktualizacja platformy RHQ z wersji 1.3 i 1.4 do wersji 3.0

Cze 13

Posted by Łukasz Stelmach in RHQ/JON | Comments off

Dwa tygodnie temu została wydana wersja 3.0.0.B06 serwera RHQ. Zachciało m się więc sprawdzić, co też w niej słychać. Zamiast jednak pobrać tę wersję ze stron projektu, zapragnąłem skompilować je samodzielnie i zrobić aktualizację używanej przeze mnie wersji serwera 1.4-SNAPSHOT.

Kolejne kroki jakie przedstawię poniżej pozwoliły mi zaktualizować:

  • serwer RHQ wraz z dołączanymi wtyczkami
  • wtyczki do serwera JBoss
  • agentów monitorujących wraz z ich wtyczkami


Na samym początku jeszcze mam jedną uwagę: mogę się założyć, że droga którą wybrałem była jedną z trudniejszych i na pewno istnieje prostszy sposób kompilacji źródeł serwera RHQ i aktualizacji istniejącego już systemu. W moim przypadku zacząłem od kompilacji kodu a następnie po kolei rozwiązywałem problemy jakie się pojawiały w kolejnych krokach. Myślę jednak, że musi istnieć prostsza metoda, więc myślę że zanim zaczniesz realizować kolejne kroki, postaraj się ją najpierw znaleźć, a tutaj wróć w ostateczności :).

Krok 1: przygotowanie środowiska

Pierwszym krokiem będzie przygotowanie środowiska, w którym będzie można skompilować serwer RHQ. W moim przypadku środowisko już miałem wstępnie przygotowane ze względu na kompilację wersji 1.4. Będziemy potrzebowali:

  • Java – zainstalować JDK 6, należy także poprawnie skonfigurować zmienną systemową $JAVA_HOME, która powinna wskazywać na katalog domowy z Javą
  • Maven – zainstalowany w wersji przynajmniej 2.1.x, można pobrać go ze strony http://maven.apache.org/download.html
  • PostgreSQL – zainstalować bazę danych, w wersji przynajmniej 8.3 (ja używałem wersji 8.4)
  • Git – system kontroli wersji

Krok 2: pobranie źródeł

W stosunku do poprzedniej wersji systemu RHQ uległ zmianie używany system kontroli wersji: wersja 1.3/1.4 używa systemu Subversion, aktualna systemu Git. W związku z tym pobranie i aktualizacja źródeł wygląda inaczej. Do aktualnej wersji RHQ zostały także włączone wtyczki pozwalające na zarządzanie serwera aplikacji JBoss, więc nie będzie także potrzeby pobrania osobnych źródeł dla nich.

Pobranie źródeł:

git clone git://git.fedorahosted.org/rhq/rhq.git

Pobranie źródeł trochę potrwa, u mnie zajęły w sumie około 150 MB, z tym że sam katalog git miał rozmiar 50MB.

Możemy także aktualizować źródła przy użyciu tego polecenia (wykonywanego w katalogu z pobranymi źródłami RHQ):

git pull -v --stat

Krok 3: konfiguracja bazy danych

Konfigurację bazy danych opisałem w artykule Jak skompilować ze źródeł aplikacje RHQ Server oraz Jopr w punkcie 3. Zamiast jednak tworzyć bazę danych o nazwie rhq należy utworzyć bazę o nazwie rhqdev:

createdb -U postgres -O rhqadmin rhqdev

Krok 4: kompilacja źródeł

Czas teraz na kompilację źródeł. Robi się to przy użyciu aplikacji maven. Pierwsza kompilacja może zająć sporo czasu (nawet do godziny), ponieważ zostaną pobrane biblioteki niezbędne do kompilacji i działania serwera RHQ. Każda następna powinna już być zdecydowania szybsza.

Kompilację rozpoczynamy będąc w katalogu ze źródłami aplikacji następującą komendą:

mvn -Penterprise,dev -Dmaven.test.skip=true -Ddbsetup install

Podczas procesu kompilacji zostanie utworzona baza danych, w związku z tym musi ona być odpowiednio skonfigurowana.

Po zakończeniu kompilacji można znaleźć serwer RHQ w katalogu modules/enterprise/server/container/target. Można w nim znaleźć także archiwum o nawie rhq-server-3.0.0-SNAPSHOT.zip, które można użyć do instalacji nowej wersji serwera lub też do aktualizacji już istniejącej.


Można także skompilować RHQ przy użyciu takiego polecenia:

mvn -Penterprise,dist -Dmaven.test.skip=true -Ddbsetup install

Spowoduje to utworzenie archiwum przeznaczonego do instalacji i aktualizacji. Ja niestety tak nie zrobiłem, co naraziło mnie na późniejsze problemy. Być może użycie tak przygotowanych plików binarnych rozwiązałoby je samo….

Krok 5: konfiguracja nowej wersji RHQ

Pozostaje teraz skopiować plik rhq-server-3.0.0-SNAPSHOT.zip na serwer docelowy i przystąpić do instalacji nowej wersji RHQ.

W moim przypadku instalowałem serwer w katalogu /opt/rhq-server. Początkowa konfiguracja sprowadza się do podania ścieżki dostępu do środowiska Java, czyli definiujemy odpowiednie zmienne w pliku bin/rhq-server.sh:

86
87
88
RHQ_SERVER_HOME=/opt/rhq-server
# RHQ_SERVER_DEBUG=true
JAVA_HOME=/usr/lib/jvm/java-6-sun

Teoretycznie, teraz można było uruchomić serwer, ale niestety nie w tym przypadku. Ponieważ podczas kompilacji została utworzona wersja deweloperska, to jest ona już przygotowana do pracy z odpowiednią bazą danych. Nie ma możliwości przeprowadzenia aktualizacji już istniejącego schematu. W związku z tym należy odwrócić proces instalacji, i przygotować tak serwer, aby pozwalał na uruchomienie procesu instalacji.

Nie ma takiej potrzeby, jeżeli kompilacja odbywała się z opcją dist.

Poniższe akcje należy wykonać w katalogu jbossas/server/default/deploy/. Zmieniają one nazwy niektórych aplikacji i usuwają niepotrzebne aplikacje (które zostaną utworzone podczas konfiguracji).

cd /opt/rhq-server/jbossas/server/default/deploy/
mv alert-cache-service.xml{,.rej}
rm -fr jms
mv jmx-console.war{,.rej}
mv mail-service.xml{,.rej}
mv rhq-agent.sar{,.rej}
rm rhq-ds.xml
mv rhq.ear{,.rej}

Powyższe kroki spowodują, że teraz serwer RHQ uruchomi się w trybie instalacji.

Można teraz uruchomić serwer RHQ, najlepiej w trybie konsoli:

bin/rhq-server.sh console

Po pomyślnym uruchomieniu, można połączyć się z adresem http://localhost:7080 i dalszą konfigurację przeprowadzić przy użyciu przeglądarki internetowej.

Na drugim ekranie możemy zdefiniować podstawowe dane potrzebne do instalacji serwera. Ponieważ przeprowadzamy aktualizację serwera, należy podać namiary na istniejącą bazę danych i po ich podaniu wybrać przycisk Test connection. Połączenie zostanie sprawdzone, RHQ wykryje że baza danych istnieje i będzie istniała możliwość zdefiniowania co z nią zrobić. Należy wybrać opcję Keep.

Ostatnim elementem będzie zdefiniowanie informacji o serwerze, na którym będzie pracował serwer RHQ. Można to zrobić przy polu Registered Servers. Z wyświetlonej listy wybieramy nasz serwer.

RHQ Server - aktualizacja serwera

RHQ Server - aktualizacja serwera

Warto pamiętać, że informacje o połączeniu z bazą danych oraz o konfiguracji serwera można znaleźć w pliku rhq-server.properties.

Po wykonaniu powyższych modyfikacji, można rozpocząć instalację serwera.

W moim przypadku w tym momencie zaczął pokazywać się dosyć długi wyjątek, który sprowadzał się do następującego komunikatu:

Cause: org.postgresql.util.PSQLException: BŁĄD: relacja "rhq_raw_config_id_seq" już istnieje

Przyczyną jego występowania jest próba utworzenia już istniejącej sekwencji (co można łatwo sprawdzić łącząc się z bazą danych). Usuwanie tej sekwencji z bazy i ponowne uruchamianie procesu instalacji niestety nie rozwiązywało problemu, w dalszym ciągu komunikat się pojawiał.

I w tym miejscu rozpoczyna się bardziej żmudna część tej instalacji. Nie będę już przynudzał, co i gdzie sprawdzałem aby się dowiedzieć w jaki sposób jest dokonywana aktualizacja bazy danych, skupię się tylko na sposobie rozwiązania tego problemu.

Baza danych aktualizowana jest na podstawie zawartości pliku db-upgrade.xml, który można znaleźć w archiwum jbossas/server/default/deploy/rhq-installer.war/WEB-INF/lib/rhq-core-dbutils-3.0.0-SNAPSHOT.jar. Należy ten plik otworzyć, wprowadzić modyfikację oraz zapisać. Ponieważ plik znajduje się w archiwum jar, dobrze jest tutaj użyć jakiegoś narzędzia, które pozwoli na modyfikowanie jego zawartości bez ręcznego wypakowywania plików. Ja używałem aplikacji Midnight Commander, który sobie z tym poradził znakomicie. I po kolei, trzeba zrobić:

  1. Otwieramy plik jbossas/server/default/deploy/rhq-installer.war/WEB-INF/lib/rhq-core-dbutils-3.0.0-SNAPSHOT.jar
  2. Otwieramy plik db-upgrade.xml w trybie edycji
  3. Znajdujemy linię, która zawiera definicję sekwencji rhq_raw_config_id_seq i komentujemy ją:
    1668
    <!-- <schema-createSequence name="RHQ_REPO_GROUP_ID_SEQ" initial="10001" /> -->
  4. Ponownie uruchamiamy instalację serwera
  5. Jeżeli wystąpi błąd z inną sekwencją, wykonujemy ponownie kroki od 2 do 4. W moim przypadku musiałem tę operację powtórzyć dla następujących linii:
    1725
    <!-- <schema-createSequence name="RHQ_REPO_RELATION_TYPE_ID_SEQ" initial="10001" /> -->
    1749
    <!-- <schema-createSequence name="RHQ_REPO_RELATION_ID_SEQ" initial="10001" /> -->
    1808
    <!-- <schema-createSequence name="RHQ_DISTRIBUTION_TYPE_ID_SEQ" initial="10001" /> -->
    1915
    <!-- <schema-createSequence name="RHQ_TAG_ID_SEQ" initial="10001" /> -->
    1929
    <!-- <schema-createSequence name="RHQ_DISTRIBUTION_FILE_ID_SEQ" initial="10001" /> -->
    2298
    <!-- <schema-createSequence name="RHQ_REPO_SYNC_ID_SEQ" initial="10001" /> -->
    2358
    <!-- <schema-createSequence name="RHQ_BUNDLE_ID_SEQ" initial="10001" /> -->
    2399
    <!-- <schema-createSequence name="RHQ_BUNDLE_VERSION_ID_SEQ" initial="10001" /> -->
    2464
    <!-- <schema-createSequence name="RHQ_BUNDLE_FILE_ID_SEQ" initial="10001" /> -->
    2588
    <!-- <schema-createSequence name="RHQ_BUNDLE_RES_DEPLOY_ID_SEQ" initial="10001" /> -->
    2624
    <!-- <schema-createSequence name="RHQ_BUNDLE_RES_DEP_HIST_ID_SEQ" initial="10001" /> -->
    2710
    <!-- <schema-createSequence name="RHQ_SAVED_SEARCH_ID_SEQ" initial="10001" /> -->
    2762
    <!-- <schema-createSequence name="RHQ_ROLE_LDAP_GROUP_ID_SEQ" initial="10001" /> -->
  6. W przypadku wystąpienia różnych innych błędów, warto rozpocząć proces instalacji od nowa lub w skrajnych przypadkach zrestartować serwer RHQ i ponownie rozpocząć instalację

W moim przypadku po zakomentowaniu ostatniej sekwencji instalacja przebiegła pomyślnie, baza danych została zaktualizowana, RHQ poprawnie się skonfigurował i mogłem już zalogować się na własne konto.

Krok 6: aktualizacja agentów monitorujących

Ostatnim elementem związanym z aktualizacją serwera jest poprawny upgrade agentów monitorujących. I tutaj pokazała się siłą tej architektury :). W moim przypadku wystarczyło po prostu zrestartować agenty, i już samoczynnie się one zaktualizowały.

Jeżeli posiadasz zdefiniowaną grupę z agentami (informacje o tym jak to zrobić możesz znaleźć w tym wpisie: Definiowanie grupy usług w serwerze RHQ), to wystarczy ją wybrać i wydać polecenie restartu. Polecenie zostanie zdalnie wykonane, agenty się zrestartują i zaktualizują.

W moim przypadku agenci wykryli nowe zasoby na serwera oraz niestety od nowa niektóre serwery JBoss (przynajmniej tyle na razie zauważyłem). Przestało także działać monitorowanie serwera Apache.

Tym sposobem dotarliśmy do końca, mam nadzieję że na więcej problemów nie natraficie.

Źródła

Tags: , , , , , , ,

Jak skompilować ze źródeł aplikacje RHQ Server oraz Jopr

Maj 21

Posted by Łukasz Stelmach in RHQ/JON | Comments off

Poniżej znajduje się krótki przewodnik w którym przestawię w jaki sposób skompilować oraz zainstalować ze źródeł zarówno serwer RHQ jak i pluginy dostarczane z aplikację JOPR. Kroki są te niezbędne, aby udało się uruchomić monitorowanie JBossa EAP 5 (lub też wersji społecznościowe 5.1) przy użyciu Jopra. Standardowa instalacja (w wersji 2.3.1) niestety nie zawiera odpowiedniego pluginu.

Krok 1: warunki wstępne

Przed rozpoczęciem kompilacji tych aplikacji, trzeba wcześniej zainstalować w systemie następujące aplikacje:

  • Java – zainstalować JDK 6, należy także poprawnie skonfigurować zmienną systemową $JAVA_HOME, która powinna wskazywać na katalog domowy z Javą
  • Maven – zainstalowany w wersji przynajmniej 2.1.x, można pobrać go ze strony http://maven.apache.org/download.html
  • Subversion – należy zainstalować klienta tego systemu wersji
  • PostgreSQL – zainstalować bazę danych, w wersji przynajmniej 8.3 (ja używałem wersji 8.4)

Krok 2: pobranie źródeł

Zanim przystąpimy do konfiguracji kolejnych aplikacji, można rozpocząć pobieranie źródeł aplikacji. Proces ten zajmuje trochę czasu, więc może się wykonywać w czasie gdy przystosujemy kolejne elementy instalacji.

Źródła należy pobrać z repozytorium SVN udostępnianego zarówno przez RHQ jak i Jopra. Najprościej to zrobić używając komendy svn, ale można też użyć innych aplikacji współpracujących z tym systemem kontroli wersji.

Pobranie kodu źródłowego RHQ Server:

svn co http://svn.rhq-project.org/repos/rhq/trunk/ rhq

Pobranie kodu źródłowego Jopr:

svn co https://anonsvn.jboss.org/repos/jopr/trunk/ jopr

W moim przypadku została dla RHQ Serwer została pobrana wersji repozytorium o numerze 5305 a dla Jopr o numerze 1360, także pozostałe informacje dotyczą tych wersji kodu. W nowszych niektóre rzeczy na pewno mogą się zmienić.

Krok 3: konfiguracja bazy danych

RHQ Server do swojego działania potrzebuje bazy danych. Może on działać produkcyjnie na bazie danych PostreSQL lub Oracle, testowo na HSQL (istnieje także eksperymentalne wsparcie dla MSSQL). Na potrzeby tej instalacji skonfigurujemy bazę danych PostgresSQL.

Konfiguracja bazy danych sprowadza się do następujących punktów:

  • konfiguracja pliku pg_hba.conf, w przypadku Ubunut plik ten znajduje się w tym katalogu: /etc/postgresql/8.4/main, należy włączyć logowanie zaufane dla użytkowników korzystających z lokalnego interfejsu sieciowego oraz z lokalnego komputera (uwaga, powoduje to, że nie będą oni pytani o hasło dostępu przy próbie łączenia się z bazą danych):
    82
    83
    84
    85
    86
    #local   all         all                               ident
    local   all         all                               trust
    # IPv4 local connections:
    #host    all         all         127.0.0.1/32          md5
    host    all         all         127.0.0.1/32          trust
  • utworzenie użytkownika w bazie danych o nazwie rhqadmin oraz z hasłem rhqadmin:
    createuser -U postgres -S -D -R -P rhqadmin
  • utworzyć bazę danych rhq, której właścicielem będzie użytkownik rhqadmin:
    createdb -U postgres -O rhqadmin rhq

Krok 4: kompilacja RHQ Server

Można teraz przystąpić do kompilacji oraz instalacji serwera RHQ. Robi się to przy użyciu aplikacji Maven, która powinna być dostępna na ścieżce. Pierwsze wykonanie kompilacji może zająć sporo czasu (w moim przypadku trwało to ponad godzinę), ponieważ muszą zostać pobrane odpowiednie biblioteki niezbędne do kompilacji.

Uruchomić kompilacje można wydając takie polecenie (należy jednocześnie znajdować się w katalogu z plikami źródłowymi RHQ Server):

mvn -Penterprise,dev -Dmaven.test.skip=true -Ddbsetup install

Parametr -Ddbsetup powoduje utworzenie schematu w bazie danych i jest wymagany podczas pierwszej kompilacji i za każdym razem gdy jej schemat zostanie zmieniony.

W trakcie procesu kompilacji zostanie utworzony schemat bazy danych. Zostanie także utworzony katalogu dev-container, w którym będzie znajdowała się aplikacji. Aby uruchomić RHQ Server, należy wejść do katalogu dev-container/bin i wykonać polecenie:

cd dev-container/bin
./rhq-server.sh start

Spowoduje to uruchomienie serwera RHQ. Po uruchomieniu powinien o być dostępny pod adresem: http://localhost:7080. Aby się do niego zalogować, należy użyć loginu rhqadmin oraz hasła rhqadmin.

About RHQ

Informacje o wersji RHQ Server

Istnieje także możliwość utworzenia archiwum z serwerem RHQ, które będzie można następnie użyć do instalacji nowej jego instancji. Należy w takim przypadku wydać następujące polecenie (będąc w katalog głównym ze źródłami RHQ):

mvn -Penterprise,dist -Dmaven.test.skip=true -Ddbsetup install

Spowoduje to kompilację projektu i utworzenie w katalogu modules/enterprise/server/container/target zarówno katalogu z serwerem (rhq-server-1.4.0-SNAPSHOT), jak i odpowiedniego archiwum zip (rhq-server-1.4.0-SNAPSHOT.zip). Uruchomienie tak przygotowanego serwera spowoduje konieczność przejścia przez kolejne kroki związane z jego konfiguracją.

Krok 5: kompilacja Jopr

Ostatnim elementem jest kompilacja pluginów wchodzących w skład Jopr oraz ich instalacja w ramach serwera RHQ.

Zanim jednak uda się zbudować Jopr, trzeba zmodyfikować pliki konfiguracyjne pom.xml w kilku miejscach. Jest to spowodowane tym, że znajdują się w nich odwołania do repozytorium Mavena, które nie istnieją, więc nie daje się przeprowadzić pomyślnie kompilacji projektu. Mam nadzieję, że zostanie to zmienione w repozytorium i nie będzie potrzeby wprowadzania tych zmian, ale dla wersji której ja używałem niestety było to potrzebne.

Przygotowałem plik o nazwie jopr-1360.patch, który zawiera różnice pomiędzy modyfikacjami które wprowadziłem oraz wersją źródeł które używałem. Należy pobrać ten plik i użyć aplikacji patch, która zastosuje go do źródeł. Aplikację te należy wywołać w katalogu w którym znajdują się źródła jopr:

$ patch -p0 < ../jopr-1360.patch.txt
patching file modules/tools/jbas5-plugin-descriptor-gen/pom.xml
patching file modules/plugins/jboss-as-5/testsuite/pom.xml
patching file modules/plugins/jboss-as-5/pom.xml
patching file modules/plugins/jboss-cache-v3/pom.xml
patching file pom.xml
patching file etc/jbas5-ejb2-mdb-test/pom.xml
patching file etc/jbas5-jnp-client/pom.xml
patching file etc/jbas5-ejb-client/pom.xml

Należy zwrócić uwagę na to, że niekoniecznie ten plik będzie działał, jeżeli coś się zmieniło w źródłach aplikacji. Dlatego też w przypadku gdy kompilacja nie będzie działać, proponują zobaczyć co ten plik modyfikuje i ręcznie te modyfikacje nanieść do odpowiednich plików.

Sama kompilacja Jopr polega na wywołaniu aplikacji Maven (w katalogu ze źródłami aplikacji):

mvn -Pdev -Drhq.containerDir=rhq/dev-container/ install

Za pomocą parametru -Drhq.containerDir wskazujemy miejsce, gdzie znajduje się skompilowana wersja RHQ Server. Należy zwrócić uwagę, aby podać pełną ścieżkę do tego katalogu, w innym przypadku pluginy mogą zostać skopiowane do innego katalogu.

Zamiast katalogu z wersją deweloperską serwera RHQ można także podać katalog modules/enterprise/server/container/target/rhq-server-1.4.0-SNAPSHOT. Wtedy wtyczki zostaną skopiowane do tej instancji serwera, wystarczą ją teraz skompresować i już można spróbować zainstalować na innym serwerze.

Tyle przynajmniej w teorii :(. Z jakiś magicznych powodów podczas instalacji serwera RHQ łącznie z wtyczkami z Jopra pojawiał się błąd o niemożliwości instalacji jednej z aplikacji (rhq.ear).W moim przypadku nie chciało to do końca działać. Rozwiązaniem okazało się utworzenie dwóch oddzielnych archiwów: w jednym był serwer RHQ, w drugim wtyczki Jopr. Czy w przypadku kompilacji wtyczek Jopr nie podajemy katalogu do samego serwera, ale jakiś katalog tymczasowy. Zostanie w nim odzwierciedlona odpowiednia struktura serwera, i wtyczki zostaną zapisane w odpowiednie miejsca. Wystarczy po instalacji serwera RHQ po prostu skopiować te pliki i już powinno działać.

Oto serwer RHQ Server oraz wtyczki Jopr, skompilowane:

Konfiguracja klastra oparta o moduł mod_cluster – kompilacja modułów

Maj 17

Posted by Łukasz Stelmach in JBoss AS | Comments off

Moduł mod_cluster jest dostępny dla kliku architektur, ale na pewno nie dal wszystkich. W moim przypadku wersja pobrana ze stron JBossa nie chciała działać z serwerem Apache. Nie pozostało więc nic innego, jak skompilować odpowiednie moduły ze źródeł. Na szczęście nie jest to trudne :).

Oto wpisy poświęcone konfiguracji modułowi mod_cluster:

  1. Konfiguracja klastra oparta o moduł mod_cluster — wprowadzenie
  2. Konfiguracja klastra oparta o moduł mod_cluster — kompilacja modułów
  3. Konfiguracja klastra oparta o moduł mod_cluster – konfiguracja

Krok 1: instalacja potrzebnych pakietów

Pierwszym krokiem jest rozstrzygnięcie, czy chcemy korzystać z wersji udostępnionej na stronie w postaci źródeł czy też pobrać najnowszą wersję modułów z systemu kontroli wersji. W pierwszym przypadku trzeba udać się na stronę pozwalająca ściągnąć źródła w odpowiedniej wersji.

W przypadku drugim należy zainstalować (jeżeli nie mamy) narzędzie Subversion. W moim przypadku komenda instalująca pakiet była następująca (musiałem wybrać wersję architektury, aby zainstalowała się odpowiednia wersja pakietu, prawdopodobnie nie jest to potrzebne w większości przypadków):

yum install subversion.x86_64

Kolejnym elementem jest instalacja dwóch pakietów:

  • autoconf – narzędzia potrzebne do konfiguracji kompilacji
  • httpd-devel – narzędzia i biblioteki potrzebne do budowania modułów dla serwera Apache
yum install autoconf
yum install httpd-devel-2.2.14-1.2.6.jdk6.ep5.el5.x86_64

I tutaj również musiałem bardzo szczegółowo podać wersję pakietu httpd-devel. Być może będziesz potrzebować innych pakietów więc w razie problemów w dalszych krokach będzie trzeba te braki uzupełnić.

Krok 2: pobranie źródeł

W celu pobrania źródeł pakietu z systemu kontroli wersji należy wydać następujące poleceni:

svn co http://anonsvn.jboss.org/repos/mod_cluster/trunk/ mod_cluster

Utworzy ono katalog mod_cluster i w nim zapisze pobrane źródła.

Można także pobrać źródła modułu ze strony Downloads.

Ja pobrałem aktualne źródła z repozytorium, w wersji o numerze 271.

Krok 3: kompilacja i instalacja modułów

Odpowiednie moduły skompilują poniższy zestaw instrukcji (powinny one zostać wykonane w katalogu mod_cluster/native:

1
2
3
4
5
6
7
8
9
for DIR in advertise mod_manager mod_proxy_cluster mod_slotmem
do
    cd $DIR
    sh buildconf
    ./configure --with-apxs=/usr/sbin/apxs
    make
    cp *.so /etc/httpd/modules/
    cd ..
done

Przed uruchomieniem powyższego skryptu proszę zwrócić uwagę na ścieżki dostępu, zarówno do narzędzia apxs jak i miejscu gdzie znajdują się moduły Apacha. Powyższy także kopiuje moduły do katalogu z modułami.

Jeżeli kompilacja przebiegła bez problemów, to odpowiednie moduły powinny już znaleźć się w katalogu z modułami Apache i można je używać.

Źródła

  • Building mod_cluster from sources

Tags: , , , , ,

SN Google Plus