True Solutions

Poniższy problem starych wyjadaczy Javy pewnie nie zaskoczy, ale ja ani za Javą nie przepadam, ani jej zbyt często nie używam, więc lekko mnie zdziwił…

Dzisiaj postanowiłem poprawić drobny błąd przy konwertowaniu maili z HTML na czysty tekst. Poprawa trywialna: kilka wywołań replaceAll() i po kłopocie. Ale…

Po wrzuceniu poprawki na produkcję, przy wysyłaniu maili, pojawił się błąd:

javax.mail.MessagingException: Could not connect to SMTP host: xxxxxxxxxx, port: 25;
nested exception is:
java.net.SocketException: java.lang.ClassNotFoundException: Cannot find the specified class aaaaa.yyyyy

Błąd oczywiście zupełnie nie związany z wprowadzonymi poprawkami.
Okazało się, że ostatnia (zaintalowałem ją wczoraj) poprawka Javy od Apple zmienia nieco zachowanie kompilatora. Klasa potrzebna do zestawienia połączenia SSL (wyżej nazwana aaaaa.yyyyy) jest ładowana dynamicznie przez wskazanie jej jako dostawcy gniazda przy połączeniach SSL:

Security.setProperty( “ssl.SocketFactory.provider”, SSL_PROVIDER );

Pomimo iż w nagłówku pliku z klasą gdzie ww instrukcja się pojawiła widniała dyrektywa:

import aaaaa.*;

Kompilator postanowił nie kompilować potrzebnej klasy, bo nie była ona jawnie użyta. Wcześniej nie było tego problemu i wszystkie klasy wpisane w import były kompilowane, niezależnie czy kompilator wykrył, że są używane, czy też nie.

Rozwiązanie jest oczywiście trywialne – nie należy polegać na wykrywaniu zależności przez kompilator i trzeba ręcznie (jawnie w skrypcie kompilacji) skompilować potrzebne klasy.

IMHO to dość istotna zmiana w zachowaniu kompilatora jak na poprawkę nie zmieniającą nawet numeru wersji (nazwali ją Java for Max OS X 10.6 Update 1)

To nie pierwszy raz, kiedy Apple zaskoczyło mnie poprawką Javy, która spowodowała problemy z naszym systemem.

Postanowiłem zebrać dla potomnych (i dla siebie, w razie jakbym czegoś zapomniał) kilka informacji, które ułatwią używanie tego narzędzia oraz pokać inne potencjalne zastosowania inne niż zdalne logowanie.

Automatyczna autoryzacja

Logowanie do zdalnej maszyny jest trywialne:

ssh -llogin nazwa-serwera

potem podajemy hasło i gotowe. Problem pojawia się gdy hasło wygląda tak:

z7kw=TQksHO!CVGSMXmX#5K42hK@ePMQs6(YS

SSH (na szczęście) nie pamięta haseł, ani nie pozwala podawać ich w postaci przełącznika (wtedy można by zapisać hasło w jakimś skrypcie). Jest jednak proste rozwiązania tego problemu – autoryzacja przez parę: klucz prywatny – klucz publiczny.

Cała operacja sprowadza się do trzech kroków: wygenerowania ww. pary, umieszczenia w ustawieniach użytkownika klucza prywatnego i skopiowania na maszynę zdalną klucza prywatnego.

Nie będę przepisywał sczegółowej instrukcji, którą znajdziecie tutaj: http://www.csua.berkeley.edu/~ranga/notes/ssh_nopass.html

Aliasy

Wpisanie nazwy użytkownika i nazwy serwera jako argumentów polecenia nie jest zbyt kłopotliwe, dopóki nie wygląda to tak (przykład skrajny :) ):

ssh -p 1234 -leustachybrzeczyszczykiewicz serwer-osiemnasty.szafa-trzydziestadruga.siec-szkieletowa.funnela.com

Z pomocą przychodzi plik konfiguracyjny, który dostępny jest pod ścieżką ~/.ssh/config (jak go nie ma, to trzeba sobie zrobić).

Można w nim ustawić na prawdę wiele rzeczy (zachęcam do lektury: man ssh_config ), ale nas w tej chwili interesuje najbardziej trywialna: aliasy.

Po dodaniu takiego wpisu do konfiguracji:

Host s18s32

HostName serwer-osiemnasty.szafa-trzydziestadruga.siec-szkieletowa.funnela.com

Port 1234

User eustachybrzeczyszczykiewicz

HostKeyAlias serwer18szafa32

pan Eustachy, aby dostać się na serwer osiemnasty w trzydziestej drugiej szafie wpisuje po prostu:

ssh s18s32

lub

ssh serwer18szafa32

I nie musi już pamiętać nazwy serwera, numeru portu czy nazwy użytkownika. Przede wszystkim nie musi tego za każdym razem wpisywać.

Przekierowywanie portów

Bardzo przydatną w specyficznych sytuacjach funkcją SSH jest możliwość przekierowania portów dowolnej zdalnej maszyny na komputer lokalny. Rozważmy taki przykład:

Nadgorliwy administrator sieci zablokował praktycznie wszystkie usługi. Nawet HTTP kuleje – nie da się wysłać większej porcji danych POST. Na szczęscie działa SSH. (tak jest skonfigurowana sieć Politechniki Poznańskiej).

My chcemy z takiej sieci zrobić commit SVN ( port: 3690 ) lub połączyć się z bazą danych.

Na pomoc przychodzi oczywiście SSH.

Przy okazji połączenia SSH stawiamy tunel, który mapuje porty jakiejś zdalnej maszyny (np. tej na którą logujemy się przez SSH) na porty lokalne.

W tym celu do pliku konfiguracyjnego dopisujemy linijkę w formacie:

LocalForward <port lokalny> <maszyna zdalna>:<port zdalny>

np:

Host tunnel

HostName serwer-pierwszy.funnela.com

User root

LocalForward 3690 localhost:3690

LocalForward 5432 localhost:5432

LocalForward 8080 router.funnela.com:8080

po zestawieniu połączenia ( ssh tunnel ), możemy połączyć się z komputerem lokalnym na porcie 3690 aby uzyskać połączenie z SVN na serwerze pierwszym. Analogicznie dla Postgresa.

Aby nie mieć w programach klienckich dwóch konfiguracji dla połączenia przez tunel ( połączenie z localhost ) i bezpośrednio, można zastosować prosty trick. Po połączeniu tunelu należy dodać do /etc/hosts wpis, który powiąże nazwę serwera ( serwer-pierwszy.funnela.com ) z adresem 127.0.0.1. Od tej chwili wszelkie połączenia SVN lub Postgres z serwer-pierwszy.funnela.com będą szły przez tunel i zgrabnie ominą firewalla.

Podobnie będą działały połączenia z localhost na porcie 8080, jednak tym razem zostaną przekierowane na zupełnie inną maszynę (router).

SOCKS Proxy

W celu ominięcia firewalla lub w przypadku konieczności połączenia się z użyciem innego zewnętrznego adresu IP, możemy również skorzystać z kolejnej przydatnej funkcji SSH – SOCKS proxy. Podczas nawiązywania połączenia ze zdalnym serwerem, możemy użyć przełącznika -D wraz z numerem lokalnego portu. Podczas takiego połączenia nasz komputer lokalny będzie działał jako serwer SOCKS. Wystarczy teraz w ustawieniach programu klienckiego (lub ustawieniach sieci np. w Max OS X) wskazać, żeby połączenie odbywało się przez serwer SOCKS pod adresem localhost na podanym wcześniej porcie. Możemy teraz cieszyć się połączeniem przekierowanym przez nasz serwer SSH.

Serwer proxy jest znacznie prostszy w konfiguracji niż przekierowywanie portów – nie wymaga konfiguracji każdej usługi oddzielnie. Ma jednak sporą wadę: nie wszystkie programy potrafią korzystać z proxy, więc jego zastosowanie ogranicza się głównie do przeglądarki internetowej.

Oczywiście połączenie przez SSH jest zawsze szyfrowane, więc korzystanie z SOCKS lub przekierowywania portów nie tylko pozwala ominąć blokadę portów w sieci, ale również chroni nas przed analizą pakietów przez dynamiczny firewall bądź przechwyceniem ich przez intruza.

Mamy okazję na małe święto – właśnie puściliśmy rewizję numer 3000 do SVN-a dla naszego projektu zwanego roboczo “Flux”.

Rewizja nr 3000 powędrowała do SVN-a

Wszystkich zainteresowanych efektami commit-ów zapraszamy na blog Fluksa oraz do zapisania się na beta testy.

Dodatkowo przenieśliśmy się na lepszy serwer, co pozwoliło zwolnić z pracy nasz poprzedni serwer deweloperski. Na zdjęciu macierz w roli podstawki, natomiast serwer wystąpił jako nie-odkurzony-jeszcze stolik pod kawę.

Nasz pierwszy testowy serwer IBM wraz z macierzą

Oto specyfikacja tego ciężkiego zestawu (dosłownie)

• 2x Pentium III Katmai
• 512 MB RAM
• 2x SCSI Storage Controller (Adaptec + IBM) RAID 5

Dla wszystkich zainteresowanych tym, co się dzieje wokół projektu Flux, uruchomiliśmy dedykowanego bloga.

Docelowo – blog który aktualnie czytasz – ma być miejscem naszych przemyśleń związanych z szeroko rozumianym biznesem internetowym. Natomiast pozostałe blogi będą precyzyjnie skupiały się przeznaczonej im tematyce.

Zapraszam do lektury!

O co chodzi?

Trudno nie odnieść się do zamieszania jakie powstało w sieci po tym, jak nasza-klasa.pl wprowadziła opłatę za wyświetlanie informacji o tym, którzy z użytkowników n-k odwiedzili nasz profil. Nietrudno przewidzieć reakcję użytkowników portalu – atmosfera wśród nich jest gorąca, wielu na własną rękę rozpoczęło protest, umieszczając w swoich profilach zdjęcia z apelami tekstowymi.

Co sądzą na ten temat specjaliści?

Poziom komentarzy daje jasny obraz o średniej wieku pomysłodawców protestu. Ujawniło się wielu ekspertów, oto kilka ich najciekawszych wypowiedzi (kluczowe fragmenty zostały wytłuszczone):

• specjalista ds. regulacji prawnych:

  mamy prawo do bezpłatnego wglądu w historię odwiedzin naszego profilu

• specjalista ds. modelów biznesowych:

  jest nasz dużo i sądzimy, że n-k może się utrzymać z reklam i innych opłat

• specialista ds. autorytetu

  w ramach protestu ogłaszam ciszę bez logowania się

• specialista ds. komercyjnych sztuk walki

  Wstaw ten obraz do swojego profilu, jeśli jesteś przeciwko komercyjnym chwytom portalu

• specjalista ds. społeczności & web 2.0

  n-k jest portalem społecznościowym i nie powinna pobierać opłat za korzystanie z jego zasobów

Komentarz do wypowiedzi jest chyba zbędny – obrazują jednak one, jak znikoma jest świadomość społeczna na temat funkcjonowania biznesu w internecie.