Rozpakowanie plików z archiwum RPM

Mar 29

Posted by Łukasz Stelmach in RedHat Enterprise Linux | Comments off

Komenda, która pozwala na rozpakowanie wszystkich plików znajdujących się danym archiwum RPM:

rpm2cpio pakiet.rpm | cpio -vid

Zawartość pakietu zostanie rozpakowana do aktualnego katalogu.

Tags: , , , ,

Jak uruchomić więcej niż jedną instancję serwera JBoss na jednej maszynie fizycznej?

Mar 29

Posted by Łukasz Stelmach in JBoss AS | Comments off

Czasami zachodzi potrzeba uruchomienia więcej niż jednej instancji serwera JBoss na jednym komputerze, czy to do celów testowych, deweloperskich czy nawet produkcyjnych. Aby było to możliwe, należy spełnić następujące warunki:

  • każda instancja serwera musi posiadać własny profil
  • należy skonfigurować odpowiednio serwer aplikacji oraz maszynę na której go uruchamiamy

W sumie największym problem jaki się pojawia w momencie uruchamiania kolejnych instancji serwera, jest konflikt wykorzystania tych samych portów na wybranej maszynie. Sposobów rozwiązania jest kilka, niektóre wymagają modyfikacji konfiguracji maszyny fizycznej, inne jedynie modyfikacji serwera JBoss AS.

Pierwszym krokiem będzie utworzenie dwóch profili w katalogu $JBOSS_HOME/server, które będą potem wykorzystywane do uruchomienia serwera. W dalszych części przyjmę, że profile te noszą nazwy profile1 oraz profile2 i są kopią profilu default.

Dodanie kolejnych aliasów IP do interfejsów sieciowych

Najprostszą metodą poradzenia sobie z konfliktem portów jest dodanie kolejnego (kolejnych) interfejsu sieciowego, będącego aliasem to już istniejącego. Czyli po prostu przyznanie sobie kolejnego numeru IP i przypięcie do niego konkretnej instancji serwera. Może to być spokojnie kolejny interfejs lokalny (loopback), jeżeli nie chcemy mieć dostępu do serwera z poza lokalnego komputera.

Jak utworzyć kolejne interfejsy? To zależy od używanego systemu operacyjnego:

I teraz nie pozostaje zrobić nic innego, jak uruchomić JBossa. Standardowo JBoss przypina się tylko interfejsu oznaczonego jako localhost (czyli adresu 127.0.0.1) oraz uruchamiania profil default. Aby to zmienić, należy użyć odpowiednich przełączników:

  • -c – nazwa konfiguracji do uruchomienia, a naszym przypadku profile1 lub profile2;
  • -b – nr IP, który ma wykorzystać JBoss do nasłuchiwania na połączenia;

Uruchomienie serwera z konfiguracją profile1 oraz nasłuchiwaniem na adresie 127.0.0.1:

$JBOSS_HOME/bin/run.sh -c profile1 -b 127.0.0.1

Uruchomienie serwera z konfiguracją profile2 oraz nasłuchiwaniem na adresie 127.0.0.2:

$JBOSS_HOME/bin/run.sh -c profile2 -b 127.0.0.2

Po tych operacjach powinniśmy otrzymać dwa uruchomione serwery JBoss, każdy nasłuchujący na innym adresie IP, w związku z czym nie wchodzących sobie w paradę. Sprawdzić można to przy użyciu polecenia netstat:

$ sudo netstat -tlpn | grep java
tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:8083          0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 0.0.0.0:51415           0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:51035         0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 0.0.0.0:60988           0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:4444          0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:58460         0.0.0.0:*               LISTEN      12789/java      
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      12887/java      
tcp        0      0 127.0.0.2:4445          0.0.0.0:*               LISTEN      12789/java      
...

Zmiana portów (Service Binding Manger)

Drugim rozwiązaniem problemów konfliktu portów jest ich zmiana. Można to zrobić na albo przy użyciu specjalnej usługi zwanej Service Binding Manger lub też ręcznie

Od wersji 5.0 serwera aplikacji usługa ta jest domyślnie włączona i udostępnia 4 konfiguracje portów:

  • ports-default – domyślna konfiguracja portów
  • ports-01 – dodanie do każdego portu z domyślnej konfiguracji wartości 100
  • ports-02 – dodanie do każdego portu z domyślnej konfiguracji wartości 200
  • ports-03 – dodanie do każdego portu z domyślnej konfiguracji wartości 300

Jak widać konstrukcja jest całkiem prosta, definicja tych mapowań można znaleźć w pliku $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml. Tam znajduje się zarówno definicja wszystkich domyślnych portów, jak i definicje pozostałych konfiguracji (łącznie z offsetami).

Aby uruchomić JBossa z zadanym zestawem portów, należy ustawić w JVM zmienną jboss.service.binding.set na wartość odpowiadającej jednemu ze sposobów mapowań:

$JBOSS_HOME/bin/run.sh -c profile2 -Djboss.service.binding.set=ports-01

Można także zapisać zmiany w odpowiednim pliku konfiguracyjnym, nie będzie wtedy potrzeby konfigurowania zmiennej dla JVM. Plik, który należy edytować: $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml:

17
18
19
20
21
22
23
24
25
26
<!-- Provides management tools with a ProfileService ManagementView
interface to the SBM and its components -->
<bean name="ServiceBindingManagementObject"
class="org.jboss.services.binding.managed.ServiceBindingManagementObject">
 
<constructor>
 <!-- The name of the set of bindings to use for this server -->
 <parameter>${jboss.service.binding.set:ports-default}</parameter>
 
 <!--  The binding sets -->

W linii 24 znajduje się wpis wskazujący na domyślnie użyty zestaw portów. Wystarczy zmienić wpis ports-default na jedną z wartości: ports-01, ports-02 czy ports-03 i zrestartować serwer JBossa.

A oto jak wygląda mapowanie portów po uruchomieniu dwóch serwerów:

$ sudo netstat -tlpn | grep java
tcp        0      0 127.0.0.1:8083          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:8180          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:25460         0.0.0.0:*               LISTEN      15787/java
tcp        0      0 0.0.0.0:32885           0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:8183          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:51035         0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4444          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 0.0.0.0:60988           0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4445          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4446          0.0.0.0:*               LISTEN      12887/java
tcp        0      0 127.0.0.1:4544          0.0.0.0:*               LISTEN      15787/java
tcp        0      0 127.0.0.1:4545          0.0.0.0:*               LISTEN      15787/java
...

Jak widać, są uruchomione dwa procesy JVM i można zaobserwować podobne mapowania portów z różnicą 100 pomiędzy nimi.

Zmiana portów (admin-console)

W wersji 5.0 JBoss AS istnieje możliwość zmiany portów przy użyciu aplikacji admin-console. Umożliwia ona zarówno zmianę profilu, który będzie użyty podczas tworzenia konkretnych mapować, jak i modyfikację zarówno profili jak i poszczególnych portów dla różnych usług.

Binding Manager in the Admin Console

Binding Manager in the Admin Console

Czyli najprościej otworzyć Service Binding Manager, a następnie zmienić właściwość

Active Binding Set Name

. Pozostaje jeszcze tylko zrobić restart serwera i powinno działać.

Zmiana portów (ręczna)

Jeżeli z jakiś powodów nie można użyć usługi Service Binding Manager do zmiany domyślnych portów, pozostaje jeszcze możliwość ich recznej konfiguracji. W przypadku JBossa 5.1 należy otworzyć plik $JBOSS_HOME/server/PROFIL/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml oraz przyjrzeć się dokładnie w jaki sposób jest zdefiniowany domyślne mapowanie. W przypadku mojego pliku początek tej definicji wygląda następująco:

99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
!-- Base binding metadata that ServiceBindingStore uses to create bindings for each set -->
<bean name="StandardBindings" class="java.util.HashSet">
<constructor>
 <parameter class="java.util.Collection">
    <set elementClass="org.jboss.services.binding.ServiceBindingMetadata">
    <!-- ********************* conf/jboss-service.xml ****************** -->

    <!-- Naming Service -->
    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=Naming</property>
       <property name="bindingName">Port</property>
       <property name="port">1099</property>
       <property name="description">The listening socket for the Naming service</property>
    </bean>

    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=Naming</property>
       <property name="bindingName">RmiPort</property>
       <property name="port">1098</property>
       <property name="description">Socket Naming service uses to receive RMI requests from client proxies</property>
    </bean>

    <!-- Remote classloading service -->
    <bean class="org.jboss.services.binding.ServiceBindingMetadata">
       <property name="serviceName">jboss:service=WebService</property>
       <property name="port">8083</property>
       <property name="description">Socket for dynamic class and resource loading</property>
    </bean>

...

Jak widać, każda usługa posiada zdefiniowany jakiś port. Jeżeli mamy potrzebę, to możemy ten port zmienić, zrestartować serwer i powinno działać.

Podsumowanie

Wydaje mi się, że najlepszym sposobem uruchomienia kilku instancji serwera JBoss na jednej maszynie fizycznej jest użycie oddzielnych aliasów IP dla każdej z nich. Tylko jeżeli nie jest możliwe zastosowanie takiego sposobu, można zastanowić się nad zastosowaniem usługi Service Binding Manager. Jedynie ostatecznością powinna być ręczna modyfikacja portów, na jakich nasłuchują różne usługi uruchamiane przez serwera aplikacji:

Dlaczego warto używać oddzielnych adresów IP w zależności od instancji serwera:

  • łatwiej jest skojarzyć konkretną instancje JBossa z konkretnym numerem IP, niż pamiętać na jakie usługi na pracują na których niestandardowych portach
  • łatwiej jest skonfigurować zaporę ogniową
  • jeżeli istnieje na maszynie wiele usług, rośnie prawdopodobieństwo wystąpienia konfliktu portów nawet jeżeli używamy usługi SBM
  • łatwiejsza aktualizacja serwera aplikacji (brak problemów wynikających z nadpisaniem plików konfiguracyjnych, w szczególności w przypadku ręcznej edycji numerów portów)

Powyższe opisy działa w przypadku JBossa 5.1 i 5.0, w przypadku wcześniejszych wymagana jest trochę inna konfiguracja. Zmiana domyślnego adresu IP na którym nasłuchuje serwer jest taka sama, ale w przypadku JBossa 4.2 usługa SBM nie jest domyślnie włączona. Trzeba ją włączyć samodzielnie, co wymaga edycji odpowiednich plików. Podobnie inaczej się przypisuje ręcznie porty, na których nasłuchują poszczególne usługi (należy zmodyfikować pliki konfiguracyjne poszczególnych usług). Dokładniejszy opis można znaleźć w materiałach źródłowych.

Źródła

Tags: , , , , , , , , ,

Czym jest JBoss Microcontainer?

Mar 28

Posted by Łukasz Stelmach in JBoss AS | Comments off

JBoss Microcontainer jest to nowe jądro serwera aplikacyjnego JBoss AS 5. Powstało w wyniku prac nad poprzednim JXM Microkernel zmierzających do dodanie do niego wsparcia dla obiektów POJO. Nowe wydania jądra serwera aplikacyjnego może także być używane samodzielnie (jak zresztą większość pozostałych produktów JBossa). Oto jego najważniejsze cechy:

  • wsparcie dla wszystkich cech JMX Microcontainer
  • obsługa bezpośredniej instalacji komponentów POJO
  • obsługa wstrzykiwania zależności
  • poprawy w zarządzani cyklem życia
  • dodanie dodatkowych możliwości kontroli nad zależnościami
  • integracja z AOP
  • wprowadzenie Virtual File System (VFS)
  • ładowanie klas przy użyciu OSGI

Podstawowe moduły jądra

Moduły, jakie wchodzą w skład jądra JBossa oraz zależności między nimi:

Moduły JBoss Microcontainer

Moduły JBoss Microcontainer

  • Bootstrap – mechanizm pozwalający na aktywację jądra (jego załadowanie)
  • Controller – odpowiada za upewnienie się, że obiekty POJO zostaną załadowane, skonfigurowane oraz uruchomione w zależności od wybranego profilu, rozwiązywanie zależności i konfigurację oraz cykl życia rożnych systemów i usług
  • Registry – przechowywanie informacji o zainstalowanych obiektach POJO
  • Configurator – inicjalizuje i konfiguruje obiekty POJO
  • Deployer – proces instalacji obiektów
  • Bus –
  • Repository – przechowywanie metadanych o zainstalowanych oraz dostępnych (lecz nie zainstalowanych) obiektach POJO
  • Profile – pozwala na zdefiniowanie które systemy, podsystemy, obiekty POJO zostają zainstalowane, które usługi wystartują automatycznie a które będzie można uruchomić ręcznie

Proces startu serwera

Sam proces startu serwera jest obsługiwany przez oddzielaną bibliotekę, pochodząca z projektu JBoss Bootstrap. Start serwera typowo wygląda tak:

  • utworzenie serwera
  • wskazanie serwerowi, gdzie znajduje się konfiguracja, w przypadku JBossa jest to plik bootstrap.xml
  • uruchomienie serwera
  • zamrożenie konfiguracji, uniemożliwienie jej zmian w czasie działania serwera
  • serwer zostaje uruchomiony, uruchamia po kolei swoje usługi, zdarzenia
  • serwer przechodzi w stan „STARTED”
  • można działać
  • zamykanie serwera, uruchamianie zdarzeń związanych ze zmianą stanu
  • ewentualny restart serwera

Plik XML zawierający konfigurację procesu startu zawiera odnośniki do plików, które odpowiadają za konfigurcację poszczególnych usług serwera. W przypadku JBossa 5.1 wygląda on następująco (znajduje się on w pliku $JBOSS_HOME/server/default/conf/bootstrap.xml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
< ?xml version="1.0" encoding="UTF-8"?>
<!--
  The list of URLs for mc beans to load during bootstrap.
  $Id: bootstrap.xml 88109 2009-05-01 20:10:48Z bstansberry@jboss.com $
-->
<bootstrap xmlns="urn:jboss:bootstrap:1.0">

   <url>bootstrap/logging.xml</url>
   <url>bootstrap/vfs.xml</url>
   <url>bootstrap/classloader.xml</url>
   <url>bootstrap/aop.xml</url>
   <url>bootstrap/jmx.xml</url>
   <url>bootstrap/deployers.xml</url>
   <url>bootstrap/profile.xml</url>

</bootstrap>

Poszczególne pliki odpowiadają za konfigurację i inicjalizację odpowiedniego zestawu usług:

  • logging.xml
  • vfs.xml – inicjalizacja Virtual File System
  • classloader.xml – główny system ładowania klas oraz konfiguracja ścieżki dostępu do klas
  • aop.xml – inicjalizacja ziarna JBoss AOP AspectManager, wczytanie potrzebnych bibliotek
  • jmx.xml – inicjalizacja JMXKernel
  • deployers.xml – inicjalizacja szeregu ziaren odpowiedzialnych za aplikację rożnych usług lub aplikacji
  • profile.xml –

Źródła

Tags: , , ,

Jak wyczyścić pamieć podręczną DNS w Linuksie

Mar 23

Posted by Łukasz Stelmach in Linux | Comments off

Problem jest prosty: ulega zmianie adres serwera a nasz komputer ciągle łączy się ze starym adresem. Jest to spowodowane tym, że odpowiedzi od serwera DNS są przechowywane w pamięci podręcznej (żeby nie zasypywać biednego serwera DNS ciągle pytaniami). Ponieważ każda odpowiedź z serwera DNS ma pewien czas życia, możemy poczekać aż on upłynie i ponownie zostanie wysłane pytanie, lub też spróbować coś z tym zrobić.

W zależności od konfiguracji, może zadziałać jeden ze sposobów:

  • Restart interfejsów sieciowych – jeżeli jest możliwe, może się okazać najprostszą metodą, ale nie zawsze skuteczną.
  • Używamy demona dnsmasq – demon do przechowywania w pamięci podręcznej adresów DNS. Aby wyczyścić pamięć podręcznę, należy wysłać do niego sygnał SIGHUP
    # kill -SIGHUP $(pgrep dnsmasq)
  • Używamy demona bin – można użyć aplikacji służącej do zarządzaniem tym serwerem rndc
    # rndc flush
  • Używamy demona nscd:
    # /etc/init.d/nscd restart

Tags: , , , , ,

Logowanie przychodzących połączeń HTTP w serwerze JBoss AS i Apache Tomcat

Mar 21

Posted by Łukasz Stelmach in JBoss AS | 2 komentarze

Standardowo (przynajmniej w przypadku JBossa) nie są śledzone przychodzące połączenia HTTP. Może to wprowadzać pewną konsternację :), na szczęście łatwo to zmienić.

Odpowiednie modyfikacje należy wprowadzić w pliku server.xml, który w przypadku JBossa (5.0) znajduje się w katalogu deploy/jbossweb.sar odpowiedniej konfiguracji, z którą serwer jest uruchamiany.

Logowanie odbywa się przez klasę AccessLogValve uruchomianą jako valve (hmm, kranik z angielska, ale nie mam pojęcia jak to będzie po polsku). Należy więc odszukać definicję z tą klasą i ją po prostu odkomentować. Wygląda ona następująco:

80
81
82
83
<Valve className="org.apache.catalina.valves.AccessLogValve"
    prefix="localhost_access_log." suffix=".log"
    pattern="common" directory="${jboss.server.log.dir}"
    resolveHosts="false" />

Konstrukcję tę można umieścić w dowolnym kontenerze (Context, Host, Engine) i będą wtedy zapisywane wszystkie połączenia przechodzące przez dany komponent.

Dopuszczalne parametry konfiguracyjne:

  • className
    Nazwa klasy, która ma odpowiadać za obsługę logowania. Do wyboru są dwie wartości:

    • org.apache.catalina.valves.AccessLogValve – bardziej ogólna, umożliwia zdefiniowanie zakresu logowanych informacji
    • org.apache.catalina.valves.FastCommonAccessLogValve – klasa przeznaczona do wykorzystania na systemach produkcyjnych, umożliwia jedynie na logowanie informacji w formacie common lub combined
  • prefix
    Ciąg znaków dodawany na początku nazwy pliku z logiem. Domyślną wartością jest access_log.
  • suffix
    Ciąg znaków dodawany na końcu nazwy pliku z logami.
  • pattern
    Ciąg znaków zawierający informacje o tym, co powinno zostać zapisane w pliku z logami. Może to być definicja używający specjalnych znaczników lub też słowa common lub combined oznaczające jeden ze standardów logowanych informacji. Dokładną specyfikację można znaleźć w dokumentacji Tomcata.
  • directory
    Ścieżka dostępu do katalogu w którym powinny być zapisywane pliki z logami.
  • resolveHosts
    Jeżeli zostanie ustawiona na true to adresy IP zostaną zamienione na nazwy domenowe (będzie to negatywnie wpływało na wydajność, ponieważ będą potrzebne dodatkowe zapytania do serwera DNS). Jeżeli parametr przyjmie wartość false, zostaną użyte adresy IP.
  • rotatable
    Parametr określa, czy plik z logami ma być rotowany. Domyślnie przyjmuje wartość true. Jeżeli zostanie ustawiony na false, plik z logiem nigdy nie będzie rotowany oraz zawartość pola fileDateFormat zostanie zignorowana.
  • condition
    Włączenie logowania warunkowego. Jeżeli parametr zostanie ustawiony na jakąś wartość, to informacja o połączeniu zostanie zalogowań tylko wtedy, gdy ServletRequest.getAttribute() będzie równe null. Jeżeli wartością parametru będzie loguj, to połączenie zostanie zalogowane tylko wtedy, gdy będzie spełniony ten warunek: ServletRequest.getAttribute("loguj") == null.
  • fileDateFormat
    Pozwala na określenie formatu daty w nazwie pliku z logiem. Jednocześnie decyduje o tym, jak często plik ten będzie rotowany. Aby włączyć rotowanie co godzinę, można ustawić wartość parametru tak: yyyy-MM-dd.HH.

Źródła

Tags: , , , , ,