Instalacja oraz uruchomienie usługi sieciowej pod WebSphere Application Server 7

Uruchomienie usługi sieciowej pod WAS'em nie jest rzeczą skomplikowaną, przekonałem się o tym, wykorzystując do tego celu stworzoną wcześniej przykładową usługę (Tworzenie usługi sieciowej z wykorzystaniem JAX-WS i NetBeans IDE 6.8). Poniżej znajduje się krótki opis z serii "Zrób to sam" :)

1. Instalacja aplikacji

Logujemy się do konsoli administracyjnej. Z menu wybieramy Applications -> New Application . Interesuje nas tylko jeden typ aplikacji do zainstalowania: New Enterprise Application.

Podajemy ścieżkę do archiwum war zawierającego usługę (Local file system -> Browse) . Następnie wciskamy przycisk "Next".

Opcja instalacji "na skróty" (Fast Path) w zupełności nas zadowala. Przechodzimy dalej wciskając "Next".

Przed nami pięć kroków umożliwiających skonfigurowanie instalacji.


W kroku pierwszym możemy określić m.in. miejsce docelowe instalowanej aplikacji, jej nazwę, prawa dostępu do plików oraz wersję (Build ID). Jeżeli chcemy pozostawić wartości domyślne, możemy śmiało przejść dalej.

Krok drugi i trzeci również możemy pominąć, domyślne wartości pozwolą nam uruchomić usługę na naszym serwerze aplikacji.

W kroku czwartym określamy context root dla aplikacji. Podając /mywebapp sprawimy, że wszystkie wywołania dla http://localhost:9080/mywebapp oraz http://localhost:9080/mywebapp/* będą kierowane do instalowanej usługi (o ile nie zdefiniujemy później bardziej szczegółowego context root dla innej usługi np. /mywebapp/service).

Ostatni krok to podsumowanie dokonanej konfiguracji, wciskamy przycisk "Finish". Jeżeli wszystko zrobiliśmy poprawnie, powinien pojawić się ekran potwierdzający pomyślną instalację. Nie zapominamy zapisać dokonanych zmian, "Save".



2. Uruchomienie usługi

W konsoli administracyjnej przechodzimy do Applications -> Application types -> WebSphere enterprise applications . Zaznaczamy naszą aplikację oraz wciskamy przycisk "Start".


Otrzymany komunikat świadczy o poprawnym uruchomieniu aplikacji.


Dokument WSDL usługi możemy znaleźć pod adresem http://localhost:9080/mywebapp/MyFirstWsService/MyFirstWsService.wsdl . Plik ten wykorzystamy podczas tworzenia aplikacji klienckiej, bazującej na tej stworzonej wcześniej przy pomocy środowiska NetBeans 6.8 . Archiwum jar klienta będziemy modyfikować własnoręcznie (bez wykorzystania IDE), ale o tym już następnym razem.

Integracja systemu Kerberos z WebSphere Application Server 7

Poznawanie technologii Web Services zapewniało mi niemałą rozrywkę przez ostatnich kilka dni, a to dopiero początek mojej przygody z SOAP, WSDL i JAX-WS. Temat pochłonął mnie tak bardzo, że zupełnie zapomniałem opisać w jaki sposób dokonałem integracji poprawnie skonfigurowanego systemu Kerberos z WAS'em. Jak wspomniałem konfigurację Kerberos'a mam już za sobą, stąd wykonanie poniższych czynności było jedynie formalnością, dopełnieniem wykonanej wcześniej pracy.

Po zalogowaniu się do konsoli administracyjnej WAS'a przechodzimy do Security -> Global Security -> Kerberos configuration.


Biorąc pod uwagę, że w bazie danych systemu Kerberos istnieje principal WAS/linux-fi5z.site@SITE, który został dodatkowo wyeksportowany do pliku kt.keytab, nasz realm nosi nazwę SITE
a plik konfiguracyjny Kerberos'a znajduje się w /etc pod nazwą krb5.conf, konfiguracja w konsoli administracyjnej powinna wyglądać następująco:


Klikamy myszką "OK" oraz zapisujemy wprowadzone dane "Save".
Od tej chwili domyślnym mechanizmem autoryzacji dla WAS'a jest Kerberos. Należy o tym pamiętać przy kolejnej próbie zalogowania się do konsoli administracyjnej. Komunikat "Login failed. Check the user ID and password and try again." z pewnością pojawi się jeżeli zapomnieliśmy dodać do kerberosowej bazy danych odpowiedniego wpisu.

Dla konta administratora o nazwie admin wymagany principal wprowadzamy następująco:


Podane hasło należy zapamiętać, będziemy używać go podczas logowania się do konsoli administracyjnej.

Troubleshooting - ciąg dalszy

Błędne było przyjęte założenie, że źródłem problemów podczas prób wykorzystania systemu Kerberos jako mechanizmu autoryzacji jest WAS. Pomysły jak rozwiązać zagadkę kończyły się wraz z upływem czasu - może dlatego coś mnie podkusiło aby jeszcze raz zainteresować się plikami Kerberos'a.

Po chwili zastanowienia wpadłem na pomysł aby jeszcze raz wyeksportować principal "WAS/linux-fi5z.site@SITE" do pliku keytab, który miał posłużyć WAS'owi. Użyłem w tym celu kadmin.local wydając za jego pomocą polecenie
ktadd -k /usr/local/var/krb5kdc/kt.keytab WAS/linux-fi5z.site@SITE.
Chcąc sprawdzić czy faktycznie plik kt.keytab zawiera pożądane pola posłużyłem się narzędziem klist.


Jak można zauważyć powyżej, wszystko się zgadza. Użyłem więc tego pliku przy konfiguracji - tym razem obyło się bez problemu.

Jak się okazało kością niezgody był tutaj plik keytab, do którego ścieżkę podawałem w konsoli administracyjnej WAS'a. Niedopatrzenie kosztowało mnie sporo czasu, lekcja nie poszła jednak na marne - teraz z pewnością będę zwracać większą uwagę na zawartość plików, których używam korzystając z zewnętrznych aplikacji.

WAS7 Troubleshooting: Tracing CreateKrbAuthMechanism

Od kilku dni próbuję wykorzystać system Kerberos jako mechanizm autoryzacji w IBM WebSphere Application Server 7 . Wszelkie próby skonfigurowania WAS'a tak aby współpracował z Kerberosem kończą się niepowodzeniem. Za każdym razem pojawia się komunikat:

"org.ietf.jgss.GSSException, major code: 13, minor code: 0 major string: Invalid credentials minor string: Cannot get credential from JAAS Subject for principal: WAS/linux-fi5z.site@SITE".

Zakładam, że konfiguracja systemu Kerberos jest poprawna i "wina" leży w tym przypadku po stronie WAS'a. Podążając dalej tym tropem postanowiłem sprawdzić dokładniej jak przebiega proces tworzenia konfiguracji. Opis jak to zrobić zamieściłem poniżej.

1. Logujemy się do konsoli administracyjnej, w menu wybieramy Troubleshooting -> Logs and trace. Następnie wybieramy server1.


2. Wybieramy Diagnostic Trace.


3. W tym miejscu możemy dokładnie określić plik wyjściowy dla danych. Przechodzimy do Change Log Detail Levels.


4. Następnie mamy możliwość sprecyzowania, które komponenty lub grupy komponentów nas interesują. CreateKrbAuthMechanism odnajdziemy w Groups. Klikamy myszką na znak "+" przy nazwie listy "All Groups" w celu jej rozwinięcia.


5. Klikamy myszką na odnaleziony na liście CreateKrbAuthMechanism. Z menu wybieramy Message and Trace Levels -> finest.


6. Klikamy myszką na przycisk "OK". Następnie potwierdzamy operację zapisu - "Save".


7. Domyślna lokalizacja pliku trace.log to /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/. Tam odnajdziemy uzyskane informacje.

IBM Update Installer for WebSphere Software

Ponieważ podstawowa instalacja IBM WebSphere Application Server 7 nie wspiera systemu Kerberos jako mechanizmu autoryzacji ("This function is currently disabled") postanowiłem uaktualnić oprogramowanie do nowszej wersji. Wykorzystałem do tego celu narzędzie IBM Update Installer for WebSphere Software. Poniżej znajduje się opis czynności wykonanych przy realizacji tego zadania.

1. Pliki do pobrania

IBM Update Installer V7.0.0.9 for WebSphere Software for Linux: link
WebSphere Application Server V7.0 Fix Pack 7 for Linux: link
Java SDK 1.6 SR6 Cumulative Fix for WebSphere Application Server: link

2. Instalacja

Znajdując się wewnątrz rozpakowanego archwium narzędzia IBM Update Installer ( w moim przypadku wewnątrz 7.0.0.9-WS-UPDI-LinuxIA32/UpdateInstaller/ ) wydajemy polecenie install.
Po przeprowadzonej pomyślnie instalacji, automatycznie uruchomione zostanie narzędzie umożliwiające wskazanie ścieżki do plików WAS Fix Pack 7 oraz Java SDK 1.6 SR6 Cumulative Fix . Jak widać poniżej oba pliki umieściłem w /root.

Jeżeli wskazana ścieżka do plików jest poprawna program automatycznie odszuka gotowe do instalacji uaktualnienia.

Ostatnim krokiem jest uruchomienie procesu aktualizacji, którego poprawne ukończenie zaowocuje w pełni działającym WAS'em w wersji 7.0.0.7 .

Podsumowanie ubiegłego tygodnia

Wreszcie nadszedł upragniony weekend! Teoretycznie powinienem przewracać się z boku na bok ciesząc się chwilą odpoczynku, ale dobrze wiem, że tym razem nie będę leniuchować. Mam zamiar opracować interfejs graficzny do kolejnego z ćwiczeń dotyczących wielowątkowości oraz bliżej zapoznać się z MIT Kerberos 5 Release 1.8.

Całe szczęście, że ubiegły tydzień mogę zaliczyć do udanych - utwierdziło mnie w tym przekonaniu przeprowadzone z Jackiem Laskowskim podsumowanie wykonanej pracy. Instalacja oprogramowania WebSphere Application Server 7 była równie intuicyjna co instalacja systemu SUSE Linux Enterprise Server 11, aczkolwiek nie obyło się bez drobnych przeszkód. Z pierwszą
- was7 nie rozpoznał SUSE, jako wspieranego systemu operacyjnego - poradziłem sobie bez problemu. Przed przystąpieniem do instalacji zapoznałem się z dokumentacją produktu stąd wiedziałem,
że wystarczy jedynie podmienić plik WAS/was.primary.pak/maintenance.xml na nowszą wersję, w tym przypadku dla architektury IA32. Plik służący do nadpisania maintenance.xml można pobrać tutaj.

Mniej zrozumiałym problemem okazał się być komunikat narzędzia IVT, uruchomionego przeze mnie po instalacji w celu zweryfikowania czy wszystko przebiegło zgodnie z planem. IVT nieczule poinformował mnie, że "IVTL0170I: Cannot find profile home. IVT cannot continue.". Dość mocno się zdziwiłem - przecież stworzyłem profil podczas instalacji, która zakończyła się sukcesem. Próba dodania profilu za pomocą Profile Management Tool nie przyniosła zamierzonego efektu. Rozwiązania problemu szukałem w InfoCenter dla was7, nie odnalazłem jednak żadnej istotnej z mojego punktu widzenia informacji.

Błędem, jaki popełniłem było szukanie odpowiedzi na nurtujące mnie pytanie z dala od źródła - wszystko, czego potrzebowałem znajdowało się w pliku /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/wsadmin.traceout zawierającym informację o zaistniałym wyjątku (java.net.UnknownHostException). Okazało się, że przyczyną kłopotów był brakujący wpis w /etc/hosts, którego brak istnienia zawdzięczam narzędziu YaST (oraz poniekąd swojej spostrzegawczości :), które domyślnie odznaczyło polecenie "Write Hostname to /etc/hosts" przy konfiguracji ustawień sieciowych.

Poprawnie utworzony profil dał mi możliwość uruchomienia przykładowej witryny sklepu internetowego "Plants by WebSphere"
co ostatecznie upewniło mnie, że tym razem wszystkie czynności zostały wykonane należycie.

Praca w korporacji ma swoje mocne dobre strony. Na początku tygodnia zwróciłem się z prośbą o przydział komputera z większą ilością pamięci RAM na pokładzie a już w piątek podczas kilkuminutowej rozmowy telefonicznej zostałem zapewniony,
że maszyna zostanie wysłana z Warszawy w poniedziałek. Podoba mi się podejście, które można krótko opisać w następujący sposób: "Damy Ci wszystko, czego potrzebujesz tylko przekonaj nas, że to,
co otrzymamy w zamian jest warte tego, o co prosisz". Gorzej, gdy nie wiesz, w jaki sposób uzasadnić swoje potrzeby, tutaj nie ma zmiłuj się - liczą się konkrety. Sprzęt to podstawa, ale jeszcze większe znaczenie mają narzędzia, którymi IBM nas obdarowuje. Łatwość komunikacji i dostęp do ogromnej bazy informacji
to z pewnością jedne z głównych zalet, które zrobiły na mnie wrażenie. Dostrzegam, że wraz z czasem coraz lepiej wykorzystuję dane mi narzędzia, co ma bezpośrednie przełożenie na fakt, iż coraz lepiej wykonuję swoją pracę.