Posts Tagged jopr

Co nowego pojawiło się w nowej wersji platformy RHQ Server 3.0.0

7 lipca pojawiła się finalna wersja serwera RHQ w wersji 3.0.0. Linki do pobrania można znaleźć na stronie Download projektu.

Poniżej lista modyfikacji w stosunku do wersji poprzedniej wersji stabilnej 1.3 (tak z punktu widzenia użytkownika, nie programisty):

  • nastąpiła zmiana numeracji z 1.3 na wersji 3.0 – aby wyrównać numerację różnych projektów
  • wtyczki do zarządzania serwerem JBoss (projekt o nazwie Jopr) zostały zintegrowane z projektem RHQ (czyli ich źródła znajdują się w tym samym repozytorium kodu, w ramach swoich modułów)
  • wprowadzenie wtyczek po stronie serwera, co umożliwa dodawanie nowych funkcji bez potrzeby kompilacji i modyfikacji kodu źródłowego: Server Plugin Development
  • możliwość dodawania własnej obsługi alarmów: Alert Sender Plug-ins
  • zmiana nazwy pozycji menu związanych z zarządzaniem instalacją i aktualizacja aplikacji z „Content Source” na „Content Providers” oraz „Channel” na Repositories”
  • synchronizacja zdefiniowanych repozytoriów
  • możliwość przeglądania repozytoriów oraz pobierania pakietów przy użyciu przeglądarki
  • zmiana sposobu przechowywania alarmów
  • możliwość utworzenia szablonów używanych do powiadamiania o różnych zdarzeniach
  • nowa przeglądarka zasobów
  • maskowanie hasła dostępowego do bazy danych (przy użyciu skryptu bin/generate-db-password.sh)
  • dodanie wsparcia bazy danych Oracle 11g
  • uwierzytelniania na podstawie grup LDAPowych
  • poprawa wsparcia serwera Apache
  • zestaw wtyczek, które pojawiły się w nowej wersji a nie były dostępne w wersji RHQ 1.3 w połączeniu z Jopr 2.3.1
    • jopr-jboss-as-5 – obsługa serwera aplikacji JBoss w wersji 5
    • jopr-jboss-cache
    • rhq-aliases
    • rhq-ant-bundle
    • rhq-augeas – obsługi biblioteki Augeas, pozwalającej na dostęp do rożnych plików konfiguracyjnych
    • rhq-cobbler
    • rhq-cron – definiowanie zadań w cronie
    • rhq-postfix – obsługa serwera pocztowego Postfix
    • rhq-samba – obsługa serwera Samba
    • rhq-sudoers – edycja pliku sudoers
    • rhq-twitter

Dokładną listę wszystkich modyfikacji (wraz z numerami poszczególnych zgłoszeń w systemie Jira) można znaleźć na stronach projektu, w ramach publikowanej każdej wersji beta.

Źródła

Tags: , , ,

Zabezpieczenie komunikacji pomiędzy serwerem RHQ a agentem monitorującym

W podstawowej konfiguracji komunikacja pomiędzy serwerem RHQ oraz agentami monitorującymi poszczególne systemy nie jest ani szyfrowana ani nie ma zaimplementowanych mechanizmów uwierzytelnienia. Może to prowadzić do wielu problemów związanych z bezpieczeństwem systemów:

  • jest możliwe dodanie do infrastruktury monitorującego nowego agenta i jego rejestracja w serwerze RHQ
  • jest możliwe podsłuchanie ruchu pomiędzy serwerem a agentami (i tym samym poznanie konfiguracji maszyn, być może różnych dodatkowych wrażliwych informacji)
  • istnieje możliwość przechwycenie komunikacji pomiędzy serwerem RHQ a agentem monitorującym oraz takie jej zmodyfikowanie, aby uzyskać wpływ na działanie agenta (a trzeba pamiętać, że agent często pracuje na uprawnieniach użytkownika root)

Oczywiście, takie potencjalne problemy mogą prowadzić tylko do jednego wniosku: taką konfigurację można używać tylko w ramach takiej infrastruktury, która jest kontrolowana w 100% i nikt nie powołany nie może z niej korzystać (czyli jak dla mnie to nigdy :D).

W przypadku serwera RHQ problem zabezpieczenia komunikacji oraz uwierzytelniania pomiędzy nim a agentami jest rozwiązana przy użyciu szyfrowania SSL oraz konfiguracji odpowiednich certyfikatów.

W sytuacji, gdy chcemy skonfigurować tylko szyfrowane połączenie (bez uwierzytelniania agentów) wystarczy tylko włączyć używanie protokołu SSL. Odpowiedni certyfikat powinien być już wygenerowany i domyślnie będzie znajdował się w pliku rhq-server/jbossas/server/default/conf/rhq.keystore.

Ja postaram się przedstawić bardziej zaawansowaną konfigurację, gdzie każdy agent także uwierzytelnia się na podstawie odpowiedniego certyfikatu.

Krok 1: Utworzenie certyfikatów SSL

Aby zarówno serwer RHQ jak agent monitorujący potrafiły zidentyfikować się wzajemnie należy zdefiniować odpowiednie certyfikaty SSL, które pozwolą na ich identyfikację. Zarówno serwer RHQ jak i każdy agent musi posiadać swój własny certyfikat. Można tutaj wykorzystać zarówno istniejące certyfikaty (podpisane np. przez jakieś CA), lub też wygenerować własne korzystając z narzędzia keytool.

Poniższe kroki należy wykonać osobno dla serwera RHQ jak i dla każdego agenta monitorującego, modyfikując odpowiednio parametry:

  1. Utworzenie pliku z certyfikatem oraz kluczami publicznym i prywatnym (należy pamiętać, że operację tę należy wykonać zarówno dla serwera jak i dla każdego agenta monitorującego):
    keytool -genkey -dname "CN=nazwa_hosta.example.com" -keystore nazwa_hosta-keystore.dat\
            -validity 3650 -alias nazwa_hosta -keyalg DSA -storetype JKS\
            -keypass haslo_do_klucza_prywatnego -storepass haslo_do_pliku_z_certyfikatem

    Polecenie to utworzy plik o nazwie nazwa_hosta-keystore.dat, w którym zostanie zapisany certyfikat z podaną nazwą maszyny (ważne, należy użyć odpowiedniej nazwy, przypisanej do danej maszyny na której działa agent lub serwer). Certyfikat będzie dostępu przy użyciu nazwy zdefiniowanej przy użyciu parametru alias, czyli w tym przypadku będzie to nazwa_hosta. Klucz prywatny zostanie zabezpieczony hasłem podanym przy użyciu parametru keypass a cały plik hasłem podanym przy użyciu parametru storepass. Certyfikat będzie miał ważność 10 lat (wartość validity). Podane wartości należy zapamiętać, będą one potrzebne dalej.

  2. Zapisanie utworzonego certyfikatu w osobnym pliku (co umożliwi potem jego import to pliku ze wszystkimi certyfikatami):
    keytool -export -keystore nazwa_host-keystore.dat -alias nazwa_hosta\
            -storetype JKS -storepass haslo_do_pliku_z_certyfikatem -file nazwa_hosta-cert
  3. Dodanie certyfikatu do wspólnego pliku z certyfikatami truststore.dat:
    keytool -import -keystore truststore.dat -alias nazwa_hosta\
            -storetype JKS -filenazwa_hosta-cert -noprompt\
            -keypass haslo_do_klucza_prywatnego -storepass haslo_do_pliku_z_certyfikatem

    Dzięki tej operacji dodamy każdy certyfikat do jednego pliku, dzięki czemu będziemy mogli ich używać w celu uwierzytelnienia agentów.

  4. Można w każdej chwili sprawdzić, czy i jakie certyfikaty znajdują się w pliku truststore.dat:
    keytool -list -keystore truststore.dat -storepass haslo_do_pliku_z_certyfikatem\
            -storetype JKS

Po wykonaniu powyższych operacji dla każdego agenta monitorującego i serwera RHQ będziemy dysponowali zarówno zdefiniowanymi dla każdego z nich kluczami prywatnymi jak i plikiem z certyfikatami, dzięki czemu będzie możliwe sprawdzenie ich tożsamości.

Aby ułatwić sobie kolejne kroki, stworzyłem prosty skrypt, które dokładnie wykona wszystkie powyższe kroki dla każdej maszyny. Skrypt należy zapisać w pliku o nazwie create_cert.sh a następnie wywoływać z dwoma parametrami: aliasem klucza oraz pełną nazwą maszyny, czyli np. tak:

./create_cert.sh nazwa_hosta nazwa_hosta.example.com

Skrypt tworzący klucze create_cert.sh:

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

ALIAS=$1
HOSTNAME=$2

KEYPASS="haslo"
STOREPASS="haslo"
KEYSTORE="${ALIAS}-keystore.dat"
CERTSTORE="${ALIAS}-cert"
TRUSTSTORE="truststore.dat"

echo -n "Create SSL Cert for $ALIAS...   "
keytool -genkey -dname "CN=$HOSTNAME" -keystore ${KEYSTORE}\
        -validity 3650 -alias $ALIAS -keyalg DSA -storetype JKS\
        -keypass ${KEYPASS} -storepass ${STOREPASS}
echo "done"

echo "Export certficate"
keytool -export -keystore ${KEYSTORE} -alias ${ALIAS}\
        -storetype JKS -storepass super_haslo -file ${CERTSTORE}

echo -n "Import certificate to ${TRUSTSTORE}...  "
keytool -import -keystore ${TRUSTSTORE} -alias ${ALIAS}\
        -storetype JKS -file ${CERTSTORE} -noprompt\
        -keypass ${KEYPASS} -storepass ${STOREPASS}
echo "done"

echo "Certificate list"
keytool -list -keystore ${TRUSTSTORE} -storepass ${STOREPASS}\
        -storetype JKS

Oczywiście, należy zdefiniować w skrypcie odpowiednie hasło.

Krok 2: Dystrybucja kluczy

Odpowiednie pliki z kluczami są już utworzone, należy je teraz skopiować na odpowiednie maszyny. Należy skopiować zarówno plik ze wszystkimi certyfikatami oraz specyficzny dla każdego agenta plik z kluczem prywatnym. Należy zwrócić szczególną uwagę na to, aby odpowiednie pliku umieścić na odpowiednich maszynach.

  • Instalacja certyfikatu na serwerze RHQ
    Najprościej będzie umieścić plik z certyfikatem serwera (o nazwie nazwa_hosta-keystore.dat) oraz truststore.dat w katalogu konfiguracyjnym serwera JBoss, w ramach którego pracuje RHQ. Czyli kopiujemy te pliki do katalogu rhq-server/jbossas/server/default/conf. Oczywiście można je umieścić w dowolnym innym miejscu, należy tylko pamiętać aby serwer RHQ miał możliwość ich odczytania.

    Należy jeszcze tak zmienić parametry dostępu do tych plików, aby tylko właściciel procesu RHQ miał możliwość ich odczytu.

  • Instalacje certyfikatu w agencie monitorującym
    Plik z kluczem prywatnym (nazwa_hosta-keystore.dat) oraz truststore.dat należy także umieścić w katalogu conf danego agenta, czyli w katalogu rhq-agent/conf. Dzięki temu, plik ten nie zostanie usunięty podczas procesu automatycznej aktualizacji agenta. Jeszcze raz powtórzę: należy skopiować odpowiedni plik nazwa_hosta-keystore.dat do odpowiedniego agenta.

Krok 3: Konfiguracja serwera RHQ

Teraz czas na odpowiednią konfigurację serwera RHQ, czyli włączenie szyfrowania i uwierzytelnienia. Najlepiej jest wyłączeń serwer przed przystąpieniem do realizacji kolejnych kroków.

Zaczynamy od edycji pliku konfiguracyjnego serwera rhq-server/bin/rhq-server.properties:

  • włączenie korzystania z SSL poprzez zdefiniowania transportu jako sslservlet:
    64
    65
    66
    67
    rhq.communications.connector.transport=sslservlet
    rhq.communications.connector.bind-address=
    rhq.communications.connector.bind-port=
    rhq.communications.connector.transport-params=/jboss-remoting-servlet-invoker/ServerInvokerServlet
  • konfiguracja magazynów z kluczami dla połączeń przychodzących:
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    # Server-side SSL Security Configuration for HTTPS thru Tomcat
    # These are used for browser https: access and for incoming messages from agents over sslservlet transport
    # [you cannot use ${x} variables - see https://jira.jboss.org/jira/browse/JBWEB-74]
    rhq.server.tomcat.security.client-auth-mode=true
    rhq.server.tomcat.security.secure-socket-protocol=TLS
    rhq.server.tomcat.security.algorithm=SunX509
    rhq.server.tomcat.security.keystore.alias=alias_klucza_dla_serwera
    rhq.server.tomcat.security.keystore.file=conf/nazwa_hosta_keystore.dat
    rhq.server.tomcat.security.keystore.password=haslo
    rhq.server.tomcat.security.keystore.type=JKS
    rhq.server.tomcat.security.truststore.file=conf/truststore.dat
    rhq.server.tomcat.security.truststore.password=haslo
    rhq.server.tomcat.security.truststore.type=JKS

    Powyższa konfiguracja umożliwia odszyfrowanie wiadomości przychodzących od agentów. Jednocześnie pozwoli także na uwierzytelnienie tych agentów, ponieważ będzie można odczytać tylko te wiadomości od tych agentów, których klucze publiczne znajdują się w pliku truststore.dat. Jednocześnie będzie można określić, jaki agent dana informację wysłał.

  • konfiguracja magazynów z kluczami dla połączeń wychodzących:
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    # Client-side SSL Security Configuration (for outgoing messages to agents)
    rhq.server.client.security.secure-socket-protocol=TLS
    rhq.server.client.security.keystore.file=${jboss.server.home.dir}/conf/nazwa_hosta-keystore.dat
    rhq.server.client.security.keystore.algorithm=SunX509
    rhq.server.client.security.keystore.type=JKS
    rhq.server.client.security.keystore.password=haslo
    rhq.server.client.security.keystore.key-password=haslo
    rhq.server.client.security.keystore.alias=nazwa_hosta
    rhq.server.client.security.truststore.file=${jboss.server.home.dir}/conf/truststore.dat
    rhq.server.client.security.truststore.algorithm=SunX509
    rhq.server.client.security.truststore.type=JKS
    rhq.server.client.security.truststore.password=haslo
    rhq.server.client.security.server-auth-mode-enabled=true

    Dzięki tej konfiguracji będzie można komunikować się z agentami tak, aby byli oni pewni że nadawcą jest serwer RHQ.

Krok 4: Konfiguracja agenta monitorującego

Ostatnim elementem będzie konfiguracja agenta monitorującego. Istnieją trzy sposoby na jakie można skonfigurować agenta:

  1. Uruchomić konfigurowanie agenta w trybie zaawansowanym, można to zrobić uruchamiając go z następującymi parametrami --cleanconfig --setup --advanced.
  2. Uruchomić agenta w trybie console a następnie wydać polecenie setup advanced.
  3. Bezpośrednio zmodyfikować plik konfiguracyjny conf/agent-configuration.xml i następnie uruchomić agenta z przełącznikiem cleanconfig.

Sposoby pierwszy i drugi wymagają odpowiedzi na szereg pytań, ja przedstawię co należy zmodyfikować w pliku konfiguracyjnym.

  • konfiguracja połączenia z serwerem:
    120
    121
    122
    123
    <entry key="rhq.agent.server.transport"        value="sslservlet" />
    <entry key="rhq.agent.server.bind-port"        value="7443" />
    <entry key="rhq.agent.server.bind-address"     value="rhq-server.example.com" />
    <entry key="rhq.agent.server.transport-params" value="/jboss-remoting-servlet-invoker/ServerInvokerServlet" />
  • konfiguracja łączności agenta monitorującego
    885
    886
    887
    <entry key="rhq.communications.connector.rhqtype"          value="agent" />
    <entry key="rhq.communications.connector.transport"        value="sslsocket" />
    <entry key="rhq.communications.connector.bind-port"        value="16163" />
  • konfiguracja łączności z serwerem – włączenie korzystania z uwierzytelnienia (parametr client-auth-mode) oraz definicja dostępu do certyfikatów:
    931
    932
    933
    934
    935
    936
    937
    938
    939
    940
    941
    942
    <entry key="rhq.communications.connector.security.secure-socket-protocol" value="TLS" />
    <entry key="rhq.communications.connector.security.keystore.file"          value="conf/nazwa_hosta-keystore.dat" />
    <entry key="rhq.communications.connector.security.keystore.algorithm"     value="SunX509" />
    <entry key="rhq.communications.connector.security.keystore.type"          value="JKS" />
    <entry key="rhq.communications.connector.security.keystore.password"      value="haslo" />
    <entry key="rhq.communications.connector.security.keystore.key-password"  value="haslo" />
    <entry key="rhq.communications.connector.security.keystore.alias"         value="nazwa_hasla" />
    <entry key="rhq.communications.connector.security.truststore.file"        value="conf/truststore.dat" />
    <entry key="rhq.communications.connector.security.truststore.algorithm"   value="SunX509" />
    <entry key="rhq.communications.connector.security.truststore.type"        value="JKS" />
    <entry key="rhq.communications.connector.security.truststore.password"    value="haslo" />
    <entry key="rhq.communications.connector.security.client-auth-mode"       value="need" />
  • konfiguracja łączności z klientem – włączenie korzystania z uwierzytelnienia (parametr server-auth-mode-enabled) oraz konfiguracja dostępu do plików z certyfikatami:
    944
    945
    946
    947
    948
    949
    950
    951
    952
    953
    954
    955
    <entry key="rhq.agent.client.security.secure-socket-protocol"   value="TLS" />
    <entry key="rhq.agent.client.security.keystore.file"            value="conf/nazwa_hosta-keystore.dat" />
    <entry key="rhq.agent.client.security.keystore.algorithm"       value="SunX509" />
    <entry key="rhq.agent.client.security.keystore.type"            value="JKS" />
    <entry key="rhq.agent.client.security.keystore.password"        value="haslo" />
    <entry key="rhq.agent.client.security.keystore.key-password"    value="haslo" />
    <entry key="rhq.agent.client.security.keystore.alias"           value="nazwa_hosta" />
    <entry key="rhq.agent.client.security.truststore.file"          value="conf/truststore.dat" />
    <entry key="rhq.agent.client.security.truststore.algorithm"     value="SunX509" />
    <entry key="rhq.agent.client.security.truststore.type"          value="JKS" />
    <entry key="rhq.agent.client.security.truststore.password"      value="haslo" />
    <entry key="rhq.agent.client.security.server-auth-mode-enabled" value="true" />

Oczywiście, należy te wpisy dostosować do własnych potrzeb (w szczególności dotyczy to zdefiniowania odpowiednich haseł). Po wprowadzeniu modyfikacji, należy zatrzymać agenta i uruchomić go przy użyciu następującej komendy:

rhq-agent/bin/rhq-agent.sh --cleanconfig

Spowoduje ona uruchomienie agenta oraz uruchomienie jego procesu konfiguracji. Należy odpowiedzieć na pierwsze pytania, poczekać aż agent połączy się z serwerem i jeżeli nie wystąpiły żadne błędy to wszystko powinno działać OK.

Jeżeli wystąpiły błędy, to trzeba je zanalizować i próbować zmienić wpisy w pliku konfiguracyjnym. Jeżeli pierwsze uruchomienie powiodło się, można już uruchomić agenta przy użyciu skryptu uruchomieniowego.

Pozostaje teraz skonfigurowanie pozostałych agentów i możemy się cieszyć szyfrowaną transmisją między serwerem RHQ a agentami.

Źródła

Tags: , , , , , , ,

Automatyczne uruchamianie serwera RHQ Server (oraz Jopr) podczas startu systemu.

W systemie produkcyjnym porządna jest sytuacja, gdy wszystkie potrzebne usługi uruchamiają się automatycznie podczas jego startu oraz korzystają z minimalnych uprawnień jakie można im przydzielić. Serwer RHQ zawiera skrypty uruchomieniowe, które pozwalają go odpowiednio uruchamiać oraz zatrzymywać, nie pozwalają jednak skonfigurować użytkownika, który ma zostać użyty do jego uruchomienia. Serwer do swojego działania nie potrzebuje uprawnień innych niż posiada zwykły użytkownik (przynajmniej w sytuacji, gdy nie używamy wbudowanego agenta).

Konfiguracja systemu

Pierwszym krokiem będzie stworzenie odpowiedniego użytkownika, który zostanie użyty do uruchamiania serwera RHQ. Będzie on się nazywał rhqadmin i można utworzyć go następującym poleceniem:

# useradd -b /opt/rhq-server -d /opt/rhq-server -s /bin/bash rhqadmin

Polecenie powyższe doda nowego użytkownika rhqadmin, skonfiguruje odpowiedni katalog domowy dla niego oraz powłokę domyślną. Nie będzie miał on również skonfigurowanego hasła – nie ma potrzeby aby logował się do systemu.

Pozostaje zmienić uprawnienia do katalogów:

# chown -R rhqadmin.rhqadmin /opt/rhq-server
# chmod -R ug+rw,ug+X,o-rwx rhq-server
# chmod -R ug=rwx,o-rwx rhq-server/bin/*.sh

Utworzenie skryptu startującego RHQ Server

W domyślnej instalacji istnieje skrypt, który pozwoli uruchomić serwer RHQ przy użyciu uprawnień bieżącego użytkownika. Można go znaleźć w tym miejscu: /opt/rhq-server/bin/rhq-server.sh. Bezpośrednio w skrypcie nie ma zaimplementowanej możliwości zmiany użytkownika używanego do jego uruchomienia. Do wyboru są więc dwie możliwości:

  • zmodyfikować skrypt rhq-server.sh tak, aby uruchamiał serwer JBoss korzystając z wybranego użytkownika – to było moje pierwsze podejście, jednak okazało się, że wymaga w praktyce sporo modyfikacji, i jakoś tak do końca nigdy mi to rozwiązanie nie zadziałało do końca poprawnie
  • utworzyć wrapper na skrypt rhq-server.sh, który od razu ten skrypt będzie wykonywał na uprawnieniach wybranego użytkownika – okazuje, że utworzenie tego wrappera jest dosyć prostym rozwiązaniem i co najważniejsze, działa bez kłopotów

Poniższy skrypt należy zapisać w pliku /etc/init.d/rhq-server. Można go dostosować do swoich potrzeb (modyfikując odpowiednio ścieżki dostępu, użytkownika i tak dalej). Jak łatwo zauważyć, skrypt sam w sobie wiele nie robi, po prostu wywołuje skrypt rhq-server.sh modyfikując tylko użytkownika i delegując już resztę roboty do niego. Skrypt doskonały nie jest (w szczególności jeżeli jakieś błędy będą występować), ale działa.

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#! /bin/sh
### BEGIN INIT INFO
# Provides:          rhq-server
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: RHQ Server start script
# Description:       Start RHQ Server
### END INIT INFO

PATH=/opt/rhq-server/bin:/sbin:/usr/sbin:/bin:/usr/bin
DESC="Uruchomienie RHQ Server"
NAME=rhq-server
DAEMON=/opt/rhq-server/bin/rhq-server.sh
SCRIPTNAME=/etc/init.d/$NAME
RHQ_USER="rhqadmin"

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

case "$1" in
  'console')
        su - $RHQ_USER -c "$DAEMON console"
        ;;
  'start')
        su - $RHQ_USER -c "$DAEMON start"
        ;;
  'stop')
        su - $RHQ_USER -c "$DAEMON stop"
        ;;
  'kill')
        su - $RHQ_USER -c "$DAEMON kill"
        ;;
  'status')
        su - $RHQ_USER -c "$DAEMON status"
        ;;
  *)
        su - $RHQ_USER -c "$DAEMON usage"
        ;;
esac

Automatyczne uruchamianie skryptu

Ostatnim elementem będzie skonfigurowanie automatycznego uruchamiania serwera w Debianie

# update-rc.d rhq-server defaults 90 10
update-rc.d: warning: /etc/init.d/rhq-server missing LSB information
update-rc.d: see <http ://wiki.debian.org/LSBInitScripts>
 Adding system startup for /etc/init.d/rhq-server ...
   /etc/rc0.d/K10rhq-server -> ../init.d/rhq-server
   /etc/rc1.d/K10rhq-server -> ../init.d/rhq-server
   /etc/rc6.d/K10rhq-server -> ../init.d/rhq-server
   /etc/rc2.d/S90rhq-server -> ../init.d/rhq-server
   /etc/rc3.d/S90rhq-server -> ../init.d/rhq-server
   /etc/rc4.d/S90rhq-server -> ../init.d/rhq-server
   /etc/rc5.d/S90rhq-server -> ../init.d/rhq-server

Tags: , , , , ,

Aktualizacja platformy RHQ z wersji 1.3 i 1.4 do wersji 3.0

Dwa tygodnie temu została wydana wersja 3.0.0.B06 serwera RHQ. Zachciało m się więc sprawdzić, co też w niej słychać. Zamiast jednak pobrać tę wersję ze stron projektu, zapragnąłem skompilować je samodzielnie i zrobić aktualizację używanej przeze mnie wersji serwera 1.4-SNAPSHOT.

Kolejne kroki jakie przedstawię poniżej pozwoliły mi zaktualizować:

  • serwer RHQ wraz z dołączanymi wtyczkami
  • wtyczki do serwera JBoss
  • agentów monitorujących wraz z ich wtyczkami


Na samym początku jeszcze mam jedną uwagę: mogę się założyć, że droga którą wybrałem była jedną z trudniejszych i na pewno istnieje prostszy sposób kompilacji źródeł serwera RHQ i aktualizacji istniejącego już systemu. W moim przypadku zacząłem od kompilacji kodu a następnie po kolei rozwiązywałem problemy jakie się pojawiały w kolejnych krokach. Myślę jednak, że musi istnieć prostsza metoda, więc myślę że zanim zaczniesz realizować kolejne kroki, postaraj się ją najpierw znaleźć, a tutaj wróć w ostateczności :).

Krok 1: przygotowanie środowiska

Pierwszym krokiem będzie przygotowanie środowiska, w którym będzie można skompilować serwer RHQ. W moim przypadku środowisko już miałem wstępnie przygotowane ze względu na kompilację wersji 1.4. Będziemy potrzebowali:

  • Java – zainstalować JDK 6, należy także poprawnie skonfigurować zmienną systemową $JAVA_HOME, która powinna wskazywać na katalog domowy z Javą
  • Maven – zainstalowany w wersji przynajmniej 2.1.x, można pobrać go ze strony http://maven.apache.org/download.html
  • PostgreSQL – zainstalować bazę danych, w wersji przynajmniej 8.3 (ja używałem wersji 8.4)
  • Git – system kontroli wersji

Krok 2: pobranie źródeł

W stosunku do poprzedniej wersji systemu RHQ uległ zmianie używany system kontroli wersji: wersja 1.3/1.4 używa systemu Subversion, aktualna systemu Git. W związku z tym pobranie i aktualizacja źródeł wygląda inaczej. Do aktualnej wersji RHQ zostały także włączone wtyczki pozwalające na zarządzanie serwera aplikacji JBoss, więc nie będzie także potrzeby pobrania osobnych źródeł dla nich.

Pobranie źródeł:

git clone git://git.fedorahosted.org/rhq/rhq.git

Pobranie źródeł trochę potrwa, u mnie zajęły w sumie około 150 MB, z tym że sam katalog git miał rozmiar 50MB.

Możemy także aktualizować źródła przy użyciu tego polecenia (wykonywanego w katalogu z pobranymi źródłami RHQ):

git pull -v --stat

Krok 3: konfiguracja bazy danych

Konfigurację bazy danych opisałem w artykule Jak skompilować ze źródeł aplikacje RHQ Server oraz Jopr w punkcie 3. Zamiast jednak tworzyć bazę danych o nazwie rhq należy utworzyć bazę o nazwie rhqdev:

createdb -U postgres -O rhqadmin rhqdev

Krok 4: kompilacja źródeł

Czas teraz na kompilację źródeł. Robi się to przy użyciu aplikacji maven. Pierwsza kompilacja może zająć sporo czasu (nawet do godziny), ponieważ zostaną pobrane biblioteki niezbędne do kompilacji i działania serwera RHQ. Każda następna powinna już być zdecydowania szybsza.

Kompilację rozpoczynamy będąc w katalogu ze źródłami aplikacji następującą komendą:

mvn -Penterprise,dev -Dmaven.test.skip=true -Ddbsetup install

Podczas procesu kompilacji zostanie utworzona baza danych, w związku z tym musi ona być odpowiednio skonfigurowana.

Po zakończeniu kompilacji można znaleźć serwer RHQ w katalogu modules/enterprise/server/container/target. Można w nim znaleźć także archiwum o nawie rhq-server-3.0.0-SNAPSHOT.zip, które można użyć do instalacji nowej wersji serwera lub też do aktualizacji już istniejącej.


Można także skompilować RHQ przy użyciu takiego polecenia:

mvn -Penterprise,dist -Dmaven.test.skip=true -Ddbsetup install

Spowoduje to utworzenie archiwum przeznaczonego do instalacji i aktualizacji. Ja niestety tak nie zrobiłem, co naraziło mnie na późniejsze problemy. Być może użycie tak przygotowanych plików binarnych rozwiązałoby je samo….

Krok 5: konfiguracja nowej wersji RHQ

Pozostaje teraz skopiować plik rhq-server-3.0.0-SNAPSHOT.zip na serwer docelowy i przystąpić do instalacji nowej wersji RHQ.

W moim przypadku instalowałem serwer w katalogu /opt/rhq-server. Początkowa konfiguracja sprowadza się do podania ścieżki dostępu do środowiska Java, czyli definiujemy odpowiednie zmienne w pliku bin/rhq-server.sh:

86
87
88
RHQ_SERVER_HOME=/opt/rhq-server
# RHQ_SERVER_DEBUG=true
JAVA_HOME=/usr/lib/jvm/java-6-sun

Teoretycznie, teraz można było uruchomić serwer, ale niestety nie w tym przypadku. Ponieważ podczas kompilacji została utworzona wersja deweloperska, to jest ona już przygotowana do pracy z odpowiednią bazą danych. Nie ma możliwości przeprowadzenia aktualizacji już istniejącego schematu. W związku z tym należy odwrócić proces instalacji, i przygotować tak serwer, aby pozwalał na uruchomienie procesu instalacji.

Nie ma takiej potrzeby, jeżeli kompilacja odbywała się z opcją dist.

Poniższe akcje należy wykonać w katalogu jbossas/server/default/deploy/. Zmieniają one nazwy niektórych aplikacji i usuwają niepotrzebne aplikacje (które zostaną utworzone podczas konfiguracji).

cd /opt/rhq-server/jbossas/server/default/deploy/
mv alert-cache-service.xml{,.rej}
rm -fr jms
mv jmx-console.war{,.rej}
mv mail-service.xml{,.rej}
mv rhq-agent.sar{,.rej}
rm rhq-ds.xml
mv rhq.ear{,.rej}

Powyższe kroki spowodują, że teraz serwer RHQ uruchomi się w trybie instalacji.

Można teraz uruchomić serwer RHQ, najlepiej w trybie konsoli:

bin/rhq-server.sh console

Po pomyślnym uruchomieniu, można połączyć się z adresem http://localhost:7080 i dalszą konfigurację przeprowadzić przy użyciu przeglądarki internetowej.

Na drugim ekranie możemy zdefiniować podstawowe dane potrzebne do instalacji serwera. Ponieważ przeprowadzamy aktualizację serwera, należy podać namiary na istniejącą bazę danych i po ich podaniu wybrać przycisk Test connection. Połączenie zostanie sprawdzone, RHQ wykryje że baza danych istnieje i będzie istniała możliwość zdefiniowania co z nią zrobić. Należy wybrać opcję Keep.

Ostatnim elementem będzie zdefiniowanie informacji o serwerze, na którym będzie pracował serwer RHQ. Można to zrobić przy polu Registered Servers. Z wyświetlonej listy wybieramy nasz serwer.

RHQ Server - aktualizacja serwera

RHQ Server - aktualizacja serwera

Warto pamiętać, że informacje o połączeniu z bazą danych oraz o konfiguracji serwera można znaleźć w pliku rhq-server.properties.

Po wykonaniu powyższych modyfikacji, można rozpocząć instalację serwera.

W moim przypadku w tym momencie zaczął pokazywać się dosyć długi wyjątek, który sprowadzał się do następującego komunikatu:

Cause: org.postgresql.util.PSQLException: BŁĄD: relacja "rhq_raw_config_id_seq" już istnieje

Przyczyną jego występowania jest próba utworzenia już istniejącej sekwencji (co można łatwo sprawdzić łącząc się z bazą danych). Usuwanie tej sekwencji z bazy i ponowne uruchamianie procesu instalacji niestety nie rozwiązywało problemu, w dalszym ciągu komunikat się pojawiał.

I w tym miejscu rozpoczyna się bardziej żmudna część tej instalacji. Nie będę już przynudzał, co i gdzie sprawdzałem aby się dowiedzieć w jaki sposób jest dokonywana aktualizacja bazy danych, skupię się tylko na sposobie rozwiązania tego problemu.

Baza danych aktualizowana jest na podstawie zawartości pliku db-upgrade.xml, który można znaleźć w archiwum jbossas/server/default/deploy/rhq-installer.war/WEB-INF/lib/rhq-core-dbutils-3.0.0-SNAPSHOT.jar. Należy ten plik otworzyć, wprowadzić modyfikację oraz zapisać. Ponieważ plik znajduje się w archiwum jar, dobrze jest tutaj użyć jakiegoś narzędzia, które pozwoli na modyfikowanie jego zawartości bez ręcznego wypakowywania plików. Ja używałem aplikacji Midnight Commander, który sobie z tym poradził znakomicie. I po kolei, trzeba zrobić:

  1. Otwieramy plik jbossas/server/default/deploy/rhq-installer.war/WEB-INF/lib/rhq-core-dbutils-3.0.0-SNAPSHOT.jar
  2. Otwieramy plik db-upgrade.xml w trybie edycji
  3. Znajdujemy linię, która zawiera definicję sekwencji rhq_raw_config_id_seq i komentujemy ją:
    1668
    <!-- <schema-createSequence name="RHQ_REPO_GROUP_ID_SEQ" initial="10001" /> -->
  4. Ponownie uruchamiamy instalację serwera
  5. Jeżeli wystąpi błąd z inną sekwencją, wykonujemy ponownie kroki od 2 do 4. W moim przypadku musiałem tę operację powtórzyć dla następujących linii:
    1725
    <!-- <schema-createSequence name="RHQ_REPO_RELATION_TYPE_ID_SEQ" initial="10001" /> -->
    1749
    <!-- <schema-createSequence name="RHQ_REPO_RELATION_ID_SEQ" initial="10001" /> -->
    1808
    <!-- <schema-createSequence name="RHQ_DISTRIBUTION_TYPE_ID_SEQ" initial="10001" /> -->
    1915
    <!-- <schema-createSequence name="RHQ_TAG_ID_SEQ" initial="10001" /> -->
    1929
    <!-- <schema-createSequence name="RHQ_DISTRIBUTION_FILE_ID_SEQ" initial="10001" /> -->
    2298
    <!-- <schema-createSequence name="RHQ_REPO_SYNC_ID_SEQ" initial="10001" /> -->
    2358
    <!-- <schema-createSequence name="RHQ_BUNDLE_ID_SEQ" initial="10001" /> -->
    2399
    <!-- <schema-createSequence name="RHQ_BUNDLE_VERSION_ID_SEQ" initial="10001" /> -->
    2464
    <!-- <schema-createSequence name="RHQ_BUNDLE_FILE_ID_SEQ" initial="10001" /> -->
    2588
    <!-- <schema-createSequence name="RHQ_BUNDLE_RES_DEPLOY_ID_SEQ" initial="10001" /> -->
    2624
    <!-- <schema-createSequence name="RHQ_BUNDLE_RES_DEP_HIST_ID_SEQ" initial="10001" /> -->
    2710
    <!-- <schema-createSequence name="RHQ_SAVED_SEARCH_ID_SEQ" initial="10001" /> -->
    2762
    <!-- <schema-createSequence name="RHQ_ROLE_LDAP_GROUP_ID_SEQ" initial="10001" /> -->
  6. W przypadku wystąpienia różnych innych błędów, warto rozpocząć proces instalacji od nowa lub w skrajnych przypadkach zrestartować serwer RHQ i ponownie rozpocząć instalację

W moim przypadku po zakomentowaniu ostatniej sekwencji instalacja przebiegła pomyślnie, baza danych została zaktualizowana, RHQ poprawnie się skonfigurował i mogłem już zalogować się na własne konto.

Krok 6: aktualizacja agentów monitorujących

Ostatnim elementem związanym z aktualizacją serwera jest poprawny upgrade agentów monitorujących. I tutaj pokazała się siłą tej architektury :). W moim przypadku wystarczyło po prostu zrestartować agenty, i już samoczynnie się one zaktualizowały.

Jeżeli posiadasz zdefiniowaną grupę z agentami (informacje o tym jak to zrobić możesz znaleźć w tym wpisie: Definiowanie grupy usług w serwerze RHQ), to wystarczy ją wybrać i wydać polecenie restartu. Polecenie zostanie zdalnie wykonane, agenty się zrestartują i zaktualizują.

W moim przypadku agenci wykryli nowe zasoby na serwera oraz niestety od nowa niektóre serwery JBoss (przynajmniej tyle na razie zauważyłem). Przestało także działać monitorowanie serwera Apache.

Tym sposobem dotarliśmy do końca, mam nadzieję że na więcej problemów nie natraficie.

Źródła

Tags: , , , , , , ,

Definiowanie uprawnień dostępu w serwerze RHQ

Serwer RHQ umożliwia definiowanie uprawnień dostępu do poszczególnych zasobów, które są monitorowane. Możliwa jest także odpowiednia granulacja tych uprawnień, zarówno ze względu na dostępu do poszczególnych usług jak i operacji jakie można na nich wykonywać.

Model uwierzytelniania w RHQ opiera się o role, które są miejscem łączącym operacje jakie można wykonać wraz z odpowiednimi użytkownikami oraz grupami.

Celem będzie uzyskanie następującej sytuacji: utworzenie nowego użytkownika, który będzie miał możliwość monitorowania wszystkich zasobów oraz możliwość pełnej kontroli nad skryptami startowymi agentów monitorujących.

Rodzaje uprawnień w RHQ

Poszczególne uprawnienia dzielą sią na dwie grupy: globalne i dotyczące zasobów.

W przypadku uprawnień globalnych, są dostępne następujące zezwolenia:

  • Manage security (users/roles) – pozwala na modyfikowanie ustawień związanych z zarządzaniem rolami oraz użytkownikami. W praktyce użytkownik z tą rolą ma kontrolę nad całym systemem (zawsze może sobie odpowiednią rolę samodzielnie).
  • Manage inventory (resources/groups) – pozwala na wykonywania dowolnych akcji na każdym zasobie, niezależnie od innych uprawnień jakie mogą być skonfigurowane.
  • Administer RHQ Server settings – pozwala na modyfikowanie konfiguracji serwera RHQ

Uprawnienia do zasobów odnoszą się tylko do zasobów, które są dodanie do danej roli. Są dostępne następujące zezwolenia:

  • Modify – pozwala na modyfikacje opis zasobów w serwerze RHQ (czyli np. jego nazwy), nie umożliwia konfiguracji zasobu;
  • Delete – pozwala na usunięcie danego zasobu z serwera;
  • Create Child – pozwala na dodanie nowego zasobu potomnego;
  • Alerts – pozwala na zarządzanie alarmami;
  • Measurements – pozwala na niemodyfikowanie sposobów w jakie zbierane są informacje z monitoringu;
  • Content
  • Control – pozwala na wykonywanie akcji w ramach zasobów
  • Configure – pozwala na modyfikację konfiguracji danego zasobu

Tak się prezentuje rola super użytkownika:

RHQ Server - Super User Role

RHQ Server - Super User Role

Utworzenie grup zasobów

Ponieważ konkretne uprawnienia są przydzielane do grup, to najpierw należy zdefiniować dwie grupy, obie dynamiczne:

  • Agent Laucher Script – lista agentów działających w ramach systemu monitorującego
  • Wszystkie platformy – wszystkie platformy jakie są podłączone do serwera monitorującego

O sposobie definicji grupy dynamicznej oraz jak zdefiniować pierwszą grupę można przeczytać w tym wpisie: Definiowanie grupy usług w serwerze RHQ.

Definicja grupy obejmującej wszystkie zasoby powinna wyglądać następująco:

RHQ Server - definicja grupy "Wszystkie platformy"

Utworzenie ról dla grup

Po zdefiniowaniu odpowiednich grup zasobów przychodzi czas na zdefiniowanie odpowiednich uprawnień do nich. Robi się to poprzez utworzenie ról, w których będzie można powiązać zasoby i uprawnienia do nich przypisane.

Wyświetlenie listy dostępnych ról i ekranu pozwalającego na zarządzanie nimi jest możliwe po wybranie z menu pozycji Administration->Security->Roles:

RHQ Server - role

RHQ Server - role

Po wybranie tej pozycji z menu zostanie wyświetlona lista wszystkich dostępnych ról w systemie:

RHQ Server - lista dostępnych ról

RHQ Server - lista dostępnych ról

Domyślnie w RHQ są dostępne dwie specjalne role:

  • Super User Role – rola super użytkownika, osoba przypisana do tej roli ma dostęp do wszystkich elementów serwera monitorującego RHQ, roli tej nie można modyfikować
  • All Resources Role – rola ta daje dostęp do wszystkich zasobów serwera, ale nie umożliwia modyfikowania uprawnień użytkowników, ról czy też konfiguracji serwera

Definicja nowej roli jest możliwa po wybraniu przycisku NEW.

RHQ Server - definicja nowej roli

RHQ Server - definicja nowej roli

Podczas definiowania nowej roli należy przede wszystkim zdefiniować jej nazwę (unikalną w ramach serwera RHQ) oraz odpowiednie uprawnienia. Dostępne uprawnienia zostały już powyżej opisane.

W naszym przypadku definiujemy nazwę roli jako RHQ Agent i przypisujemy tej roli wszystkie uprawnienia z grupy Resource Permissions a następnie zatwierdzamy nową rolę.

W tym momencie dysponujemy już zdefiniowaną rolę, ale jeszcze nie wskazaliśmy jakich zasobów ma ona dotyczyć. W związku z tym czas teraz na wybór w grupie Assigned Groups przycisku ADD TO LIST. Zostanie wyświetlona strona, która pozwoli na przypisanie grup zasobów do danej roli.

Należy wybrać z listy rolę DynaGroup - Agent Laucher Script i zatwierdzić wybór. Po zatwierdzeniu, grupa ta powinna wyglądać następująco:

RHQ Server - dodanie grup zasobów do roli

RHQ Server - dodanie grup zasobów do roli

Analogicznie należy utworzyć drugą rolę, o nazwie Monitorowanie serwerów. Jej definicja powinna wyglądać następująco:

RHQ Server - definicja roli Monitorowanie serwerów

RHQ Server - definicja roli Monitorowanie serwerów

Tym sposobem dysponujemy dwoma rolami, które definiują dostęp do agentów monitorujących oraz wszystkich innych zasobów. Teraz pozostaje utworzyć odpowiedniego użytkownika, który będzie z nich korzystał.

Utworzenie nowego użytkownika

Ostatnim elementem będzie utworzenie nowego użytkownika, który będzie należał do dwóch zdefiniowanych grup.

Wyświetlenie strony pozwalającej na zarządzanie użytkownikami jest możliwe poprzez wybranie następującej pozycji z menu: Administration->Security->Users:

RHQ Server - zarządzanie użytkownikami

RHQ Server - zarządzanie użytkownikami

Zostanie wyświetlona strona z listą zdefiniowanych użytkowników. Dodanie nowego użytkownika jest możliwe po wybraniu przycisku NEW. Pozwoli to na zdefiniowanie podstawowych informacji o nowym użytkowniku systemu:

  • Name – imię i nazwisko użytkownika
  • Email – mail
  • Password – hasło dostępu użytkownika
  • Username – login użytkownika
  • Phone – nr telefony
  • Department – dział
  • Enable Login – wyłącznie konta (wyłączenie uniemożliwi logowanie na to konto)

Przykładowa definicja użytkownika:

RHQ Server - definiowanie nowego użytkownika

RHQ Server - definiowanie nowego użytkownika

Po zatwierdzeniu danych użytkownika przechodzimy do strony pozwalającej na wybór ról, jakie mają z danym użytkownikiem zostać skojarzone. Należy wybrać role RHQ Agent oraz Monitorowanie serwerów. Po zatwierdzeniu definicja użytkownika powinna prezentować się następująco:

RHQ Server - zdefiniowany użytkownik

RHQ Server - zdefiniowany użytkownik

Od tej chwili Jan Kowalski może się zalogować do systemu, otrzyma dostęp do monitorowania wszystkich serwerów oraz usług, ale modyfikować będzie mógł tylko zachowanie agentów monitorujących.

Źródła

Tags: , , ,