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”.

Jak zmusić Firefoksa pod CentOSem do współdziałania z Javą? Okazuje sie 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.

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.

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 ;-)

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

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.

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.

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 ;-)

Minęło kilka tygodni i znowu moja wiedza okazała się niewystarczająca do rozwiązania problemu z (innym już) produktem Firmy. Tym razem spróbowałem swoich sił i zacząłem przeglądać strony WWW. Po raz kolejny okazało się, że rozwiązanie problemu jest trywialne, tylko ja taki niedouczony. Ale tym razem zaproponowano mi udział w ankiecie, która pytała jak bardzo mi się podobało szukanie znajdowanie informacji. Niby nic wielkiego, ale urzekło mnie jedno pytanie, na które nie znalem (i nie znam do tej pory) odpowiedzi:

Oficjalną informację o końcu wsparcia można przeczytać tutaj.