Nasze kilkudniowe walki z własnym serwerem Wave zakończyliśmy na instalacji, konfiguracji oraz przetestowaniu serwera OpenFire. Kolejnym wielkim krokiem na drodze do sukcesu jest zainstalowanie samego rozszerzenia Fali i spięcie go z OpenFire.
Całą operację zaczynamy od ściągnięcia źródeł rozszerzenia za pomocą komendy: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol. Niespodziewanie w tym miejscu pojawił się pierwszy problem - co to za polecenie hg. Z pomocą przyszła konsola podpowiadając, że najpierw trzeba zdobyć samo narzędzie i można to zrobić wykonując następujące polecenie: sudo apt-get install mercurial. Po zainstalowaniu narzędzia wracamy ponownie do ściągnięcia kodów poleceniem: hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol. Ściągnąwszy pomyślnie źródła przechodzimy do jednego z utworzonych katalogów: cd wave-protocol i wywołujemy budowę wtyczki poleceniem: ant. W tym miejscu ponownie zostajemy rozczarowani, ponieważ nie ma takiego polecenia. Na szczęście Ubuntu ponownie przychodzi nam z pomocą i proponuje ściągnięcie odpowiedniej aplikacji: sudo apt-get install ant. Gdy ją zainstalujemy ponownie próbujemy zbudować wtyczkę poleceniem: ant. Po jakimś czasie powinniśmy zostać poinformowani o sukcesie.
Kolejnym krokiem jest wygenerowanie odpowiednich certyfikatów bez których nie uda się uruchomić wtyczki. Mamy dwie opcje, albo wygenerujemy prosty certyfikat, albo certyfikat sygnowany przez centrum certyfikacji. Oczywiście w obu przypadkach posługujemy się znacznym uproszeniem, ale w momencie, gdy zechcemy oferować publiczny dostęp do serwera ważnym elementem może być uzyskanie prawdziwego certyfikatu poświadczonego przez zewnętrzną instytucję. Dla naszych testowych zastosować wystarczy pierwsza opcja. Poniżej znajduje się skrypt, który pozwoli nam wygenerować prosty certyfikat:
Zasada posługiwania się certyfikatem polega na tym, że plik z rozszerzeniem *.crt udostępniamy publicznie osobom, które będą mogły potwierdzić otwartą przez nas komunikację (np. maile) oraz zaszyfrować przeznaczoną tylko do nas komunikację. Plik *.key jest natomiast przeznaczonym tylko dla nas kluczem prywatnym - nie można go nikomu przekazywać.
Będąc w posiadaniu obu plików możemy powrócić do konfiguracji pluginu. Po zbudowaniu aplikacji w katalogu wave-protocol dostępny jest plik: run-config.sh.example - jego zawartość należy skopiować do pliku: run-config.sh. Następnie należy dokonać zmian w nowoskopiowanym pliku.
Na powyższym rysunku zaznaczyłem miejsca w których dokonałem zmiany. W pierwszym przypadku zakomentowałem linijkę (znakiem: #). Druga zmiana polegała na podaniu nazwy lub adresu IP serwera - w naszym wypadku adres IP: 192.168.1.51. Kolejna zmiana dotyczy wprowadzenie sekretnego hasła, które podaliśmy podczas konfiguracji OpenFire. Dwie kolejne zmiany polegają na podaniu ścieżek do plików kolejno z kluczem (zmienna PRIVATE_KEY_FILENAME) i certyfikatem (zmienna CERTIFICATE_FILENAME_LIST) wcześniej wygenerowanymi (*.key i *.cert). Następne dwie zmiany polegają na podaniu adresu IP serwera w dwóch parametrach: CERTIFICATE_DOMAIN_NAME oraz XMPP_SERVER_PING. Ostatnia zmiana polegała na podaniu false w elemencie: WAVESERVER_DISABLE_SIGNER_VERIFICATION.
Sprawdźmy czy poprawnie skonfigurowaliśmy certyfikaty za pomocą polecenia: ./check-certificates.sh. Jeżeli zobaczymy komunikat jak na poniższym obrazku to oznacza, że wszystko jest ok w tym punkcie.
Pozostaje uruchomić samego Wave'a za pomocą polecenia: ./run-server.sh.
Wraz z referencyjną implementacją protokołu dostarczony jest prosty klient konsolowy. Można go uruchomić za pomocą komendy: /run-client-console.sh . Po wydaniu tego polecenia pojawi się konsolowe okienko podzielone na dwie części. W jednej części prezentowany jest podgląd fal, natomiast w drugiej szczegóły tej jednej wybranej.
W celach testowych na dwóch różnych konsolach zalogowałem się jako dwaj różni użytkownicy i spróbowałem nawiązać komunikację. Efekt widać poniżej.
Wykonując ten skrypt zostaniemy poproszeni o podanie kilku danych dotyczących miejsca, firmy, nazwy oraz adresu email. W wyniku działania skryptu powinny zostać utworzone dwa pliki: $nazwa.key i $nazwa.crt, gdzie $nazwa to identyfikator podany podczas wywoływania skryptu. Na poniższym rysunku zaznaczyłem wywołanie generowania certyfikatu oraz utworzone pliki.#!/bin/bash NAME=$1 if [ "$NAME" == '' ] then echo "$0" 1>&2 exit 1 fi openssl genrsa 1024 | openssl pkcs8 -topk8 -nocrypt -out $NAME.key openssl req -new -x509 -nodes -sha1 -days 365 -key $NAME.key -out $NAME.crt
Zasada posługiwania się certyfikatem polega na tym, że plik z rozszerzeniem *.crt udostępniamy publicznie osobom, które będą mogły potwierdzić otwartą przez nas komunikację (np. maile) oraz zaszyfrować przeznaczoną tylko do nas komunikację. Plik *.key jest natomiast przeznaczonym tylko dla nas kluczem prywatnym - nie można go nikomu przekazywać.
Będąc w posiadaniu obu plików możemy powrócić do konfiguracji pluginu. Po zbudowaniu aplikacji w katalogu wave-protocol dostępny jest plik: run-config.sh.example - jego zawartość należy skopiować do pliku: run-config.sh. Następnie należy dokonać zmian w nowoskopiowanym pliku.
Na powyższym rysunku zaznaczyłem miejsca w których dokonałem zmiany. W pierwszym przypadku zakomentowałem linijkę (znakiem: #). Druga zmiana polegała na podaniu nazwy lub adresu IP serwera - w naszym wypadku adres IP: 192.168.1.51. Kolejna zmiana dotyczy wprowadzenie sekretnego hasła, które podaliśmy podczas konfiguracji OpenFire. Dwie kolejne zmiany polegają na podaniu ścieżek do plików kolejno z kluczem (zmienna PRIVATE_KEY_FILENAME) i certyfikatem (zmienna CERTIFICATE_FILENAME_LIST) wcześniej wygenerowanymi (*.key i *.cert). Następne dwie zmiany polegają na podaniu adresu IP serwera w dwóch parametrach: CERTIFICATE_DOMAIN_NAME oraz XMPP_SERVER_PING. Ostatnia zmiana polegała na podaniu false w elemencie: WAVESERVER_DISABLE_SIGNER_VERIFICATION.
Sprawdźmy czy poprawnie skonfigurowaliśmy certyfikaty za pomocą polecenia: ./check-certificates.sh. Jeżeli zobaczymy komunikat jak na poniższym obrazku to oznacza, że wszystko jest ok w tym punkcie.
Pozostaje uruchomić samego Wave'a za pomocą polecenia: ./run-server.sh.
Wraz z referencyjną implementacją protokołu dostarczony jest prosty klient konsolowy. Można go uruchomić za pomocą komendy: /run-client-console.sh
W celach testowych na dwóch różnych konsolach zalogowałem się jako dwaj różni użytkownicy i spróbowałem nawiązać komunikację. Efekt widać poniżej.
Ponieważ klient jest konsolowy wszystkie akcje należy wydawać za pomocą komend. Poniżej kilka poleceń:
- /new - zakłada nową falę
- /open
- otwiera w prawym oknie podgląd fali o podanym identyfikatorze - /add
@ - dodaje użytkownika do aktywnej fali - /remove
@ - usuwa użytkownika z aktywnej fali
Więcej poleceń znaleźć można na następującej stronie.
W ten sposób dobrnęliśmy do końca. Udało się nam uruchomić i przetestować działanie naszego serwera Wave'a. Niestety osobiście odczuwam pewien niedosyt, jak się okazało w tej chwili jedynym znanym i darmowym klientem do otwartych fal jest klient konsolowy dostarczany wraz z referencyjną implementacją serwera. Oczywiście w przyszłości pewnie pojawią się nowe aplikacje, które będą wypełniać tę lukę jednak jak patrzę na webowego klienta Googlowskiego Wave to zaczynam wątpić czy kiedykolwiek będą one w stanie dorównać pierwowzorowi.
W ten sposób dobrnęliśmy do końca. Udało się nam uruchomić i przetestować działanie naszego serwera Wave'a. Niestety osobiście odczuwam pewien niedosyt, jak się okazało w tej chwili jedynym znanym i darmowym klientem do otwartych fal jest klient konsolowy dostarczany wraz z referencyjną implementacją serwera. Oczywiście w przyszłości pewnie pojawią się nowe aplikacje, które będą wypełniać tę lukę jednak jak patrzę na webowego klienta Googlowskiego Wave to zaczynam wątpić czy kiedykolwiek będą one w stanie dorównać pierwowzorowi.
Brak komentarzy:
Prześlij komentarz