Osoby zainteresowane poznaniem większej ilości szczegółów lub porównaniem kodu powstałych aplikacji zachęcam do rozmowy - nawet podczas przerwy między zajęciami na uczelni.
wtorek, 30 marca 2010
Programowanie współbieżne - ciąg dalszy
Kolejnym zadaniem do zrealizowania w ramach przedmiotu "Programowanie współbieżne i rozproszone" było napisanie aplikacji wielowątkowej synchronizującej pracę barmana obsługującego klientów przy barze. Aplikacja powinna posiadać interfejs graficzny w celu wprowadzenia ilości stołków i klientów oraz wizualizacji jego działania. Realizacja zadania trwała dwa tygodnie dlatego pracę rozłożyłem na dwa etapy: tworzenie GUI oraz dobudowywanie funkcjonalności. Wykonane ćwiczenie zostało ocenione na ocenę bardzo dobrą a wynik pracy (z punktu widzenia użytkownika) można zobaczyć poniżej.
Synchronizacja wątków-klientów z wątkiem odpowiedzialnym za wizualizację została przeprowadzona poprzez połączenie klasy CountDownLatch z semaforami. Wywołanie metody await() klasy CountDownLatch zostało umieszczone przed kodem odpowiedzialnym za wyświetlenie aktualnego stanu stołków w barze. Kazdy klient po pojedyńczym wykonaniu pętli (określeniu swojego stanu, np. pije piwo lub odszedł od baru) wykonuje metodę countDown() (CountDownLatch) i acquire() (Semaphore). Metoda await() czeka tak długo aż wszyscy klienci określą swój stan, po czym w następnej kolejności wyświetlona na ekranie zostaje aktualna sytuacja mająca miejsce w barze. Przy kolejnym wykonaniu pętli obsługującej wizualizację wszystkie wątki-klienci dostają pozwolenie na dalsze działanie za pomocą metody release() (Semaphore). Funkcja barmana została zrealizowana poprzez metodę synchronizowaną zwracającą wartość logiczną - true jeżeli barman zamierza obsłużyć danego klienta oraz false w przeciwnym przypadku. Do metod synchronizowanych zalicza się również próba uzyskania miejsca przy barze, która w przypadku zajęcia stołka zwraca jego numer.
Osoby zainteresowane poznaniem większej ilości szczegółów lub porównaniem kodu powstałych aplikacji zachęcam do rozmowy - nawet podczas przerwy między zajęciami na uczelni.
Osoby zainteresowane poznaniem większej ilości szczegółów lub porównaniem kodu powstałych aplikacji zachęcam do rozmowy - nawet podczas przerwy między zajęciami na uczelni.
Etykiety:
współbieżność
piątek, 26 marca 2010
Instalacja i konfiguracja systemu Kerberos
Zaczynając swoją przygodę z oprogramowaniem Kerberos 5 Release 1.8 nie rozstawałem się z dokumentacją nawet na chwilę. Ku mojemu zdziwieniu, już przy pierwszej napotkanej przeszkodzie okazało się, że wszelkie zgromadzone przeze mnie informacje sprawiają wrażenie niewystarczających do rozwiązania problemu. Zanim jednak przedstawię więcej szczegółów na ten temat chciałbym opisać krok po kroku czynności niezbędne do wykonania przy instalacji i konfiguracji systemu kerberos.
1. Instalacja
Źródła do pobrania: krb-1.8-signed
Przed przystąpieniem do instalacji należy upewnić się, że system zawiera kompilator gcc oraz narzędzie yacc, co można sprawdzić poleceniem which, które zwraca pełną ścieżkę do programu (np. which yacc). U mnie na SUSE Enterprise Server 11 domyślnie zainstalowane oprogramowanie nie zawierało ani jednego ani drugiego, dlatego zmuszony byłem uzupełnić system o paczki rpm:
gcc oraz bison (które przeważnie można znaleźć na dvd z linuxem).
Po rozpakowaniu archiwum ze źródłami systemu kerberos powinniśmy przejść do wnętrza folderu krb5-1.8/src/ oraz wykonać następujące komendy:
./configure
make
make check (jeżeli chcemy przetestować skompilowany system)
make install
2. Konfiguracja
Przykładowa zawartość pliku /etc/krb5.conf dla hosta o nazwie linux-fi5z znajdującego się w domenie site wygląda następująco:

Realm wg obowiązującej konwencji powinien nosić taką samą nazwę jak domena i składać się wyłącznie z wielkich liter. Jak można zauważyć usługa Key Distribution Center oraz serwer administratora znajdują się pod adresem linux-fi5z.site a ich pliki log mieszczą się w /var/log/krb5/ .
Przykładowy plik konfiguracyjny usługi KDC /usr/local/var/krb5kdc/kdc.conf :

Tutaj staramy się nie zmieniać zbyt wiele bez wyraźnej potrzeby, pozostawiamy większość domyślnych wartości.
Informację o usługach kerberosa działających na danych portach powinniśmy umieścić w pliku /etc/services dodając do niego poniższe linie:

Kolejnym krokiem jest stworzenie bazy danych dla usługi KDC za pomocą polecenia /usr/local/sbin/kdb5_util create -r SITE -s
Dodawać administratorów będziemy za pomocą narzędzia /usr/local/sbin/kadmin.local . Polecenie mające na celu dodanie uzytkownika root do grupy administratorów wyglądać będzie następująco addprinc root/admin
Natomiast dodanie użytkownika, który będzie korzystać z usług za pomocą systemu kerberos przeprowadzamy poleceniem addprinc user_name
Dla nowo utworzonych użytkowników powinniśmy stworzyć listę uprawnień /usr/local/var/krb5kdc/kadm5.acl , w której na potrzeby przykładu nadamy każdemu administratorowi wszelkie dostępne uprawnienia: */admin@SITE *
Utworzenie pliku keytab umożliwi demonowi kadmind dekodowanie biletów Kerberosa w celu przyznania lub nie dostępu do bazy danych. Po uruchomieniu narzędzia /usr/local/sbin/kadmin.local wydajemy polecenie ktadd -k /usr/local/var/krb5kdc/kadmin5.keytab kadmin/admin kadmin/changepw
Po wykonaniu podstawowej konfiguracji systemu Kerberos możemy uruchomić usługi krb5kdc i kadmind (/usr/local/sbin/).
3. Napotkana przeszkoda
Chcąc sprawdzić czy system Kerberos działa poprawnie postanowiłem skorzystać z dołączonych przykładowych aplikacji. W tym celu dodałem do bazy danych pozycję sample/linux-fi5z.site@SITE oraz linijkę sample 13135/tcp do pliku /etc/services . Następnie uruchomiłem przykładowy serwer komendą sserver -p 13135 -S /usr/local/var/krb5kdc/kt.keytab .
Po uzyskaniu za pomocą kinit biletu TGT umożliwiającego dalsze działania postanowiłem połączyć się z serwerem komendą sclient linux-fi5z . Jak można zauważyć poniżej test zakończył się niepowodzeniem.

"Wrong principal in request" - nie jestem w stanie odgadnąć, co jest przyczyną błędu, za wszelkie pomysły na rozwiązanie zagadki będę bardzo wdzięczny.
1. Instalacja
Źródła do pobrania: krb-1.8-signed
Przed przystąpieniem do instalacji należy upewnić się, że system zawiera kompilator gcc oraz narzędzie yacc, co można sprawdzić poleceniem which, które zwraca pełną ścieżkę do programu (np. which yacc). U mnie na SUSE Enterprise Server 11 domyślnie zainstalowane oprogramowanie nie zawierało ani jednego ani drugiego, dlatego zmuszony byłem uzupełnić system o paczki rpm:
gcc oraz bison (które przeważnie można znaleźć na dvd z linuxem).
Po rozpakowaniu archiwum ze źródłami systemu kerberos powinniśmy przejść do wnętrza folderu krb5-1.8/src/ oraz wykonać następujące komendy:
./configure
make
make check (jeżeli chcemy przetestować skompilowany system)
make install
2. Konfiguracja
Przykładowa zawartość pliku /etc/krb5.conf dla hosta o nazwie linux-fi5z znajdującego się w domenie site wygląda następująco:
Realm wg obowiązującej konwencji powinien nosić taką samą nazwę jak domena i składać się wyłącznie z wielkich liter. Jak można zauważyć usługa Key Distribution Center oraz serwer administratora znajdują się pod adresem linux-fi5z.site a ich pliki log mieszczą się w /var/log/krb5/ .
Przykładowy plik konfiguracyjny usługi KDC /usr/local/var/krb5kdc/kdc.conf :
Tutaj staramy się nie zmieniać zbyt wiele bez wyraźnej potrzeby, pozostawiamy większość domyślnych wartości.
Informację o usługach kerberosa działających na danych portach powinniśmy umieścić w pliku /etc/services dodając do niego poniższe linie:
Kolejnym krokiem jest stworzenie bazy danych dla usługi KDC za pomocą polecenia /usr/local/sbin/kdb5_util create -r SITE -s
Dodawać administratorów będziemy za pomocą narzędzia /usr/local/sbin/kadmin.local . Polecenie mające na celu dodanie uzytkownika root do grupy administratorów wyglądać będzie następująco addprinc root/admin
Natomiast dodanie użytkownika, który będzie korzystać z usług za pomocą systemu kerberos przeprowadzamy poleceniem addprinc user_name
Dla nowo utworzonych użytkowników powinniśmy stworzyć listę uprawnień /usr/local/var/krb5kdc/kadm5.acl , w której na potrzeby przykładu nadamy każdemu administratorowi wszelkie dostępne uprawnienia: */admin@SITE *
Utworzenie pliku keytab umożliwi demonowi kadmind dekodowanie biletów Kerberosa w celu przyznania lub nie dostępu do bazy danych. Po uruchomieniu narzędzia /usr/local/sbin/kadmin.local wydajemy polecenie ktadd -k /usr/local/var/krb5kdc/kadmin5.keytab kadmin/admin kadmin/changepw
Po wykonaniu podstawowej konfiguracji systemu Kerberos możemy uruchomić usługi krb5kdc i kadmind (/usr/local/sbin/).
3. Napotkana przeszkoda
Chcąc sprawdzić czy system Kerberos działa poprawnie postanowiłem skorzystać z dołączonych przykładowych aplikacji. W tym celu dodałem do bazy danych pozycję sample/linux-fi5z.site@SITE oraz linijkę sample 13135/tcp do pliku /etc/services . Następnie uruchomiłem przykładowy serwer komendą sserver -p 13135 -S /usr/local/var/krb5kdc/kt.keytab .
Po uzyskaniu za pomocą kinit biletu TGT umożliwiającego dalsze działania postanowiłem połączyć się z serwerem komendą sclient linux-fi5z . Jak można zauważyć poniżej test zakończył się niepowodzeniem.
"Wrong principal in request" - nie jestem w stanie odgadnąć, co jest przyczyną błędu, za wszelkie pomysły na rozwiązanie zagadki będę bardzo wdzięczny.
Etykiety:
kerberos
sobota, 20 marca 2010
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ę.
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ę.
Subskrybuj:
Posty (Atom)