Tag: serwer

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.

Opublikowane w

Bullseye

Zakończyłem aktualizację ostatniej[1] maszyny do Debiana 11 czyli Bullseye, pora na tradycyjne podsumowanie.

Najpierw zaktualizowałem kontenery. Operacja totalnie bezproblemowa przy pomocy apt. Czyli wariant zalecany. Z większych zmian warto jedynie odnotować zmianę wpisu dla repozytorium security w sources.list.

Główny host jedynie odrobinę gorzej. Coś mu nie poszło przy zależnościach i odinstalował mariadb. Konfiguracje i dane zostały, więc przywrócenie trwało moment. Niemniej miał prawo się pogubić, korzystam z dodatkowych repozytoriów w tym systemie.

Desktopy również niemal bezproblemowo, w tym przejście z unstable na stable przy okazji upgrade. Jedyne z czym był problem to WiFi i wicd. Z uwagi na zależność od Pythona 2.x pakiet jest usuwany i… skończyłem bez sieci na pierwszym systemie. Rozwiązanie jest proste: wystarczy przeprosić się z network managerem i zainstalować go zamiast wicd przed aktualizacją. Po takim zabiegu aktualizacja bezproblemowa.

Ostatnie było Raspberry Pi robiące za router GSM. Tam co prawda jest Raspbian, nie Debian, ale można powiedzieć, że także była to aktualizacja do Bustera z uwagi na zmiany wpisów w sources.list. Nieco się pospieszyłem i instalowałem jako wersję niestabilną. Niemniej – bez problemu. Choć przygotowałem się na reinstalację systemu i operację przeprowadzałem nie zdalnie, a z fizycznym dostępem do sprzętu.

Ogólnie wygląda na brak większych zmian i chyba najbardziej bezproblemową aktualizację w historii. Jedyne co zauważyłem, to nieco większe zużycie miejsca na dysku. Generalnie tak to już bywa, że nowszy soft jest większy niż stary, ale w przypadku maszyny z kontenerami lxc zabolało to nieco bardziej. Dobiłem do granicy wolnego miejsca na dysku przy wykonywaniu się backupów. IIRC nie skończyło się zupełnie, ale było dosłownie na styk.

Zrobiłem porządki zarówno w logach, zbędnych rzeczach, jak i pakietach. Okazało się bowiem, że w kontenerach mam trochę nadmiarowych rzeczy. Przy tej ostatniej operacji okazało się, że na jednym z kontenerów apt działa wolno. Pobieranie działało normalnie, przeliczanie zależności także. Natomiast każde dodanie lub usunięcie pakietu zaczynało się od przestoju, podczas którego nic się na oko nie działo. Szybki strace ujawnił, że chodzi o okolice dbus. Usunięcie pakietu – kolejnego zbędnego, zresztą – rozwiązało problem.

[1] Tak naprawdę jeden kontener został na Buster i póki co zostanie – soft do generowania Planety Joggera zniknął z Bullseye. I raczej nie wróci, więc trzeba pomyśleć nad przesiadką na inny soft. Niemniej, nic związanego z samym systemem.

Opublikowane w

Zmiany we free tier w Google Cloud Platform

Tytułem wstępu: Google ma swoją chmurę, czyli Google Cloud Platform, a w ramach niej coś takiego jak free tier, czyli zasoby dostępne bez opłat[1]. Zasoby są niewielkie, dodatkowo podlegające pewnym ograniczeniom, raczej do zabawy. Ale do testów, nauki czy właśnie zabawy – idealne. Między innymi można mieć uruchomioną w ramach compute engine najsłabszą VMkę, czyli f1-micro.

Mail

Jeśli ktoś korzysta z GCP, to zapewne dostał już maila. Dla tych, co maila przeoczyli, krótkie podsumowanie. Od pierwszego sierpnia 2021 instancje e2-micro są bezpłatne (w określonej ilości czasu), natomiast od pierwszego września instancje f1-micro będą płatne. Regiony pozostają bez zmian. Instrukcja zmiany linkowana w mailu dostępna jest tu.

To różne platformy, więc ciężko porównać dokładnie, ale:
f1-micro to 0.2 VCPU i 0.6 GB RAM w cenie $0.0076 (us-central1)
e2-micro to 0.25 VCPU i 1 GB RAM w cenie $0.008376 (us-central1)
Dodatkowo w przypadku e2-micro możliwy jest burst do 2 VCPU.

Google pisze[2]:

As we improve the experience of the Free Tier, we will be introducing the E2-micro VM, which is a part of a second generation VM family.

Wydajność

W przypadku RAM zysk jest oczywisty, natomiast w przypadku CPU – niekoniecznie. Wiele zależy od tego, na jakiej platformie CPU znajduje się obecnie VMka, i na jakiej wyląduje po przeniesieniu. Tabela platform CPU dla serii N1 i E2 jest dość skomplikowana. Jednak patrząc na base frequency, przeciętnie powinno być szybciej.

I jeszcze wynik cat /proc/cpuinfo z mojej instancji f1-micro:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping : 0
microcode : 0x1
cpu MHz : 2299.998
cache size : 46080 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology n$
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips : 4599.99
clflush size : 64

Jak się zmigruję to uzupełnię wpis, co dostałem po migracji i jak wrażenia.

Migracja

Wczoraj zmigrowałem maszynę na e2-micro. Migracja błyskawiczna i bezproblemowa. Zgodnie z instrukcją zatrzymać instancję, wyedytować typ, zapisać zmianę, uruchomić maszynę.

Po migracji dostałem dokładnie ten sam procesor. Tyle, że teraz cat /proc/cpuinfo pokazuje dwa. Jeśli chodzi o osiągi i wydajność w praktyce, to najlepiej widać to na obrazku.

Wykorzystanie CPU na f1-micro i po migracji na e2-micro w GCP free tier
Wykorzystanie CPU na f1-micro vs e2-micro

Migracja chwilę przed 12:00, później wzrost obciążenia spowodowany porządkami, chwilę po 18:00 koniec ostatnich ręcznych prac. Jak widać, główny zysk wynika ze wzrostu mnożnika z 0.2 do 0.25 VCPU. Ponieważ przydział jest dynamiczny, procesy jednowątkowe także skorzystają na zmianie parametrów.

Podsumowując, warto migrować, bo e2-micro w stosunku do f1-micro oferuje 66% więcej RAM i 25% więcej CPU.

[1] Wymagane jest podpięcie karty debetowej, a po przekroczeniu puli darmowych zasobów jest automatycznie naliczana opłata za przekroczoną część.
[2] Nawiasem, wysłaniem tego maila Google Cloud Platform zdobyło u mnie sporo punktów sympatii. Mogli przecież np. zamieścić info o zmianie cenników free tier na blogu i billować nieuważnych, albo wysłać suchego maila o zmianach w cenniku. Wiele firm tak właśnie by postąpiło. A tu osobne, czytelne powiadomienie, z instrukcją migracji. Miło.