Java-package z powrotem w Debianie.

Jakiś czas temu Sun zmienił politykę dotyczącą wydawania swojej wersji Javy, w wyniku czego wyleciała ona zarówno z Ubuntu, jak i Debiana. Użytkownicy zostali z niezaktualizowanymi wersjami, więc obie dystrybucje skierowały swoje zainteresowanie w stronę OpenJDK, która teoretycznie ma zapewnić wystarczającą funkcjonalność. Więcej o sprawie można poczytać tu w przypadku Debiana, oraz tu w przypadku Ubuntu. Ten drugi link zawiera instrukcję co zrobić, żeby mieć bezpieczny system, czyli opis migracji do OpenJDK na Ubuntu (IIRC dokładnie to samo należy zrobić w przypadku Debiana).

Fajnie, że jest wolne rozwiązanie, fajnie, że pewnie projekt OpenJDK dostanie niezłego kopa, jeśli chodzi o rozwój, ale jednak nie wszystkim w tej chwili wystarcza OpenJDK, które jest wolniejsze i… nie zawsze działa poprawnie (ja miałem problem z appletami VNC, które przydają się przy administracji sprzętem, zwłaszcza w przypadku rozwiązań typu KVM…). Wybór był trojaki: instalacja ręczna Javy od Sun, stara, dziurawa wersja albo niedziałanie aplikacji.

Pierwszy wybór jest męczący, jeśli ktoś lubi mieć wszystko w systemie spaczkowane (ja lubię), pozostałe dwa są niezbyt dopuszczalne w praktyce… Cieszy mnie więc reaktywacja projektu java-package (aktualnie dostępny w unstable, jeśli wszytko pójdzie dobrze, będzie we Wheezy), czyli prymitywnego skądinąd narzędzia pozwalającego na zrobienie w prosty sposób pakietu deb z Javą od Sun. Sam fakt spaczkowania oczywiście nie wpływa na działanie w żaden sposób, ale na pewno ułatwi utrzymanie porządku w systemach poprzez włącznie Javy od Sun do systemu zarządzania pakietami, wrzucenie do swojego repozytorium pakietów itp.

Tunele IPv6 od Hurricane Electric i IRC – uwaga przy przeniesieniach!

Od dłuższego czasu byłem – powiedzy, że szczęśliwym, chociaż przy dynamicznym IP miałem uwagi – użytkownikiem IPv6. Jednym źródłem jest tunel od HE, drugim jest tunel IPv6 od czeskiego virtio.cz. Z HE byłem zadowolony, ale AFAIK wymagają publicznego IP na końcówce tunelu (lub zabawy z przekierowywaniem portów – głowy nie dam, czy w ogóle się da, ale powinno się dać). Natomiast rozwiązanie Czechów korzysta z Tunnel6, który bez problemu, OOTB, bez zabaw z przekierowaniem portów przechodzi przez NAT (a akurat taką miałem potrzebę). I tak sobie to wszystko działało parę lat, służąc głównie do połączeń SSH, zapewniając stały adres IP służący dla dostępu IRCa i – w drugim przypadku – robiąc za przejście NAT bez przekierowywania portów na routerze.

Wszystko działało dobrze, do czasu… Niedawno uruchomiony został PoP HE w Warszawie, więc postanowiłem przenieść tam terminowanie tunelu. Pełna treść ogłoszenia wyglądała następująco. Nic nie wróży problemów, prawda? Trochę może boleć konieczność usunięcia i założenia nowego tunelu, ale rozumiem powody. Postępuję zgodnie z instrukcją, tj. usuwam stary tunel (to był błąd! powiadam wam, nie idźcie tą drogą!) i tworzę nowy, terminowany w W-wie. Niby bliżej, ale szału nie ma – opóźnienia do docelowych hostów podobne jak były. Ogólnie – wiele hałasu o nic, spokojnie mogło zostać po staremu, czyli z terminowaniem w Holandii. No ale skoro już zmieniłem, odwrotu nie ma, skoro wszystko działa, to niech tak zostanie…

Wszytko działało. Do czasu. Parę dni temu zauważyłem, że nie mogę się połączyć do serwerów IRC. Co gorsza, i co bardziej podejrzane, w żadnej sieci. Nie działał ani IRCnet, ani Freenode, ani OFTC. Szybka diagnostyka (ogólnie łączność do serwerów jest, wygląda na blokadę portów i to na pierwszym hopie), ticket do HE, ale zanim odpowiedzieli, znalazłem już przyczynę:

Due to an increase in IRC abuse, new non-BGP tunnels now have IRC blocked by default.  If you are a Sage, you can re-enable IRC by visiting the tunnel details page for that specific tunnel and selecting the 'Unblock IRC’ option. Existing tunnels have not been filtered.

Pewnie nawet kiedyś to przeczytałem i zdążyłem zapomnieć. Oczywiście – to już informacja z odpowiedzi z ticketa – przeniesione tunele traktowane są jak nowe, będą miały zablokowany dostęp do IRC (do momentu uzyskania Sage) i tyle. Czyli chwilowo „odwyk” od IRCa.

Cóż, z jednej strony jest to jakiś motywator do powrotu do zrobienia certyfikatu IPv6 od HE (który polecam, bo bawiąc uczy, ucząc bawi), z drugiej strony jest to wylewanie dziecka z kąpielą, bo co to za popularyzowanie przez blokowanie? Zrobienie certyfikatu nie jest problemem (ale – póki co – okazało się niemożliwe w pierwotnie zakładanym wariancie, czyli „bezinwestycyjnie”, opierając się tylko na dostępnych za darmo usługach w sieci, stąd opóźnienie w jego robieniu). Być może skończy się po prostu zakupem domeny…

PS. Tak, wiem, mogę wziąć kolejny tunel od Czechów. Albo od SixXS (który AFAIK też zza NAT od kopa działa). Ale HE obok wad ma zalety. Choćby aktualizacja endpointa wgetem, co sprawia, że wszędzie (*wrt) zadziała.

Debian Squeeze (i wyżej) i niedziałające SNMP.

Jeśli w Debianie Squeeze (i zapewne nowszych) po wywołaniu np. snmpwalk dostajemy wszystko mówiący komunikat:

Unknown Object Identifier (Sub-id not found: (top) -> mib-2)

to należy:

  • zainstalować pakiet snmp-mibs-downloader (wajig install snmp-mibs-downloader)
  • zakomentować linię mibs : w pliku /etc/snmp/snmp.conf
  • podziękować polityce Debiana, która pozwala mieć zupełnie wolny, choć niekoniecznie wystarczający do pracy z urządzeniami sieciowymi, system 😉

Wiem, raczej proste do wygooglania. Zapisuję, bo z trzeci raz dziś tego szukałem, przy czym za pierwszym był gigantyczny WTF?!, bo zawsze działało…