Zamknięcie serwisu jogger.pl

Wczoraj przeczytałem ogłoszenie o planowanym zamknięciu serwisu jogger.pl. Mimo wszystko smutno. Było to miejsce, gdzie znalazłem wiele ciekawych blogów (czyt.: ludzi), a przede wszystkim miejsce, gdzie zacząłem przygodę z blogowaniem. Więc trochę wspomnień jest. Nawet myślałem o tym niedawno, bo nie dalej jak parę dni temu wpisałem w CV w zdolnościach komunikacyjnych ponad dziesięć lat pisania blogów… No i cała otoczka sieciowa, od składni HTML przez Markdown i jakiekolwiek pojęcie o standardach dotyczących stron WWW, zawdzięczam Joggerowi.

Tak czy inaczej, wiadomo było, że zamknięcie jogger.pl nastąpi. Żaden serwis nie może stać w miejscu – albo się rozwija, albo – prędzej czy później – umiera. Widać było, że czasu i chęci na rozwój i utrzymanie brakuje coraz bardziej, a autorzy mają opory przed opublikowaniem kodu as is. Była co prawda propozycja przepisania Joggera, czyli wersji 3.0, ale jak pisałem, i za późno, i nie tędy droga.

Dawno temu porównywałem Joggera i Blox, nawet dwa razy. Pod wieloma względami Jogger miał bardzo ciekawe rozwiązania. Integracja z jabberem, poziomy wpisów, możliwość dynamicznych feedów RSS, ciekawy, dający bardzo dużą kontrolę nad blogiem, system szablonów. Udało się też przyciągnąć ciekawie piszących ludzi. TBH nadal regularnie czytam parę osób z Joggera. W pewnym momencie coś nie wypaliło/coś się posypało. Tak pobieżnie patrząc, to stała pięta achillesowa Joggera, czyli kontrola nad komentarzami i spamem… IMHO ciekawy temat do analizy, swoją drogą.

Pisałem już o tym w komentarzu (podkreślam, nie negując w żaden sposób praw właścicieli do kodu i domeny), ale powtórzę, bo to nie jest IMO dobre zamknięcie. A komentarz stamtąd zaraz zniknie:

  1. Mało czasu na wyniesienie się. Pięć tygodni przy braku narzędzi i planu, to niewiele. Nie widać powodu, czemu akurat teraz i tak nagle. Oczywiście może być coś, o czym autorzy nie chcą/nie mogą pisać. Ale chyba można by ten czas wydłużyć.
  2. Można było rozważyć przejście do wersji archiwalnej – read only, bez możliwości komentowania. Przypuszczam, że całość obecnie dostępnej treści to raptem małe kilkaset GB. Zatem koszt utrzymania i nakład pracy są minimalne, podejrzewam, że aktualnie używający chętnie się zrzucą.
  3. Można w końcu uwolnić kod źródłowy – jest tam parę osób technicznych, może ktoś się skusi na kontynuację, może pohostuje innym…
  4. Można sprzedać serwis bez danych osobistych. Wystarczy nie eksportować/usunąć wpisy na poziomie 3 i wyższych.
  5. Nieszczęśnikom, którzy nie korzystali z własnych domen można udostępnić subdomeny na prawach domeny.
  6. No i w końcu: można było zapytać ludzi, jakie widzą rozwiązania.

Tak czy inaczej, kolejny serwis z którego korzystałem umiera (wcześniej zniknął blip.pl), i trochę żal. Szeroko rozumianej ekipie z Joggera dziękuję za wszystko.

UPDATE Administratorzy Joggera jednak nie planują po prostu trzasnąć drzwiami. Kwiecień nie jest datą ostateczną, po prostu kod jest stary, utrzymanie pracochłonne stąd pomysł wyłączenia serwisu w dotychczasowej formie. Prawdopodobnie zostanie zachowana jakaś forma statyczna strony, archiwum i zbiór linków do miejsc, w których autorzy będą utrzymywać swoje blogi. Niemniej zamknięcie jogger.pl jest faktem.

UPDATE2 Statyczny mirror bloga na Joggerze można zrobić przy pomocy opisywanego kiedyś sposobu na backup bloga przy pomocy wget. Efekt działania wersji statycznej można zobaczyć tutaj.

Jak zrobić router GSM na Linuksie?

Niedawno miałem awarię netu. Stwierdziłem, że warto przy tej okazji poćwiczyć awaryjne udostępnianie sieci na Linuksie. Oczywiście zrobienie routera z komputera z Linuksem to kwestia paru poleceń, ale stwierdziłem, przećwiczyć udostępnianie sieci po WiFi.

Istnieje pakiet hostapd, który ułatwia zamianę komputera z Linuksem w access point. Instalacja pakietu hostapd:

apt-get install hostapd

Jakość pakietu nie zachwyca, ale jest niezły tutorial do hostapd. Skrypt init nie zadziała – należy go uzupełnić o ścieżkę do pliku – zmienna DAEMON_CONF. Podobnie sam pakiet nie dostarcza – jak to zwykle ma miejsce w przypadku pakietów Debiana – pliku konfiguracyjnego umieszczonego w katalogu /etc. Przykładowy plik konfiguracyjny dla hostapd znajdziemy jednak w /usr/share/doc/hostapd/examples.

Żeby nie przedłużać, poniżej cały plik konfiguracyjny, którego ostatecznie użyłem:

interface=wlan0country_code=PLssid=NAZWA_SIECIhw_mode=gchannel=6wpa=2wpa_passphrase=TAJNE_HASLOwpa_key_mgmt=WPA-PSKwpa_pairwise=TKIPrsn_pairwise=CCMPauth_algs=1macaddr_acl=0

Jak widać, są lekkie różnice w stosunku do tutoriala. Brakujące ustawienie zmiennej w skrypcie startowym znalazłem później, więc ostatecznie uruchamiałem hostapd z ręki, bez demonizacji (w ramach debugu, zresztą).

Oczywiście sama konfiguracja hostapd nie wystarczy. Trzeba mieć jeszcze skonfigurowane „przyjście” netu. W moim przypadku internet był dostarczony z modemu GSM (tutaj opis konfiguracji Aero2 na modemie Huawei E3131). Użycie modemu LTE pozwoli oczywiście zrobić szybszy router GSM na Linuksie. Przyda się również serwer DHCP i konfiguracja DNS. Obie rzeczy może załatwić dość dokładnie opisany kiedyś dnsmasq. Ale dla przydzielania adresów IP systemom łączącym się z naszym routerem GSM wystarczą dla ww. konfiguracji dwie linie w /etc/dnsmasq.conf:

interface=wlan0dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,1h

Należy też dodać adres IP na interfejsie wlan0, włączyć forward pakietów dla IPv4 oraz uruchomić NAT. Wersja „ręczna” ww. czynności (dla mojej konfiguracji, interfejsy mogą się zmieniać) to:

ip a a 192.168.10.1/24 dev wlan0
ip link set wlan0 up
service dnsmasq restart
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Po tym wszystkim, inne komputery powinny móc się połączyć z naszym linuksowym routerem GSM, dostać adres IP oraz posiadać dostęp do internetu za jego pośrednictwem. W przypadku problemów warto sprawdzić kolejno: otrzymanie adresu IP, ping do routera (192.168.10.1), ping do świata po IP, ping do świata pod domenie (w zasadzie: resolvowanie DNS).

Na rynku jest sporo sprzętów, które pozwolą zbudować mocny routera GSM na Linuksie. Choćby przykładowo Banana Pi, Orange Pi czy nieśmiertelne Raspberry Pi. Oczywiście jeśli miałby być to sam router, to nie bardzo widzę sens ekonomiczny, bo zestaw modem+płytka+karta wifi+zasilacz pewnie będzie kosztował więcej, niż tani router LTE (no chyba, że ktoś akurat – jak ja – ma ww. graty pod ręką 😉 ), ale w przeciwieństwie do taniego routera GSM można tu uruchomić dodatkowe funkcjonalności typu NAS, VPN czy serwer WWW. Ten ostatni to może niekoniecznie na łączu GSM…

Mam nadzieję, że opis się przyda. Gdybym o czymś zapomniał, albo coś nie działało, proszę o uwagi.

PS. Oczywiście mam świadomość, że udostępnienie internetu z GSM potrafi w trzech kliknięciach zrobić chyba każdy smartfon z Androidem. W przypadkach awaryjnych jest to pewnie najszybsza droga. I tak, użyłem Aero2 i pakietu testowego bez captcha. Niskie opóźnienia pozytywnie zaskakują.

UPDATE: Istnieje coś takiego jak projekt RaspAP, o którym warto wspomnieć. Narzędzie umożliwia konfigurację access pointa WiFi w ładny (GUI) sposób. Wsparcie dla wielu języków, wygodny dostęp do wielu opcji.

Ubuntu 14.04 LTS, apt-dater i restart usług

Jakiś czas temu zachwalałem apt-dater jako narzędzie do aktualizacji większej ilości systemów. Jak pisałem w późniejszych uwagach, apt-dater nieźle integruje się z programem needrestart. Tyle teorii…

Niestety, o ile na Debianie Jessie wyglądało to naprawdę dobrze i sprawdzenie przez checkrestart (inne polecenie realizujące podobne zadanie) dawało spójne wyniki z needrestart, o tyle na Ubuntu 14.04 LTS needrestart pokazywał często, że do restartu nic nie ma, o tyle checkrestart był zupełnie innego zdania... I – co gorsza – miał rację.

Przyczyną okazała się różnica w wersji needrestart. W Jessie jest to 1.2, w Ubuntu 14.04 LTS – 0.5. Ponieważ to skrypt perlowy, to dałem szansę i wrzuciłem wersję z Debiana (stable). Instaluje się czysto, działa bardzo dobrze – w połączeniu z apt-dater wykrywa więcej usług do restartu i także tu wyniki needrestart są teraz spójne z checkrestart.

Nawiasem, checkrestart w Jessie ma problem z mysql i zawsze pokazuje, że należy go zrestartować. Jest na to zgłoszony bug. Ale to tak nawiasem, kto korzysta, ten wie, zresztą można dopisać mysql do wyjątków w konfigu.