my personal page

Koledzy z firmy wydłubali ostatnio jakiś super-hiper wyczesany portal dla klienta, który oparli na Liferay’u. Testowali to na jednym z Windowsowych serwerów (z zainstalowanym dla potrzeb testów MySQLem). Testy się udały, portal zaczął prawidłowo działać, więc nadszedł odpowiedni czas na przeniesienie tego na serwery produkcyjne: serwer bazodanowy (MySQL) oraz WWW (tomcat + dodatki). Oba działające pod kontrolą CentOSa. Sama platforma z portalem to jeden problem (bo wymaga dość mało popularnych interfejsów do SAPa), który – szczęśliwie – udało się w miarę szybko zwalczyć.

Ale natychmiast pojawiła się bardzo dziwna sytuacja. Pomimo tego, że mysqldump utworzył (wydawałoby się) poprawną kopię danych, a baza na serwerze produkcyjnym nie zgłosiła zastrzeżeń co do jego poprawności i ochoczo wessała wszystkie podstawione jej dane, to po konfiguracji tego wszystkiego okazało się, że owszem, portal wystartował, ale nie zawiera żadnych informacji używanych podczas testów. Baza jest, użytkownik jest, zalogować się 'z ręki’ można, tabele zawierają wszystko, co powinny, a portal nie działa.

Zajęło nam kilka dni, zanim udało się znaleźć przyczynę dziwnego zachowania. Okazało się, że w zależności od systemu, na jakim został zainstalowany, serwer MySQL nie zawsze bierze pod uwagę wielkość liter w nazwach baz/tabel. Dokładniej jest to opisane tutaj. Serwer źródłowy (czyli ten z Windowsem) jest case-insensitive (nieczuły? :-)) z punktu widzenia systemu plików (i mysqldump’a!), więc wyeksportował nazwy tabel małymi literami. I tak też wciągnął te nazwy Linux. Z tą różnicą, że zapytania z portalu zawierają literki o różnej wielkości (Windowsowi było i tak wszystko jedno, bo nie brał tego pod uwagę) – i to był nasz problem. Dane owszem, były na swoim miejscu, ale w tabelach, których nazwy składały się wyłącznie z małych liter (zgodnie z tym, co zawierało archiwum utworzone przez mysqldump’a). A Liferay szukał tabelek nazwanych dużymi literami…

Ponieważ docelowy serwer bazodanowy został specjalnie skonfigurowany dla potrzeb tego typu portali, to przełączenie bazy w tryb lower_case_table_names=1 (czyli case insensitive) nie ma dla mnie żadnych negatywnych skutków i tak też zrobiłem. Po restarcie bazy (i – na wszelki wypadek – ponownym imporcie jej zawartości) wszystko zaczęło działać poprawnie, a dane pojawiły się równie magicznie, jak wcześniej zniknęły :-)

Tak zupełnie szczerze, to nie wiem, ile czasu by mi zajęło szukanie, gdybym nie natknął się na ten wpis na forum Liferay’a.

Paczkę z potrzebnymi binarkami możemy pobrać spod adresu http://service.sap.com/swdc. Niestety, żeby się tam dostać trzeba mieć konto dostępowe.

Na początek kilka słów o tym, jak znaleźć odpowiedni pakiet. W przypadku SAPa nic nie jest oczywiste, więc nawet z pobieraniem oprogramowania można mieć pewne problemy. Przede wszystkim musimy określić, jaka właściwie wersja będzie nam potrzebna. Z pomocą przychodzi notka o numerze 825494. Ponieważ aktualnie mam zamiar to instalować na CentOSie 5.4 w wersji 32-bitowej, potrzebuję RFCSDK w wersji 6.40 lub 7.00 (przynajmniej tak wynika ze wspomnianej noty). Teraz zaglądamy do noty numer 413708. Mamy tu ładnie opisane gdzie, co i w jakiej kolejności kliknąć, żeby dojść do miejsca z którego możemy sobie pożądane rzeczy pobrać. Oczywiście z rzeczywistością ma to niewiele wspólnego :-) Jak już znajdziemy to, co nas interesuje, to możemy kliknąć „download” i przy odrobinie szczęścia po chwili będziemy posiadaczami wymarzonego pakietu.

Następnym krokiem jest rozpakowanie pliku, który pobraliśmy. Potrzebne jest do tego narzędzie SAPCAR. Do pobrania z serwisu SAP. Tutaj jest trochę łatwiej. Przebijamy się przez menu, aby dojść do miejsca „Search for Support Packages and Patches” i w polu „Search” wpisujemy „SAPCAR”. Klikamy na odpowiednią wersję, wybieramy platformę i pobieramy pakiet. Co ciekawe, wersja dla Linuksa także ma rozszerzenie .exe, ale jest to najzwyklejsza binarka w formacie ELF.

Dobra, mamy dwa upragnione pliki i coś z nimi teraz trzeba zrobić. Na początek zmieńmy atrybuty sapcara:
chmod 755 ./SAPCAR_0-10003688.exe
Tutaj drobna uwaga: Jeżeli próba uruchomienia tego ostatniego spowoduje wywalenie błędu "./SAPCAR_0-10003688.exe: error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory" to oznacza, że musimy doinstalować pakiet zgodności o nazwie „compat-libstdc++-33„.

Rozpakowujemy archiwum z instalką RFCSDK:
./SAPCAR_0-10003688.exe -xvf ./RFC_25-10004432.SAR

W wyniku dostajemy katalog rfcsdk, który trzeba gdzieś skopiować. Na przykład do /usr/sap.
Żeby to wszystko chciało działać, musimy jeszcze utworzyć plik sap.conf w katalogu /etc/ld.so.conf.d i wpisać do niego dwie linijki:
/usr/sap/rfcsdk/lib
/usr/sap/lib


Wywołanie sapinfo powinno dać w wyniku mniej-więcej coś takiego:

[kbechler@sv bin]$ /usr/sap/rfcsdk/bin/sapinfo -v
This RFC library belongs to the SAP R/3 Release *** 700,0,239 ***
Versions of SAP internal libraries:
dptr: 2
ni : 38
cpic: 3
rfc : 3
Compiled by compiler version:
3.3.3 (SuSE Linux)
[kbechler@sv bin]$

Ale po co to wszystko? Ano po to, żeby móc monitorować systemy SAP za pomocą Nagiosa i tego skryptu(1).

Skrypt wywołuje się mniej-więcej tak:

[kbechler@sv /]# /usr/lib/nagios/plugins/check_sap_rfcping.pl -a 192.168.0.1 -s 10 -w 50 -c 200
RFCPING OK - No Problems found, AvgRTT=1 ms (SAPF001_SF1_10)
[kbechler@sv /]#


Konfiguracja Nagiosa:

do pliku ’commands.cfg’ dodałem wpis:

define command{
command_name check_sap_rfcping
command_line $USER1$/check_sap_rfcping.pl -a $HOSTADDRESS$ -s $ARG1$ -w 50 -c 200
}


Potem zdefiniowałem serwis, który będzie monitorował PINGa:
define service{
use generic-service
host_name sap_sandbox1
service_description SAP RFC PING
check_command check_sap_rfcping!10!-w 100 -c 300
}


I to w zasadzie wszystko. Ruszyło za pierwszym razem (co w IT zdarza się niekoniecznie zawsze ;-))

(1) Żeby skrypt działał, musimy jeszcze pobawić się trochę w linkowanie katalogów: 'ln -s /usr/sap /usr/local/sap'

Tym razem będzie o routerach…

Mam w firmie pudełko, które odpowiada wyłącznie za terminowanie tuneli VPN do klientów. Nic nadzwyczajnego, ot „czarna skrzynka”, która robi swoje i się nie psuje. Ale czasami zdarza się tak, że jakiś tunel przestaje nagle działać, sam się nie umie zestawić ponownie, a „druga strona” twierdzi, że nic nie dotykała i nic nie wie. Najprostszą i najbardziej podstawową metodą diagnozowania takich problemów jest włączenie na routerze debuga (debug crypto ipsec/isakmp) i oglądanie co się dzieje podczas próby podniesienia tunelu. Problem w tym, że tuneli jest wiele, a ja tylko jeden i od ilości danych, które przelatują nagle przez ekran można dostać oczopląsu. Szczęśliwie Cisco udostępnia bardzo fajną komendę: debug crypto condition peer ipv4 A.B.C.D. Nie robi ona chyba nic więcej, jak tylko ogranicza ilość zbieranych i wyświetlanych przez router informacji do jednego tylko peer’a. I jest to dokładnie to, o co mi chodzi – na monitorze widzę, jak routerki gadają ze sobą i próbują wynegocjować jakieś wartości, które byłby dla obu akceptowalne, a jednocześnie nie muszę oglądać tony innych, w danej chwili zupełnie mi niepotrzebnych rzeczy.

Aha, takie ograniczenie wyłącza się następująco: „debug crypto condition reset”.

Jakoś tak się składało, że przez naprawdę długi czas Linux stanowił dla mnie niemalże wyłącznie platformę serwerową, gdzie konsola była w zupełności wystarczająca. Wobec takiego stanu rzeczy, cały rozwój tego systemu związany ze środowiskiem graficznym mnie, delikatnie pisząc, ominął. Obecnie zacząłem trochę 'eksperymentować’ z graficznym Linuksem i natykam się na dziwne – jak dla mnie – problemy. Przykładowo…

Jak zmusić Firefoksa pod CentOSem do współdziałania z Javą? Okazuje się to nie być aż tak trywialnym zadaniem, jak by się wydawało (czyli kliknąć, potwierdzić i mieć). Zainstalowałem sobie dość standardowego CentOSa, wyposażonego w pełnowartościowy system graficzny kontrolowany przez GNOMEa. Okazało się, że Firefox jako taki był sam z siebie. Ale nie bardzo, OOTB, wspierał Javę.

Po pierwsze pobrałem najnowszą wersję JRE w wersji „Linux RPM”. Co ciekawe, plik, który udało mi się sciągnąć okazał się „prawie” RPMem. Niby w środku RPM, ale dodatkowo opakowany kawałkiem skryptu BASH:
[root@h7-centos ~]# file ./jre-6u20-linux-i586-rpm.bin
./jre-6u20-linux-i586-rpm.bin: Bourne shell script text executable

Po uruchomieniu „instalatora” najpierw wyświetliło licencję, potem się samo rozpakowało a na koniec powiedziało „Done.” :-)

Problem w tym, że wprawdzie Java się niby zainstalowała, ale Firefox jakby nie załapał, że powinien z niej w jakikolwiek sposób skorzystać i w dalszym ciągu marudził, że nie rozumie. Nic to, nie zrażony pierwszym niepowodzeniem, zacząłem szukać, jak to wszystko zmusić do współdziałania. Może cała procedura (nota bene składająca się z jednego polecenia :-)) nie jest jakoś porażająco skomplikowana, ale tak zupełnie oczywista dla mnie na początku też nie była.

Po krótkich poszukiwania okazało się, że Firefox szuka swoich pluginów w dwóch katalogach:
– globalnym, który wpływa na zachowanie przeglądarkidla wszystkich użytkowników korzystających z danego systemu: /usr/lib/mozilla/plugins,
– lokalnym użytkownika: ~/.mozilla/plugins.

Aby pożenić Firefoksa ze świeżo zainstalowaną przeze mnie Javą, musiałem utworzyć dowiązanie symboliczne (w katalogu, w którym FF szuka pluginów) do odpowiedniej binarki Javy. Wyglądało to tak:
[root@h7-centos ~]# cd /usr/lib/mozilla/plugins
[root@h7-centos plugins]# ln -s /usr/java/default/lib/i386/libnpjp2.so ./
[root@h7-centos plugins]# ls -la libnpj*
lrwxrwxrwx 1 root root 38 lip 2 22:06 libnpjp2.so -> /usr/java/default/lib/i386/libnpjp2.so
[root@h7-centos plugins]#

Po restarcie Firefoksa, program nagle zaczął rozumieć Javę i chyba ją nawet trochę polubił :-)

P.S. Dokładnie tak samo należy postąpić z niedziałającym Flashem, linkując do znanego nam już katalogu plik /usr/lib/flash-plugin/libflashplayer.so.

Właśnie konfiguruję serwer terminali oparty o CentOSa i GNOME. Wszystko wygląda całkiem nieźle, ale natknąłem się na pewien niewielki problem: jak pozbawić użytkowników korzystających z tego terminala możliwości wyłączania/restartowania całego systemu? Zostawienie tej opcji włączonej może skutkować dość nieprzyjemnymi objawami w postaci nagłych i niespodziewanych restartów całego serwera, a ja nie lubię się denerwować.

Okazuje się, że jest kilka metod, którymi zły użytkownik może się posłużyć i powinniśmy zneutralizować je wszystkie. Ale po kolei:

1) Ikonki „Uruchom ponownie” oraz „Wyłącz” widoczne na ekranie logowania (GDM).

To akurat wyłącza się wyjątkowo prosto:
W sekcji [greeter] pliku /etc/gdm/custom.conf musimy dopisać linijkę
SystemMenu=false i zrestartować X’y. Koniec.

Po takim zabiegu ikony służące do denerwowania administratora znikną z ekranu powitalnego raz na zawsze (albo do ponownego włączenia).

2) Menu systemowe GNOME.

Uruchamiamy gconf-editor (jeżeli nie mamy go w systemie, to trzeba sobie doinstalować: yum install gconf-editor), i w gałęzi /apps/panel/global zaznaczamy opcję „disable_log_out„. Nazwa jest trochę myląca, bo samej możliwości wylogowania z systemu nie wyłącza, ale robi to, co mi potrzebne a ja nie muszę chyba wszystkiego rozumieć :-)

3) Zablokowanie możliwości wywołania „poweroff” lub „reboot” z terminala.

Domyślnie CentOS (zamiast kombinować z flagą SUID) dość intensywnie korzysta z programu consolehelper(*) i właśnie w jego konfiguracji będziemy grzebać. Wszystkie programy, które mogą być uruchamiane przez zwykłych użytkowników z prawami roota zdefiniowane są w dwóch katalogach:
/etc/security/console.apps oraz /etc/pam.d

Aby wyłączyć (brutalnie, ale skutecznie) użytkownikom możliwość denerwowania innych, należy z pierwszego z podanych katalogów (czyli /etc/security/console.apps) usunąć pliki „reboot„, „halt” oraz „poweroff„. Warto jeszcze usunąć dowiązania symboliczne do samego consolehelpera z katalogu /usr/bin (bez usuwania linków użytkownikom, zamiast „nie ma takiego pliku…” wyświetlać się będzie okienko „Nieznany błąd”, co wygląda mało profesjonalnie :-)).

I to chyba wszystko. Po krótkich staraniach nie udało mi się zdalnie wyłączyć systemu nie posiadając uprawnień roota :-)

(*) Trochę więcej o programie consolehelper można poczytać sobie tutaj.

Możliwość pracy na oddalonym o setki kilometrów systemie już nikogo nie dziwi. Do administracji serwerami pracującymi pod kontrolą Linuksa w zasadzie wystarcza klient SSH (np. Windowsowe PuTTY), do tych, które kontroluje oprogramowanie Microsoftu używamy klienta RDP. A jeżeli chcemy połączyć pingwina z obrazkami (czyli wyświetlić na swoim monitorze zdalną sesję X’ów), to wykorzystujemy VNC lub FreeNX/NoMachine NX.

Jest jednak jeszcze jedna możliwość: Można uruchomić „pod” Windows serwer X’ów i podpinać do niego programy, które uruchamiamy na innych maszynach. Do przeprowadzenia eksperymentu będą nam potrzebne:
– klient SSH: PuTTY,
– serwer X: Xming,
– jakaś (zdalna) maszyna z zainstalowanym i (odpowiednio) skonfigurowanym Linuksem.

Po pierwsze instalujemy i uruchamiamy Xminga (na razie wystarczy sam serwer, nie będziemy korzystać z dobrodziejstw XLaunch). W zasobniku systemowym (system tray) powinna pojawić się ikonka informująca o tym, że serwer X jest gotowy do działania.

Po drugie odpalamy PuTTY i łaczymy się ze zdalnym hostem za pomocą SSH. Tutaj ważna uwaga: w menu „Connection” -> „SSH” -> „X11” musimy „zakliknąć” opcję „Enable X11 forwarding”.

Po trzecie, po zalogowaniu do serwera uruchamiamy w shellu zegarek albo cokolwiek innego. Po chwili wybrana aplikacja powinna nam się automagicznie pojawić na (lokalnym) ekranie. Wygląda to mniej-więcej tak:

Xming potrafi oczywiście o wiele więcej, ale po szczegóły odsyłam do dokumentacji ;-)

…to genialny program do oglądania i wstępnej obróbki fotek. Posiada chyba wszystko, czego można sobie zażyczyć. Potrafi wyświetlać, obracać (o dowolny kąt), skalować (zachowując proporcje lub nie),  zmieniać ilość kolorów, zredukować efekt czerwonych oczu i wszystko to, co potrafią także inne programy. Niby nic nadzwyczajnego. Ale ma też opcję przetwarzania hurtowego (batch), która przy dużej ilości zdjęć się bardzo przydaje. A co poza tym? Ma sporo różnych fajnych pluginów (np. JPEG lossless crop), które bardzo ułatwiają życie. I, oczywiście, jest darmowy :-)

A oto, co można zrobić w trybie wsadowym:

Właśnie dostałem maila od serwisu FreeDNS, że decyzją władz SGH (czyli właściciela serwerów) usługa zostaje wyłączona. Było to chyba najlepsze w naszym kraju miejsce, gdzie można było utrzymywać serwery DNS – w dodatku zupełnie za darmo.

Szczęśliwie, uczelnia (pomimo regulaminu, który stanowi o możliwości zakończenia działania serwisu bez uprzedzenia i w dowolnym momencie) dała użytkownikom 60 dni na przeniesienie swoich dóbr na w inne miejsca. I bardzo się z tego cieszę, bo nie ma chyba nic gorszego, niż „zniknięta” domena.

Będę musiał w najbliższym czasie poszukać innego miejsca, które przygarnie moje zasoby. Przed tym samym problemem staną właściciele ponad 51 tysięcy innych domen, które serwuje FreeDNS…

Szkoda…

Aktualizacja: Piotr Kucharski, czyli twórca i administrator serwisu zamierza kontynuować projekt (już bez udziału SGH) i przemigrować wszystkie dotychczasowe konta i domeny w nowe miejsce. Mam wielką nadzieję, że akcja się powiedzie. Raz, że jestem tym osobiście zainteresowany (co przejawia się kilkoma domenami, które tam trzymam), a dwa, że życzę Piotrowi jak najlepiej.

Jestem szczęśliwym posiadaczem odtwarzacza MP3 SanDisk Sansa Clip. Producent dostarcza do niego niewielkie oprogramowanie, które zainstalowane na komputerze informuje, czy nie pojawiła się przypadkiem aktualizacja oprogramowania (i wyświetla reklamy :-)). Kilka tygodni temu SanDisk wypuścił aktualizację, ale dopiero wczoraj udało mi się kliknąć w odpowiednie miejsce i ją zainstalować.

Problem w tym, że po założeniu słuchawek okazało się, że mój Clip gra dużo ciszej, niż do tej pory. Zacząłem przeglądać menu urządzenia, bo wydawało mi się, że gdzieś widziałem opcję „volume: normal/high”, a wgranie nowej aktualizacji powoduje zresetowanie urządzenia do ustawień fabrycznych. Niestety, nigdzie czegoś takiego nie znalazłem. Sprawdziłem słuchawki na innym urządzeniu – grały poprawnie.

Nie mam nic przeciwko cichej muzyce, ale jadący pociąg (w którym się akurat znajdowałem) znakomicie zagłuszał wszystko, czego chciałem posłuchać, pomimo ustawienia poziomu głośności na maksimum. Moje KOSSy nie należą do bardzo cichych słuchawek, więc zdecydowanie był to problem odtwarzacza. Coś się zmieniło i nie bardzo wiedziałem, co to mogło być.

Zacząłem szukać w Sieci i znalazłem to. Okazuje się, że jednym ze wspaniałych pomysłów UE jest ograniczenie głośności odtwarzaczy muzyki sprzedawanych w Europie. Super, tylko dlaczego ograniczenie do poziomu, w którym mój Clip stał się bezużyteczny? Z chęcią będę słuchał muzyki tak cicho, jak chce Unia, ale pod warunkiem, że wyciszą mi pociąg :-)

P.S. Sposób na „odblokowanie” Clip’a znalazłem na forum.

Zwykle staram się pisać maile nie używając HTMLa*. Ustawiłem więc sobie mojego Thunderbirda tak, żeby domyślnie tworzył wiadomości jako plain-text. Jednak czasami zachodzi potrzeba wysłania czegoś bardziej kolorowego, niż zwykły tekst. A nie zawsze jest sens „na siłę” upychać załączniki (a ja jestem zdecydowanie za bardzo leniwy, żeby używać WebMaila albo grzebać gdzieś w ustawieniach tylko dla jednego maila). I tutaj z pomocą przychodzi opcja Thunderbirda, której nie znałem…. wystarczy przytrzymać wciśnięty „shift” podczas klikania na ikonkę nowej wiadomości, żeby program na chwilę zapomniał o swoich preferencjach i zaproponował wysłanie kolorowego maila. Działa to także w przypadku odpowiadania na odebrane wiadomości i przesyłania takowych dalej.

Więcej, o żonglowaniau formatami poczty w Thunderbirdzie można poczytać tutaj. Co ciekawe, można tu także przeczytać: Unfortunately, this doesn’t work for „Forward”. , ale w przypadku mojego egzemplarza jednak działa.

*) bo HTML to zło. Mniejsze, niż topposting, ale w dalszym ciągu zło ;-)