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ęść.

UPDATE: Trochę mi to nie dawało spokoju, więc sprawdziłem większą ilość serwerów. Nie wszystko działa, ale coś tam działa. Problem jest chyba tylko z serwerami Mastodon, ale niestety są to duże instancje, co przekreśla sens rozwiązania. Posty z nich widzę, profile widzę, ale nie mogę obserwować kont.

Nieco rozrywki/stan oprogramowania. Mój GoToSocial obecnie przedstawia się home to 0 users who have written 2 posts; peered with 29 other instances. Off by one?
Przy 11 obserwowanych.

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

Ubuntu – płatne bezpieczeństwo

Ubuntu LTS kojarzy się nam z dystrybucją stabilną i bezpieczną, prawda? Otóż niezupełnie tak jest. Bowiem nie wszystkie pakiety w Ubuntu LTS (np. 20.04 LTS czy 22.04 LTS) otrzymują aktualizacje bezpieczeństwa. Przynajmniej nie za darmo. Od strony technicznej, które pakiety otrzymują aktualizacje (main), a które niekoniecznie (universe) przeczytacie w artykule na nfsec.pl, podobnie jak o genezie szumu wokół Ubuntu i repozytorium ESM (Expanded Security Maintenance).

Zarys sytuacji

Zamiast na stronie technicznej, skupię się na stronie etycznej i prawnej. Sytuacja wygląda bowiem na dość skomplikowaną. Tytułem wprowadzenia niezbędny skrót. Ubuntu w ramach Ubuntu Pro daje między innymi dostęp do repozytorium ESM, które zawiera łatki bezpieczeństwa do tych pakietów z repozytorium universe, do których zostały one przygotowane przez opłaconych przez Ubuntu maintainterów, zamiast przez maintainerów ze społeczności. Osoby fizyczne (personal) mogą bezpłatnie korzystać z Ubuntu Pro na maksymalnie 5 systemach. Natomiast firmy (enterprise) powinny zapłacić za dostęp, albo… nie korzystać z załatanych pakietów. Jest jeszcze trzecia kategoria – edukacja (education, research, and academia). Też powinni kupić, ale dostaną zniżkę w niejawnej wysokości.

Abonament na bezpieczeństwo

Mam mocno mieszane uczucia w stosunku do tego podejścia. Z jednej strony nie ulega wątpliwości, że maintainerzy, którzy wykonali na zlecenie pracę, której nikt nie chciał podjąć się za darmo, powinni otrzymać wynagrodzenie. Z drugiej strony, jest to podcinanie gałęzi, na której się siedzi i z której Ubuntu wyrasta. Bowiem maintainterzy społeczności mogą dojść do wniosku, że nie ma sensu robić za darmo tego, za co inni otrzymują wynagrodzenie. To z czasem może przełożyć się na gorsze wsparcie wolnego oprogramowania, w szczególności dystrybucji opartych o pakiety deb.

Kolejny aspekt to pewnego rodzaju szantaż w stosunku do użytkowników. Niby system i oprogramowanie są za darmo, ale jak chcesz mieć bezpiecznie, to zapłać… Płatne bezpieczeństwo to skomplikowane zagadnienie. Co powiecie na abonament na ABS, poduszki powietrzne czy pasy bezpieczeństwa w aucie? Albo jeszcze lepiej: hamulce w wersji zwykłej i pro, te drugie zapewniające krótszą drogę hamowania? I wszystko to rzecz jasna w formie abonamentu, czyli wszędzie jest zamontowane, ale trzeba zapłacić, by było aktywne.

Opłata za udostępnianie

No i ostatnia sprawa – czy Ubuntu może w ogóle brać pieniądze za udostępnianie oprogramowania na wolnych licencjach? Ograniczę się do licencji GPL. Zarówno wersja druga, jak i trzecia GPL wprost mówi, że akt udostępnienia oprogramowania może być zarówno darmowy, jak i płatny. Czyli Ubuntu może żądać wynagrodzenia za udostępnienie oprogramowania.

Jednak jednocześnie GPL zabrania zmiany licencji[1], a licencjonobiorca nabywa wszystkie prawa. W szczególności prawo do dalszej dystrybucji. Czyli czy dowolna osoba może skorzystać z Ubuntu Pro w wersji personal, pobrać z repozytorium ESM pakiety lub kod źródłowy i udostępnić je na swoim serwerze każdemu chętnemu? IANAL, ale wygląda na to, że tak. Przynajmniej te pakiety/patche wydane na licencji GPL.

O sprawie zaczęło się robić głośno dopiero teraz i sam jestem ciekaw, czy jakoś bardziej się to rozwinie i jak się ostatecznie skończy. Trzeba pamiętać, że Ubuntu Pro to znacznie więcej, niż tylko dostęp do załatanych pakietów z repozytorium universe w ramach ESM. To także możliwość aktualizacji kernela bez konieczności restartu systemu, support 24/7. Być może lepszą strategią dla Canonical byłoby udostępnienie patchy społeczności za darmo? Tym bardziej, że z prawnego punktu widzenia raczej są na przegranej pozycji, przynajmniej w kontekście licencji GPL.

[1] Pomijam tu przypadki oprogramowania wydawanego równolegle na kilku licencjach. Wówczas można wybrać, którą licencję się wybrało i modyfikować tylko kod na tej wybranej, dystrybuując go zgodnie z jej – i tylko jej – postanowieniami.

Pretekst

Od jakiegoś czasu szukałem pretekstu, żeby pobawić się maszynkami z Ampere A1 od Oracle. Poza tym, w zadaniach przetestowanie Cloudflare na blogu wisiało… prawie 5 lat. I jeszcze na dodatek gorącym tematem jest AI, często reprezentowana ostatnio przez ChatGPT. Ale jakoś na nic nie było czasu i potrzeby.

Zatem wpadłem na pomysł, żeby postawić bloga, który będzie WordPressem, stojącym na VMce z arm64, za Cloudflare, a treść dostarczać będzie głównie AI. Trzy pieczenie na jednym ogniu. W sumie cztery, bo jeszcze sprawdzę indeksowanie tego tworu i zarobię miliony na reklamach. Poznajcie blog everything about coffee.

Przyznam, że było trudniej, niż się spodziewałem. Najpierw był problem z wyborem domeny. Stwierdziłem bowiem, że taki eksperyment wymaga stosownej separacji. W domenach raczej nie siedzę, więc znalezienie czegoś sensownego w niewielkich pieniądzach było trudne. Stanęło na tym, że analogicznie jak na głównej domenie niech się składa w jedno słowo. I tak powstał coffee express. Bez es. W sumie także bez e w środku, bo byłyby aż trzy kolejno, ale to już wybór, nie ograniczenie techniczne.

Domena

Wydawać by się mogło, że kupno domeny w 2023 jest proste, szybkie i przyjemne. Sprostuję, nie jest. A przynajmniej nie jest, jeśli korzysta się z TLD .es a kupuje w OVH. Rejestrator ma teraz dziwne wymagania, panel OVH ma dziwne pola i komunikaty. Ostatecznie udało się, po kontakcie z supportem OVH. Dwukrotnym.

Hosting

Jeśli chodzi o Ampere A1, to ostatecznie odpuściłem instalację Debiana, którego Oracle nie dostarcza i użyłem gotowca w postaci Ubuntu. Przynajmniej na podstawce AKA hypervisorze, bo sam blog stoi już w kontenerze LXC z Debianem. Za wiele się tam nie dzieje, ale – po krótkim obcowaniu – maszynka wygląda na wydajną i generalnie śmiga.

Cloudflare

Przepięcie domeny na Cloudflare – szybkie, łatwe i przyjemne. Podpowiadają co mają podpowiadać, autouzupełnianie działa. Panel przejrzysty, ustawienia domyślne sensowne. Opcji w wersji darmowej niewiele, ale wystarczają.

Oczywiście jest tricky part związana z certyfikatami SSL czy ustawieniami DNS, jeśli chce się mieć coś dostępne bezpośrednio, ale da się. No i wypada zablokować ruch HTTP(S) do serwera spoza Cloudflare. Jest wiele sposobów, wybrałem prawdopodobnie najprostszy i najgorszy, czyli iptables z wyjątkami na klasy adresowe Cloudflare na maszynie. Może kiedyś zmienię.

WordPress

Stawianie WordPressa także okazało się pewnym wyzwaniem. Może nie tyle samo postawienie, co doprowadzenie do działania. W każdym jakby ktoś wybrał wariant z ruchem nieszyfrowanym między blogiem a Cloudflare, czyli teoretycznie najprostszą opcję, to może się naciąć. W praktyce chyba prościej uruchomić to jako szyfrowane, z certyfikatem self signed. Nie obyło się bez grzebania w wp-config.php. Poza tym, raczej było prosto. Najwięcej czasu zeszło na wybór grafiki i ręczną instalację i konfigurację wszystkich wtyczek do WordPressa, których używam.

ChatGPT

No i na koniec część związana z AI. Jak łatwo można się domyślić, bawiłem się chatGPT przy porannej kawie i wtedy powstał pomysł na bloga generowanego przy pomocy AI. No właśnie nie przez AI, a przy pomocy. Co to znaczy? Ano to, że może się zdarzyć, że ingeruję w odpowiedzi zwrócone przez chatGPT. Łączę je, przycinam, albo dodaję coś od siebie. Ale nie jest to regułą i zwykle po prostu przeklejam wprost. Bez korekty, sprawdzania faktów itd. Błędy się zdarzają, o czym można przeczytać choćby w komentarzach do tego wpisu. Poza tym, nie podaję prompta i sam, ręcznie wybieram tytuł. Ot, powiedzmy taki asystent leniwego copywrightera w postaci AI. Co do zasady muszę zmieścić się z utworzeniem wpisu od początku do końca przy paru łykach porannej kawy.

Projekt nie jest skończony. Marzy mi się dorzucanie powiązanych obrazków do każdego wpisu. Najchętniej automatyczne. Brakuje detali typu favicona czy optymalizacja szybkości. Choć ten w zasadzie goły WordPress za Cloudflare działa wg GTmetrix podobnie szybko, co ten blog. Nad wyświetlaniem reklam nadal pracuję – chwilę to trwa już po stronie Google No i oczywiście wpisów na razie jest mało, a chciałbym dodawać około dwóch tygodniowo, przynajmniej przez najbliższych parę miesięcy.

DeepL

UPDATE: Do gromady dołączył jeszcze DeepL, a dokładnie Write. Coraz częściej zdarza mi się dodać coś od siebie, poza tym ChatGPT pisze dość sucho i encyklopedycznie. Nie używam domyślnie, raczej sporadycznie póki co. I uwzględniam tylko niektóre sugestie, ale warto wspomnieć i o tym narzędziu.