Miesiąc: listopad 2014

Opublikowane w

Testowanie szybkości kluczy Zabbix agenta

Było tak, że jeden z kluczy w Zabbiksie działał wolno. Nawet: bardzo wolno. Ile czasu może się wykonywać proste sprawdzenie wersji programu typu chef-client -v, nawet na umiarkowanie dobitym systemie? Zainteresowani znajdą odpowiedź na końcu wpisu[1], dość powiedzieć, że czasami załączał się timeout po stronie zabbix agent. Problem został rozwiązany w sposób najdoskonalszy, czyli poprzez zrzucanie wartości z crona do pliku, i czytanie jej z pliku, ale niesmak pozostał. Poza niesmakiem, pozostało pytanie które jeszcze klucze są nieoptymalne?

Ponieważ na ten moment Zabbix nie daje możliwości sprawdzenia statystyk czasu zapytań dla poszczególnych kluczy, wykonałem małą protezę w postaci skryptu w Perlu, który odpyta danego hosta o wszystkie klucze kilka(naście) razy i policzy dla nich statystyki. Wklejka poniżej.

 

Skrypt przyjmuje dokładnie jeden parametr – hosta na którym będzie przeprowadzać test. Poza tym, wymaga wszystkich kluczy dla danego hosta, które ma testować, w pliku określonym w zmiennej $file. Na końcu wyświetli łączny czas wykonania zdefiniowanej ilości zapytań dla każdego klucza wyrażony w sekundach oraz sam klucz. Czytaj: pewnie chcesz przepuścić wynik przez sort -n. 😉

Parę rzeczy, które wyszły w trakcie pisania tego skryptu lub których się nauczyłem (w sumie gdyby nie one, to nie powstałby ten wpis):

Pętla sprawdzające N razy wszystkie klucze po kolei jest dokładniejsza od pętli, która sprawdza kolejno wszystkie klucze N razy każdy. Chodzi o rozkład obciążanie na maszynie, w tym drugim przypadku jest większa szansa, że któryś klucz trafi w nietypowe obciążenie maszyny.

Dokumentacja do modułu Time::HiRes jest… taka sobie. Można to zrobić prościej, jak wyżej. Początkowo kombinowałem ze sprintf oraz clock_gettime(CLOCK_REALTIME);

Może zastanawiać, skąd mnożenie przez 1000000. Otóż chodzi o bug z zapisem liczb zmiennoprzecinkowych (kojarzyłem to raczej z ośmiobitowców i dzielenia, nie wiem czy słusznie…):

perl -e '$a=1415907504.646884; $b=1415907504.603042; $d=$a-$b; print $d,$/'

vs.

perl -e '$a=1415907504.646884*1000000; $b=1415907504.603042*1000000; $d=($a-$b)/1000000; print $d,$/'

Że tak zacytuję real programmers use integer. 😉

Na koniec niezła wiadomość: jest szansa, że w przyszłości Zabbix będzie miał coś w stylu MySQLowego slowloga, czyli nie będzie trzeba robić testów na poszczególnych hostach, tylko będzie wbudowane narzędzie do wykrywania wolnych zapytań. Można głosować na ten feature. 😉

Specjalne podziękowania za uwagi i wyjaśnienia dla Tona z #perl @ IRCnet (thanks Ton!).

I wracając do pytania o nieoptymalne klucze z początku wpisu – tylko nieszczęsny chef-client okazał się być czarną owcą. Pozostałe klucze, choć czasem wymagają uruchomienia Perla lub kilku poleceń w Bashu, wykonywały się w zdecydowanie przyzwoitym czasie, grubo poniżej sekundy.

[1] Wykonuje się nawet cbanq cvęganśpvr frxhaq (rot13)! Bo na tyle ustawiony był timeout…

Opublikowane w

Własna strona w sieci Tor

Za sprawą normalnych tradycyjnych stron w sieci Tor zrobiło się ostatnio głośno z powodu Facebooka. Nie dość, że Facebook wystawił stronę oficjalnie do sieci Tor pod adresem .onion, to adres był ciekawy, a całość jest dostępna po HTTPS, czyli w wersji szyfrowanej[1]. Mniejsza o powody, dla których to uczynili. Wydaje się, że nie tyle chodziło im o anonimowość użytkowników (nie miejcie złudzeń), co o ich prywatność i bezpieczeństwo (ukrycie lokalizacji). Plus przy okazji rozwiązali sobie problem false positives przy wykrywaniu włamań, które mieli przy użytkownikach korzystających z tradycyjnych exit node[2]. Będzie zatem o własnej stronie w sieci Tor.

Tor logoŹródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Tak czy inaczej, wygląda, że Tor został dostrzeżony przez dużych w z właściwej perspektywy, czyli po prostu jako medium transmisji, a nie odrębna sieć, używana przez złoczyńców[3]. Myślę, że można spodziewać się kolejnych naśladowców.

Warto zauważyć, że to co zrobił Facebook to nie jest typowy hidden service w sieci Tor. W typowym chodzi o ukrycie tożsamości właściciela, miejsca hostowania itp. Czyli masa pracy poświęcona uszczelnianiu systemu i serwera WWW, która nie jest przedmiotem tego wpisu. Na stronie projektu Tor też się tym nie zajmują, ale zainteresowani znajdą tam ogólne wskazówki. Tu przeciwnie – wszystko jest dostępne, a tożsamość jest potwierdzona certyfikatem SSL, czyli wersja znacznie łatwiejsza w wykonaniu.

I właśnie takim przypadkiem zajmę się w tym wpisie. Całość opisana jest dokładnie na stronie projektu Tor. Widzę jednak, że pojawiają się pytania jak to zrobić, więc zamieszczę wersję skróconą i uproszczoną. Tak naprawdę całość sprowadza się do dwóch linii w pliku konfiguracyjnym. Zakładam, że Tor jest już skonfigurowany jako relay node lub bridge node. I nawet nie do napisania, tylko do odhashowania/edycji.

Przede wszystkim w pliku konfiguracyjnym[4] szukamy sekcji dotyczącej hidden services, zaczynającej się od linii:

############### This section is just for location-hidden services ###

Następnie odhashowujemy/edytujemy dwie linie:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 IP_SERWERA_WWW:80

Pierwsza musi wskazywać na katalog, który musi mieć prawa odczytu i zapisu dla użytkownika na którym działa demon Tor. W Debianie wystarczy odhashować.

Druga to wskazanie który port chcemy przekierowywać i na jaki adres oraz port. IPv4 działa na pewno, IPv6 nie udało mi się skłonić do działania. Jedyna zmiana, czy też wymóg konfiguracji po stronie serwera WWW, jest taki, że musi on pozwalać na dostęp do zasobów po IP, bez podania domeny (vhosta)[5].

Następnie należy zrestartować demona Tor i… gotowe. Pozostało jeszcze tylko sprawdzić, jaki adres ma nasz hidden service:

cat /var/lib/tor/hidden_service/hostname

Potem można już tylko zweryfikować działania serwisu za pośrednictwem adresu .onion. Jeśli nie mamy pod ręką normalnego dostępu do Tora, można posiłkować się bramką Tor2web.

[1] I całe szczęście, bo przypominam, że Tor nie szyfruje użycie Tora nie oznacza automatycznie szyfrowania danych. Co więcej, każdy węzeł, ma możliwość przechwycenia całej (co prawda zaszyfrowanej) transmisji. A exit node, jest w stanie podsłuchać nieszyfrowaną transmisję do końcowego hosta.

[2] Więcej w tym wpisie (ANG).

[3] Nie ukrywajmy, typowy użytkownik Tora kojarzył się do tej pory z nielegalnymi działaniami.

[4] W Debianie jest to /etc/tor/torrc, pewnie w Ubuntu i innych pochodnych jest analogicznie.

[5] Tu uwaga dla chcących stawiać bramki hidden service – z punktu widzenia zewnętrznego serwisu (i tylko jego, i tylko w przypadku połączeń poprzez adres .onion) mój klient Tor IP jest teraz exit node! W przypadku nadużyć za pośrednictwem sieci Tor i adresu .onion może się to skończyć wizytą policji. W przypadku serwisów, których nie jesteśmy właścicielami bezwzględnie należy mieć zgodę właściciela serwisu.

Opublikowane w

Wybory samorządowe – głosowanie poza miejscem zameldowania

Byłem przekonany, że w przypadku wyborów samorządowych można głosować tylko tam, gdzie się jest zameldowanym na stałe. Jest nieco inaczej – można się dopisać, choć wymaga to nieco zachodu. IMO nawet więcej, niż nieco, ale wygląda, że się da.

Dokładny opis procedury, wraz z dokumentami i wymaganiami znajdziecie we wpisie dotyczącym wyborów samorządowych na Ulepsz Poznań.

Jak dla mnie trochę przerost biurokracji nad treścią: dwa dokumenty (przy czym deklaracja jest dokładnym powieleniem danych zawartych we wniosku), ksero dowodu osobistego (c’mon, to już wpisanie danych dowodu i okazanie go w urzędzie nie wystarczy?). Do tego dochodzą zaświadczenia z zakładu pracy, akty własności, oświadczenia sąsiadów lub osób wspólnie zamieszkujących. Dużo. Jak dla mnie – za dużo.

Inna sprawa, że nie interesowałem się na kogo głosować, bo byłem przekonany, że i tak głosować nie mogę, więc parcia na pójście na wybory nie mam. Po prostu sobie odpuszczę (choć w sumie samorządowe ważniejsze…), a zamiast tego wyprostuję (w końcu) kwestię stałego zameldowania. Tu też ilość zmian i biurokracji mnie przeraża, będę musiał poszukać jakiejś checklisty co muszę zrobić przy zmianie stałego zameldowania. Węszę hardcore na milion miejsc.

Nawiasem, do prostowania kwestii meldunkowych bardzo zniechęciła mnie dawno temu dezinformacja w UM. Zapytałem w informacji, co muszę zrobić w przypadku meldunku czasowego, usłyszałem, że muszę gonić z książeczką wojskową do WKU. Zapytałem o adres i dostałem… samą ulicę (Bułgarska IIRC). Okraszoną – po moim zapytaniu o dokładny adres – tekstem, że „wszyscy wiedzą, gdzie jest WKU w Poznaniu”. Otóż nie wszyscy mają takie hobby, by studiować lokalizacje WKU w miastach, w których nie mieszkają[1].

[1] Tak, mogłem sprawdzić na necie. Ale wtedy nie miałem netu. I jakby od tego jest informacja w UM, żeby tak podstawowe dane zapewnić. No i nie było to coś, co spędzało mi sen z powiek. Więcej: do niczego ten meldunek czasowy nie był przez lata w praktyce potrzebny. A potem były szumne deklaracje, jak to miłościwie nam panujący znoszą obowiązek meldunkowy. AFAIK nadal nie znieśli, nasi mistrzowie skutecznych działań…