Jak biec dalej nawet blisko?

W Biedronce pojawiły się napoje na bazie napojów owocowych. Czyli głównie woda, trochę soków, przy czym tych bardziej eksponowanych na opakowaniu naprawdę mało. Do tego dodatki a’la energy drinki – witaminy, kofeina. Tak czy inaczej, wróżę im sukces – zgrabne i ładne opakowanie, pojemność 369 ml, czyli tak akurat, niewygórowana cena. Czasem kupuję, bo upały. Dziś patrzę na opakowanie i widzę:

Jak biec dalej nawet blisko?

Źródło: fot. własna.

Jak biec dalej nawet blisko? Jak mieć refleks szybciej? Jak być wypoczętym bez przerwy? Nie wiem w jakim to języku, ale przy pierwszym nawet nie mogę się domyślić, o co chodzi, a o wersji oryginalnej nawet nie śmiem wnioskować. Niezłe tłumoczenie.

UPDATE: W Piotrze i Pawle też występują, różnią się opakowaniem, ale zawartość i producent identyczne. Jak ktoś chce poczytać więcej, to tu jest strona produktu.

Owoc żywota twojego je ZUS?

Niecały tydzień pozostał do zakończenia najważniejszego IMO w tym roku głosowania w Polsce. Chodzi oczywiście o wybór pomiędzy OFE a ZUS. Jest to jedna z niewielu okazji do opowiedzenia się jasno za lub przeciw polityce rządu (o mądrym niegłosowaniu w tradycyjnych wyborach pisałem wcześniej). Rządu, który najpierw dał możliwość wyboru miejsca, gdzie lokujemy – niestety obowiązkowo – zarobione pieniądze, a następnie tę możliwość odebrał, zabierając połowę odłożonych przez nas składek do ZUS.

Nie ma co mieć złudzeń. Na efekt końcowy, czyli wysokość emerytury, wybór jednej lub drugiej opcji jest praktycznie pomijalny. W najbardziej pesymistycznym wariancie możemy stracić 15% składki emerytalnej. Najbardziej optymistyczny wariant trudno przewidzieć. Skuteczność inwestowania i gospodarność ZUS jest znana, więc OFE naprawdę IMO musiałyby się postarać, by wypaść gorzej. Z drugiej strony tego typu zagrywki rządu i zmiana otoczenia ekonomicznego nie poprawiają OFE warunków działania.

Niemniej, jak pisałem wcześniej, decyzja dla większości jest głównie polityczna. Kontrowersji wokół sprawy jest więcej. Nie chodzi tylko o zabranie połowy pieniędzy z OFE do ZUS. Dochodzi do tego wariant domyślny czyli zmiana dokonanego przez obywateli wyboru (pomijam tych, którzy nie wybierali OFE, tylko zdali się na losowanie). OFE otrzymały również zakaz reklamowania możliwości pozostawienia u nich składek. Czyli mamy cenzurowanie prywatnych przedsiębiorstw i podejście rządu wybory będą powtarzane tak długo, aż wybierzecie co chcemy. Bo może zapomnicie wybrać, a wtedy wybieracie nasz wariant.

Decyzja podejmowana nie jest na zawsze. Będzie można zmienić wybór za 2 lata, a potem co kolejne 4 lata. Natomiast aby jasno uzyskać efekt sprzeciwu przeciw polityce rządu należałoby zagłosować już teraz. Brak dokonania wyboru do końca lipca oznacza przeniesienie wszystkich składek do ZUS. Nie warto czekać do ostatniego dnia. Do tej pory wyboru dokonała tylko niewielka liczba uprawnionych osób, co może oznaczać kolejki w urzędach ZUS, szczególnie pod koniec miesiąca.

Po szczegóły typu wyliczenia, wzór deklaracji i inne źródła odsyłam do subiektywnego, ale solidnego wpisu OFE czy ZUS. Większość danych na końcu ww. wpisu plus bardzo dobra „bibliografia”, czyli odnośniki do innych źródeł w temacie.

Tails 1.1 wydany, 0day w Tails

We wtorek pojawiła się informacja o tym, że wydana została wersja 1.1 dystrybucji live Linuksa ułatwiającej zachowanie anonimowości w internecie poprzez użycie sieci Tor. Dużą zmianą jest zmiana wersji Debiana, na której Tails bazuje. Do tej pory był to Squeeze, obecnie jest to (w końcu!) Wheezy. Tradycyjnie sporo aktualizacji bezpieczeństwa. Nowy obraz iso jest większy o ok. 60 MB od poprzednika.

Skoro o aktualizacjach bezpieczeństwa mowa, to autorzy dystrybucji napisali o rzekomo odkrytych błędach 0day w dystrybucji. Wszystko wskazuje na to, że faktycznie istnieją. Błędy póki co nie zostały im ujawnione, ale ma to nastąpić w ciągu tygodnia. Otrzymali również zapewnienie, że błędy nie zostaną opublikowane, dopóki nie zdołają ich naprawić, a użytkownicy będą mieli szansę na aktualizację oprogramowania:

They informed us that they would provide us with a report within a week. We’re told they won’t disclose these vulnerabilities publicly before we have corrected it, and Tails users have had a chance to upgrade. We think that this is the right process to responsibly disclose vulnerabilities, and we’re really looking forward to read this report.

Tymczasem można pobrać wersję 1.1, która – jakkolwiek podatna – posiada naprawione inne błędy.

Dostępne wszystkie kody źródłowe dla Banana Pi

Developerzy postąpili zgodnie z zapowiedziami i udostępnili wszystkie kody źródłowe do Banana Pi. Są pierwsze doniesienia na forum o sukcesach z akceleracją GPU oraz potwierdzenia, że karta sieciowa działa na 1 Gbps na otwartym sterowniku. Nieoficjalnie słyszałem o prędkościach 520 Mbits/sec i 697 Mbits/sec (iperf; zależy czy serwer czy klient na bpi). Jak widać więcej, niż maksymalna przepływność USB. Czyli Raspberry Pi ma się coraz bardziej czego obawiać.

Biorę się do klonowania repozytoriów. 😉

Dell deanonimizuje Bitcoiny

Niedawno Dell ogłosił, że akceptuje transakcje przy pomocy Bitcoin. Mało tego, dają 10% rabatu na transakcje z użyciem BTC (do $150). Na pierwszy rzut oka jest to dobra wiadomość dla sympatyków BTC i popularyzacji Bitcoin ogólnie, ale mi się od razu zapaliły lampki ostrzegawcze. W szczególności:

We’re piloting bitcoin, the world’s most widely used digital currency, as a purchase option on Dell.com for consumer and small business shoppers in the U.S.

Czemu tylko USA? Jedną z wad Bitcoin jest możliwość prześledzenia całej historii przemieszczania się waluty, czyli zupełna kontrola przeprowadzanych transakcji. Zamawiając sprzęt z dostawą, wiążemy konto BTC (przynajmniej jedno z kont) z naszą tożsamością.

Oczywiście U.S. only może wynikać z tematów formalnych, prawnych czy organizacyjnych, ale zastanawiam się, czy nie wiąże się z łatwością/jakością śledzenia lub obszarem zainteresowania. W sumie rozsądniej byłoby zbierać dane globalnie, nawet obarczone jakimś błędem.

Oczywiście anonimowość (pozorna?) to tylko jeden z aspektów kryptowalut. Niekoniecznie najważniejszy.

Uroki korzystania z telefonu starego typu na przykładzie pobierania aplikacji moBILETu

Od początku lipca zmieniły się ceny biletów w Poznaniu[1]. Jestem przekleństwem sprzedawców telefonów GSM i od 6 lat mam niezawodny telefon Nokia 3110c. Z Javą. Bateria od początku ta sama, trzyma tydzień, ale mniejsza. Próbowałem zaktualizować cennik dla Poznania – system wykonał błąd itp. komunikaty. „OK, bywa” – myślę. Spróbowałem parokrotnie, w różnych dniach – to samo. Stwierdziłem, że zaktualizuję aplikację, tym bardziej, że w sumie nie wiem, czy to mój system wykonał błąd, czy moBILETu.

Przypomnienie hasła działa OK, teraz możesz się zalogować. Natomiast loginu nie sposób przypomnieć, a zalogować można się tylko jednym, wybranym kiedyś sposobem i może to być numer telefonu, adres email (który?), login (jaki?). A może błędne hasło, bo jeszcze coś się nie zaktualizowało? Nie wiadomo, bo komunikat to Niepoprawne hasło lub nazwa użytkownika. Proszę sprawdzić wpisywane dane. Skądinąd słuszny, ale czemu nie ma możliwości przypominania loginu? Np. wysyłanie go na adres email podany w systemie (hasło można przypomnieć tylko na komórkę, więc wysyłanie loginu na komórkę to słaby pomysł w przypadku jej przejęcia).

OK, w końcu zalogowałem się. Wybieram pobranie aplikacji, przepisuję CAPTCHA. Bo nie ma po prostu „pobierz”, jest personalizowany, unikatowy link, pod konkretny model telefonu (moBILET ma te dane u siebie) ważny 30 minut[2]. Kiedyś przysyłano SMS pobierający aplikację od razu na komórkę. Teraz nie. Zwykły SMS z linkiem. O takim: http://p.mobilet.info/ota/m/?DQ2OFQPTHN Zastanawiam się, jaki piękny umysł na to wpadł. Po pierwsze, na telefonach starego typu nie ma multitaskingu, więc trzeba gdzieś zapisać na boku. Po drugie, klepanie 43 znaków klasy wielkie, małe litery i znaki specjalne na komórce starego typu (a wiedzą, komu wysyłają linka) to szczyt ergonomii.

I część najlepsza: po dobraniu się do linka dostajemy Server not found (to już komunikat z desktopa). A czemu? Ano temu, że domena p.mobilet.info nie istnieje. Gwoli ścisłości, mobilet.info też nie istnieje. I wygląda na domenę dostępną do rejestracji. Ciekawe czy byłby to dobry sposób rozsyłania malware’u?

Normalnie wronan groteska! A bilet muszę kupić papierowy.

[1] Na absurdalnie drogie, więc korzystam z tego, że nie muszę korzystać z komunikacji miejskiej i poruszam się inaczej, głównie pieszo/rower, a z moBILETu nie korzystam już praktycznie, ale warto mieć bilet pod ręką. Nie to jednak jest przedmiotem notki.

[2] Można to (było) obejść o czym pisałem w notce o zabezpieczeniach moBILETu, ale zachowujmy się jak cywilizowani ludzie.

Banana Pi – krótka recenzja

Jak wspomniałem, zamówiłem Banana Pi. Zamówienie na Aliexpress, cena – 50 dolarów z wysyłką do Polski. Zdziwieniem i niejakim problemem był fakt, że mało kto na Aliexpress obsługuje PayPala. Przynajmniej ze sprzedających Banana Pi z darmową wysyłką. Tu porada – WBK oferuje coś takiego jak karty internetowe. Tanie, bezpieczne (prepaid), wygodne, ekologiczne (są wirtualne, otrzymujemy tylko PDF, bez plastiku), działają. Można doładowywać. Polecam.

Sprzęt przybył do mnie do domu 14 dni od dokonania płatności. Trochę szczęścia, bo kumpel, który zamówił kilka dni wcześniej, dostał równocześnie, a ze śledzenia paczki[1] wynikało, że przyleciały jednym samolotem. Cła itp. nie ma z uwagi na wartość – zwolnione z cła są przesyłki do 150, tylko nigdy nie pamiętam czy euro, czy dolarów.

Jako dystrybucję wybrałem Raspbiana dla Banana Pi 3.0. Nagrałem na kartę microSD Goodram[2] (się naprawiła), podłączyłem identycznie, jak Raspberry Pi, czyli aktywny hub UnitekY-206P, jeden kabel do dysku, drugi do Banana Pi do gniazda zasilania, trzeci (sygnał) z Banana do huba. Włączenie zasilania i… nic.

Odłączyłem dysk, nadal nic. W końcu odłączyłem kabel sygnałowy do huba i… ruszyło. Jest zauważalnie szybciej, niż na rpi. Znajomy podłączał z monitorem i stwierdził, że spokojnie nadaje się do komfortowego przeglądania poczty i WWW (oczywiście bez flasha). Tak na szybko: jest jeden LED, którym można sterować analogicznie jak w rpi, na dodatek umieszczony w miejscu, gdzie go widać. Przygotowany obraz działa, ale szału nie czyni – jest trochę śmieci, które można usunąć, typu pakiety w cache apta. Zgłoszone, pewnie poprawią przy następnym wydaniu.

Nie udało mi się uzyskać działającej konfiguracji z podłączeniem dysku. Zarówno podłączenie kabla sygnałowego do huba, jak i dysku 2,5″ powodują u mnie zgaśnięcie wszystkich LEDów i zwis Banana Pi (prąd jest pobierany, więc nie wyłączenie). Podejrzewałem problem z USB lub ładowaniem modułu kernela (nie wiedziałem jeszcze o naprawieniu się karty microSD). Ale nie, podłączenie samego kabla czy pendrive nie powoduje problemów.

Ostatecznie wziąłem ładowarkę od komórki i podłączyłem Banana do niej, a dysk do huba USB. W takiej konfiguracji działa[3]. Tyle, że tak nie może zostać. Zadałem pytanie na forum o Banana Pi, parę osób odpisało. Nie jestem sam. Wygląda, że albo Banana Pi jest bardziej wrażliwe, albo znaczenie ma feature Raspberry Pi pozwalający na zasilanie po USB (czego Banana Pi nie ma).

Podsumowując, zapowiada się ciekawie, choć pracowicie (znaczy będzie zabawa). Już przytargałem multimetr i będę starał się wyjaśnić o co chodzi z zasilaniem. Parę pomysłów mam, ale brakuje mi kabelków do testów.

Poza tym, developerzy ciężko pracują i przepraszają, że nie opublikowali źródeł sterownika do karty sieciowej (łamiąc GPL, nawiasem). Czyli obecnie 1 Gbit można mieć działający, ale tylko pod warunkiem użycia zamkniętego kernela/modułu, ze źródeł się nie da. Mam nadzieję, że się uwiną szybko, bo Banana Pi zapowiada się ciekawie.

[1] W pozytywnym szoku byłem, jak dzień czy dwa po płatności dostałem maila z numerem przesyłki i mogłem śledzić na stronie Poczty Polskiej.

[2] Wcześniej tradycyjne zdjęcie journala z ext4, zgłoszone devom, dla odmiany przyjęli do wiadomości, więc jest szansa, że kolejne wydania będą przyjazne dla nośników flash by default.

[3] Zwykle, bo czasem w momencie podłączania huba do Banana Pi potrafi zwisnąć. Ale jak wszystko jest podłączone przy starcie, działa OK.

OpenSSL AES benchmark

Mam dostęp do paru różnych maszyn, więc postanowiłem zrobić mini benchmark OpenSSL. Głównie z procesorami ARM. Wraz z kumplem z netu zebrało nam się na porównywanie wydajności różnych sprzętów. Poszło o nierewelacyjne osiągi OpenVPN na jego Banana Pi (nawiasem, do mnie też już Banan dotarł, wkrótce coś skrobnę).

Wszystkie testy na Linuksie (pochodne Debiana). Warunki niezupełnie „czyste”, bo maszyny normalnie działają (jakieś Xy, zwykłe usługi itp.), ale raczej dobrze oddaje możliwości – różnice między wynikami z netu pomijalne, maszyny raczej się nudzą. Testowane poleceniem openssl speed aes, w przypadku maszyn w których Linux widzi więcej niż jeden procesor, dodane –multi N, gdzie N  to ilość rozpoznawanych przez system rdzeni (z HT).

Na początek, w ramach punktu odniesienia, procesory Intela (testowane na architekturze amd64):

Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz (N=2)

aes-128 cbc     124896.83k   138273.46k   141166.08k   298696.36k   303164.07k
aes-192 cbc     105477.06k   116211.63k   117732.95k   246287.70k   249443.67k
aes-256 cbc      91720.90k    99602.26k   100765.95k   214892.54k   218794.67k

Intel(R) Pentium(R) Dual  CPU  T3400  @ 2.16GHz (N=1)

aes-128 cbc      63276.43k    69732.33k    71320.92k   149509.14k   152286.27k
aes-192 cbc      53920.87k    58297.88k    59832.94k   126354.09k   128532.21k
aes-256 cbc      46232.08k    49934.93k    50964.99k   109278.55k   110320.76k

Intel(R) Atom(TM) CPU D525 @ 1.80GHz (N=4)

aes-128 cbc      30904.81k    46265.24k    53263.58k    55370.66k    55836.67k
aes-192 cbc      28137.17k    40040.66k    45127.08k    46556.50k    47162.91k
aes-256 cbc      29979.57k    36609.58k    39015.17k    39410.69k    39343.52k

Intel(R) Atom(TM) CPU N2800  @ 1.86GHz (N=4)

aes-128 cbc      63529.34k    67116.33k    67479.30k    69077.33k    70063.45k
aes-192 cbc      53305.24k    55930.01k    56726.87k    58294.95k    58384.38k
aes-256 cbc      46324.97k    48419.43k    49031.42k    49620.99k    49569.79k

Intel(R) Atom(TM) CPU N2800  @ 1.86GHz (N=1)

aes-128 cbc      25546.13k    28152.09k    29100.80k    29257.82k    29417.47k
aes-192 cbc      21745.97k    23033.45k    24188.43k    24440.15k    24491.35k
aes-256 cbc      18760.60k    20222.36k    20786.01k    20862.38k    20971.52k

Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (N=2)

aes-128 cbc     139806.09k   153189.03k   157513.39k   329881.60k   336000.34k
aes-192 cbc     118517.33k   128203.82k   131191.81k   279747.24k   283568.81k
aes-256 cbc     102364.69k   110147.39k   111865.51k   240238.25k   242586.97k

Intel(R) Core(TM)2 Duo CPU     E4600  @ 2.40GHz (N=1)

aes-128 cbc      69509.47k    76975.27k    79176.79k   166760.11k   168293.72k
aes-192 cbc      59564.63k    64345.22k    65814.19k   140067.50k   141836.29k
aes-256 cbc      51423.55k    55281.11k    56354.30k   120643.58k   121760.43k

Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (N=4)

aes-128 cbc     152665.50k   160758.55k   162619.56k   162693.12k   160432.13k
aes-192 cbc     128774.61k   134266.73k   136237.23k   136946.01k   136850.09k
aes-256 cbc     111035.63k   113086.31k   115218.09k   115126.95k   115452.59k

Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (N=1)

aes-128 cbc      64605.45k    79469.89k    80944.90k    81767.94k    81679.70k
aes-192 cbc      62476.10k    66903.19k    67975.42k    68745.33k    68009.98k
aes-256 cbc      54233.60k    56778.67k    57951.06k    58175.49k    58541.29k

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (N=4)

aes-128 cbc     178233.37k   197070.14k   202821.72k   204553.22k   203276.29k
aes-192 cbc     155289.71k   164140.12k   164286.98k   167794.69k   170915.16k
aes-256 cbc     134427.71k   141611.71k   145087.32k   145325.74k   144921.94k

Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (N=1)

aes-128 cbc      93122.37k   101039.38k   104341.59k   105117.70k   104237.74k
aes-192 cbc      79544.40k    85362.03k    86720.00k    87005.87k    87758.17k
aes-256 cbc      69556.44k    73458.50k    74518.87k    74227.71k    73815.38k

AMD Sempron(tm) 2300+ (N=1) Test oczywiście dla architekury i386

aes-128 cbc      29157.09k    31077.91k    31887.50k    76258.89k    76728.08k
aes-192 cbc      25055.40k    26304.51k    26871.69k    65190.10k    65563.40k
aes-256 cbc      21279.27k    22447.52k    22859.69k    56840.22k    57122.08k

Tyle jeśli chodzi o procesory Intela, pora na benchmark openssl dla procesorów ARM:

Dockstar. Debian, architektura armel Feroceon 88FR131 rev 1 (v5l) 1,2GHz

aes-128 cbc      14013.23k    16435.69k    16982.28k    17336.92k    17317.89k
aes-192 cbc      12337.22k    14112.71k    15303.21k    14970.88k    14815.53k
aes-256 cbc      10989.90k    12474.70k    12831.67k    13312.00k    13218.91k

Raspberry Pi. Raspbian ARMv6-compatible processor rev 7 (v6l) 700 MHz

 aes-128 cbc      13241.53k    14935.94k    15386.52k    15716.75k    15576.54k
aes-192 cbc      11420.51k    13032.96k    13501.64k    13664.95k    13465.79k
aes-256 cbc      10378.09k    11521.94k    11991.62k    11855.19k    11988.44k

Banana Pi (N=2).

aes-128 cbc      38453.65k    45557.42k    47889.49k    48539.99k    48715.09k
aes-192 cbc      33638.03k    38975.96k    41001.13k    41532.42k    41694.55k
aes-256 cbc      30360.07k    34568.62k    36124.25k    36553.39k    36672.85k

Banana Pi (N=2) Debian armhf

aes-128 cbc      35393.00k    47858.58k    50317.74k    50995.88k    51183.62k
aes-192 cbc      35339.90k    40943.62k    43078.57k    43647.32k    43797.16k
aes-256 cbc      31896.82k    36317.72k    37956.01k    38405.80k    38532.44k

Feroceon 88F6282 rev 1 (v5l) 2,0 GHz

aes-128 cbc     20192.02k     24452.77k    25681.19k    25715.66k    26231.83k 
aes-192 cbc    18020.95k   21192.76k   22311.17k   22520.40k   22832.65k
aes-256 cbc    16372.28k    18963.20k   19705.60k   19748.15k  20109.48k

Cubieboard 3 (N=1)

aes-128 cbc 18192.97k 21387.56k 22688.77k 22623.23k 20960.60k 
aes-192 cbc 17613.03k 18595.58k 19475.20k 19543.38k 19595.26k
aes-256 cbc 15075.22k 16513.19k 17151.57k 17167.36k 17246.89k

Cubieboard 3 (N=2)

aes-128 cbc 40631.59k 43845.70k 44627.97k 45086.38k 45211.65k 
aes-192 cbc 35388.95k 36886.19k 38698.50k 38691.16k 39335.25k
aes-256 cbc 30851.77k 33802.65k 34321.41k 34171.56k 33778.35k

ODROID U3 (N=1)

aes-128 cbc 54399.00k 58485.80k 59575.38k 60536.83k 60385.96k 
aes-192 cbc 47215.06k 50994.73k 52349.35k 52738.73k 52731.90k
aes-256 cbc 41830.65k 44747.37k 45808.98k 46029.82k 45796.01k

ODROID U3 (N=4)

aes-128 cbc 216401.55k 233187.14k 237574.06k 237451.26k 239610.54k 
aes-192 cbc 187925.35k 203781.87k 209056.51k 202832.55k 210911.23k
aes-256 cbc 166399.47k 178351.36k 182334.38k 183437.99k 183795.71k

Jetson TK 1 (N=1)

aes-128 cbc 101615.96k 105911.73k 109555.46k 110431.91k 110553.77k 
aes-192 cbc 87593.79k 92699.41k 95376.04k 96003.75k 96133.12k
aes-256 cbc 76532.53k 80948.01k 83111.77k 83704.15k 83817.81k

Jetson TK 1 (N=4)

aes-128 cbc 400560.99k 417232.81k 426956.88k 411591.68k 423813.12k 
aes-192 cbc 327749.78k 351935.28k 364130.73k 377968.98k 379052.03k
aes-256 cbc 300564.41k 319599.06k 325819.65k 328858.28k 330391.55k

Marvell Armada 370/XP (Device Tree) (N=1)

aes-128 cbc      41961.95k    50546.82k    53594.28k    54535.26k    53449.35k
aes-192 cbc      37750.78k    44366.68k    46631.68k    47299.58k    46623.40k
aes-256 cbc      33172.31k    37925.33k    40553.30k    41431.04k    40962.73k

Marvell Armada 370/XP (Device Tree) (N=4)

aes-128 cbc     166412.45k   201555.37k   213535.57k   217358.68k   213336.06k
aes-192 cbc     149429.29k   177001.39k   186009.77k   189066.24k   186086.74k
aes-256 cbc     131774.20k   151056.06k   161813.59k   165605.38k   163482.28k

Raspberry Pi 3 (N=1; 32 bit OS)

aes-128 cbc      41017.91k    48669.00k    51254.02k    51984.38k    52215.81kaes-192 cbc      35728.01k    41270.60k    43058.26k    43608.06k    43783.51kaes-256 cbc      32115.97k    36434.37k    38004.48k    38426.71k    38482.83k

Jak widać, trochę przepaść między ARM a Intelami w wynikach całkowitych. Dodatkowo sprawę wydajności pogarsza fakt, że OpenVPN nie wątkuje (podobno ma być dodane w wersji 3), czyli klient wykorzystuje tylko jeden rdzeń, co w przypadku Banana Pi oznacza w praktyce połowę podanej wyżej wydajności.

PS. Wpis będzie edytowany/uzupełniany.

UPDATE: dodaję wyniki dla Banana Pi uzyskane osobiście na czystym Debianie w normalnej architekturze armfh. Nie jestem pewien, czy wcześniejsze nie były na „niepełnym” armfh dla Raspbiana robione…

Własna namiastka dyndns

Po ostatniej akcji Microsoftu z przejęciem i zablokowaniem domen należących do No-IP miałem przez moment umiarkowany problem z dostępem do jednej z moich maszyn, bo nie znałem IP. Nic krytycznego i szybko rozwiązałem, ale stwierdziłem, że warto by się zabezpieczyć na przyszłość. Początkowo chciałem uruchomić po prostu innego dostawcę dyndns, z inną domeną, co dałoby całkiem niezłą – jak mi się wydaje – redundancję w tym względzie, ale prowizorycznie uruchomiłem coś innego, własnego i znacznie prostszego. W komentarzu do poprzedniego wpisu padło pytanie co dokładnie zrobiłem, więc opisuję.

Tak się składa, że mam serwer dedykowany ze stałym IP (nie jest konieczne zamiast tego można skorzystać z domeny), na którym stoi serwer WWW (lighttpd). Na wszystkich maszynkach potrzebujących dyndns mam dostęp do crona (zresztą, korzystałem z crona już przy zwykłym koncie dyndns, patrz update wpisu). Rozwiązanie jest proste: klient wywołuje okresowo unikatowy URL na moim serwerze, serwer okresowo parsuje log w poszukiwaniu tego unikatowego ciągu znaków i zapisuje IP z którego nastąpiło odwołanie w określonym pliku.

Poniżej wklejki ze wszystkimi onelinerami (gotowiec dla lighttpd, w przypadku innego serwera WWW trzeba dostosować):

# po stronie klienta*/5 * * * * /usr/bin/wget -4 -q -O /dev/null http://mojadomena.com/losowyciagznakow4346456543324645 > /dev/null
 # po stronie serwera*/5 * * * * /usr/bin/awk '/losowyciagznakow4346456543324645/ {ip=$1} END {print ip}' /var/log/lighttpd/access.log > /var/www/dyndns_host1.txt
 # pobranie IPwget -O - http://mojadomena.com/dyndns_host1.txt

Po namyśle, rozwiązanie nawet lepsze niż drugi dostawca dyndns. Mniej kont, prostsza konfiguracja, mając stałe IP na upartego można całkowicie uniezależnić się od DNSów, jeśli ktoś odczuwa potrzebę.

Oczywiście nie od razu tak to wyglądało, w szczególności po stronie serwera był grep, awk, tail w użyciu. Ale skoro da się wszystko załatwić awk (a nie tylko wyświetlanie określonej kolumny, chyba najczęstsze zastosowanie awk…), to czemu nie? Tu polecam zbiór przydatnych onelinerów w awk.

UPDATE: IPv6 się popularyzuje. Okazało się, że mój skrypt nie działa poprawnie, bo łączenie między maszynami następuje po IPv6. Dodany parametr -4 do wget w celu naprawy tego problemu.

Raspberry Pi, Raspbian i problemy z kartami microSD

Jakieś siedem tygodni temu pisałem, że padła mi karta microSD (Kingston) w Raspberry Pi. Wymieniłem na nową (Goodram). Zamontowana oszczędnie, tj. bez journala i z symlinkiem /var/lib/transmission-daemon/info kierującym na dysk twardy. Wczoraj robię aktualizację systemu, a tu nagle:

Preparing to replace libssl1.0.0:armhf 1.0.1e-2+rvt+deb7u7 (using .../libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb) ...
Unpacking replacement libssl1.0.0:armhf ... dpkg: error processing /var/cache/apt/archives/libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb (--unpack):
error creating directory `./usr/share/doc/libssl1.0.0': Input/output error
Segmentation fault Segmentation fault -bash: mbrtowc.c:92: __mbrtowc: Assertion `status == __GCONV_OK || status == __GCONV_EMPTY_INPUT || status == __GCONV_ILLEGAL_INPUT || status == __GCONV_INCOMPLETE_INPUT || status == __GCONV_FULL_OUTPUT' failed.

Piękne, prawda? Oczywiście kluczowy jest input/output error. Fsck, są błędy, naprawiony filesystem. Coś mnie tknęło i sprawdziłem badblocks (badblocks -sv). Tak jest, błędy w okolicy 90% karty (dead link). Sztuk prawie 30. Wygląda, że karta Goodram wytrzymała w komfortowych warunkach raptem 7 tygodni. Masakra.

Z tego wszystkiego zacząłem sprawdzać, co pisze na dysk (iotop -ao). Wyniki (sortowane po ilości zapisów, czas działania kilka godzin) są ciekawe:

3192 be/4 root 8.00 K 4.03 M 0.00 % 0.00 % rsyslogd -c5
2184 be/4 root 240.00 K 880.00 K 0.00 % 0.00 % nmbd -D
3341 be/4 ntp 248.00 K 188.00 K 0.00 % 0.00 % ntpd -p /var/run/ntpd.pid -g -u 102:104
5256 be/4 root 0.00 B 160.00 K 0.00 % 0.00 % [kworker/u2:2]
2911 be/4 root 208.00 K 88.00 K 0.00 % 0.00 % -bash

Jak widać, głównie rsyslog. I raczej nie ma tego wiele.

I tu zaczyna się część najciekawsza. Pamiętacie uszkodzoną kartę Kingstona? Przygotowałem się do pozbycia się jej, poleciał shred. Stwierdziłem, że uruchomię badblocks na niej. I… niespodzianka. Teraz nie zgłasza błędów. Ani w teście odczytu (domyślny), ani w niedestrukcyjnym teście zapisu (badblocks -nvs). Naprawiło się?

Zaczynam podejrzewać jakiegoś buga z przejściówką microSD -> SD (ale są dwie różne, bo każda karta miała swoją), gniazdem w rpi (ale działało OK, poza tym i badblocks, i fsck robię w laptopie). Zagadka.

Ostatecznie zmniejszyłem rozmiar partycji ext4 na karcie Kingstona i działa do tej pory bez problemu. Czyli jakieś 3 tygodnie bezproblemowego działania, bo wpis zacząłem tworzyć 12 czerwca.

UPDATE: Zwariowałem. Goodram, który ewidentnie miał błędy, bo nie tylko badblocks je wykazywał, ale nawet shred puszczony przed wyrzuceniem powodował błędy IO i nie mógł dobrnąć do końca (a próbowałem nie raz), teraz działa. Nagrałem Raspbiana dla Banana Pi, test badblockiem i… czysto. WTF?

Microsoft blokuje No-IP

Krótka lekcja nt. neutralności sieci w praktyce. Zaglądając na stronę popularnego operatora domen, w szczególności jednego z bardziej znanych dostawców darmowych domen dla osób z dynamicznym IP, można dziś zobaczyć taki komunikat:

 No-IP warning

Pod pretekstem wykorzystywania domen przez twórców malware (co z pewnością miało miejsce, malware korzysta z czego się da…), na mocy nakazu sądowego, Microsoft zajął 22 domeny. Zgodnie z tym, co pisze No-IP, nie było żadnego wcześniejszego kontaktu w celu usunięcia „złych” domen. Co ciekawe, No-IP utrzymuje aktywny zespół abuse, ma surową politykę przeciwko nadużyciom i… ma historię dobrej współpracy z Microsoftem w reagowaniu na podobne nadużycia.

Najwyraźniej komuś nie zależało, by z tego skorzystać. Duży może więcej.

Poniżej kopia oświadczenia wydanego przez No-IP w tej sprawie (stan na godzinę 8:00):

We want to update all our loyal customers about the service outages that many of you are experiencing today. It is not a technical issue. This morning, Microsoft served a federal court order and seized 22 of our most commonly used domains because they claimed that some of the subdomains have been abused by creators of malware. We were very surprised by this. We have a long history of proactively working with other companies when cases of alleged malicious activity have been reported to us. Unfortunately, Microsoft never contacted us or asked us to block any subdomains, even though we have an open line of communication with Microsoft corporate executives.

We have been in contact with Microsoft today. They claim that their intent is to only filter out the known bad hostnames in each seized domain, while continuing to allow the good hostnames to resolve. However, this is not happening. Apparently, the Microsoft infrastructure is not able to handle the billions of queries from our customers. Millions of innocent users are experiencing outages to their services because of Microsoft’s attempt to remediate hostnames associated with a few bad actors.

Had Microsoft contacted us, we could and would have taken immediate action. Microsoft now claims that it just wants to get us to clean up our act, but its draconian actions have affected millions of innocent Internet users.

Vitalwerks and No­-IP have a very strict abuse policy. Our abuse team is constantly working to keep the No-­IP system domains free of spam and malicious activity. We use sophisticated filters and we scan our network daily for signs of malicious activity. Even with such precautions, our free dynamic DNS service does occasionally fall prey to cyber scammers, spammers, and malware distributors. But this heavy-handed action by Microsoft benefits no one. We will do our best to resolve this problem quickly.

UPDATE: Wpis dotyczący sprawy na blogu no-ip.com został parę razy zaktualizowany. Z tego co zauważyłem, moje domeny zaczęły działać wczoraj, czyli downtime w granicach 36h. Zdarzenie jest przykładem kluczowej roli DNS (domeny, serwery), a w kontekście bezpieczeństwa warto zwrócić uwagę na to, z jakich domen się korzysta.