Szybkość polskich stron internetowych cz. 2

Opisywany w poprzednim wpisie nt. badania szybkości polskich stron internetowych system trochę okrzepł, skończył się miesiąc, więc pora na konkrety. Co prawda listę badanych serwisów było widać na zrzucie ekranu, ale nie było dostępu do danych , więc teraz to naprawiam.

Zdecydowałem, że nie będę się bawił w wyciąganie średnich miesięcznych itp.  Jeśli ktoś jest zaintersowany, to w historii są linki do danych źródłowych (CSV), można sobie wyciągnąć samodzielnie. O ile ktoś będzie potrzebował, bo to, co domyślnie daje GTmetrix, z ładną wizualizacją, jest IMO w zupełności wystarczające.

Tak więc badanie wywoływane jest dla 10 wybranych serwisów (najpopularniejsze polskie oraz ecommerce, przy czym znaczenie miała domena) co 12h,  wykonywane z Londynu, przy pomocy Chrome, bez AdBlocka i na nielimitowanym paśmie.

Oto serwisy, po kliknięciu linka dostęp do wszelkich zebranych danych:

Jest jeszcze pomysł na uruchomienie testów za pośrednictwem innego serwisu, ale pozostaje to w sferze pomysłów, póki co bez planów na implementację.

Pomiar szybkości polskich stron internetowych

Podczas pewnej dyskusji nt. kondycji stron internetowych powołane zostało jako argument badanie szybkości stron internetowych robione przez firmę Hostersi. Jest to ciekawe badanie, prowadzone od lat ale… ma wady.

Pomiarów niby jest dużo, ale są one przeprowadzane przy pomocy autorskiego narzędzia uruchamianego ad hoc, przez tydzień, samo badanie publikowane raz na rok. Wszystko to powoduje, że wyniki trudno jest weryfikować samodzielnie, a jakaś zmiana na stronie obecna w danym tygodniu, czy chwilowe problemy wydajnościowe serwisu mogą zaburzać wyniki dla całego roku. Co widać nawet w raporcie po niektórych dziwnych danych.

Dla jasności – szanuję wykonaną pracę, ale gdyby to zależało ode mnie, wolałbym mieć dane częściej, choć może rzadziej zbierane. I tak narodził się pomysł, żeby zbierać i publikować w miarę na bieżąco dane dotyczące szybkości działania polskich stron internetowych samodzielnie, hobbystycznie, w sposób umożliwiający każdemu chętnemu samodzielną weryfikację wyników pomiarów.

Stawianie własnej infrastruktury oczywiście odpadło w przedbiegach. Zbyt zasobochłonne, zarówno jeśli chodzi o koszt, jak i o samą czasochłonność utrzymania. Poza tym, odpadnie możliwość peer review. Jednak serwis GTmetrix daje ciekawe możliwości badania szybkości ładowania stron i daje API, postanowiłem z niego skorzystać, co sprowadza pracę do napisania prostych skryptów w Pythonie. Dodatkowo pozwala dzielić się zebranymi danymi przy pomocy udostępniania unikatowych URLi.

Niestety, w wersji darmowej można robić tylko 20 zapytań po API dziennie, co wymusiło ograniczenie się do jednej lokalizacji (Londyn, jako najbliższy Polsce), jednej przeglądarki (Chrome bez AdBlocka), okrojenia liczby badanych serwisów do 10 (wybrane na podstawie raportu Hostersi z najpopularniejszych i ecommerce) i wykonywania dla każdego 2 testów dziennie. Wybrałem okolice godziny 8 rano oraz 20. Z doświadczenia o 8 jest już jakiś – choć niewielki – ruch w sieci, a 20 to szczyt. Wyniki planuję publikować co miesiąc, jako średnie wartości z danego miesiąca.

Badane strony w GTmetrix

Póki co, uruchomiłem skrypt, który przy pomocy crona robi „taktowanie”, czyli zleca uruchomienie testów. Dane zbierają się od paru dni. Pomyślę jeszcze, czy zamieszczać jakieś statystyki co miesiąc, czy po prostu ograniczyć się do zbierania. Raczej stanie na tym drugim… Stay tuned!

Nazwa.pl kupiła webhostingtalk.pl i zmienia swoją ocenę

Serwis webhostingtalk.pl traktujący o polskim hostingu został kupiony przez Nazwa.pl. Więcej można przeczytać na Wykopie i na samym forum. Nie pisałbym o tym, ale mam przeczucie, że na skutek intensywnego zamiatania pod dywan różnymi sposobami link może zniknąć, więc w ramach mirrora będzie wpis.

Forum było jakie było, ranking też. Wiadomo, że przy swobodnej wypowiedzi ludzie zamieszczają różne opinie i że są to tylko opinie pojedynczych osób. Do których jak najbardziej mają prawo. Wiadomo też, że człowiek, żeby coś zrobić, potrzebuje bodźca. Niemniej, część firm posiadała wysokie oceny, a samo forum było neutralne i funkcjonujące na przejrzystych zasadach.

Tymczasem po kupnie, oceny Nazwa.pl zostały zmodyfikowane. Oczywiście na korzyść firmy. Z 49 opinii o Nazwa.pl istniejących we wrześniu 2016 zostało 31. Średnia ocena zmieniła się z 2,27 na 4,07. Co ciekawe, było 18 osób poleca i  31 nie poleca. Teraz jest 26 poleca, 5 nie poleca. Oczywiście nie sposób wykluczyć, że naturalnie pojawiło się w tym czasie 8 pozytywnych opinii, ale biorąc pod uwagę dotychczasowe ilości, jest to bardzo mało prawdopodobne. Bardzo prawdopodobna jest za to manipulacja, mająca na celu wybielenie Nazwa.pl.

Pojawił się też wątek wzrostu liczby domen, który powoduje, że Nazwa.pl wskoczyła na pierwsze miejsce w rankingu, ale to trochę bardziej skomplikowane, więc z braku czasu pomijam.

Linki, screeny, źródła:
Web Archive opinie o firmie Nazwa.pl wrzesień 2016


Opinie o Nazwa.pl wrzesień 2016

Powyżej screenshot z WebArchive

 

 

Opinie o Nazwa.pl 06.09.2017

Powyżej screenshot wykonany dziś, podczas pisania wpisu

Bez reklam na przeglądarkach mobilnych (Chrome, Focus)

Wygląda, że szykuje się lekka rewolucja w mobilnej części internetu. Wersja testowa (canary) Chrome w wersji mobilnej wyposażona jest przez producenta w blokowanie inwazyjnych reklam. Zobaczymy jak to w praktyce wyjdzie, ale wygląda, że szykuje się zmiana zasad gry – de facto oznacza to kontrolowanie rynku reklam przez dostawcę przeglądarki, będącego przy okazji jednym z większych (o ile nie największym) graczy na rynku reklamy w sieci. Podobna zmiana jest zapowiedziana dla wersji desktopowej na początek roku.

Firefox Focus już w tej chwili ma podobne rozwiązanie – wbudowana blokada reklam i ochrona prywatności. Przy okazji, przetestowałem Focusa i wygląda on bardzo zachęcająco. W przeciwieństwie do Firefoksa jest lekki (~2 MB do pobrania) i działa żwawo. Czego o Firefoksie (no dobrze, rok temu, nie wiem jak teraz) powiedzieć się nie dało, więc na smartfonie korzystałem z Chrome. W każdym razie Focus domyślnie blokuje reklamy, nie ładuje zbędnych części strony i czyści historię, co czyni tradycyjne ad-trackery bezużytecznymi. Chwilę poklikałem – jest szybko, jest wygodnie, strony wyświetlały się OK. Polecam, jeśli ktoś nie potrzebuje na smartfonie tabów w przeglądarce. Niestety nie widzę wersji dla desktopa ani kodu źródłowego.

Mam mieszane uczucia jeśli chodzi o korzyści dla użytkowników. Z jednej strony strony mają być szansę lżejsze, nie zamulać urządzeń zbędnymi javascriptami czy animacjami i ładować się szybciej, zużywając mniej transferu. Z drugiej strony, szczególnie w przypadku Google, nie mam złudzeń. Natura nie znosi próżni, więc reklamy nadal będą. Ale od Google (lub za ich zgodą). A Google i tak ma śmieci w reklamach AdSense. Podobnie ze śledzeniem – może strony nie będą w stanie tego robić, ale przeglądarka jak najbardziej… No i może historia zatoczy koło – albo płatna przeglądarka, albo wyświetlanie reklam? To już oczywiście było, w czasach płatnej wersji Opery.

W każdym razie właściciele stron stracą (znowu) trochę wolności.

Nginx z automatycznym odnawianiem certyfikatu SSL, HTTP/2 i A+

Artykuł na z3s o automatycznym odnawianiu darmowego certyfikatu SSL od Let’s Encrypt przypomniał mi, że nie skończyłem sprawy z nginx i certyfikatami SSL. Po pierwsze, brakowało mi wpisu w cronie. Trzy miesiące to jednak kawał czasu, a na serwer i tak się logowałem, więc certyfikaty były odświeżane ręcznie. No ale jak robić to porządnie, czyli w pełni automatycznie.

Wpis do crontab, którego używam to:

43 3 * * 2 /usr/bin/certbot renew --post-hook "service nginx reload" >> /var/log/certbot.log

Nie jest idealny – przede wszystkim restart nginx będzie wykonywany przy każdej próbie przeładowania, czyli raz na tydzień. Wydaje mi się, że przedładowanie konfiguracji nie będzie stanowiło problemu, ale jeśli komuś przeszkadza, to polecam zainteresowanie się opcją –renew-hook, zamiast –post-hook, która wykonuje się tylko przy odświeżeniu certyfikatu (czyli raz na kwartał). Z tym, że mam kilka certyfikatów i nie jestem przekonany, że restart nginx podczas odświeżania certyfikatu to jest to, co chcę robić, a testować mi się nie chce, tym bardziej, że na sucho średnio jest jak.

Rozwiązałem sprawę nie do końca działającego HTTP/2 (problemy z Firefox) opisaną w poprzednim wpisie. Przyczyna wskazana w komentarzach była trafna, żeby było ciekawiej, korzystałem dokładnie z

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL';

tyle, że zapewne podczas zabaw ze zwiększaniem kompatybilności z przeglądarkami zmieniłem to na wersję z gotowca, a potem odkręciłem ale… nie wszędzie. Poza tym, dopisanie http2 w każdej linii listen zawierajacej ssl i jest HTTP/2. Trochę sztuka dla sztuki, jak pokazały testy szybkości, ale wynika to głównie z tego, że same strony są małe i lekkie. Albo, jak Planeta Joggera, korzystają głównie z zasobów zewnętrznych, więc zmiany na moim serwerze nic nie dają.

W każdym razie powyższe szyfry i włącznie HSTS wystarczają do uzyskania oceny A+ na teście SSL, czego w nadchodzącym 2017 wszystkim życzę, korzystając z tego, że wpis przeleżał w szkicach nieco dłużej, niż planowałem.

Goodbye lighttpd

Do niedawna korzystałem na prywatnych gratach z lighttpd jako serwera WWW. Lekki, fajny, składnia pliku konfiguracyjnego powiedzmy perlowa, działał. Niby wszystko OK, ale… raczej nie jest wykorzystywany w różnych nowych projektach, jeśli ktoś daje narzędzia czy instrukcje, to raczej można się nie spodziewać znalezienia wersji dla lighttpd.

W międzyczasie troche bliżej miałem okazję zetknąć się z nginx i zrobił na mnie bardzo dobre wrażenie – dla kilku vhostów bardziej przejrzysty konfig, nieźle wspierany w dokumentacji różnych projektów (apache to to nie jest, ale jest dobrze). Gwoździem do trumny dla lighttpd okazał się brak wsparcia dla HTTP/2, a nawet brak planów w tym zakresie. I łatwość włączenia obsługi HTTP/2 na nginx – wystarczy jedna dyrektywa w pliku konfiguracyjnym (przy odpowiednio nowej wersji nginx – jest w backportach debianowych). Trochę na zasadzie „wykorzystać, nie wykorzystać, możliwość mieć można”.

Nic dziwnego, że pojawił się pomysł przesiadki na prywatnych gratach z lighttpd na nginx. Brakowało motywacji, bo po pierwsze istniejąca wersja działała, po drugie konfiguracja była lekko zakręcona, po trzecie brak czasu. Ostatecznie któregoś razu zebrałem się, wymyśliłem, że uruchomię oba serwery WWW równolegle, na różnych portach i zrobię szybki benchmark lighttpd vs nginx. Który to benchmark oczywiście wykaże, że nginx jest szybszy i potwierdzi słuszność przesiadki[1]. 😉

Jak już się zebrałem, to okazało się, że w sumie nie ma aż tak wielu rzeczy skonfigurowanych, a z wielu można/wypadałoby zrezygnować. Głównym wyzwaniem okazało się skonfigurowanie nginx tak, żeby HTTP słuchało na niestandardowym porcie i jednocześnie przekierowywało na HTTPS, również na niestandardowym porcie. Znalazłem rozwiązanie, ale machnąłem ręką – dziwne, nieprzystające do normalnego konfiga, a przydatne tylko na moment, przy benchmarku. Za to przydać się może ładny gotowiec do przekierowań z wersji z www na bez www i odwrotnie.

Przy okazji instalacji SSL dowiedziałem się, że w końcu istnieje oficjalna paczka z klientem Certbot dla certyfikatów SSL od Let’s Encrypt w Jessie (trzeba skorzystać z backportów). Plus, strona daje gotowe instrukcje instalacji dla popularnego oprogramowania (znowu: nginx jest, lighttpd nie ma). Czyli w certyfikatach też został zrobiony porządek. Dla pamięci: znalazłem stronkę z gotowcem, jak uzyskać A+ na popularnym teście SSL. Nieco przestarzała, ale nadal przydatna.

W zasadzie poszło zaskakująco dobrze, najwięcej niespodzianek wyszło na rzeczach najprostszych – a to serwer nie kompresował treści (tu jest o włączaniu kompresji), a to był problem z przetwarzaniem skryptów PHP. W końcu jest sensowna obsługa haseł na dostęp do stron (ew. miałem to wcześniej zrobione słabo).

Z rzeczy, które powinny działać, a nie działają – HTTP/2. Nie wiem, czy bardziej kwestia konfiguracji, wersji nginx, czy Firefoksa, ale wg testu HTTP/2 działało, a w Firefoksie (i na niektórych testach, zapewne korzystają z Firefoksa) strona się nie otwierała. Na innych przeglądarkach działało OK, ale do czasu rozwiązania problemu wyłączam HTTP/2.

Ponieważ wygląda, że publiczne motywatory działają: następna w kolejce jest przesiadka z chronicle na pelican na Wattmeter. Robi dobre wrażenie i jest w Pythonie. 😉

[1] Na przykładzie strony nextbike.tk i prostego testu przy pomocy ab -n 2000 -c 20 okazało się jednak, że różnicy większej niż błąd pomiaru nie ma. Być może kwestia wielkości małej wielkości pliku i narzutu na transmisję, być może kwestia obciążenia serwera, konfigi serwerów też nie były ani identyczne, ani optymalizowane. W każdym razie dla mnie szybciej nie będzie.

Debian over Tor

Z lekkim opóźnieniem, ale nadal news godny uwagi: Debian jest dostępny po sieci Tor. Najwidoczniej pozazdrościli Facebookowi, o którym wspominałem opisując uruchomienie strony w sieci Tor. 😉 Uzasadnienie uruchomienia jest następujące (i ładne):

The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others.

Dodatkowo, Tor zapewnia niezależne od zewnętrznych źródeł, „wbudowane” uwierzytelnianie i szyfrowanie treści – powiedzmy, że taki wbudowany HTTPS. Pełen katalog serwisów Debiana dostępnych via Tor dostępny jest tutaj, ale najważniejsze są chyba repozytoria pakietów.

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

Przy okazji dowiedziałem się o load balancerze dla serwisów Tor.

Wpis jest pokłosiem dodania do czytnika RSS nowego serwisu Debiana, czyli micronews, który swoją drogą też wygląda ciekawie i być może pod względem technicznym będzie cegiełką do uruchomienia kolejnego projekciku…

Jak zenbox.pl z domen klientów korzystał

Niedawno na blogu sprawnymarketing.pl pojawił się wpis o tym, jak rzekomo Zenbox stosował black hat SEO. Sprawa okazała się znacznie głębsza, szersza i ciekawa, niż na pierwszy rzut oka wyglądał. W różnych wymiarach, od technicznych, po prawne.

Przede wszystkim, niezaprzeczalnym faktem jest, że niektóre strony (raczej: większość) hostowane na zenbox.pl, pokazywały co innego przy wejściu przez HTTP, a co innego przez HTTPS. Jak pokazują zamieszczone w ww. wpisie zrzuty ekranu, narzędzia do badania SEO zauważały te linki. Raczej słusznie, bo wbrew temu, co twierdzi zenbox.pl, strony te nie zostały zignorowane przez Google, lecz normalnie zaindeksowane, co pokazuje poniższy zrzut ekranu:

Zenbox.pl SEO HTTPS

Szybko okazało się, że zenbox.pl nie jest jedynym hostingiem, który działa w ten sposób, a winny jest prawdopodobnie panel DirectAdmin, którego domyślna konfiguracja powoduje pokazywanie „zaślepki” przy braku podpiętego certyfikatu SSL. Potem było już tylko weselej, bo w dyskusji na Wykopie niektórzy sugerowali, że w zaślepkach powinien być w linkach atrybut nofollow. Uważam, że akurat brak nofollow świadczy w tym przypadku na korzyść zenbox.pl i braku celowego działania – gdyby ktoś zawracał sobie głowę atrybutami czy anchor text (a są i tacy), to znaczy, że pomyślał o pozycjonowaniu.

Jeszcze bardziej dziwi mnie skupienie się na SEO i ominięcie sedna sprawy: nie chodzi o – celowe lub nie – wprowadzenie w błąd Google. Przede wszystkim mamy do czynienia z podmianą treści na stronie zamieszczonej w określonej domenie. Wątpię, by właściciele domen mieli wiedzę, że taka podmiana miała miejsce. Jeszcze bardziej wątpię w ich zgodę na takie działanie.

HTTPS zamiast HTTP niewiele tu zmienia – oczywiście jest możliwość serwowania różnych treści w zależności od protokołu, podobnie jak strona z przedrostkiem www (de facto subdomena) z technicznego punktu widzenia może kierować zupełnie gdzie indziej, niż domena bez takiego przedrostka, ale przyjęte jest, że kierują w to samo miejsca. W przypadku HTTPS jest to IMO wręcz oczywiste.

Pamiętajmy też, że strony WWW, zwłaszcza popularniejsze blogi, potrafią po prostu sprzedawać miejsce na reklamę na stronie. Wydaje mi się, że w przypadku takich blogów wykazanie szkody w sądzie byłoby trywialne. Dlatego podejście zenbox.pl do sprawy mnie dziwi. Jak widać w komentarzach na blogu, mamy kolejno:

  1. straszenie „na takie działania godzić się nie można i zrobimy wszystko aby takie akcje miały konsekwencje”
  2. negacja, najpierw problemu w ogóle (screenshot w ww. wpisie), potem wpływu „działania nie mają wpływu na pozycję stron klientów ani wpływu na pozycję witryny zenbox.pl”
  3. przyznanie istnienia problemu „wspomnianego problemu nie doświadczyli” i w końcu podjęcie działań (zmiana konfiguracji, mailingi)

Wydaje mi się, że znacznie bardziej na miejscu byłaby analiza sytuacji, podziękowanie za zwrócenie uwagi, naprawienie problemu (poprawa konfiguracji) i przeproszenie klientów.

Cała sprawa ma jeszcze jeden ciekawy aspekt. Wydaje mi się, że największy błąd popełniło… Google, które podmienioną treść na stronie jak widać łyka jak pelikan. Mimo ewidentnych błędów HTTPS (certyfikat nie pasuje do domeny), które m.in. przed taką podmianą miały chronić. W czasach, gdy każda domena może mieć rozpoznawany przez przeglądarki certyfikat SSL za darmo (oczywiście chodzi o projekt Let’s Encrypt) strony za niepasującymi, wygasłymi i self signed certyfikatami powinny po prostu być ignorowane.

Prawidłowa konfiguracja to IMHO ta sama treść dostępna po HTTP i HTTPS. Czy to za sprawą odpowiedniego przekierowania (to sensownie uda się tylko z HTTP na HTTPS…), czy też – zwł. na shared hostingu – pod certyfikatem hostingodawcy, jeśli domena nie ma własnego.

Przeglądarka Vivaldi

Parę dni temu do przeglądarek dostępnych na rynku dołączył nowy gracz – Vivaldi. A w zasadzie nie tyle dołączył, co ukazała się wersja 1.0. Oczywiście zainstalowałem i się pobawiłem. Jest parę ciekawych ficzerów, które przypadły mi do gustu, ale nie wszystko mi się podoba.

Pierwszą rzeczą, którą widzimy po instalacji i uruchomieniu przeglądarki, jest tzw. wizard. Można wybrać schemat kolorów, rozmieszczenie belki z tabami i… obrazek, który będzie służył za tło przy speed dial. Wszystko oczywiście można zmienić później w ustawieniach, ale uważam, że taka szybka i łatwo dostępna personalizacja to miła rzecz. Poza nieszczęsną tapetą dla speed dial – po co tam komu tapeta? Przecież to potrzebne jak tapeta w systemie – widzę ją przez parę sekund po uruchomieniu i tyle.

Kolejną rzeczą, która zwróciła moją uwagę, jest pasek postępu – pokazuje ilość pobranych danych, postęp ładowania w postaci przesuwającego się paska i chyba ilość obrazków na stronie. W każdym razie kiedyś któraś przeglądarka już tak miała i uważam to za lepsze rozwiązanie, niż niewiele mówiące kręcące się kółeczko.

Vivaldi ma chyba pewne ambicje do zastąpienia systemu operacyjnego. Jest i wspomniana tapeta, jest wbudowany w przeglądarkę klient poczty, jest możliwość tworzenia notatek, no i w końcu są panele, czyli tak naprawdę funkcjonalność kafelkowego managera okien. O ile do pierwszych dwóch podchodzę zdecydowanie negatywnie, to do tworzenia notatek mam mieszane uczucia. Za to panele nawet mi się podobają – jest to coś w stylu mini strony WWW, domyślnie w wersji mobilnej, dostępna na każdej zakładce. Po prostu podział powierzchni okna na dwie części. Przy obecnych szerokich monitorach może zdawać egzamin, a w panelach można umieścić np. social media, które i tak nie wymagają wiele miejsca.

OgólnieVivaldi bardzo przypomina mi Operę. Jak się okazało, słusznie, bo projekt tworzą ludzie, którzy kiedyś pisali Operę. Jest parę różnic, przede wszystkim większy nacisk na prezentację. Jest parę innowacji, więc przypuszczam, że – podobnie jak niegdyś OperaVivaldi zdobędzie pewne grono gorących zwolenników. Wielkiej popularności nie wróżę, ale zdecydowanie warto spróbować. Ja planuję od czasu do czasu używać, być może Vivaldi zostanie moją przeglądarką do social mediów.

Na koniec słowo o obsługiwanych systemach operacyjnych – Vivaldi dostępna jest dla Maców, Windows (wersje 32 i 64 bit) oraz Linuksa (pakiety deb i rpm w wersjach 32 i 64 bit). Twórcy nie chwalą się adresami repozytoriów, ale są one dostępne i dodawane automatycznie po instalacji (bez ostrzeżenia, nie lubię). Dla porządku, dla gałęzi stabilnej przeglądarki i Debiana wpis dla sources.list  to:

deb http://repo.vivaldi.com/stable/deb/ stable main


Letsencrypt i lighttpd – HOWTO

Czym jest Let’s Encrypt wie już chyba każdy, kogo interesują certyfikaty SSL, ale wypada jakieś wprowadzenie napisać, więc: to prosty sposób na odnawialne automatycznie, rozpoznawane przez przeglądarki, bezpłatne certyfikaty SSL dla każdego. Projekt jest w fazie public beta, więc przystąpić może każdy, stoją za nim duzi (przykładowi, bardziej znani sponsorzy: Mozilla, EFF, Cisco, OVH, Google Chrome, Facebook), więc raczej coś z tego będzie i jest krokiem w kierunku zwiększania bezpieczeństwa w sieci pod hasłem wszystko po HTTPS (które to rozwiązanie ma wady, ale o tym już było).

Let's Encrypt logo

Źródło: https://letsencrypt.org/trademarks/

Ponieważ właśnie dostałem maila od Let’s Encrypt, że wygenerowany przez nich, darmowy certyfikat SSL dla mojej domeny wygasa, postanowiłem skorzystać z największego dobrodziejstwa, czyli zautomatyzować całość. Prosty skrypt, który zadziała dla lighttpd i jednej domeny:

#!/bin/bash LECMD="/opt/bin/letsencrypt/letsencrypt-auto"DOMAIN="mojadomena.com"WEBROOT="/var/www/mojadomena.com/html/"EMAIL="adres@email"$LECMD --renew-by-default -a webroot --webroot-path $WEBROOT --server https://acme-v01.api.letsencrypt.org/directory --email $EMAIL --text --agree-tos -d $DOMAIN authcat /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/letsencrypt/live/$DOMAIN/cert.pem > /etc/letsencrypt/live/$DOMAIN/ssl.pemservice lighttpd restart

Zakładam oczywiście, że skrypt letsencrypt jest pobrany z gita, masz dostęp do roota, lighttpd jest skonfigurowane i ma podpięty certyfikat SSL. Plus, że w konfiguracji lighttpd jest linia w stylu:

ssl.pemfile = "/etc/letsencrypt/live/mojadomena.com/ssl.pem"

To co wyżej to sama esencja, brakuje choćby kontroli błędów/statusu wykonania poleceń, ale wywołane z ręki działa i pewnie dodam do crona wykonywanie raz w miesiącu (wzmocnione przez && w ramach „kontroli błędów”). Opisuję, by mi nie zginęło, poza tym, widziałem albo skrypty automatyzujące, albo opisy uruchomienia letsencrypt z lighttpd, więc liczę, że zebrane do kupy się komuś przyda.

UPDATE Wpis się lekko zdezaktualizował o czym więcej w tym wpisie. A krótko: jest gotowiec od EFF o nazwie Certbot do automatycznego zarządzania darmowymi certyfikatami SSL Let’s Encrypt, z opisami dla różnych serwerów.

Statystyki hitów Wykopu

Przy okazji startu Vagli do Senatu w pewnym momencie pojawiły się spekulacje nt. zasięgu Wykopu. Tzn. do ilu ludzi można dotrzeć przy pomocy tego serwisu, jeśli doda się ciekawe znalezisko. W pewnym momencie popełniłem analizę zasięgu Wykopu, ale ponieważ to jednorazowe było, postanowiłem podejść do sprawy bardziej systematycznie, tym bardziej, że wartości były raczej niskie.

Prosty skrypt w Perlu zbiera dane o wszystkich znaleziskach, które są na stronie Hity (czyli, zakładam, że są najlepsze), następnie pobiera bezpośrednio z nich interesujące dane (wykopy, zakopy, wyświetlenia) i pakuje do bazy danych. Dzięki temu miałem nie tylko dane maksymalne, ale także dynamikę zmian w czasie. I w sumie na moje potrzeby to wystarczało, ale ponieważ rozmawiałem ostatnio z ludźmi, to stwierdziłem, że warto się podzielić.

Efekt można zobaczyć tutaj. Strona, generowana raz na godzinę, jest bardzo uproszczona. Sortowanie malejąco po ilości wejść. Nie ma informacji o zakopach (żaden problem dodać, ale po co zaciemniać?), nie ma żadnych danych nt. dynamiki. Robiłem przymiarkę do prezentacji tych danych, ale wygląda brzydko i mało czytelnie, więc na razie odpuszczę.

Z ciekawostek – patrzyłem na Wykop i w pewnym momencie przy sortowaniu pojawia się słowo diggs. Doczytałem w Wikipedii, że Wykop jest/był klonem serwisu digg.com, ale zastanawiam się, czy przypadkiem nie dzieli z nim (części) kodu źródłowego?

Spam o grze na giełdzie – wzorzec, sprawdź logi

Od pewnego czasu dostaję sporo spamu dotyczącego gry na giełdzie. Polsko brzmiące From, w treści zwykle niemieccy uczeni, gra na giełdzie, sztuczna inteligencja oraz całą dobę. W różnych wariantach. Do tego link do strony.

Z tego co mi się obiło o ekran, nie tylko ja to dostaję, a z tego co widzę po skrzynkach – filtry nadawców sobie nie radzą. Poza tym, myślałem, że się skończyło, ale widzę, że nadchodzi kolejna fala.

Zgłaszałem do SpamCopa (nie bez trudności) i akurat w tej kwestii dostałem kilka odpowiedzi z podziękowaniami za zwrócenie uwagi na problem, poza tym, jest charakterystyczny ciąg w URLu, więc wygląda na działanie jakiegoś niezbyt znanego robaka.

Mianowicie wszystkie(? albo prawie wszystkie) URLe, do których odsyłają maile ze spamem zawierają ciąg:

.php?b=2

Zapewne jeśli prowadzi serwer WWW, to warto grepnąć logi pod tym kątem. Kod 200 będzie oznaczał, że prawdopodobnie strona jest zainfekowana.

Zatem prośba do adminów WWW o sprawdzenie logów pod tym kątem, a do adminów poczty o próbę uwzględnienia tego w regułach antyspamowych.

PS Jakby przyjrzeć się bliżej, to pewnie nawet okaże się, że problem dotyczy tylko starej wersji któregoś CMSa, ale tego nie chce mi się już analizować.

Bezpieczniejsze i wydajne łącze mobilne

Nieco ponad pół roku temu opisałem możliwe sposoby przyspieszania łącza internetowego. Znowu jestem na urlopie, bez dostępu do „normalnego” łącza i korzystam z Aero2. Jak pisałem, najbardziej, ze względu na łatwość uruchomienia, przynajmniej w środowisku Linux, odpowiada mi wariant z socks proxy i ssh.

Poza tym, mignęła mi ostatnio – zupełnie nie pamiętam przy jakiej okazji, ale niezwiązana z tym tematem – informacja o polipo, czyli cache’ującym serwerze proxy, pomyślanym o użytku osobistym, domowym lub małych grupach użytkowników. W stosunku do pełnoprawnego proxy WWW, czyli popularnego squida ma parę ciekawych cech: jest lekki i szybki, prosty w konfiguracji, może robić za mostek między sieciami IPv4 i IPv6, umie socks proxy, posiada pewne opcje umożliwiające łatwe filtrowanie reklam i zwiększanie prywatności.

W kombinacji z tunelem SSH z którego korzystam, polipo będzie pełnił rolę cache oraz translatora socks proxy na zwykłe proxy WWW. O ile większość przeglądarek jakoś obsługuje socks proxy, o tyle chyba tylko w Firefoksie można to po prostu wyklikać, pozostałe wymagają zabawy z wierszem poleceń w celu uruchomienia obsługi. Poza tym, mając proxy WWW w systemie można je wykorzystać nie tylko do przeglądarek, ale do wszystkich programów, które umożliwiają ustawienie proxy HTTP.

Czyli całe rozwiązanie składa się więc z dwóch elementów: tunelu SSH, zapewniającego szyfrowanie przesyłanych danych (bezpieczeństwo) oraz kompresję (wydajność), oraz polipo zapewniającego cache plików (wydajność). Ponieważ moje łącze mobilne jest wolne (Aero2; DOWN/UP 512/256 kbps), zdecydowałem się umieścić serwer proxy na laptopie, przed tunelem SSH (patrząc od strony przeglądarki). Wydaje mi się, że tak będzie wydajniej – część zapytań nie trafi w ogóle do tunelu. Możliwa jest też konfiguracja z proxy uruchomionym na serwerze terminującym tunel – patrz linki na końcu wpisu. Topologia rozwiązania wygląda zatem następująco:

Internet - serwer - tunel SSH - polipo - przeglądarka

Serwer to maszyna z Linuksem (może być VPS dowolnego typu), serwerem SSH i przyzwoitym (optymalnie: lepszym od naszego mobilnego łączem).

Uruchomienie tunelu:

ssh -CND 9000 user@serwer

Konfiguracja serwera polipo (bardzo podstawowa, dostępnych jest znacznie więcej opcji, ale ich opis wykracza poza tematykę tego wpisu; cat /etc/polipo/config):

logSyslog = true
logFile = /var/log/polipo/polipo.log
socksParentProxy = 127.0.0.1:9000
socksProxyType = socks5

Następnie ustawiamy w przeglądarce WWW jako HTTP proxy: adres 127.0.0.1 i port 8123 (domyślny port na którym słucha polipo). Gotowe.

Uwaga dotycząca bezpieczeństwa: z uwagi na to, że w ww. rozwiązaniu szyfrowany jest tylko ruch HTTP, i tylko ten przechodzący przez proxy, należałoby pewnie ograniczyć dostęp dla pozostałego ruchu wychodzącego na firewallu. Jeszcze lepszym rozwiązaniem pod względem bezpieczeństwa, z uwagi na ew. spoofing DNS i uniezależnienie się od DNSów dostawców sieci, byłby VPN. Ale w tym przypadku nie to jest priorytetem, poza tym, korzystam z lokalnego serwera DNS.

Linki:

  1. Opis konfiguracji Aero2, wvdial i modemu Huawei E3131.
  2. Alternatywna konfiguracja z polipo uruchomionym na serwerze.

PUM

Jakiś czas temu zacząłem korzystać z Uptime Monitor. Przyznaję, że jestem zadowolony, do pełni szczęścia brakowało mi czegoś, co wystawi moje uptime’y na WWW. Tzn. jest sporo fajnych narzędzi, rysujących ładnie i live, tzn. z autoodświeżaniem, ale… nie byłem przekonany do pomysłu publikacji kluczy API. Tym bardziej, że w niektórych przypadkach udostępnienie klucza wiąże się z z podaniem danych hosta, loginu i hasła do htpasswd itp.

Wolałbym mieć możliwość ukrycia nazwy/IP i ogólnie nie podawania zbyt wielu informacji, zwł. klucza API. Zauważyłem też, że nie ma (a przynajmniej nie znalazłem) nic do obsługi Uptime Monitora w Perlu. Stwierdziłem, że generowanie statycznego HTML (docelowo) z crona jest zupełnie wystarczające, a ew. autoodświeżanie prosto można załatwić JSem czy IIRC nawet polem META w HTML (koła nie odkrywam, „konkurencja” też tak robi.

I w ten sposób powstał PUM czyli Perl Uptime Monitor. 😉 Jest możliwość nadpisania nazwy, jest możliwość generowania uptime dla danego okresu (ilość dni wstecz). Brakuje opakowania wyniku w HTML (wyniki na STDOUT póki co…), ale to wkrótce… W sumie nie ma problemu z pobraniem danych do wykresu czasu odpowiedz, ale nie planuję póki co. Zachęcam do forkowania i zgłaszania pull requestów, ew. pomysłów w komentarzach.