Kategoria: Inne

Opublikowane w

Idź na socjal

Idź na socjal – tak właśnie można przetłumaczyć GoToSocial, czyli nazwę serwera ActivityPub napisanego w Golangu. Czyli serwera, by zaistnieć w Fediverse. Bo Mastodon może i jest popularny, ale nie jest jedyny.

GoToSocial był moim wyborem do zabawy z Fediverse już dawno temu, jednak wymagania nieco odstraszały. Głównie te związane z VPSem i jego parametrami. Co prawda niby powinno działać na mniej niż 1 GB RAM i kilkanaście GB dysku, ale jakoś nie miałem gdzie tego wcisnąć na istniejących maszynkach. Zwłaszcza, że chodzi wyłącznie o zabawę.

Jak wspominałem we wpisie o Sesji Linuksowej, wygrałem talon na VPS mikr.us. I niedawno go zrealizowałem na potrzeby innego projektu. Zasobów jest tam dużo za dużo, więc idealny moment, by pobawić się GoToSocial. Tym bardziej, że VPS na mikr.us nie pozwala na uruchomienie kontenerów LXC. W każdym razie mi się nie udało, a konsultacja na Discordzie potwierdziła, że się nie da. Za to działa docker.

Nie jestem fanem dockera. Zdarza mi się go używać, ale raczej nie jest pierwszym wyborem. Jednak i Uptime Kuma, i GoToSocial dają obrazy i sensowną – na pierwszy rzut oka – dokumentację. Postanowiłem spróbować.

Z dokumentacji GoToSocial dowiedziałem się, że potrzebuję otwartego portu 443 oraz osobnej domeny dla instancji. Ogólnie wymagania są nieco dziwne. Po pierwsze, nie można wykorzystać dowolnego portu. Na mikrusie to problem, bo o ile możemy sobie przekierować kilka portów, to są to inne porty niż 443. Po drugie, domena jest trwale przywiązana do instancji (a w zasadzie kluczy), co oznacza, że nie można zmienić oprogramowania serwera na tej samej domenie.

Wziąłem zatem darmową (sub)domenę, którą wykorzystam tylko do tego jednego celu i tylko do testu. Mikrus daje normalny dostęp po IPv6, bez konieczności przekierowywania portów, a większe serwery działają w dual stack, wiec stwierdziłem, że instancja będzie dostępna wyłącznie po IPv6.

Ostateczny setup na który się zdecydowałem to: GoToSocial w dockerze (tylko IPv4), nginx na froncie, robiący za reverse proxy, nasłuchujący na porcie 443 i adresie IPv6. TLS od Let’s Encrypt z wykorzystaniem certbota, terminowany na nginx. Dla domeny ustawiłem wyłącznie rekord AAAA. Czemu tak? Bo tak jest najwygodniej i standardowo. Mógłbym pominąć nginx, ale straciłbym wszystkie dodatkowe możliwości typu bezproblemowy rate limit. I musiałbym włączyć IPv6 w dockerze.

Uruchomienie nie było bezproblemowe. Już sama konfiguracja i start dockera sprawiły trudności. Przyczyną były oczywiście uprawnienia do katalogów. Niby jest to pokazane w logach, ale zachowanie jest nieco dziwne, zwł. w kwestii tworzenia nieistniejących katalogów. Jednak w końcu docker ruszył.

Dla odmiany z nginx poszło łatwo. Przykładowy konfig zadziałał niemal od kopa, drobnego dostosowania wymagała jedynie obsługa http2 w starszej wersji nginx. Uroki Ubuntu 24.04 LTS. Gdy już wszystkie znaki na niebie i ziemi wskazywały, że powinno działać, przyszła pora na dodanie użytkownika.

Tu nastąpiło moje lekkie zdziwienie, bo GoToSocial nie oferuje żadnego panelu, jedynie API. Użytkowników zakłada się z wiersza poleceń. Nieco dziwny wybór i raczej nie przysporzy popularności rozwiązaniu, w każdym razie nie poza grupą geeków. Kolejną konsekwencją jest konieczność połączenia się jakimś klientem, bo nie ma interfejsu WWW.

Czyli kolejny problem, bo okazało się, że nie mam dostępu do IPv6 z domu. Ani korzystając z internetu w domu od ISP, ani na telefonie, po wyłączeniu WiFi. To ostatnie mnie zdziwiło, byłem przekonany, że GSM to głównie IPv6. Na szczęście jest Pinafore, czyli klient dostępny w przeglądarce. Do tego tunel SSH do VPSa z IPv6[1], rozwiązywanie nazw DNS po socks proxy i… mogłem zobaczyć swoje konto i napisać coś.

Niektórym to może wystarczyć, jednak idea jest nieco inna. Powinna być możliwa interakcja z innymi instancjami. Wyszukałem jakieś konto w Pinafore, wybrałem follow, powtórzyłem dla kilku innych i… żadnego efektu. Informacja o oczekiwaniu na zatwierdzenie. Tylko te konta nie wymagały zatwierdzania. Sprawdziłem na swoim podstawowym koncie, na którym dla odmiany wymagam zatwierdzenia obserwacji. Ten sam efekt – pokazywało, że czeka na zgodę, ale nie dostałem zapytania o zgodę. No i nie mogłem z podstawowego konta wyszukać konta na testowej instancji. Czyli coś nie działa.

Diagnostyka tego zajęła sporo czasu, usłyszałem, że z IPv6-only bywają problemy, dostałem niepocieszające opisy problemów z GoToSocial i forwardowaniem portów przy NAT i w zasadzie już miałem stwierdzić, że gdzieś zrobiłem błąd, gdy skutecznie zaobserwowałem konto na instancji, która miała tylko adres IPv4 i korzystała z GoToSocial. Natomiast konta na serwerach Mastodon pozostawały niedostępne. Także na tych, które miały tylko IPv4.

Ostatecznie znalazłem instancję Mastodona, posiadającą zarówno adres IPv4 jak i IPv6, gdzie mogłem normalnie obserwować konta[2]. Dostrzegłem też w gąszczu logów błędy 503 przy próbach interakcji z innymi instancjami (subskrybcji). Czyli jakiś problem z kompatybilnością softów GoToSocial i Mastodon, nie u mnie z konfiguracją.

Jak już było wiadomo czego szukać, to ustaliłem, że z Mastodon v4.8.0-alpha.1 działa (dual stack), za to nie działa z v4.8.0-nightly.2026-08-27 (też dual stack) ani v4.7.0 (wyłącznie IPv4). Z kronikarskiego obowiązku, używana przeze mnie wersja to 0.22.1+git-fdff42b.

Co dalej? Pewnie nic. Może jeszcze coś mi przyjdzie do głowy, zasobów na VPS nie potrzebuję, więc zabawek nie zbieram. Przy okazji obserwacja: wymagania podawane przez dokumentację GoToSocial wyglądają na zawyżone, ale może to być kwestia obliczania pod ilość userów i interakcji zewnętrznych. Do samego postawienia opisanego setupu wystarczy spokojnie 0,5 GB RAM, na Ubuntu.

Natomiast w kwestii rozważań o selfhostingu, własnej instancji itp. – wygląda, że rozwiązanie nie robi i ciężko stwierdzić dokładnie, dlaczego. Kolejna lekcja to konieczność posiadania adresu IPv4, co skreśla mikrusa. Może być ciężko podłączyć się do instancji bez takiego adresu. Teoretycznie rozwiązaniem mógłby być Cloudflare, ale na takie eksperymenty zupełnie mi odeszła ochota, skoro nie działa zasadnicza część.

[1] Zupełnym przypadkiem tego samego, na którym działa serwer GoToSocial, ale to bez znaczenia.
[2] Popularne Dziesiony. Szacun dla administratorów.

Opublikowane w

Won, Halski!

Za sprawą kodu promocyjnego na kawę dowiedziałem się, że InPost zrobił platformę sprzedażową i zmiany w appce na telefony. Z tej okazji trochę pierwsze wrażenie z korzystania i nieco przemyśleń w temacie.

Po pierwsze, chętnych do tortu e-commerce i platformy sprzedażowej na wzór Allegro jest wielu. Pomijając zagranicznych gigantów, mamy na polskim rynku – wymieniając na szybko, z głowy: erli.pl, Empik, mBank. I teraz InPost. Często są to twory zrobione na przyczepkę, w stylu „mamy X klientów na coś innego, sprzedawajmy też mydło i powidło”.

Moje doświadczenia z platformami są takie, że na Allegro kupuję regularnie i jest to pierwszy wybór. Znam interfejs, jest spory wybór, jest przewidywalne. Wady to coraz trudniejsze wyszukiwane z uwagi na zalew ofert promowanych i coraz mniej atrakcyjne ceny.

Empik, który kojarzył się ze sklepem z kulturą, zaczął parę lat temu sprzedawać różności. Jakieś karmy dla zwierząt, jakieś śrubki. Zdarzyło mi się parę zakupów tam, zwykle jakieś promocje, ale nie korzystam regularnie. Erli.pl – podchodziłem parę razy i… nic nie kupiłem, ostatecznie. Słaby wybór i ceny, za to wyszukiwanie i wygląd podobają mi się (desktop), takie odchudzone Allegro. Ostatni jest mBank, który wprowadzając zakupy do appki stracił u mnie sporo wizerunkowo jako bank, a nigdy niczego nie kupiłem.

No i na to wszystko na rynek wchodzi InPost. Z jednej strony rozumiem, bo po co przewozić cudze zakupy, skoro można własne. Podobnie – choć z drugiej strony – podeszło Allegro, budując swoją sieć dystrybucji. Po co płacić za dostarczenie zakupów komuś, skoro można to zrobić samodzielnie? Ale styl wejścia na rynek…

Jest na bogato. W appce do odbioru przesyłek pojawił się animowany pies, a cały proces zorientowany jest pod tego psa. Teksty itp. Czuć, że włożono w to sporo pracy. Tylko ten pies zupełnie mi się nie kojarzy z InPostem, wygląda na wziętego z innej bajki i wklejonego. No dobrze, ale odpalam appkę nie po to, żeby psa oglądać.

Zdarzyło mi się kupić w appce InPostu. Akurat pojawiła się w promocji oferta na kawę, o której dowiedziałem się z innego źródła, appkę już miałem, kawę piję. Stwierdziłem, że kupię, bo kilogram kawy za 35 zł to dobra cena. W aplikacji okazało się, że dodatkowo jest darmowa dostawa, więc już zupełnie dobrze.

Tyle, że interfejs jest tragiczny. Pomijam psa, który nic nie wnosi. Chodzi o to, że zapytanie do wyszukiwania obowiązkowo przechodzi przez asystenta AI. Pobawiłem się chwilę i faktycznie jest LLM pod spodem, to nie stylizacja. Nie wiem kto wpadł na pomysł, że wpisywanie tekstu na ekranie telefonu w celu przetworzenia przez AI, jako podstawowa metoda interakcji to coś, co się ludziom spodoba. No mi się nie podoba. W dodatku AI oznacza dodatkowe oczekiwanie na wynik. Męczące.

W zastosowaniach typowo LLMowych też sobie nie radził za dobrze. Wrzuciłem, że mam 100 zł do wydania i… no słabo sobie poradził. Propozycje nietrafione, nie dopytywał. Za to coś pobredzał o poprzednich zakupach (niezbyt trafnie). Ale nie chciał podać, skąd ma dane. Nie wiem jak to wygląda u innych, bo nigdy nie próbowałem korzystać z asystenta AI. Zupełnie nie mam potrzeby korzystać z niego w pojedynczym sklepie w jakiejś wersji, która nie wiem, co robi. Jeśli szukam czegoś i chcę skorzystać z LLMa, to wolę z „pełnego”, niezależnego od sklepu, mającego dostęp do sieci.

Sam zakup wyglądał tak, że znalazłem inną kawę, niż ta za rzekome 35 zł. Bardziej mi pasowała z opisu. Dodałem ją do koszyka, wpisałem kod, obniżył cenę o 15 zł. Spróbowałem zmienić na tę z promocji, już tylko, żeby sprawdzić cenę, bo coś mi się nie zgadzało i… kod nie wchodził w ogóle. Albo coś skopane, albo literówka.

Okazało się, że zamówień jest dużo, więc dostałem maila, że się przedłuży. Nie dostałem informacji o ile. Nie dostałem też (albo nie zauważyłem) powiadomienia (mail), że paczka dotarła i czeka w paczkomacie. Aplikacja Allegro sygnalizuje to o wiele lepiej. I chyba dodatkowo wysyła SMSa.

I tak sobie myślę, że po tym, co zobaczyłem, raczej nie palę się do zakupów w InPost. Jasne, dam się skusić na kolejny kupon, ale tak bez okazji, to chyba nie. No chyba, że mocno to wszystko poprawią.

Opublikowane w

Uptime

W ramach side questa potrzebowałem monitoringu dostępności stron WWW, z API i dość dużą liczbą monitorowanych serwisów. Powiedzmy od 100 w górę. I najchętniej za darmo, bo potrzebuję tylko do PoCa. I fajnie, jakby umiał monitorować nieco częściej, niż raz na 5 minut.

Zdziwiłem się, bo okazało się, że… nie ma. A przynajmniej nie znalazłem. Oczywiście jest Uptime Robot, którego – jak się okazało – używam od ponad dekady. Z własnym narzędziem do wyświetlania dashboardu. No ale tam mam sporo slotów zużytych z 50, które może od biedy by wystarczyły.

Jestem zdziwiony, bo tego typu monitoring jest w miarę tani. Bo czymże jest request HTTP czy wysłanie pakietu ICMP raz na minutę i zapamiętanie stanu. A dla wysyłki poczty (SMTP relay) serwisów pozwalających nawet niewielkie newslettery jest całkiem spory wybór. I wygląda na nieco bardziej inwazyjne, potencjalnie (spam). No ale nie ma i co zrobisz, trzeba selfhostować. Za to będzie pełna dowolność w interwałach sprawdzania dostępności.

Szybko odpędziłem myśl o napisaniu własnego rozwiązania, bo tak, plik YAML z definicjami serwisów, prosty skrypt w Pythonie z wykorzystaniem biblioteki requsets, napędzany cronem spokojnie by wystarczył do tego, co chcę osiągnąć. Postanowiłem rozejrzeć się za gotowcami.

No i znalazłem coś, co mnie nawet zachwyciło. Nazywa się Uptime Kuma, daje API, daje ładny frontend, sensowną dokumentację w zakresie uruchomienia, obsługuje wiele kanałów powiadomień. Od początku ujęło mnie tym, że potrafi korzystać zarówno z bazy sqlite, jak i MySQL, więc przy małych zastosowaniach można sobie trzymać bazę w pliku, bez kolejnego serwera.

Oczywiście są wady. Po pierwsze nie przepadam za technologią, w której jest stworzone rozwiązanie. Po drugie, dedykowana biblioteka Pythona do obsługi API nie działa poprawnie. W sumie przez to straciłem więcej czasu, niż na uruchomienie monitorigu + reverse proxy w oparciu o nginx. Skończyło się tym, że nie korzystam z dedykowanej biblioteki, tylko robię requesty na żywca.

Gdyby ktoś chciał sobie porobić wykresy albo monitorować usługi – polecam sprawdzenie Uptime Kuma. 90k gwiazdek na GitHub nie jest przypadkiem.