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. 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ę i 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, które są można czy wręcz 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. Za to 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. Tak czy inaczej w starciu lighttpd vs nginx wygrał u mnie ten ostatni.

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ę. Abo może 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.

Planeta Joggera

Jak było wspominane, Jogger się zamyka. Padł pomysł, żeby nie rozleźć się całkiem i jakoś zachować kontakt. Tym bardziej, że część ludzi się przeniosła z blogami w inne miejsce i nadal pisze. Poza tym, ma to być taki trochę pomniczek, czy też – dla wierzących/kultywujących – ołtarzyk.

Ponieważ jakieś tam doświadczenie z tworzeniem tzw. planet miałem, a niespecjalnie coś się, mimo zapowiedzi, działo ze strony oficjalnej i w ogóle pojawiły się głosy wątpiące, że coś się ruszy, to stwierdziłem, że zrobię planetę. W końcu to moment, bo gotowce gdzieś mam, wystarczy zebrać URLe. Tak powstała Planeta Joggera. Z założenia miało być open source (GitHub coraz bardziej mi się podoba, wielowymiarowo, w końcu jakiś social network z sensem…). Czyli jak się właścicielom spodoba, to skorzystają, więc powstało stosowne repozytorium na GH. A tymczasem może wisieć u mnie – serwer mam tak czy inaczej, zasobów wiele to nie potrzebuje.

Odgrzebałem stare skrypty i konfigi dotyczące planety. Zakląłem. Potem zainstalowałem planet venus i zakląłem wiele razy… Jakąś wersję udało się ostatecznie sklecić. IMO wygląda to nawet znośnie i estetycznie i robi swoją robotę, ale niesmak dot. planet venus pozostaje. Skrypt, który niby ma umieć skracać artykuły średnio chce działać. Przynajmniej dla treści strony, przynajmniej z takim formatem template, jaki jest używany. A specjalnie grzebać przy frontendzie nie chce, jednak, szczególnie, że miałoby to być tak samo, ale inaczej. Chociaż troszkę pogrzebałem i mój skill dot. CSS gwałtownie wzrósł.

Mniejsza jednak nawet o ten skrypt. Ogólnie HTTPS zwykle działa, ale dla niektórych kanałów RSS… nie działa. Zresztą, jest jeden URL, z którym jest zawsze problem, czy to po HTTP, czy po HTTPS. A nic wymyślnego – WordPress. Jeden z wielu. Jeśli myślicie, że chce mi się debugować pythonowy kod, który ostanie commity na GH ma parę lat temu, to źle myślicie. Ogólnie być może warto zmienić silnik, ale ten po pierwsze już jest. Po drugie jakoś działa, więc może kiedyś (czytaj: pewnie nie). Gdyby ktoś rozważał stawianie planety i nie miał doświadczenia z żadnym silnikiem, ani gotowców, to sugeruję raczej nie tracić czasu na testowanie planet venus, tylko przejść do innych rozwiązań. Chociaż planeta Debiana jest właśnie na tym oparta i jakoś działa…

Tak czy owak, bunkrów nie ma, ale i tak jest zajebiście i jestem zadowolony z efektu, który można zobaczyć tutaj. Można pomóc! Jest parę issues otwartych na GH, wiem, że może tego bloga czytać parę osób, które niekoniecznie zaglądają na Joggera, ale które miały tam blogi, albo chociaż czytały, więc drobny apel tutaj. Przejrzyjcie czytniki RSS i jeśli znacie jakichś bloggerów, którzy zaczynali na Joggerze, a teraz piszą gdzie indziej, to dajcie im znać. I zapraszam do dołączenia ich blogów do planety (pull request pls!). Planeta Joggera jest zrobiona maksymalnie tak, by nie kraść treści (noarchive, noindex). Więc raczej nikt nie powinien mieć nic przeciwko obecności na planecie. Ale zapytać oczywiście wypada.

Let’s encrypt i lighttpd – HOWTO

Czym jest Let’s Encrypt wie już chyba każdy, kogo interesują certyfikaty SSL. Wypada jednak 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. 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. Dodatkowo 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. Liczę więc, ż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 użycia dla różnych serwerów.