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.

Feedburner wymaga IPv6

Od jakiegoś czasu w zadaniach do zrobienia miałem następujące zadanie związane z migracją bloga w nowe miejsce: poprawić RSS Feedburner. Teoretycznie to są trzy kliknięcia, ale przy próbie zmiany źródła feeda dostawałem niewiele mówiący komunikat:

An error occurred connecting to the URL: unknown error

W logach serwera brak jakiejkolwiek informacji połączenia, komunikat enigmatyczny, myślałem, że coś po stronie Google, jakiś cache, DNS, coś takiego. Chciałem nawet napisać do supportu, ale Feedburner nie posiada takowego – jak widać Google niezbyt dba o ten serwis. Są nawet głosy, żeby przenieść się z Feedburnera – może niebawem, póki co zostaje jak jest.

Sprawa była niezbyt pilna – tam gdzie mi zależało najbardziej, podałem bezpośredni URL do feedu RSS. Część ludzi ma jednak podany stary feed, tak też kieruje stary blog i zapowiadałem, że będzie on aktualny, więc wypadało naprawić.

Dziś zrobiłem test SSL i w oczy rzuciło mi się, że serwer WWW słucha tylko na IPv4. Zamierzona zaszłość. Teoretycznie przy braku łączności po IPv6 w większości popularnych implementacji powinno nastąpić połączenie po IPv4 (mechanizm Happy Eyeballs i podobne), ale jak widać Feedburner tego nie robi i wymaga serwera słuchającego na adresie IPv6, jeśli tylko domena bloga posiada rekord AAAA.

Błędu nie zgłoszę, skoro Google nie chce. Poprawiłem konfigurację serwera, by słuchał także na IPv6 i feed działa. W sumie mój błąd, że nie odpaliłem sniffera od razu przy diagnostyce, ale odrobinę lepszy komunikat błędu, np. connection to ADRES_IP failed wyjaśniał by wszystko.

W każdym razie do zapamiętania: jeśli chcemy, by Feedburner działał dla domeny rozwiązującej się na IPv4 i IPv6, to serwer musi słuchać na IPv6.

IPv6 w 2016 – zmiany w tunelach

Pierwszego kwietnia SixXS wysłał do swoich użytkowników maila, w którym poinformował, że

We are now fully stopping accepting signups and tunnel & subnet requests.

Czyli że ograniczają świadczenie usług do istniejących klientów i usług. Decyzja jest motywowana brakiem czasu oraz tym, że część ISP uważa, że darmowe tunele IPv6 są dla nich alibi do nie wdrażania IPv6 swoim klientom końcowym.

Unfortunately it seems a large number of ISPs think that our service is
a free pass for them to not deploy IPv6, as they direct their (paying)
customers who want IPv6 to our service.

Trudno się z tym nie zgodzić. Wdrożenia IPv6 są rzadkością, także – czy może raczej: zwłaszcza – w Polsce (tu ciekawa prezentacja z Orange z komentarza do innego wpisu, dzięki za podrzucenie).

Piszę o tym z dwóch powodów. Po pierwsze, gogoNET ogłosił, że się zamykają:

After 5 years we are closing down gogoNET on April 23, 2016.  Freenet6 will continue to work for some time but we can’t guarantee for how long.

Po drugie, umknęła mi dość istotna akcja pt. zadzwoń do ISP po IPv6. Jest też uruchomiona wiki, gdzie można wpisywać co udało się osiągnąć w sprawie IPv6.

Nie jestem do końca przekonany, czy rewolucję należałoby faktycznie zaczynać od ISP, ale faktem jest polscy dostawcy treści nadal nie dystrybuują treści po IPv6 (brak rekordów AAAA, źródło ww. prezentacja), a IPv6 w większości przypadków jest poruszane jedynie od święta, na spotkaniach branżowych typu PLNOG.

Warto w tym momencie przypomnieć (nieco zbyt ambitne IMO) stanowisko prezesa UKE, zakładające, że końcowi użytkownicy otrzymają publiczne adresy IPv6 od stycznia 2012 (stacjonarni, mobilni rok później). Tymczasem otwarte pozostaje pytanie kiedy nadejdzie era IPv6?

To co, „zadzwonimy” do ISP? Wpisujcie na wiki i w komentarzach, co usłyszeliście. A cudzysłów, bo może być zgłoszenie emailem czy zapytanie w social media. Kto wie, czy to ostatnie nie jest najlepsze…