1. Musimy posiadać odpowiedni certyfikat do podpisywania maili. Ponieważ podpisywanie odbywa się za pomocą klucza prywatnego, a potwierdzenia autentyczności można dokonać przy użyciu (ogólnie dostępnego) certyfikatu – musimy takową w jakiś sposób zdobyć.
Można ją kupić w dowolnym centrum, jak np. VeriSign – wtedy będziemy wyglądać bardzo profesjonalnie, a nasz certyfikat będzie automatycznie rozpoznawany przez większość używanych obecnie programów. Jest to jedyna rozsądna opcja, jeżeli chcemy taką funkcjonalność oferować klientom. Jednak do testów wygenerowałem sobie certyfikat podpisany przez moje (światowo niezaufane :-)) centrum. Opisów, jak „zrobić” sobie taką infrastrukturę jest w Sieci całkiem sporo i nie będę tego teraz opisywał.

2. Musimy zebrać certyfikaty użytkowników, do których będziemy wysyłać maile. Szyfrowanie danych odbywa się za pomocą certyfikatu (dostępnego publicznie) i bez niego raczej ciężko nam będzie cokolwiek zrobić. Certyfikaty klientów nie muszą by wygenerowane przez zaufane centrum, a nam zależy wyłącznie na tym, aby klucze prywatne, które są z nimi powiązane, były odpowiednio bezpieczne.

3. Ktoś powinien nam dostarczyć odpowiednie dane, które będziemy wysyłać – w moim przypadku będą to pliki PDF, które wygeneruje SAP lub jakiś inny potwór, którego działania nie rozumiem.

4. Trzeba tego PDFa jakoś zaszyfrować, podpisać i wysłać.

I tu zaczynają się schody… o ile zaszyfrowanie i podpisanie maila jest operacją dość prostą:

cat ./plik.txt | openssl smime -encrypt cert_kogos.pem | openssl smime -sign -signer cert.pem -inkey privkey.pem

to wysłanie tego mailem w taki sposób, żeby było poprawnie wyświetlone w czytniku poczty, nie jest już takie oczywiste.

Próbowałem na różne sposoby, jednak za pomocą „czystej” konsoli nie udało mi się osiągnąć tego, co sobie wymyśliłem. Rozwiązaniem okazało się napisanie prostego skryptu w PERLu, który to wszystko po kolei zrobi:

#!/usr/bin/perl
use MIME::Lite;
use Crypt::SMIME;
 
$wiadomosc = MIME::Lite->new(
        From            => 'moj_adres@gmail.com',
        To              => 'odbiorca@wp.pl',
        Subject         => 'temat',
        Type            => 'TEXT',
        Data            => "Dzien dobry\n\nTRESC\n\n-- \nPozdrawiam,\nKonrad"
);
 
$wiadomosc->attach(
        Type            => 'application/pdf',
        Path            => 'tajne_dane.pdf',
        Filename        => 'tajne_dane.pdf'
);
 
{
    local $/=undef;
    open(MY_PKEY, "certs/moj_klucz.pem") || die "open failed: $!"; $privkey = ;
    open(MY_CERT, "certs/moj_cert.pem") || die "open failed: $!"; $cert = ;
    open(TO_CERT, "certs/cert_odbiorcy.pem") || die "open failed: $!"; $to_cert = ;
}
 
$smime = Crypt::SMIME->new();
$smime->setPrivateKey($privkey, $cert);
$smime->setPublicKey($to_cert);
$tmp = $smime->sign($wiadomosc->as_string);
open(MAIL, "|/usr/sbin/sendmail -t");
print MAIL $smime->encrypt($tmp);
close(MAIL);

No dobra, biblioteka MIME::Lite została tutaj użyta dość osobliwie, bo wcale nie do wysyłania maili, ale jest to najprostszy sposób sformatowania maila przed jego zaszyfrowaniem, na który wpadłem. Poza tym, PERLa właściwie nie znam, a ten kod powyżej to „składanka” z przykładów, które znalazłem gdzieś w Sieci.

Teraz muszę się jeszcze zająć tematem podpisywania samych PDFów. No bo skoro ma być tak super profesjonalnie, to dlaczego nie? :-)

Mamy mało krytyczny serwer, świadczący pewne usługi dla użytkowników. Dopóki działa i robi swoje, nikt się do niego nie dotyka. Ale ostatnio zachciało mi się przejrzeć listę systemów i porobić trochę aktualizacji. Byłem dość mocno zdziwiony, jak po zalogowaniu i wpisaniu „yum clean all”, program zawisł. Dosłownie – nie reagował na nic, poza „kill -9″. Zacząłem przeglądać logi, porównałem konfigurację, wyłączyłem wszystkie pluginy – nadal nic. Następnym krokiem byłoby przeinstalowanie pakietu, ale w tym wypadku było to mało realne (no bo przecież do instalacji potrzebny jest właśnie YUM, który nie działa).
Poszedłem więc odrobinę inną drogą i ściągnąłem sobie ręcznie nową wersję bezpośrednio z repozytorium CentOSa (wget jest jednym z bardziej przydatnych narzędzi w ratowaniu systemu). „rpm -U yum…” i…. wisi!
Okazało się, że uszkodzeniu uległa baza pakietów (a dokładniej, pliki blokad) RPMa. Wystarczyło je usunąć:
rm -f /var/lib/rpm/__db*żeby wszystko wróciło do normy. Warto zapamiętać ;-)

Systemem wykonującym kopie bezpieczeństwa dla wspomnianych przeze mnie systemów jest Linux (konkretnie CentOS w wersji 5). Po przejrzeniu informacji dostępnych w Internecie okazało się, że metod szyfrowania systemów plików nie ma wcale tak dużo. Pierwszym kandydatem był TrueCrypt, którego z powodzeniem używam w wielu innych miejscach (zarówno zawodowo, jak i prywatnie), jednak – z niewiadomych mi przyczyn – był mało stabilny i potrafił wywalić całą maszynę. Znalazłem nawet informację, że problem faktycznie występuje i że zostanie to kiedyś poprawione. Ale potrzebowałem czegoś „na już”, więc zacząłem szukać dalej. Ostatecznie padło na LUKSa. Nie będę się specjalnie rozpisywał, co można za pomocą tego oprogramowania zrobić, bo jest to ładnie opisane na stronie domowej. Ograniczę się jedynie do krótkiej ściągawki, jak wykonać podstawowe czynności.

Załóżmy, że dysk, który chcemy „zaLUKSować” to /dev/sdd1. Podstawowym narzędziem, jakiego będziemy używać to „cryptsetup”.

Sprawdzanie, czy dane urządzenie nie jest już przypadkiem zaszyfrowane:
cryptsetup isLuks /dev/sdd1 2>>/dev/null && echo TAK || echo NIE
Jeżeli poprzednie polecenie dało wynik negatywny (czyli nie jest jeszcze zaszyfrowane), to możemy je „sformatować”:
cryptsetup luksFormat /dev/sdd1
Teraz warto sprawdzić, czy operacja się faktycznie udała i podejrzeć nagłówek LUKSa:
cryptsetup luksDump /dev/sdd1
Nastepnym krokiem jest „otworzenie” zaszyfrowanego urządzenia:
cryptsetup luksOpen /dev/sdd1 bkpPo tej operacji powinno nam się w systemie pojawić nowe urządzenie blokowe, do którego możemy uzyskać dostęp poprzez /dev/mapper/bkp.

Po zamontowaniu możemy sobie obejrzeć jego „stan”:
dmsetup info bkp
Jeżeli wszystko się zgadza (a przynajmniej nie ma żadnych rażących błędów), przystępujemy do tworzenia systemu plików:
mke2fs -j /dev/mapper/bkp

Na koniec wystarczy zamontować system plików w systemie:
mount /dev/mapper/bkp /mnt/usb…i cieszyć możliwością ukrywania naszych ściśle tajnych danych przed światem.

Po zakończeniu zabawy należy oczywiście odpowiednio wszystko pozamykać:
sync
umount /mnt/usb
cryptsetup luksClose bkp

[kbechler@flame .ssh]$ scp kbechler@lupus:~/lico-update.sh ~
kbechler@lupus's password:
lico-update.sh 100% 19KB 18.9KB/s 00:00
[kbechler@flame .ssh]$


Trudne to jakoś specjalnie nie było.

A teraz spróbujmy zrobić to samo, ale z urządzeniem blokowym (bo chcemy zrobić kopię zapasową odmontowanej partycji):

[kbechler@flame .ssh]$ scp kbechler@lupus:/dev/sda2 ~
kbechler@lupus's password:
scp: /dev/sda2: Permission denied
[kbechler@flame .ssh]$


Hmmm, brakuje nam trochę uprawnień :-\
Ale możemy przecież zrobić tak, aby te uprawnienia uzyskać:

[kbechler@lupus ~]$ sudo chmod 644 /dev/sda2


I co teraz?

[kbechler@flame .ssh]$ scp kbechler@lupus:/dev/sda2 ~
kbechler@lupus's password:
scp: /dev/sda2: not a regular file
[kbechler@flame .ssh]$


Upsss….chyba niewiele to dało. Przywróćmy lepiej poprzednie prawa:
[kbechler@lupus ~]$ sudo chmod 64 /dev/sda2

No dobra, to co możemy zrobić? Ano możemy połączyć siłę SSH z wielce użytecznym narzędziem dd oraz potokami:

[kbechler@flame ~]$ ssh kbechler@lupus "sudo dd if=/dev/sda2" | dd of=~/sda2
kbechler@lupus's password:
4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 70.9355 seconds, 29.7 MB/s
4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 75.0957 seconds, 28.1 MB/s
[kbechler@flame ~]$

Tadam!

W zależności od tego, co tak naprawdę przesyłamy, możemy do kompletu zaprosić jeszcze jakiś kompresor:

[kbechler@flame ~]$ ssh kbechler@lupus "sudo dd if=/dev/sda2 | bzip2 -9" | bzip2 -d | dd of=~/sda2
kbechler@lupus's password:
4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 74.1963 seconds, 28.4 MB/s
ex4116480+0 records in
4116480+0 records out
2107637760 bytes (2.1 GB) copied, 107.966 seconds, 19.5 MB/s
[kbechler@flame ~]$

W sumie tyle :-)

Ponieważ kilka dni temu zostałem po raz kolejny wymęczony (tym razem za pomocą ankiety) przez audyt, postanowiłem przyjrzeć się sytuacji na rynku skanerów bezpieczeństwa i spróbować coś u siebie w firmie wdrożyć. Do tej pory najlepiej pracowało mi się z Nessusem i od niego zacząłem. Program wygląda naprawdę fajnie (z ciekawości przetestowałem sobie nawet bezpłatną wersję „dla domu”) i jest jednym z najbardziej popularnych skanerów. Ma tylko jedną wadę – cena usługi ProfessionalFeed wynosi 1.200 USD rocznie. I nawet pomimo tego, że według mnie Nessus wart jest tych pieniędzy, to jestem dziwnie spokojny, że nie byłoby łatwo przeforsować takiego wydatku. Kolejnym strzałem była Retina. Produkt równie dojrzały i uznany, co Nessus, to i cena dość podobna. Co dalej? Kiedyś był SATAN, ale znalazłem tylko coś, co nazywało się SARA i nie jest już rozwijane. Kolejną witryną, jaką odwiedziłem była strona domowa projektu SAINT. Niestety, w tym przypadku nie znalazłem nawet konkretnej ceny interesującego mnie produktu. Na tym etapie działania wiedziałem, że mam do wybory trzy produkty, z czego jeden znam, lubię i jest prawdopodobnie najtańszy. Ale to jeszcze nie koniec…

Nie wiem skąd się tam wziąłem, ale w pewnym momencie moim oczom ukazała się strona domowa projektu OpenVAS. O ile udało mi się zorientować, jest to fork Nessusa, który rozpowszechniany jest na licencji GNU. Składa się z kilku współpracujących ze sobą modułów i zestawu testów, które stanowią o sile tego rozwiązania. Co ciekawe, same testy (Network Vulnerability Tests) napisane są w języku NASL opracowanym dla Nessua – kolejna rzecz, która mi się spodobała. Postanowiłem zainstalować OpenVASa na jakiejś maszynie i zobaczyć, ile to cudo jest warte. W CentOSie 5.6 instalacja przebiegła bez problemu i po niedługim czasie miałem gotowe rozwiązanie do skanowania swoich zasobów…

Na razie jestem z odkrycia bardzo zadowolony i w wolnych chwilach staram się tego w jakiś sensowny sposób użyć. Pomimo pewnej „toporności” interfejsu (używam Greenbone Security Assistant), wydaje mi się, że zaprzyjaźnię się z OpenVASem na dłużej. Ciekawe tylko, co powiedzą audytorzy, jak zobaczą raporty utworzone w jakimś abstrakcyjnym systemie, który nie jest „ogólnie uznany przez środowisko” :-)

Można, na przykład, skorzystać z takiej instrukcji, ale dla mnie jest ona odrobinę za bardzo skomplikowana, poza tym nie przepadam za rsync’iem.

Alternatywny proces tworzenia własnego repozytorium pakietów w moim przypadku wyglądał tak:

Po pierwsze – w katalogu /mnt/md3 (bo akurat tutaj miałem trochę miejsca)  utworzyłem odpowiednią strukturę katalogów:
[kbechler@sv ~]# tree /mnt/md3/mirror/centos/5.5 -L 2
/mnt/md3/mirror/centos/5.5
|-- addons
|   |-- i386
|   `-- x86_64
|-- centosplus
|   |-- i386
|   `-- x86_64
|-- contrib
|   |-- i386
|   `-- x86_64
|-- extras
|   |-- i386
|   `-- x86_64
|-- os
|   |-- i386
|   `-- x86_64
`-- updates
|-- i386
`-- x86_64

Po drugie – napisałem sobie prosty plik, o taki:


[kbechler@sv ~]$ cat /mnt/md3/mirror/centos55.lftp
open http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/5.5
lcd /home/www/html/centos/5.5
echo CENTOS_OS
mirror -e --verbose=3 --parallel=10 os/x86_64 os/x86_64
mirror -e --verbose=3 --parallel=10 os/i386 os/i386
echo CENTOS_ADDONS
mirror -e --verbose=3 --parallel=10 addons/x86_64 addons/x86_64
mirror -e --verbose=3 --parallel=10 addons/i386 addons/i386
echo CENTOS_EXTRAS
mirror -e --verbose=3 --parallel=10 extras/x86_64 extras/x86_64
mirror -e --verbose=3 --parallel=10 extras/i386 extras/i386
echo CENTOS_UPDATES
mirror -e --verbose=3 --parallel=10 updates/x86_64 updates/x86_64
mirror -e --verbose=3 --parallel=10 updates/i386 updates/i386
echo CENTOS_CENTOSPLUS
mirror -e --verbose=3 --parallel=10 centosplus/x86_64 centosplus/x86_64
mirror -e --verbose=3 --parallel=10 centosplus/i386 centosplus/i386
echo CENTOS_CONTRIB
mirror -e --verbose=3 --parallel=10 contrib/x86_64 contrib/x86_64
mirror -e --verbose=3 --parallel=10 contrib/i386 contrib/i386
exit

Po trzecie – w katalogu /etc/cron.daily utworzyłem skrypt, który wywołuje polecenie:

lftp -f /mnt/md3/mirror/centos55.lftp > /var/log/mirror_centos55.log

Po czwarte – skonfigurowałem Apache’a na ten maszynie tak, aby link „http://sv/centos” wskazywał na katalog /mnt/md5/mirror/centos.

Po piąte – poczekałem, aż skrypt z crona zrobi swoje i na lokalnym serwerze będę miał aktualną kopię wszystkich pakietów. Tutaj drobna uwaga: przy wolnym łączu do internetu trzeba albo sprytnie napisać skrypt do synchronizacji, albo uruchomić tą ostatnią „z palca”, a skrypt dopisać do crona po jej zakończeniu. W innym wypadku możemy się natknąć na race-condition, w którym kolejne wywołania „zazębią” się ze sobą (o ile pierwsza synchronizacja nie zakończy się w ciągu 24h).

Po szóste (i ostatnie)  – poprosiłem wszystkie moje systemy, aby pobierały aktualizacje z nowo utworzonego repozytorium. Polegało to na tym, że wywaliłem standardową zawartość katalogu /etc/yum.repos.d i wrzuciłem tam poniższy plik:

[kbechler@sv ~]$ cat /etc/yum.repos.d/centos.repo
[base]
name=CentOS-$releasever - Base
baseurl=http://sv/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[updates]
name=CentOS-$releasever - Updates
baseurl=http://sv/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[addons]
name=CentOS-$releasever - Addons
baseurl=http://sv/centos/$releasever/addons/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
[extras]
name=CentOS-$releasever - Extras
baseurl=http://sv/centos/$releasever/extras/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#additional packages that extend functionality of existing packages
[centosplus]
name=CentOS-$releasever - Plus
baseurl=http://sv/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#contrib - packages by Centos Users
[contrib]
name=CentOS-$releasever - Contrib
baseurl=http://sv/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5

I to tyle – od momentu wykonania tego powyżej, wszystkie moje maszyny instalują i aktualizują pakiety z lokalnego repozytorium. Dzięki temu zaoszczędziłem odrobinę ruchu (co akurat nie jest w moim przypadku specjalnie ważne), oraz uprościłem konfigurację samej sieci – większość z tych maszyn nie „wystaje” na zewnątrz i konfiguracja NATa stała się zbędna.

Przykład: Debian służący jako serwer WWW na którym miałem okazję ostatnio grzebać. Niestety, webmaster zapomniał, że czasami warto czyścić katalogi, w których serwis zapisuje dane sesji użytkownika. Efekt? Proszę bardzo:
k@m:~/domains/xxx/public_html/cache$ ls -1 | wc -l
594013
Już samo listowanie takiego katalogu jest bardzo uciążliwe. A co ma powiedzieć serwer, które operuje na zawartych w nim plikach i tworzy kolejne? Po znalezieniu kilku takich „kwiatków” przestałem się dziwić, że maszyna działała wyjątkowo niestabilnie. Nawet biedny tar nie był w stanie zrobić kopii bezpieczeństwa takiego katalogu…

OK, ale co możemy z taką sytuacją zrobić? Po pierwsze spróbować przywrócić normalność, czyli wyrzucić wszystko, co się w tym katalogu znajduje.

Upsssss….
k@m:~/domains/xxx/public_html/cache$ rm ./*
bash: /bin/rm: Lista argumentów za długa
Chyba ilość plików przeraziła basha :-)

Spróbujmy więc inaczej:

k@m:~/domains/xxx/public_html/cache$ find . -type f | xargs rm
[tutaj musimy uzbroić się w cierpliwość]

k@m:~/domains/xxx/public_html/cache$ ls -1 | wc -l
0

Ta-dam :-)

Po drugie – grzecznie (ale stanowczo) poprosić webmastera, żeby poprawił swój portal i sprzątał po sobie śmieci.

A po trzecie – tak na wszelki wypadek – dorzucić do crona coś takiego:

find /home/www/domains/xxx/public_html/cache/* -mtime +10 | xargs rm

Konkluzja: Warto zaznajomić się z poleceniem xargs i ideą potoków, bo czasami narzędzia, które uważamy za podstawowe i uniwersalne, odmawiają współpracy.

Mała aktualizacja (rekordu): Inny serwer, ten sam webmaster:
e:/home/domains/yyy/public_html/__sessions__# ls -1 |wc -l
3125242


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.

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'

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.