Tag: linux

Opublikowane w

Terminal HP T630

Jakiś czas temu pisałem o zakupionym HP T620. Sprawdził się jako sprzęt. Brak wentylatora, możliwości rozbudowy RAM i SSD, dużo wyjść. Działał dobrze i w sumie nie było powodu do wymiany, ale… Kumpel z pracy też kupił T620. Tyle, że w wersji z czterema rdzeniami. I jak mi dwa rdzenie wystarczały, tak widać po obciążeniu było, że do odtwarzania multimediów na styk są. I pewne operacje, nazwijmy to przygotowawcze do odtwarzania, mogłyby wykonywać się szybciej. No i kupiłem wersję z SSD o rozmiarze 8 GB, co dla Debiana z GUI pod rozrywkę i multimedia też na styk było[1]. Więc niby mógłby robić za podstawowy desktop, ale jednak nie do końca.

Terminal HP T630
Źródło: strona producenta

Pojawił się więc pomysł wymiany na wersję z czterema rdzeniami. Tym bardziej, że nie boję się kupna wersji używanej, a systemu nie potrzebuję – Debian działa dobrze. Trochę jest to próba racjonalizacji nowego gadżetu, nie ukrywam. Normalnie szukałbym nowej płytki z SoC ARM, ale ceny są tu tak nieprzyzwoicie wysokie, że odpuściłem. Jak już szukałem, to postanowiłem sprawdzić, czy są jakieś alternatywy.

Okazało się, że istnieją terminale HP T630, bardzo podobne do T620. Główna różnica to taktowanie CPU. 2 GHz, zamiast 1.5 GHz w wersji czterordzeniowej. I dwa razy większy maksymalny rozmiar pamięci RAM. Kupiłem więc T630 w wersji z dyskiem 32 GB i 8 GB RAM. Dla pamięci: w sierpniu 2022 zapłaciłem 220 zł. T620 miał 8 GB dysk, 4 GB RAM i kosztował w listopadzie 2020 120 zł.

Instalacja Debiana bezproblemowa. Działanie po uruchomieniu także. Poza jedną, istotną, wynikającą z hardware różnicą. Otóż T620 posiadał dwa osobne gniazda: line-in oraz line-out, a dodatkowo gniazdo słuchawkowe. W HP T630 jest nadal gniazdo słuchawkowe na froncie, ale gniazdo oznaczone line-in oraz line-out jest tylko jedno. Było z tym niewielkie zamieszanie, ale o tym w kolejnym wpisie.

Jest zauważalnie szybciej. Czy spróbuję, choćby testowo, korzystać z HP T630 jako podstawowego desktopa? Zobaczymy. Szansa na pewno jest.

[1] Tak, można wymienić SSD. Albo wręcz dołożyć pendrive’a albo czytnik kart microSD na USB do któregoś z licznych wolnych portów USB. W tym USB 3.0.

Opublikowane w

Co w 433 MHz piszczy?

Wpis na blogu o termometrach zewnętrznych przypomniał mi o pewnym zakupie, który jakiś czas temu poczyniłem. Chodzi o termometr bezprzewodowy z Jula. Nieco spontaniczny zakup, by mieć pretekst do zabawy urządzeniami pracującymi w paśmie 433 MHz. Z drugiej strony nawet gdyby nie udało się dobrać do danych z komputera, to jakaś tam potrzeba poznania temperatury w różnych miejscach w mieszkaniu była.

Do zabawy nie doszło, nie pamiętam dlaczego. Z tego co pamiętam chciałem pójść bardziej w stronę dedykowanego odbiornika (i transmitera…) 433 MHz, nie SDR. I trochę utknąłem na zakupie, a w zasadzie na zastanawianiu się nad podłączeniem tego – lub czegoś podobnego – do zwykłego komputera, najchętniej przez USB.

rtl_433

W każdym razie wpis zwrócił moją uwagę na program rtl_433 i możliwość odczytu danych przez SDR. Wersja docelowa to może nie będzie, w rozmowie ze znajomymi z pracy mieliśmy nieco obawy co do jakości sygnału, ale skoro tak łatwo dostępne, to warto spróbować. Okazało się, że pakiet rtl-433, który jest dostępny w Debianie SID, mam już zainstalowany. Zupełnie nie przypominam sobie, bym go używał, ale może to z czasów kiedy instalowałem wszelki soft do SDR?

Uruchomiłem i… to działa, po prostu, od kopa. Okazało się, że termometr z Jula, który kupiłem, jest wspierany. Okazało się także, że podobny czujnik jest gdzieś w okolicy. Najciekawsze zaś jest, że wykrytych zostało sporo innych czujników. Z których wiele udostępnia nie tylko dane o temperaturze, ale także o wilgotności.

Ilość widocznych czujników naprawdę mnie zaskoczyła. Z fabryczną, biedną anteną ustawioną w losowym miejscu na biurku SDR widzi kilka. W tym – sądząc po nazwach – trochę czujników temperatury i ciśnienia powietrza z samochodów.

Zastosowanie

W oparciu o Raspberry Pi lub podobną płytkę można łatwo można zrobić sobie własną stację pogodową, z dowolną ilością czujników. Wariant udostępniający dane po WWW jest trywialny i zapewne w tę stronę pójdę. Nic nie stoi jednak na przeszkodzie by dołożyć wyświetlacz i na nim prezentować dane, tworząc odpowiednik prawdziwej stacji.

Dodatkowo opisywane rozwiązanie daje możliwość skorzystania z danych z cudzych czujników. Mój czujnik zdalny jest w innym pomieszczeniu, niż stacja. Trochę miałem dylemat, czy nie umieścić go za oknem. Ale skoro sąsiad ma na zewnątrz, to ja już nie potrzebuję… Tracimy co prawda kontrolę nad umiejscowieniem czujnika, który może np. znajdować się w nasłonecznionym miejscu, ale darowanemu koniowi w zęby się nie zagląda.

Rozglądam się teraz i myślę jaki termometr bezprzewodowy kupić. Póki co znalazłem ładny moduł do stacji pogodowej za 34 zł, kuszą jednak inne moduły do stacji pogodowych, które zapewniają pomiar wilgotności. Co prawda nie mam pewności czy będą obsługiwane przez rtl_433, ale zakładam, że tak. Ewentualnie można dopisać ich obsługę.

Opublikowane w

Certstream HOWTO

Do czego można wykorzystać dane pochodzące z certstream można zobaczyć choćby na prezentacji z konferencji z BSides Warsaw z 2019 roku. Ponieważ każdy ma certstream, mam i ja. Nie jest to zbyt zasobożerne, a można popatrzeć pod kątem security i phishingu, co w sieci piszczy.

Problem

Niestety, zauważyłem korzystanie z certstream jak w przykładach, z użyciem biblioteki Pythona nie jest idealne. Problem objawia się tym, że co jakiś czas następuje zerwanie połączenia z serwerem widoczne jako:

[ERROR:certstream] 2021-11-22 17:18:01,171 - Error connecting to CertStream - Connection to remote host was lost. - Sleeping for a few seconds and trying again…
[INFO:certstream] 2021-11-22 17:18:06,564 - Connection established to CertStream! Listening for events…
[ERROR:certstream] 2021-11-22 17:18:51,893 - Error connecting to CertStream - Connection to remote host was lost. - Sleeping for a few seconds and trying again…
[INFO:certstream] 2021-11-22 17:18:57,213 - Connection established to CertStream! Listening for events…

Początkowo nie wydawało się to dramatem. Kilka sekund przerwy, co parę minut nie powinno mocno wpływać na wyniki. Niestety, pominięte certyfikaty okazały się zauważalne, więc zacząłem szukać przyczyny i rozwiązania tego problemu.

Debug

Na pierwszy ogień poszła wyszukiwarka. Okazało się, że ludzie mają ten problem w różnych warunkach. Jedni sugerowali, że zależne jest to od wersji Pythona. Inni nie potwierdzali i sugerowali problem z serwerem certstream.calidog.io. Podejrzewałem także zbyt niską wydajność serwera VPS na którym działa skrypt, ale ten pomysł szybko odrzuciłem – na mocniejszym VPS nie było wielkiej różnicy. Problem nie był palący i przeleżał trochę czasu. Dopiero na którejś konferencji zaczepiłem Adama L., który również korzysta z certstream i zdarza mu się wspominać w prezentacjach o tym. Zasugerował problem z biblioteką, jej debug i zrobienie po swojemu, na wzór.

Zainspirowało mnie to do bliższych oględzin. Nie jest to trudne – biblioteka jest niewielka i prosta. Na pierwszy ogień poszła złożoność operacji wykonywanych w skrypcie podczas sprawdzania domen. Szybko jednak okazało się, że nawet nie wykonując jakichkolwiek operacji, nawet nie wyświetlając domen, nadal obserwuję rozłączenia. Postanowiłem spróbować skorzystać z innego serwera certstream, tym bardziej, że biblioteka wprost przewiduje zmianę URLa. Tyle, że miałem problem ze znalezieniem takowego.

Na szczęście CaliDog udostępnia także kod źródłowy serwera napisany w… Eliksirze. Nie ukrywam, że była to dla mnie nowość. Instalacja na Debianie była pewnym wyzwaniem. Dla leniwych jest dostępny obraz dockera, ale z pewnych względów stwierdziłem, że wolę zainstalować w systemie.

Instalacja serwera certstream na Debianie

Instalacja na Debianie Bullseye jest w zasadzie zgodna z tym, co napisano w instrukcji repo i na stronie Elixir. Czyli nie jest zgodna. Pierwsza sprawa, to brak pakietów dla Bullseye[1]. Bez problemu można jednak skorzystać z pakietów przygotowanych dla starszej wersji, czyli Buster. W pliku /etc/apt/sources.list.d/erlang-solutions.list powinno pojawić się zatem:

deb http://binaries.erlang-solutions.com/debian buster contrib

Kolejna rzecz powodująca problemy z uruchomieniem serwera certstream to konieczność doinstalowania pakietu erlang-dev:

apt-get install erlang-dev

Po tych zabiegach serwer powinien się bez problemu uruchomić. Domyślnie działa bez szyfrowania na porcie 4000, więc jeśli nie postawimy frontu z certyfikatem SSL, to URL serwera certstream zmieni się z domyślnego wss://certstream.calidog.io na ws://NASZ.ADRES:4000 – trzeba podać port i usunąć jedno s.

Po uruchomieniu własnego serwera i podłączeniu tego samego skryptu, z tego samego VPSa, okazało się, że rozłączenia prawie nie występują. Zaś porównując ilość zgubionych domen okazało się, że jest ich znacznie więcej, niż przypuszczałem. Nawet średnie kilkadziesiąt procent.

Serwis

Do pełni szczęścia brakuje tylko, aby wszystko działało automatycznie. Można to uzyskać tworząc serwis. Można np. utworzyć plik:

/etc/systemd/system/certstream-server.service

o zawartości

[Unit]
Description=Certstream server service
After=network.target
StartLimitIntervalSec=3

[Service]
Type=simple
Restart=always
RestartSec=1
User=certstream
WorkingDirectory=/opt/certstream-server
ExecStart=/usr/bin/mix run --no-halt

[Install]
WantedBy=multi-user.target

Następnie należy zarejestrować serwis i można cieszyć się serwisem uruchamiającym się automatycznie podczas startu systemu. A także po ew. awarii. Ścieżki i user do dokonfigurowania we własnym zakresie.

[1] UPDATE: Część o braku pakietów dla Bullseye jest nieaktualna. Ze sporym opóźnieniem, ale się pojawiły. Warto zatem korzystać z wersji dedykowanej dla używanej dystrybucji.