Polecenie twiddle: operacje na zasobach serwera

Polecenie twiddle pozwala na wykonywanie różnych operacji na serwerze aplikacji JBoss.

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

Pobranie informacji o wartości atrybutu: get

Przy użyciu polecenia twiddle można uzyskać informacje o wartości różnych atrybutów poszczególnych ziaren przy użycia komendy get. Konstrukcja polecenia jest następująca:

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

Get the values of one or more MBean attributes

usage: get [options] <name> [<attr>+]
  If no attribute names are given all readable attributes are retrieved
options:
    --noprefix    Do not display attribute name prefixes
    --            Stop processing options

Jak widać, aby poznać wartość wybranego ziarna należy odwołać się do ziarna oraz podać listę atrybutów, których wartości nas interesują. Przykładowe wywołanie, sprawdzające czy serwer wystartował:

$ twiddle.sh get "jboss.system:type=Server" Started
Started=false

Jak widać, serwer jeszcze nie działa, polecenie zostało wykonane w trakcie jego startu. Wydanie go już po pomyślnym starcie serwera zwraca następujący wynik:

$ twiddle get --noprefix "jboss.system:type=Server" Started
true

Widać tutaj także jak wpływa na wynik działania użycie opcji --noprefix, zostanie wyświetlona tylko wartość podanego atrybutu, bez jego nazwy.

A oto jak działa pobranie wartości więcej niż jednego atrybutu (w tym przypadku minimalnej i maksymalnej ilości otwartych połączeń w danej puli):

$ twiddle.sh get jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize MaxSize
MinSize=5
MaxSize=20

To samo polecenie, ale bez nazw atrybutów:

$ twiddle.sh get --noprefix jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize MaxSize
5
20

Ustawienie wartości atrybutów: set i setattrs

Do ustawienia wartości pojedynczego atrybutu można użyć komendy set:

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

Set the value of one MBean attribute

usage: set [options] <name> <attr> <val>
options:
    --noprefix    Do not display attribute name prefixes
    --            Stop processing options

Do zmiany wartości atrybutu potrzeba jest wiedza o nazwie ziarna oraz nazwie atrybutu. Przykładowe wywołanie, zmieniające minimalną ilość otwartych połączeń w puli:

$ twiddle.sh set jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize 10
MinSize=10

Ustawia wartość otwartych połączeń na 10.

Do jednoczesnej zmiany wartości więcej niż jednego atrybutu w danym ziarnie można użyć komendy setattrs:

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

Set the values of one or more MBean attributes

usage: setattrs [options] <name> [<attr value>+]
options:
    --noprefix    Do not display attribute name prefixes
    --            Stop processing options

Struktura polecenia jest taka sama jak polecenia set, pozwala jednak na podanie większej ilości atrybutów. Przykładowe wywołanie zmieniające minimalną i maksymalną ilość połączeń w puli:

$ twiddle.sh setattrs jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize 5 MaxSize 30
The following attributes were set successfuly:
MinSize=5
MaxSize=30

Warto zauważyć, że w wyniku działania tego polecenia albo zostaną ustawione wszystkie wartości wybranych atrybutów (jeżeli nie wystąpi żaden błąd w trakcie działania polecenia) lub też żadne zmiany nie zostaną wprowadzone (w przypadku wystąpienia jakiegoś błędu):

$ twiddle.sh setattrs jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize 1 MaxSize pięć
11:52:02,550 ERROR [Twiddle] Exec failed
java.lang.NumberFormatException: For input string: "pięć"
        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
        at java.lang.Integer.parseInt(Integer.java:449)
        at java.lang.Integer.valueOf(Integer.java:554)
        at sun.beans.editors.IntEditor.setAsText(IntEditor.java:21)
        at org.jboss.console.twiddle.command.SetAttrsCommand.execute(SetAttrsCommand.java:174)
        at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:306)

Pobranie informacji o ziarnach zwróci następujące wartości:

$ twiddle.sh get jboss.jca:name=DefaultDS,service=ManagedConnectionPool MinSize MaxSize
MinSize=5
MaxSize=30

Wywołanie akcji na ziarnie: invoke

Za wywołania konkretnych metod na wybranym ziarnie odpowiada komenda invoke:

$ twiddle -H invoke
Help for command: 'invoke'

Invoke an operation on an MBean

usage: invoke [options] <query> <operation> (<arg>)*

options:
    -q, --query-type[=<type>]    Treat object name as a query
    --                           Stop processing options

query type:
    f[irst]    Only invoke on the first matching name [default]
    a[ll]      Invoke on all matching names

Jako argumenty przyjmuje ona nazwę ziarna na którym ma zostać wykonana dana akcja, nazwę metody do wywołania jej parametry (jeżeli są potrzebne). Wywołania drzewa JNDI:

$ twiddle invoke jboss:service=JNDIView list true
...
<h1>java: Namespace</h1>
<pre>
  +- securityManagement (class: org.jboss.security.integration.JNDIBasedSecurityManagement)
  +- comp (class: javax.namingMain.Context)
  +- XAConnectionFactory (class: org.jboss.jms.client.JBossConnectionFactory)
  +- JBossCorbaInterfaceRepositoryPOA (class: org.omg.PortableServer.POA)
...

Ponieważ polecenie to pozwala na bezpośrednie wywoływania różnych akcji na danym serwerze, istotne jest zabezpieczenie dostępu do konsoli JMX poprzez ustawienie odpowiedniego użytkownika oraz mocnego hasła.

Tags: , , , , , , , , ,

pdftk – operacje na plikach PDF

Podczas przygotowywania materiałów do prezentacji musiałem dokonać kilu operacji na plikach PDF:

  • połączyć kilka plików w jeden
  • wyciąć niektóre strony z pliku PDF i także dodać je do dokumentu wynikowego
  • narzędzie powinno dać się skonfigurować w całości z linii poleceń (prawdopodobnie będzie potrzeba wykonywania operacji kilkukrotnie)

Kiedyś do takie celu wykorzystywałem Jave i bibliotekę iText Pdf, ale tym razem nie bardzo chciałem tworzyć specjalną aplikację. Ostatnio używałem aplikacji do rozpoznawaniu tekstu w dokumentach PDF (Dodanie możliwości przeszukiwanie plików PDF), gdzie do operacji na dokumentach PDF była używana aplikacja pdftk. I nie zawiodłem się :).

Aplikacja pdftk pozwala na manipulację dokumentami PDF, wg dokumentacji:

  • łączenie dokumentów PDF
  • wyodrębniać poszczególne strony
  • obracać strony
  • odszyfrowywać w razie potrzeby pliki (wymagana jest podanie hasła)
  • szyfrowanie tworzonego dokumentu
  • wypełnianie formularzy PDF
  • tworzenie znaku wodnego
  • pobierania oraz aktualizacja metadanych
  • dodawania załączników do stron lub całych dokumentów
  • pobierać załączników
  • naprawiać zepsute dokumenty

Na moje potrzeby wystarczyły dwie pierwsze możliwości i je przedstawię poniżej.

Składania polecenia pdfk na potrzeby tego artykułu (składania jest bardziej skomplikowana, proszę zajrzeć na stronę pomocy polecenia)

pdftk <wej ściowe pliki PDF>
            cat [<argumenty operacji>]
            output <nazwa pliku wyjściowego>

Aby połączyć pliki PDF i utworzyć z nich plik wynikowy wystarczy wydać taką komendę:

pdftk plik1.pdf plik2.pdf cat output wyjście.pdf

Dwa pliki PDF zostaną połączone i zostanie utworzony plik wynikowy o nazwie wyjście.pdf.

Istnieje także możliwość zdefiniowania, jakie strony z którego pliku mają zostać pobrane do pliku wyjściowego. Można także na tych stronach dokonać kilku transformacji. Wymaga to jednak trochę innego wywołania komendy:

pdftk A=plik1.pdf B=plik2.pdf cat A10-12 B3 A13-18even output wyjście.pdf

Jak widać, każda nazwa pliku wejściowego została poprzedzona wielką literą. Jest to tak zwany uchwyt, poprzez który można się następnie odwoływać do plików (nie tylko przy łączniu ich, ale np. także przy podawaniu hasła w celu odszyfrowania danego pliku). Uchwyt musi być pojedynczą wielką literą.

Powyższe polecenie pobierze najpierw z pliku plik1.pdf strony od 10 do 12, następnie doda do tego stronę nr 3 z pliku plik2.pdf i na końcu wstawi nieparzyste strony od 13 do 18 z pliku plik1.pdf.

Poniżej jeszcze znajduje się przykładowy skrypt, który wykonuje takie akcje:

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
#!/bin/bash

#set -x

echo "Konfiguracja"
PDFTK=`which pdftk`

SOURCE_DIR="./PDF/"
EXTRA_PDF="extra.pdf"

ROZ_00=`ls $SOURCE_DIR/00*.pdf`
ROZ_01=`ls $SOURCE_DIR/01*.pdf`

OUTPUT_PDF="konspekt.pdf"


# połączenie konspektu w całość

PDF_INPUT_LIST="A=${ROZ_00} B=${ROZ_01} J=${EXTRA_PDF}"

#echo $PDF_INPUT_LIST

CAT="A B J51-70 J110-116"

echo "Tworzenie dokument PDF"
$PDFTK $PDF_INPUT_LIST cat $CAT  output "$OUTPUT_PDF"
echo "Utworzono konspetk: $OUTPUT_PDF"

O wiele więcej informacji można znaleźć w dokumentacji do aplikacji, na jej stronach MAN.

Tags: ,

Typy aplikacji jakie można zainstalować w serwerze aplikacji JBoss

Każda aplikacja, która ma działać w ramach danego serwera JBoss musi zostać najpierw zainstalowana przez niego zainstalowana. Jest to możliwe na kilka sposobów:

  • można umieścić aplikację w katalogu deploy serwera;
  • można zainstalować aplikację przy użyciu polecenia twiddle;
  • można użyć konsoli administracyjnej;

Więcej informacji na temat instalacji aplikacji znajduje się w tym wpisie: Zarządzanie instalacją aplikacji w JBoss AS.

Formaty pakietów z aplikacjami

Instalowana aplikacja może zarówno być w formie archiwum jak i jak katalogu z plikami zapisanymi w odpowiedniej strukturze (archiwum to nic innego jak ten sam katalog skompresowany przy użyciu algorytmu ZIP). Każda z form ma swoje wady i zalety, ale nie różnią się one efektem. Zarówno w jednym jak i drugim przypadku pozwalają na instalację aplikacji.

W przypadku skompresowanego archiwum mamy do czynienia z pojedynczym plikiem, które dużo łatwiej przesłać czy też skopiować. W przypadku jego rozkompresowanej formy mamy do czynienia z setkami czy też często tysiącami plików. Trudniej w takim przypadku zarządzać taką aplikacją (nie można np. zainstalować jej przy pomocy konsoli administracyjnej), za istnieje możliwość modyfikacji pojedynczych plików (np. strony JSP) i następnie łatwe wymuszenie restartu aplikacji.

Odpowiedni wątek monitorujący pojawienia się (lub też usuniecie) aplikacji w katalogu deploy monitoruje czasy modyfikacji odpowiednich plików w archiwum. I tak, jeżeli zmienimy odpowiedni plik (w zależności od rodzaju aplikacji) to nastąpi automatyczne odinstalowanie wybranej aplikacji i jej ponowna instalacja.

Podstawowe deskryptory aplikacji
Typ aplikacji Plik deskryptora
WAR WEB-INF/web.xml
EAR META-INF/application.xml
SAR META-INF/jboss-service.xml
JAR META-INF/ejb-jar.xml
RAR META-INF/ra.xml

Typy aplikacji instalowanych przez JBossa

JBoss rozróżnia poszczególne typy aplikacji na podstawie końcówek ich nazw (uwaga, często jest to więcej niż rozszerzenie). Ponieważ każdy typ aplikacji spełnia inne funkcje w ramach infrastruktury, którą zapewnia serwer aplikacji istotne jest zachowanie odpowiedniej kolejności startowania tych aplikacji. I tak różnego rodzaje aplikacje usługowe musza zostać uruchomione przed aplikacjami biznesowymi, które mają z nich korzystać. Tak samo najpierw należy odpowiednio skonfigurować połączenia z bazą danych, zanim zaczną działać aplikacje z nich korzystające.

W poniżej tabeli znajdują się typy poszczególnych aplikacji wraz z ich krótkim omówieniem. Jednocześnie pozycja występowania na tej liście mówi o kolejności startu danej aplikacji.,

Końcówka nazwy Typ aplikacjia
.deployer
-deployer-beans.xml
Aplikacje, które pozwalają na instalację innych rodzajów aplikacji. W przypadku JBossa 5.1 znajdują się one w katalogu $JBOSS_HOME/server/PROFIL/deployers
aop
-aop.xml
Definicja aspektów stosowany do klas lub rozszerzenie czy też dodanie nowych funkcji do tych klas
.sar
-service.xml
Różnego rodzaju aplikacje usługowe, rozszerzające możliwości serwera aplikacji
-jboss-beans.xml Definicja obiektów POJO mikrokontenera
.rar Konfiguracja różnych zasobów
-ds.xml Definicja źródeł danych, używanych potem przez aplikacje w celu uzyskania dostępu do bazy danych
.har Definicja archiwum Hibernate, używanego do do dostępu do bazy danych przy użyciu Hibernate
.jar Zbiór komponentów EJB lub też po prostu biblioteka klas
.zip Serwer aplikacji sprawdzi zawartość archiwum i postara się rozpoznań typ aplikacji jaki się w nim znajduje. Potem zostanie ona zainstalowana jak aplikacja o odpowiednim typie.
.war Archiwum z aplikację webową, dostarczająca interfejs dostępny przez przeglądarkę lub też web service
.wsr Archiwum specyficzne dla JBossa, zawiera web service. Używany jeżeli dana aplikacja ma zostać zainstalowana po wszystkich archiwach WAR.
.ear Aplikacja Java EE, zawiera EJB, aplikacja WAR oraz inne biblioteki klas
.bsh Definicja usługi przy użyciu powłoki bean shell
.last Tak oznaczone aplikacje będą instalowane jako ostatnie w ramach swojego typu

Aplikacje same w sobie mogą byc zagnieżdżone. I tak aplikacja typu EAR najczęściej składa się z szeregu plików JAR z logiką biznesową, z warstwy prezentacji WAR oraz różnych innych deskryptorów. W takim przypadku JBoss stara się odnaleźć te różne aplikacji i je w ramach głównej aplikacji zainstalować. Tutaj również ma zastosowanie taka sama kolejność instalacji aplikacji jak w tabeli powyżej.

Źródła

Tags: , , , ,

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: , , , , , , , , , , , ,