Tag: howto

Opublikowane w

Jak włączyć SSH w Raspbian?

Sytuacja zmusiła mnie do odkopania RPi. Szybko potrzebowałem przetestować jedną rzecz, więc wybrałem Raspbian Jessie Lite. Główna zaleta to niewielki rozmiar i kernel w wersji 4.4. Po włączeniu i pobraniu IP przez RPi okazało się jednak, że nie sposób się zalogować po SSH do Raspbian – nic nie słuchało na porcie.

Instrukcje, które znalazłem, są dobre, jeśli ktoś ma monitor i klawiaturę. Ja nic takiego pod ręką nie miałem. Zacząłem więc przyglądać się skryptom startowym. Ale w międzyczasie zapytałem na IRCu i dostałem linka, który podaje prosty przepis na włączenie SSH. Wystarczy utworzyć plik ssh o dowolnej zawartości w katalogu /boot na karcie SD z Rasbianem:

touch /boot/ssh

Oczywiście powyższe zadziałałoby, gdyby było wykonywane bezpośrednio z Raspberry Pi, trzeba wziąć poprawkę na punkt montowania, ale wiadomo o co chodzi. 😉

Po tym zabiegu SSH w Raspbian jest dostępne po uruchomieniu systemu. Zalogować się można tradycyjnie przy pomocy użytkownika pi i hasła raspberry.

SSH w Raspbian wyłączono w domyślnej wersji ze względów bezpieczeństwa (tu link).

Z kronikarskiego obowiązku: w Raspbianie bazujązym na Jessie wiele się nie zmieniło. Swap nadal domyślnie włączony i zarządzany w dziwny sposób (nie /etc/fstab), journal na FS obecny, sterowanie LED i odczyt temperatury bez zmian.

Opublikowane w

Autossh

Jak zapowiedziałem w notce o porządkach, przepiąłem się z łącza ADSL na komórkę. Decyzję przyspieszyła wydatnie awaria ADSL, polegająca na tym, że transfery liczone są w pojedynczych kB, a mimo obiecującego początkowego kontaktu, awaria nadal trwa… Przy czym po tym jak odesłałem parametry łącza, które chcieli, to przestali się odzywać. Mimo dwóch kontaktów mailowych z mojej strony.

Nie obyło się bez zawirowań i ledwo działający dostęp ADSL ratował mi tyłek, ale może o tym w innej notce. W tej chwili sytuacja wygląda tak, że cały ruch leci przez modem GSM wpięty do routera na Banana Pi. Jeśli chodzi o dostawcę łącza, to poszedłem na łatwiznę i jest to Aero2. W zeszłym miesiącu zużyłem (tj. bardziej rodzice) niecałe 2GB z 3GB pakietu. Czyli przewidywany koszt łącza to 5-10 zł/m-c. Wyższe pingi nie są problemem, zresztą różnica w stosunku do BSA jest niewielka. Prędkość to jakieś 3/1 Mbps[1], więc też lepiej, niż było.

Problemem okazał się dostęp do routera, który chciałbym zachować. Znalazłem autossh, o którym wspominałem w komentarzach do notki o porządkach, ale uruchomienie zajęło znacznie więcej czasu, mimo prostych instrukcji. Oczywiście wszystko przez moje niezrozumienie tematu, albo raczej wcześniejsze wyobrażenia. Liczyłem, że po zestawieniu tunelu, łącząc się do zdalnego hosta na określonym porcie, zostanę automagicznie przekierowany do hosta za NAT, z którego jest zestawiony tunel.

Tak jednak nie jest. Autossh słucha na zdalnym hoście wyłącznie na adresie lokalnym (127.0.0.1) i zdebugowanie tego zajęło mi dłuższą chwilę. Może oszczędzę tym wpisem komuś szukania. Korzystając z instrukcji dostępnych w sieci faktycznie połączymy się do hosta za NAT, ale tylko z maszyny do której jest zestawiony tunel. Można wystawić ten dostęp na świat, ale wymaga to dodatkowego przekierowania portu, czy to przy pomocy iptables, czy programu redir.

Ostatecznie wypracowałem następujący schemat. Połączenie zestawione z hosta za NAT przy pomocy autossh (uruchamiane przy starcie systemu, logowanie po kluczach bez hasła):

autossh -f -M 5122 -N -R 8888:127.0.0.1:22 user@host

Jeśli chcę się dostać do routera (hosta za NAT) to na hoście docelowym uruchamiam przekierowanie portów:

redir --lport=8888 --laddr=IP_PUBLICZNE --cport=8888 --caddr=127.0.0.1

W tym momencie łącząc się na port 8888 maszyny z publicznym IP, de facto łączę się do routera za NAT:

ssh -p 8888 user_za_nat@host

Oczywiście analogicznie mogę także zestawiać tunele SSH itp., które umożliwią mi wyjście w świat przez modem GSM.

Czemu redir, a nie iptables? Nie potrzebuję dostępu do tej maszyny cały czas. Wolę więc uruchomić na chwilę przekierowanie, niż wystawiać router na świat, chociaż po docelowym zabezpieczeniu pewnie się to zmieni.

[1] Tzn. 3/1Mbps wykazał speedtest, ale może być lepiej, zwł. download . Później zauważyłem, że konfigurując router ustawiłem limitowanie pasma na 3 Mbps dla pojedynczej końcówki za NAT.

Opublikowane w

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.