Archive for Kwiecień, 2010

Automatyczna instalacja aplikacji znajdującej się poza katalogiem deploy

Domyślna konfiguracja serwera aplikacji JBoss automatycznie instaluje wszystkie aplikacje które znajdą się w katalogu deploy wybranego profilu. Może się jednak zdarzyć, że potrzebujemy instalować automatycznie zainstalować aplikację która znajduje się poza tym katalogiem (np. nie mamy dostępu do tego katalogu, jest to katalog współdzielony przez inne instancje czy też może z innych powodów).

Jednym ze sposób takiej instalacji jest użycie polecenia twiddle, tak jak jest to opisane tutaj: Zarządzanie instalacją aplikacji w JBoss AS. Taka instalacja jednak nie przetrwa restartu serwera, trzeba będzie odpowiednie polecenie wydawać po każdym uruchomieniu serwera lub aktualizacji aplikacji.

Innym sposobem jest wskazie w konfiguracji serwera dodatkowego katalogu, który będzie traktowany tak jak katalog deploy. Czyli w domyślnej konfiguracji wszystkie aplikacje (czy też pliki) będą automatycznie instalowane w serwerze aplikacji.

W przypadku serwera aplikacji JBoss wersji 5.1 odpowiedni należy modyfikacje wprowadzić w pliku conf/bootstrap/profile.xml. Plik ten znajduje się w wybranym profilu. Można tam znaleźć taką linię:

25
26
27
28
29
<property name="applicationURIs">
    <list elementClass="java.net.URI">
        <value>${jboss.server.home.url}deploy</value>
    </list>
</property>

Widać tutaj definicję podstawowego katalogu, który służy do instalacji aplikacji: ${jboss.server.home.url}deploy. Wystarczy teraz umieścić dodatkowy wpis określający nowy katalog i od tej pory JBoss powinien już go używać także do instalacji aplikacji. Ścieżkę dostępu należy podać w formie URI:

25
26
27
28
29
30
31
32
<property name="applicationURIs">
    <list elementClass="java.net.URI">
        <value>${jboss.server.home.url}deploy</value>

        <!-- Nowy katalog do skanowania -->
        <value>file:///nfs/applications</value>
    </list>
</property>

Źródła

Tags: , , , , ,

JBoss Cluster – zabezpieczenie komunikacji między serwerami

Przy użyciu serwera aplikacji JBoss AS bardzo łatwo jest utworzyć klaster. Serwer ten wspiera automatyczne wykrywanie poszczególnych maszyn, które uczestniczą w danym klastrze. Konfiguracja polega na uruchomieniu serwera przy użyciu profilu opartego o profil all i podaniu kilku parametrów:

$ ./run.sh -c node1 -b jboss1 -Djboss.messaging.ServerPeerID=1 -g CLUSTER -u 239.255.100.100  -m 1234

Powyższe poleceniu uruchomić instancję serwera JBoss przy następujących parametrach:

  • -c node1 – nazwa profilu jaki ma zostać uruchomiony (profili musi obsługiwać tworzenia klastrów, czyli najprościej powinien być kopią profilu all lub production
  • -b jboss1 – adres IP z którym ma zostać związana dana instancja serwera aplikacji
  • -Djboss.messaging.ServerPeerID=1 – numer dla JMS (unikalny w ramach klastra)
  • -g CLUSTER – nazwa klastra
  • -u 239.255.100.100 – adres multicastowy, który będzie używany do komunikacji między serwerami
  • -m 1234 – port adresu multicastowego

Aby dane instancje JBossa zaczęły współpracować ze sobą w ramach klastra, parametry -g, -u oraz -m muszą mieć taką samą wartość. Jak widać, nie ma tutaj miejsca na żadne uwierzytelnienie poszczególnych węzłów klastra. Jeżeli ktokolwiek będzie w stanie wpiąć maszynę do danej sieci fizycznej oraz poznać te parametry, będzie mógł się bez problemu wpiąć w klaster na równoprawnych warunkach.

Przy domyślnej konfiguracji JBossa musimy zapewnić fizyczne bezpieczeństwo naszej sieci wewnętrznej oraz przy pomocy innych narzędzi dbać o to, aby nie pojawiły się w niej żadne nie pożądane komputery. Sprawa może zacząć się komplikować, gdy zaczniemy używać klastra w sieci rozległej lub tez nie takiej, której nie ufamy w 100% czy też nie mamy nad nią pełnej kontroli.

Pozostaje wtedy zainteresować się różnymi metodami uwierzytelniania poszczególnych serwerów. Niestety, nie udało mi się znaleźć dokładnej dokumentacji na ten temat. Duża część informacji opiera się na testach oraz obejrzeniu kodu źródłowego pozwalającego na tego typu operacje.

Co trzeba wiedzieć na wstępie

Za obsługę komunikacji między poszczególnymi węzłami serwera aplikacji JBoss odpowiada biblioteka JGroups.Posiada ona szereg właściwości takich jak: automatyczne tworzeni klastra, przesyłanie wiadomości pomiędzy nimi, obsługuje zarówno protokołu UDP jak i TCP. Więcej informacji można znaleźć na stronie domowej JGroups.

Protokół transportujący wiadomości składa się z kilku różnych warstw. Każda z nich odpowiada za realizację określonych funkcji (takiej jak wykrywanie serwerów, dzielenie komunikatu na mniejsze części, łączenie go z powrotem w całości i inne). Warstwy te współpracują ze sobą. Dlatego też dodanie uwierzytelniania serwerów sprowadza się do dodania kolejnej warstwy w protokole transportującym, która będzie pilnowała czy dany komunikat może zostać przyjęty od danego serwera czy też do niego wysłany.

W przypadku serwera JBoss AS konfiguracja znajduje się w pliku: $JBOSS_HOME/server/node1/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml i to ten plik będzie trzeba edytować w celu dodania uwierzytelnienia dla grupy klastrów.

Bazową klasą używana do autentykacji jest org.jgroups.auth.AuthToken. Wszystkie moduły dziedziną po niej i rozszerzają ja o własne metody i parametry potrzebne do przeprowadzenie uwierzytelnienia. Aby włączyć dany moduł, należy w pliku jgroups-channelfactory-stacks.xml umieścić taki wpis:

83
84
85
<VIEW_SYNC avg_send_interval="10000"/>
<AUTH auth_class="klasa odpowiedzialna za uwierzytelnienie"
      parametr="wartość" />

Jedynym wymaganym tutaj argumentem jest auth_class, który wskazuje na klasę, jaka ma zostać użyta do uwierzytelnienia. Wszystkie pozostałe argumenty zostaną przekazane do tej klasy. Dlatego też ich postać jest już zależna od konkretnego modułu uwierzytelnia, należy się skonsultować z dokumentacją do każdej klasy i sprawdzić w niej jakie wartości muszą one przyjmować.

Uwierzytelnienie na podstawie adresu IP

Za uwierzytelnienie na podstawie adresu IP odpowiada klasa o nazwie FixedMembershipToken. Pozwala ona na zdefiniowanie listy adresów IP oraz numerów, które są używane przez poszczególne komputery w klastrze. Definicja wygląda następująco:

84
85
86
<AUTH auth_class="org.jgroups.auth.FixedMembershipToken"
       fixed_members_value="192.168.3.21*192.168.3.22"
       fixed_members_seperator="*"/>

Jak widać klasa ta przyjmuje dwa parametry:

  • fixed_members_value – pozwala na określenie adresów IP serwerów wchodzących w składa klastra, poszczególne adresy są rozdzielna znakiem separatora podanym w drugim parametrze, można także podać numer portu w formacie: 192.168.3.21/1234;
  • fixed_members_seperator – znak separatora, który rozdziela poszczególne adresy IP, w przykładzie znak *

Podany opis konfiguracji musi znaleźć się na wszystkich węzłach klastra. Każda instancja serwera JBoss będzie się porozumiewała tylko z tymi maszynami, które znajdują się w jej spisie.

Uwierzytelnienie na podstawie hasła

Chyba najprostsza metoda uwierzytelniania poszczególnych serwerów w klastrze: użycie hasła. Wszystkie serwery uczestniczące w klastrze muszą mieć skonfigurowane to samo hasło dostępu, na tej podstawie następuje uwierzytelnienie. Za przeprowadzenie tego testu odpowiada klasa SimpleToken i jej definicja wygląda następująco:

84
85
<AUTH auth_class="org.jgroups.auth.SimpleToken"
       auth_value="haslo_klastra"/>

Jedynym obowiązkowym parametrem w tej metodzie jest auth_value gdzie definiujemy hasło.

Uwierzytelnianie przy użyciu preshared token

Kolejny sposób uwierzytelniania przy użyciu preshared token jest udostępniony przez klasę MD5Token. Pozwala on na zdefiniowanie tokenu oraz hasła dostępu:

84
85
86
<AUTH auth_class="org.jgroups.auth.MD5Token"
       token_hash="0425823a38b591b104ca0c3fcf1f3d9d"
       auth_value="haslo_klastra"/>

Parametry token_hash i auth_value i definiują odpowiednio token (zakodowany przy użyciu MD5 lub SHA) oraz hasło. Na wszystkich węzłach klastra muszą być podane takie same wartości tych parametrów.

Uwierzytelnienie przy użyciu certyfikatu X509

Ostatnią dostępną metodą nieuwierzytelnienia poszczególnych węzłów klastra jest użycie certyfikatu X509. Za przeprowadzenie tego sposobu uwierzytelnienia odpowiada klasa X509Token. Pozwala ona na zdefiniowania miejsca z którego można pobrać certyfikat.

Przykład komendy definiującej nowy certyfikat przy użycia polecenia keytool:

keytool -genkeypair -dname "cn=JBoss Key 1, ou=JBoss, c=PL" -alias jboss -keyalg RSA -keypass haslo_klucza -keystore keystore -storepass haslo_magazynu

Poszczególne polecenia oznaczają:

  • -genkeypair – generowanie pary kluczy, prywatnego i publicznego
  • -dname "cn=JBoss Key 1, ou=JBoss, c=PL" – nazwa certyfikatu w standardzie X509
  • -alias jboss – nazwa certyfikatu na podstawie której będzie on identyfikowany w magazynie kluczy
  • -keyalg RSA – algorytm użyty do generowania kluczy
  • -keypass haslo_klucza – hasło na klucz prywatny
  • -keystore keystore – plik z magazynem kluczy
  • -storepass haslo_magazynu – hasło dostępu do pliku z magazynem kluczy

A oto definicja XML pozwalająca na użycie wygenerowanego certyfikatu:

84
85
86
87
88
89
90
<AUTH auth_class="org.jgroups.auth.X509Token"
       auth_value="haslo_klastra"
       keystore_path="keystore"
       keystore_password="haslo_magazynu"
       cert_password="haslo_klucza"
       cert_alias="jboss"
       cipher_type="RSA"/>

Znaczenie poszczególnych parametrów:

  • auth_value – hasło używane przez klastry
  • keystore_path – ścieżka do magazyny kluczy
  • keystore_password – hasło do magazyny kluczy
  • cert_password – hasło do certyfikatu
  • cert_alias – nazwa certyfikatu
  • cipher_type – typ certyfikatu

Należy pamiętać, że wszystkie węzły klastra muszą korzystać z tego samego certyfikatu.

Źródła

Tags: , , , , , , , , , , , ,

Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach

Polecenie twiddle.sh udostępnia polecenia, które umożliwiają uzyskanie informacji o istniejących ziarnach, ich metodach oraz parametrach.

List wszystkich wpisów z tej serii:

  1. Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS
  2. Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach
  3. Polecenie twiddle: operacje na na zasobach serwera

Lista dostępnych poleceń

Aby uzyskać listę dostępnych poleceń należy wywołać polecenie twiddle.sh z przełącznikiem --help-commands:

$ twiddle.sh --help-commands
twiddle.sh commands:
    jsr77          Print out JSR77 related information
    xmbean         Print out mbean metadata as an xmbean descriptor
    info           Get the metadata for an MBean
    get            Get the values of one or more MBean attributes
    invoke         Invoke an operation on an MBean
    create         Create an MBean
    setattrs       Set the values of one or more MBean attributes
    unregister     Unregister one or more MBeans
    queryMethod    Query the server for a list of matching methods of MBeans
    listDomains    Query the server for a list of available domains
    query          Query the server for a list of matching MBeans
    set            Set the value of one MBean attribute
    serverinfo     Get information about the MBean server

Polecenie to także udostępnia krótką pomoc do każdej z tych komend:

$ twiddle.sh -H query
Help for command: 'query'

Query the server for a list of matching MBeans

usage: query [options] <query>
options:
    -c, --count    Display the matching MBean count
    --             Stop processing options
Examples:
 query all mbeans: query '*:*'
 query all mbeans in the jboss.j2ee domain: query 'jboss.j2ee:*'

Zerknijmy na jedno z częściej wywoływanych poleceń pobranie danych z drzewa JNDII:

$ twiddle.sh invoke jboss:service=JNDIView list true
<h1> Other components with java:comp namespace</h1>
<h1>java: Namespace</h1>
<pre>
  +- securityManagement (class: org.jboss.security.integration.JNDIBasedSecurityManagement)
  +- comp (class: javax.namingMain.Context)
  +- XAConnectionFactory (class: org.jboss.jms.client.JBossConnectionFactory)
  +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
  +- TransactionPropagationContextImporter (class: com.arjuna.ats.internal.jbossatx.jta.PropagationContextManager)
  +- policyRegistration (class: org.jboss.security.plugins.JBossPolicyRegistration)
  +- ClusteredConnectionFactory (class: org.jboss.jms.client.JBossConnectionFactory)
....

Polecenie to składa się z kilku części:

  • twiddle.sh – wywołanie polecenia twiddle
  • invoke – komenda, jak ma zostać wykonana (w tym przypadku wywołanie metody na wybranym ziarnie)
  • jboss – domena, w której znajduje się wybrane ziarno
  • service=JNDIView – nazwa ziarna, jakie ma zostać wywołane
  • list – akcja na wybranym ziarnie
  • true – parametr przekazany do ziarna

Jak widać, trzeba podać sporo rożnych danych, aby wywołać dowolne zarządzane ziarno. Odpowiednie parametry można poznać używając np. aplikacji WWW JMX Console, ale także można je uzyskać przy użyciu polecenia twiddle.sh.

Lista dostępnych domen: listDomains

Polecenie listDomains pozwala na wyświetlnie listy wszystkich grup, na jakie podzielone są ziarna zarządzane:

$ twiddle.sh -H listDomains
Help for command: 'listDomains'

Query the server for a list of available domains

usage: listDomains [options]
options:
    -c, --count    Display the domain count
    --             Stop processing options

Przykładowe użycie:

$ twiddle.sh listDomains
jboss.security
jboss.jdbc
jboss.remoting
jboss.mq
jboss.classloader
jboss.admin
jboss.j2ee
jboss
...

Jak widać zostały wyświetlone tylko grupy. Ale jest to jednocześnie pierwsza część nazwy ziarna.

Lista dostępnych ziaren: query

Aby uzyskać informacje zarejestrowanych ziarnach należy użyć polecenia query:

$ twiddle.sh -H query
Help for command: 'query'

Query the server for a list of matching MBeans

usage: query [options] <query>
options:
    -c, --count    Display the matching MBean count
    --             Stop processing options
Examples:
 query all mbeans: query '*:*'
 query all mbeans in the jboss.j2ee domain: query 'jboss.j2ee:*'

Aby poznać jakie ziarna należą do domeny jboss należy użyć takiego polecenia:

$ twiddle.sh query 'jboss:*'
...
jboss:type=Service,name=SystemProperties
jboss:service=KeyGeneratorFactory,type=UUID
jboss:service=proxyFactory,target=ClientUserTransactionFactory
jboss:service=invoker,type=http,target=Naming
jboss:service=JNDIView
jboss:service=invoker,type=pooled
...

Jak widać, na liście znalazło się ziarno JNDIView.

Można łatwo także uzyskać informacje o wszystkich ziarnach, jakie znajdują się na serwerze JBoss wstawiając znak * w miejsce domeny:

$ twiddle.sh query '*:*'

Lista dostępnych metod dla wybranego ziarna: info

Posiadamy już nazwę ziarna, należałoby teraz uzyskać informacje o tym jaki akcje możemy na nim wykonać, czyli poznań metody oraz ich argumenty. Służy do tego polecenie info.

$ twiddle.sh -H info
Help for command: 'info'

Get the metadata for an MBean

usage: info <mbean -name>
  Use '*' to query for all attributes

Oto co wyświetli pytanie o ziarno JNDIView:

$ twiddle.sh info jboss:service=JNDIView
Description: JNDIView Service. List deployed application java:comp namespaces,
the java: namespace as well as the global InitialContext JNDI namespace. Also
list HA-JNDI namespace in a cluster environment.
+++ Attributes:
 Name: Name
 Type: java.lang.String
 Access: r-
 Name: State
 Type: int
 Access: r-
 Name: StateString
 Type: java.lang.String
 Access: r-
 Name: HANamingService
 Type: java.lang.String
 Access: rw
+++ Operations:
 java.lang.String list(boolean verbose)
 java.lang.String listXML()
 void create()
 void start()
 void stop()
 void destroy()
 void jbossInternalLifecycle(java.lang.String method)

Jak widać poza informacjami o samym ziarnie można zobaczyć listę metod jakie ono udostępnia. Jedną z nich jest list przyjmująca jeden argument typu boolean.

Tym sposobem właśnie udało się uzyskać informacje o wszystkich składowych, które były użyte w wywołaniu polecenia invoke.

Lista dostępnych metod: queryMethod

Istnieje jeszcze jeden sposób na odszukanie ziarna oraz metody. Komenda queryMethod pozwala na odszukanie wszystkich ziaren oraz metod, które zawierają w sobie podany ciąg znaków.

$ twiddle.sh -H queryMethod
Help for command: 'queryMethod'

Query the server for a list of matching methods of MBeans

usage: queryMethod [options] <query>
options:
    -c, --count    Display the matching method count
    -f, --filter   Filter by domain
    --             Stop processing options
Examples:
 query methods of all MBeans: queryMethod list
 query all methods of all MBeans in the jboss domain: queryMethod -f "jboss:*" list

Aby odszukać metodę list w ziarnie JNDIView możemy użyć nastepujących poleceń:

  • nie wiemy do jakiej domeny należy ziarno z szukaną metodą
    $ twiddle.sh  queryMethod list
    jboss.deployment:id="SecurityConfig",type=Component  listAttachments boolean
    jboss.deployment:id="WebInfLibFilter",type=Component  listAttachments boolean
    jboss.deployment:id="TopicTemplateInfo",type=Component  listAttachments boolean
    ...

    W moim przypadku polecenie to znalazło ponad 1400 metod zwierających słowo list w swojej nazwie. Nie jest to do końca użyteczna informacja, ale zawsze jakaś :).

  • wiemy w jakiej domenie znajduje się interesujące nas ziarno
    $ twiddle.sh  queryMethod -f "jboss:*" list
    jboss:type=Service,name=SystemProperties  removeListener org.jboss.util.property.PropertyListener
    jboss:type=Service,name=SystemProperties  addListeners [Lorg.jboss.util.property.PropertyListener;
    jboss:type=Service,name=SystemProperties  addListener org.jboss.util.property.PropertyListener
    jboss:type=Service,name=SystemProperties  addListener java.lang.String
    jboss:service=JNDIView  list boolean
    jboss:service=JNDIView  listXML
    jboss:service=AttributePersistenceService  apmListAll
    jboss:service=AttributePersistenceService  apmListAllAsString
    jboss:service=invoker,type=unified  addListener org.jboss.remoting.callback.InvokerCallbackHandler
    jboss:service=invoker,type=unified  removeListener org.jboss.remoting.callback.InvokerCallbackHandler

    Tym raza lista jest krótsza i od razu widać jak nazywa się szukane ziarno łącznie z definicją metody potrzebną do wywołania akcji.

Polecenie queryMethod jako wynik podaje zarówno pełną nazwę ziarna, jak pełną definicję metody (łącznie z parametrami używanymi do jej wywołania).

Źródła

Tags: , , , , , , , , , , , ,

Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS

Twiddle jest to aplikacja, która pozwala na zdalne komunikowanie się z serwerem aplikacji JBoss AS. Przy jej pomocy można bezpośrednio wywoływać odpowiednie polecenia, akcje. W praktyce można robić to samo co przy użyciu konsoli JMX. Polecenie to można znaleźć w katalogu $JBOSS_HOME/bin.

List wszystkich wpisów z tej serii:

  1. Polecenie twiddle: jak połączyć się z serwerem aplikacji JBoss AS
  2. Polecenie twiddle: jak znaleźć informacje o ziarnach i metodach
  3. Polecenie twiddle: operacje na na zasobach serwera

Podstawowe opcje jakie można podać w aplikacji twiddle

Podstawowy zestaw przełączników jest dostępny przy uzyciu opcji -h.

Polecenia pozwalające na uzyskanie pomocy

  • -h – pomoc o przełącznikach
  • –help-commands – lista dostępnych poleceń wraz z krótkimi opisami
  • -H – wyświetlenie dodatkowej pomocy o wybranym poleceniu

Definiowanie parametrów połączenie

Teraz czas na zestaw przełączników pomocnych do nawiązania połączenia z serwerem JBoss:

  • -s – adres IP oraz port na którym nasłuchuje serwer (domyślnie localhost:1099)
  • -u – nazwa użytkownika potrzeba do uwierzytelnienia (powinna zostać zdefiniowana w pliku $JBOSS_HOME/server/PROFIL/conf/props/jmx-console-users.properties)
  • -p – hasło użytkownika potrzebne do uwierzytelnienia (powinno zostać zdefiniowane w pliku $JBOSS_HOME/server/PROFIL/conf/props/jmx-console-users.properties)

Jeżeli serwer JBoss został zabezpieczony lub też nie został uruchomiony na innym interfejsie niż lokalny, to będzie trzeba używać tych przełączników przy każdym połączeniu z serwerem aplikacji. W poniższych przykładach nie będą one umieszczane, ale nie można o nich zapominać.

Lista poleceń

Listę dostępnych poleceń jakie można wydawać za pomocą narzędzia twiddle.sh można uzyskać przy użyciu przełącznika --help-commands:

$ ./twiddle.sh --help-commands
twiddle.sh commands:
    jsr77          Print out JSR77 related information
    xmbean         Print out mbean metadata as an xmbean descriptor
    info           Get the metadata for an MBean
    get            Get the values of one or more MBean attributes
    invoke         Invoke an operation on an MBean
    create         Create an MBean
    setattrs       Set the values of one or more MBean attributes
    unregister     Unregister one or more MBeans
    queryMethod    Query the server for a list of matching methods of MBeans
    listDomains    Query the server for a list of available domains
    query          Query the server for a list of matching MBeans
    set            Set the value of one MBean attribute
    serverinfo     Get information about the MBean server

Polecenia te pozwalają na wykonanie już konkretnych akcji po stronie serwera aplikacji.

Przykładowe użycie polecenia

Uzyskanie pomocy o poleceniu serverinfo:

$ ./twiddle.sh -H serverinfo
Help for command: 'serverinfo'

Get information about the MBean server

usage: serverinfo [options]

options:
    -d, --domain    Get the default domain
    -c, --count     Get the MBean count
    -l, --list      List the MBeans
    --              Stop processing options

W podobny sposób można uzyskać krótkie informacje o wszystkich poleceniach dostępnych w twiddle.sh

Uzyskanie informacji o domyślnej domenie serwera (bez autentykacji, serwera aplikacji pracuje na domyślnym interfejsie sieciowym):

$ ./twiddle.sh serverinfo -d
jboss

Dodanie autentykacji do połączenia:

$ ./twiddle.sh -u admin -p admin serverinfo -d
jboss

Dodanie informacji o interfejsie sieciowym na którym znajduje się JBoss (lub zdalne łączenie z inną maszyną):

$ ./twiddle.sh -u admin -p admin -s SERWER:PORT serverinfo -d
jboss

Trzeba pamiętać, że przełączniku określające sposób łączenia należy podawać przed nazwą polecenia jakie ma zostać wykonane.

W pozostałych przykładach pominę już autentykację użytkownika i serwer do którego chcemy się podłączyć. W razie potrzeby należy te informacje odpowiednio dodać do polecenia.

Pobranie informacji o MBeanach pasujących do zapytania:

$ ./twiddle.sh query 'jboss:service=invoker,*'
jboss:service=invoker,type=local
jboss:service=invoker,type=jrmp
jboss:service=invoker,type=http,target=Naming
jboss:service=invoker,type=pooled
jboss:service=invoker,type=http
jboss:service=invoker,type=unified
jboss:service=invoker,type=http,target=Naming,readonly=true

Pobranie informacji o atrybutach danego ziarna:

$ ./twiddle.sh get jboss:service=invoker,type=jrmp
Name=JRMPInvoker
ServerAddress=jboss1
RMIClientSocketFactory=null
StateString=Started
Backlog=200
State=3
RMIServerSocketFactory=null
RMIServerSocketFactoryBean=org.jboss.net.sockets.DefaultSocketFactory@ad093076[bindAddress=null]
RMIObjectPort=4444
EnableClassCaching=false
RMIClientSocketFactoryBean=null
SecurityDomain=null

Wyświetlenie drzewa JNDI:

$ ./twiddle.sh invoke jboss:service=JNDIView list true
<h1> Other components with java:comp namespace</h1>
<h2>java:comp namespace of the component jboss.j2ee:ear=eBikes.ear,jar=jboss-seam.jar,name=EjbSynchronizations,service=EJB3 :</h2>
<pre>
  +- EJBContext (class: javax.ejb.EJBContext)
  +- TransactionSynchronizationRegistry[link -> java:TransactionSynchronizationRegistry] (class: javax.naming.LinkRef)
  +- UserTransaction (class: org.jboss.ejb3.tx.UserTransactionImpl)
  +- env (class: org.jnp.interfaces.NamingContext)
  +- ORB[link -> java:/JBossCorbaORB] (class: javax.naming.LinkRef)
</pre>
<h2>java:comp namespace of the component jboss.j2ee:jar=Common.jar,name=InventoryDAOImpl,service=EJB3 :</h2>
<pre>
  +- EJBContext (class: javax.ejb.EJBContext)
....

Przykłady jak instalować aplikację przy użyciu twiddle.sh można znaleźć w tym wpisie: Zarządzanie instalacją aplikacji w JBoss AS.

Źródła

Tags: , , , , , , , ,

Przechwycenie strumienia wyjściowego wybranego procesu

Czasem istnieje następująca sytuacja: musimy zobaczyć co dana aplikacja wypisuje na ekranie, ale jest ona uruchomiona na innym terminalu (do którego nie mamy dostępu) lub też działa w tle i jej komunikaty lądują w nicości (czyli /dev/null). Można to zrobić za pomocą polecenia strace. Polecenie to służy generalnie do śledzenia wywołań systemowych.

strace -f -e trace=write -e write=1,2 -p PID

Opis opcji konfiguracyjnych:

  • -f – śledzi także procesu potomne monitorowanego procesu
  • -e trace=write – śledzenie informacji zapisu
  • -e write=1,2 – deskryptory plików, dla których mają być śledzone zapisy (tutaj stdout i stderr)
  • -p PID – numer procesu, który ma być śledzony

Demonstracja

  1. Utworzyć skrypt o nazwie trace_test.sh
    1
    2
    3
    4
    5
    6
    7
    8
    9
    #!/bin/bash

    echo PID: $$

    for I in `seq 1 1000`
    do
    echo "Linia $I"
    sleep 2
    done

    Skrypt ten wyświetli numer PID z jakim został uruchomiony oraz bedzie wyświetlał komunikat co dwie sekundy.

  2. Uruchomić powyższy skrypt:
    $ bash ./trace_test.sh
  3. Należy teraz otworzyć drugą konsolę i wykonać w niej polecenie:
    strace -f -e trace=write -e write=1,2 -p PID

    W miejsce PID należy wpisać numer wyświetlony przez skrypt trace_test.sh. Przykładowy wynik działania:

    Process 14589 attached - interrupt to quit
    --- SIGCHLD (Child exited) @ 0 (0) ---
    write(1, "Linia 5\n", 8)                = 8
     | 00000  4c 69 6e 69 61 20 35 0a                           Linia 5.          |
    Process 14598 attached
    Process 14589 suspended
    Process 14589 resumed
    Process 14598 detached
    --- SIGCHLD (Child exited) @ 0 (0) ---
    write(1, "Linia 6\n", 8)                = 8
     | 00000  4c 69 6e 69 61 20 36 0a                           Linia 6.          |
    Process 14599 attached
    Process 14589 suspended
    Process 14589 resumed
    Process 14599 detached
    --- SIGCHLD (Child exited) @ 0 (0) ---
    write(1, "Linia 7\n", 8)                = 8
     | 00000  4c 69 6e 69 61 20 37 0a                           Linia 7.          |
    Process 14601 attached
    Process 14589 suspended
    Process 14589 detached
    Process 14601 detached

Analiza takich danych może nie jest najłatwiejsza, ale zawsze dobrze mieć trochę więcej informacji :).

Źródła

Tags: , , , , ,