Tag: debian

Opublikowane w

Huawei E353/E3131 w Debianie

Kiedyś opisywałem uruchomienie Aero2 z modemem Huawei E3131. Kupiłem „taki sam” model i dziś przyszedł. Po podłączeniu do komputera spodziewałem się, że będzie tak samo, jak w poprzednim. Tak się nie stało, więc może komuś oszczędzę walki, na którą straciłem dziś dobry kwadrans, jak nie lepiej. Huawei E353/E3131 różni się od poprzednio opisywanego.

Otóż nowy modem przedstawia się w lsusb:

Bus 002 Device 016: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

Natomiast po wpięciu Huawei E353/E3131 do portu USB w dmesg widać:

[11264.677637] usb 2-1.2: new high-speed USB device number 15 using ehci-pci
[11264.787001] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=1f01
[11264.787005] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11264.787007] usb 2-1.2: Product: HUAWEI HiLink
[11264.787009] usb 2-1.2: Manufacturer: HUAWEI
[11264.788426] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[11264.788583] scsi host6: usb-storage 2-1.2:1.0
[11265.736276] usb 2-1.2: USB disconnect, device number 15
[11268.517690] usb 2-1.2: new high-speed USB device number 16 using ehci-pci
[11268.627263] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=14db
[11268.627267] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11268.627269] usb 2-1.2: Product: HUAWEI HiLink
[11268.627271] usb 2-1.2: Manufacturer: HUAWEI
[11268.630336] cdc_ether 2-1.2:1.0 eth0: register 'cdc_ether' at usb-0000:00:1d.0-1.2, CDC Ethernet Device, 58:2c:80:XX:XX:XX
[11268.707401] cdc_ether 2-1.2:1.0 enx582c80xxxxxx: renamed from eth0

Co prawda świtało mi coś o hilink i zauważyłem kartę sieciową w systemie. Jednak stwierdziłem, że to tylko jeden z trybów i można używać „po staremu” z /dev/ttyUSB0 i wvdial, który to sposób mam obcykany. Zmyliło mnie też to, że nie mogłem wejść na wskazywany przy opisach wersji hilink adres 192.168.1.1.

Robiłem różne cuda, o których pisać nie będę. Na szczęście zapytałem na IRCu i dobrzy ludzie naprowadzili me zawiłe rozumowania na proste tory.

No więc ostatecznie „po staremu” mi się nie udało, natomiast żeby uzyskać adres IP wystarczy wydać polecenie:

dhclient enx582c80xxxxxx

I wtedy po wpisaniu w przeglądarkę 192.168.1.1 mamy dostęp do klikalnego interfejsu zarządzania modemem i wszystko działa od kopa.

Niestety, opisy są chyba obliczone albo na ludzi, którzy robią wszystko z ręki, albo na tych, którzy mają wszystko automatycznie. Pobieranie IP z DHCP też.

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

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 i oceną A+. 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. Wykonuje się ona 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 dla nginx 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.