SEO przy zmianie domeny bloga

To ostatni wpis nawiązujący do Blox, przynajmniej techniczny, bo być może pojawi się jeszcze jeden o tym, jak Agora ma w głębokim poważaniu wolność słowa (określając to górnolotnie) i że ważniejsze jest parę złotych.

Po przeniesieniu bloga, o którym nieco pisałem, przyszedł czas na przeniesienie pozycjonowania w Google w nowe miejsce, czyli zabawę z SEO, aby ludzie wchodząc z wyszukiwarki trafiali w nowe miejsce. Przyznaję, że motywację miałem nikłą – nie zarabiam na wejściach, bo ani nie służy on do sprzedaży produktu, ani nawet nie ma podpiętych innych, pośrednich form zarobku.

Po przeniesieniu treści postanowiłem poczekać. Zwyczajnie i po prostu, nie robiąc nic, poza daniem informacji Google, że blog jest i jak interpretować zawarte na nim dane. Zresztą akurat miałem co innego na głowie. Znaczy ograniczyłem się do wypełnienia Data HighliterWebmaster Tools. Stan taki trwał jakiś miesiąc albo dwa.

Z braku kontroli nad nagłówkami pomysł przekierowania w nowe miejsce przy pomocy kodu odpowiedzi 301 odpadł w przedbiegach, choć to najprostsza, automatyczna i zalecana – także z punktu widzenia SEO – forma przekierowania ruchu w nowe miejsce.

Trochę czasu minęło, ilość wejść na nową lokalizację była szczątkowa, choć miałem nadzieję, że Google zacznie ogarniać sytuację samodzielnie. Niestety tak się nie stało, więc postanowiłem zacząć działać, choć miałem świadomość, że to praca, która się nie automatyzuje. Pierwsze co przyszło mi do głowy, to ustawienie link canonical dla wybranych, najczęściej odwiedzanych wpisów z nową lokalizacją jako celem. I tu okazało się, że Blox przewidział sytuację i… stosowne elementy HTML znikają po dodaniu ich w edycji źródła[1].

Z braku lepszych pomysłów dodałem w najpopularniejszych wpisach namiar na nowe miejsce, poprawiłem też linki do bloga w większości miejsc, gdzie były one umieszczone i… postanowiłem jeszcze poczekać. Poczekałem kwartał, ale nie wydarzyło się nic specjalnego. Statystyki wg Webmaster Tools wyglądały na koniec kwartału następująco:

ostanie 28 dni: impr: 2250, CTR 0,84%, avg pos 33,7. 130 wizyt

Delikatnie mówiąc szału nie ma.

Postanowiłem więc podziałać inaczej. Skoro nie mogę przekierować wyszukiwarki Google, to postanowiłem przekierować przynajmniej żywych ludzi, licząc, że Google w jakiś sposób to zauważy i odpowiednio zinterpretuje. Skoro nic nie działa, to co zadziała na pewno i czego nie można zablokować? Oczywiście JavaScript. Malware korzystający z niego ma się dobrze dzięki obfuskacji, zablokować całkowicie wykorzystania JS na stornie nie bardzo można, bo masa funkcjonalności z niego korzysta. Użyłem następującej wersji przekierowania z jednej lokalizacji na drugą (dla najpopularniejszych wpisów):

<script>
window.location.replace('https://zakr.es/blog/2017/09/goodbye-yanosik/');
</script>

Oczywiście powyższy JS był tylko w odpowiadającym wpisie na starym blogu, a URL w skrypcie to URL na nowym blogu.

Zadziałało nadspodziewanie dobrze. Nadspodziewanie, bo przy wejściu na URL kategorii zawierającej wyświetlany wpis z przekierowaniem, także przekierowywało. Co gorsza przekierowywało przy wejściu na stronę główną, bo także znalazł się tam wpis z przekierowaniem. Może i więcej ruchu przez to, ale niezupełnie o to chodziło i mało to precyzyjne… Dla wpisów z głównej dokonałem więc stosownej korekty w stylu:

<script>
var stringPathName = window.location.pathname;
if (stringPathName == "/2018/02/Waze-jako-nawigacja.html") {
  window.location.replace('https://zakr.es/blog/2018/02/waze-jako-nawigacja/');
}
</script>

Poczekałem miesiąc, wyniki w statystykach były zauważalne, zacząłem więc dodawać tego typu przekierowania dla kolejnych, popularnych linków. Po dwóch miesiącach od dodania przekierowań w JS, wyniki wyglądały następująco:

28 dni: impr: 10450, CTR 4,46%, avg pos 18.8, 490 wizyt

Jak widać wzrost wszędzie. Uznałem, że jest sukces, zacząłem – dla pewności – usuwać większość treści wpisów na starym blogu. Nie było negatywnego wpływu, nastąpił nawet dalszy, równie znaczący wzrost wskaźników, choć zakładam, że wynika on po prostu z upływu czasu.

Największym zaskoczeniem jest dla mnie, że Google przy pozycjonowaniu uwzględnia JS do tego stopnia. Wiedziałem, że radzi sobie z treścią w JS i umie odczytać URLe, ale w tym przypadku wygląda, że poprawnie interpretowany jest fakt przekierowania.

Co można było zrobić lepiej lub inaczej? Całość działań można było zamknąć w mniej niż dwa miesiące, gdybym od razu wiedział co robić i działał zdecydowanie. Oczywiście lepsze efekty byłyby, gdyby zmiany dotyczyły wszystkich wpisów, ale jest to żmudna, ręczna praca, której poświęcałem kilka minut dziennie przy porannej kawie. Powyższy sposób przekierowania nie jest jedynym dostępnym w JS, miałem w planach sprawdzenie różnych, ale ten sprawdziłem jako pierwszy i zadziałał powyżej oczekiwań, więc nie testowałem innych.

Na koniec jeszcze garść cyferek. Ingerowałem ręcznie w ww. sposób w 40 wpisów. Wg Matomo nowy blog ma obecnie ok. 4-5 razy większą ilość wizyt, niż stary. Czyli ładny podział zgodnie z zasadą Pareto.

Co dalej? Dodawanie przekierowań w kolejnych wpisach i usuwanie z nich treści. Ostatecznie pewnie usuwanie przekierowanych wpisów, ale póki co nie mam na to ciśnienia.

[1] Tu zniknęła moja wątpliwość w celowość działań Blox w celu przywiązania użytkowników do swojej platformy. Przypominam: technicznie mają kontrolę nad nagłówkami i domeną – to jakby naturalne i cena za korzystanie ze współdzielonej platformy. Do tego wyłączyli parę lat temu – rzekomo tymczasowo – API. Ale jak widać dodatkowo jeszcze celowo ingerują w treść HTML.

Migracja z Aero2 na a2mobile

The world’s changing. Music’s changing. Even internet is changing.

Tak to się jakoś pomału kręci z tymi zmianami i mam pomysł na notkę z obserwacjami nt. zmian szybkości komputerów i (bardziej) łącz, ale to innym razem. Internet u rodziców miał się dobrze (via modem GSM i Raspberry Pi robiące za router), tylko pakiety Aero2 schodziły ciut szybciej, niż przewidywałem. Znaczy chyba raz zdarzyło się, by zeszły więcej niż dwa w miesiącu, ale dwa na miesiąc IIRC schodziły regularnie.

Do tego doszedł średni panel (klikasz „dodaj do koszyka” i jak nie pamiętasz, że dodawanie trwa, to możesz dodać kolejny raz, nim pierwszy „zaskoczy”), zaliczyli wyciek danych klientów no i – last but not least – pojawiły się inne oferty na rynku. W szczególności ciekawie wyglądała oferta a2mobile, gdzie za 10 zł na miesiąc mamy internet bez limitu transferu. Tj. innego niż prędkość łącza, a ta spada wraz ze zużyciem transferu, czyli klasyczny lejek. Do 5 GB transferu jest bez limitu prędkości, do 10 GB jest limit 3 Mbps (modem bez LTE, w praktyce właśnie w tych okolicach łącze działa), do 15 GB jest limit 1 Mbps, a potem 512 kbps. Zakładam, że poniżej 10 GB nie spadnie. 😉

Głównym wyzwaniem okazało się… zdobycie startera. Nie chciałem zamawiać kurierem, w FAQ pisali, że startery są do kupienia w sklepach Żabka. Właściwsze byłoby sformułowanie bywają, bo kupić udało mi się jakoś przy czwartym podejściu. Po czym musiałem zaliczyć wizytę na poczcie w celu rejestracji, więc chyba lepiej wziąć tego kuriera, zakładam, że umie on potwierdzić dane kupującego.

Konfiguracja wvdial jest w zasadzie analogiczna do tej od Aero2, zmienia się jedynie APN oraz wypadają user i hasło, czyli finalnie sekcja w wvdial.conf wygląda tak:

[Dialer a2mobile]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","a2mobile.pl"
Phone = *99#
Stupid mode = yes
Username = "blank"
Password = "blank"
Dial Attempts = 0
Auto DNS = "off"

Wrzucam, bo podobne wpisy były, nie znalazłem gotowca w sieci dla a2mobile, ale tak naprawdę wszystko jest do siebie podobne i łatwo zmienić konfigurację, jeśli ma się skonfigurowany APN na telefonie z Androidem… Kiedyś jeszcze była konfiguracja wvdial dla Orange.

Jak wysyłać powiadomienia o nowych wpisach na blogu do blabler.pl

Z serwisu blabler.pl, będącego następcą Blip.pl, aktywnie nie korzystam od dłuższego czasu, a nawet bardzo rzadko czytam. Jedyne co tam trafiało, to powiadomienia o nowych wpisach na blogu, realizowane skryptem w Perlu – zawsze to dotarcie do paru czytelników.

Skrypt był dostosowany do RSS z Blox, z paroma naleciałościami, więc po migracji na WordPressa przestał działać. Stwierdziłem, że to świetna okazja by zapoznać się – bardzo pobieżnie – z mechanize (odpowiednik genialnego WWW::Mechanize z Perla) w Pythonie.

Tak powstał skrypt umożliwiający śledzenie wordpressowego RSS i wysyłający informację o nowym wpisie na blogu do serwisu blabler.pl. Do użycia z crona. Raczej nie planuję rozwoju, pomijając naprawę ew. błędów, a takie mogą się zdarzyć, zwł. dotyczące kodowania pl-znaków, bo zupełnie tego nie testowałem, ale może się komuś przyda.

Migracja z Blox na WordPressa – HOWTO

Jak pisałem poprzednio, na pierwszy rzut do migracji poszedł blog o kapeli Bez Krótkich Spodni. Z migracją zeszło mi nieco dłużej, niż planowałem, głównie za sprawą hostingu, który się kończy, a którego nie przedłużam. Zamiast dedyka w Kimsufi zdecydowałem się na dwa VPSy w arubacloud.pl. Zaleta: taniej i SSD. Wada: potrzebuję dwie maszyny, co wiązało się z podziałem usług. I niestety, mimo konteneryzacji część usług jest od siebie zależna, głównie za sprawą domeny. W każdym razie zeszło więcej czasu, niż planowałem, ale jest to sensowniej podzielone.

Sama migracja jest prosta. Najpierw instalujemy WordPressa. Long story short:

wget https://wordpress.org/latest.tar.gz
tar -zxf latest.tar.gz
chown www-data:www-data katalog

Pozostaje utworzenie bazy i użytkownika:

CREATE DATABASE wordpress_db;
GRANT ALL PRIVILEGES ON wordpress_db.* TO "wordpress_db_user"@"localhost" IDENTIFIED BY "VeryStrongPassword";

W przypadku instalacji opartej o serwer nginx i WordPressa trzeba jeszcze dodać jedno ustawienie w konfiguracji tego pierwszego:

location /bks/ {
    try_files $uri $uri/ /bks/index.php?$args;
}

Następnie uruchamiamy instalator WordPressa przez WWW i logujemy się. Warto usunąć przykładowy wpis i strony, z których nie korzystamy, można wybrać szablon (cóż, domyślny robi robotę jak dla mnie) i zrobić porządek w pluginach.

Niestety Blox wyciął użytkownikom możliwość eksportu wpisów, więc w tym miejscu musiałem posiłkować się autorskim skryptem, by zdobyć treść bloga z Blox w formacie wordpressowym. Potem szybkie dopieszczenie szablonu, zwłaszcza zdjęcia z nagłówka i… w zasadzie jest. Niestety, obrazki w takim rozwiązaniu są serwowane nadal z serwerów Blox, więc nie mamy pełnej niezależności i będziemy dostawać komunikat ostrzegawczy przy HTTPS, bo nie wszystkie treści są serwowane w sposób bezpieczny.

Jest jednak na to sposób. Okazuje się, że istnieje plugin Download External Images In Posts, który robi dokładnie to, na co wskazuje nazwa – pobiera obrazki ze zdalnego serwera, zapisuje je lokalnie i podmienia linki we wszystkich wpisach, także już istniejących. Działa zadziwiająco dobrze, choć jedna rzecz mi się w nim nie podoba: musi pozostać aktywny po zrobieniu roboty, bo linki nie są podmienione w treści. Ale z tym jestem w stanie żyć.

Ostatni szlif to dodanie statystyk Matomo (dawniej Piwik). Skorzystałem z pluginu Insert Headers and Footers, następnie wkleiłem tam stosowny JS.

Efekt finalny widać w pierwszym linku. Jak widać zachowana została treść wpisów, ich daty, komentarze, ich autorzy oraz daty. Działają także tagi i kategorie (tych ostatnich akurat nie używam na blogu BKS). Wszystko jest serwowane po HTTPS (i dodatkowo HTTP/2, ale to już zaleta nginx z odpowiednią konfiguracją), czyli szybko, bezpiecznie i SEO friendly. Tak, jak powinno być. 🙂

Zostało posprzątanie na starym blogu i przekierowanie w nowe miejsce, ale to już bez pośpiechu…

Dodam jeszcze, że WordPress spodobał mi się na tyle, że rozważam migrację tego bloga także na WP, zamiast statycznego Pelicana. Ale nad tym jeszcze chwilę pomyślę.

UPDATE Aby działały poprawnie wszystkie ustawienia dla bezpośrednich odnośników, trzeba podać katalog w konfiguracji, zgodnie z tym opisem.

Jak usprawnić sieć w domu? cz. 5

Wpis, który chronologicznie powinien pojawić się jako drugi, ponieważ dotyczy stanu wyjściowego, czyli WiFi. Oczywiście sprzęt to opisywany niedawno TP-Link WR841 z OpenWrt. Banana Pi wpięte do portu LAN, czyli na 100 Mbps, ale głównym ogranicznikiem jest sieć bezprzewodowa. Jasności dodam, że są to wyniki sprzed optymalizacji, ale o poprawianiu WiFi napiszę innym razem. Warto też zaznaczyć, że wyniki jako jedyne są przeprowadzane na środowisku nieizolowanym, „produkcyjnym”, tj. z podłączonymi innymi urządzeniami. O ile nie powinny specjalnie rzutować na wynik, bo nie korzystały intensywnie, to na pewno wpływały w jakiś sposób ujemnie.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.04  sec   125 MBytes  17.5 Mbits/sec  10.997 ms  1908/16040 (12%)  
[  4] Sent 16040 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  67.7 MBytes  9.46 Mbits/sec  186             sender
[  4]   0.00-60.00  sec  67.6 MBytes  9.45 Mbits/sec                  receiver

3.
— 192.168.0.139 ping statistics —
600 packets transmitted, 598 received, 0% packet loss, time 61057ms
rtt min/avg/max/mdev = 0.766/2.303/42.995/4.036 ms

4.
— 192.168.0.139 ping statistics —
600 packets transmitted, 596 received, 0% packet loss, time 60280ms
rtt min/avg/max/mdev = 1.918/3.953/42.202/3.747 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.04 sec  6.27 GBytes  15.0 Mbits/sec  4.305 ms  71880/822270 (8.7%)
[  4] Sent 822270 datagrams
[…]
9.
Inea Orange

Jak widać stan wyjściowy nie był imponujący. Rzekłbym nawet, że zaskakująco słabe wyniki. Widać też, że brakuje części testów – przyznaję, że nie miałem ani cierpliwości, ani warunków. Ponieważ ustawienia lekko się zmieniły w międzyczasie, zostawię z brakiem, żeby nie fałszować. Zaskakuje słaby wynik transmisji w teście syntetycznym, w szczególności w porównaniu z testem do internetu.

Jak usprawnić sieć w domu? cz. 4

Kolejnym PLC, który otrzymałem na testy, był D-Link PowerLine AV Network Starter Kit DHP-307AV. Bardziej niż konkretny sprzęt jest to przedstawiciel starszego standardu, takiego, do którego przymiarkę robiłem zawodowo, wiele lat temu, pod kątem IPTV (i nie zdecydowaliśmy się wtedy).

W stosunku do opisywanego poprzednio główna różnica widoczna na pierwszy rzut oka, to brak gniazdka sieciowego w urządzeniu. Zaprawdę powiadam wam, pomyślcie dwa razy, nim coś takiego kupicie. Jednak główna zaleta PLC to przesył danych po sieci energetycznej obok prądu, a nie zamiast. Okazało się, że większość gniazdek w domu jest pojedyncza, w szczególności te, na których przeprowadzałem testy. Chciałem mieć równe testu warunki, więc stanęło na tym, że PLC było wpięte w gniazdko, a prąd do urządzeń doprowadzałem przy użyciu przedłużaczy z innych gniazdek, zalegających malowniczo po domu.

Detali typu wygląd, czytelność sygnalizacji, umiejscowienie portów czy przycisków pomijam – nie tego dotyczy test. Zatem do rzeczy. Błędów nie będę powielał, testy tylko w optymalnym zestawieniu, dwa gniazdka w tym samym pokoju, PLC bezpośrednio w gniazdku:

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.01  sec   402 MBytes  56.2 Mbits/sec  1.923 ms  25/51490 (0.049%) 
[  4] Sent 51490 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   279 MBytes  39.0 Mbits/sec    0             sender
[  4]   0.00-60.00  sec   278 MBytes  38.9 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60295ms
rtt min/avg/max/mdev = 3.273/3.939/8.552/0.749 ms

4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60235ms
rtt min/avg/max/mdev = 2.885/3.943/8.002/1.000 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  21.0 GBytes  50.1 Mbits/sec  2.687 ms  9031/2754740 (0.33%) 
[  4] Sent 2754740 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  16.0 GBytes  38.3 Mbits/sec    0             sender
[  4]   0.00-3600.00 sec  16.0 GBytes  38.3 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3622284ms
rtt min/avg/max/mdev = 2.715/4.149/75.146/1.069 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3620695ms
rtt min/avg/max/mdev = 2.862/3.903/83.121/1.154 ms

9.
brak danych

Jak widać, w porównaniu z poprzednim testem sprzętu nowszej generacji, urządzenia starszej generacji zapewniają znacząco mniejszy transfer. Choć działają stabilnie, nawet przy niższych opóźnieniach. O ile zaczną działać, bo brak danych w punkcie dziewiątym wynika z tego, że połączenia między pokojem a przedpokojem zwyczajnie nie udało mi się zestawić, mimo kilku prób.

Jeśli chodzi o pobór prądu to zarejestrowałem na pojedynczym urządzeniu od 3,2 W pod obciążeniem, przez 2,7 W przy braku przesyłu danych i podłączonych urządzeniach, do minimalnie 2,3 W parę minut po wypięciu kabla ethernet. Producent obiecuje poniżej 1 W w idle, jak widać jest więcej. Albo kwestia firmware, albo za krótko czekałem, albo urządzenia nie potrafią.

Jak usprawnić sieć w domu? cz. 3

No i z uwagi na lekkie zamieszanie zapomniałem uzupełnić brakujące wpisy. Pora nadrobić. Tym razem ponownie  będzie o TL-PA4010P kit. W poprzednim wpisie opisałem test w niekomfortowych warunkach, pora napisać, co potrafią te PLC wpięte jak należy, czyli bezpośrednio w gniazdka. Dodatkowo gniazdka znajdowały się w tym samym pokoju (poza testem do internetu), czyli warunki optymalne.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.01  sec   679 MBytes  94.9 Mbits/sec  0.959 ms  2399/86899 (2.8%) 
[  4] Sent 86899 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   596 MBytes  83.3 Mbits/sec  165             sender
[  4]   0.00-60.00  sec   595 MBytes  83.2 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60244ms
rtt min/avg/max/mdev = 3.265/4.578/43.719/5.233 ms

4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60215ms
rtt min/avg/max/mdev = 22.191/24.164/75.595/5.495 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  39.7 GBytes  94.6 Mbits/sec  1.226 ms  166115/5197940 (3.2%) 
[  4] Sent 5197940 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  36.3 GBytes  86.6 Mbits/sec  7730             sender
[  4]   0.00-3600.00 sec  36.3 GBytes  86.6 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3621137ms
rtt min/avg/max/mdev = 2.621/4.664/94.389/5.156 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3618021ms
rtt min/avg/max/mdev = 21.802/23.793/196.067/5.318 ms, pipe 2

9.
Inea Orange

Jak widać jest zauważalnie szybciej, zarówno po sieci, jak i do internetu. W przypadku serwera Inea (czyli dostawcy), można uznać, że osiągnięte zostało deklarowane 60/10, przynajmniej w przypadku serwera testowego znajdującego się u dostawcy. Czyli zdecydowanie warto wpiąć w sposób zalecany przez producenta.

Jak usprawnić sieć w domu? cz. 2

W poprzedniej części było o genezie cyklu, sposobach pomiaru i najlepszym możliwym połączeniu, czyli bezpośrednio skrętką. Ze względu na zainteresowanie paru osób wynikami testów PLC, przeskakuję WiFi i przechodzę do wyników testów PLC.

Na testy dostałem TL-PA4010P kit. Z tego co widzę, w wyszukiwarce znajduje zarówno, że jest to AV500 jak i AV600, ale na opakowaniu było AV600, więc link jest prawdopodobnie prawidłowy. Do podłączenia podszedłem zupełnie laicko – z tego miejsca w mieszkaniu internet ma trafić do tamtego – zupełnie nie wnikałem w to jakie są fazy i czy po drodze są listwy.

Błąd. Zalecane jest wpięcie w ten sam obwód i bezpośrednio do gniazdka, z pominięciem listew zasilających. W związku z tym wykonałem kilka testów, w tym wpisie zajmę się tylko wynikami pierwszej, najgorszej topologii – jeden kontroler bezpośrednio w gniazdku, drugi za listwą z włącznikiem i wpiętej w nią listwą zwykłą. Od razu podaję link do wskazówek jak najlepiej podłączyć PLC. Wyniki z optymalnego połączenia są lepsze i będą w kolejnym wpisie, ten to bardziej „jakoś wpiąłem i tak działało”.

Na wstępie miałem małe rozczarowanie, które rozwiewa dopiero lektura powyższego linka. AV600 oznacza 600 Mbps. I jakkolwiek przypuszczałem, że będzie to 300 upload, 300 download, to aby taki wynik osiągnąć, trzeba by mieć w urządzeniu port 1 GE. Tymczasem jak widać są tam porty 100 Mbps i taką prędkość linkowania się z urządzeniami osiągałem. Nie jest to dla mnie wielki problem, bo mój router także ma porty 100 Mbps, ale jeśli ktoś liczy na szybkie połączenie z NAS itp., to może się zawieść.

Samo podłączenie jest proste – sprowadza się do włożenia urządzeń w gniazdka, wpięcia ethernetu i naciśnięciu przycisku do parowania.

Wyniki z testu w niekomfortowych warunkach:

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec   547 MBytes  76.5 Mbits/sec  1.195 ms  0/70059 (0%) 
[  4] Sent 70059 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   418 MBytes  58.4 Mbits/sec    0             sender
[  4]   0.00-60.00  sec   417 MBytes  58.3 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60299ms
rtt min/avg/max/mdev = 3.310/3.657/13.757/0.965 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60338ms
rtt min/avg/max/mdev = 21.582/24.445/35.531/2.837 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  32.6 GBytes  77.9 Mbits/sec  1.447 ms  5136/4278660 (0.12%) 
[  4] Sent 4278660 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  24.6 GBytes  58.6 Mbits/sec    0             sender
[  4]   0.00-3600.00 sec  24.5 GBytes  58.6 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3625078ms
rtt min/avg/max/mdev = 2.759/4.280/16.010/1.247 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3618568ms
rtt min/avg/max/mdev = 22.662/24.105/106.475/2.133 ms, pipe 2

9.
Inea Orange

Jak widać nawet w tych niekomfortowych warunkach zestaw radził sobie przyzwoicie. Brak strat pakietów, niskie i stabilne opóźnienia. Widać wzrost czasu odpowiedzi w zależności od wielkości pakietu i jak sprawdziłem empirycznie pojawia się on przy rozmiarze pakietu między 900 a 1000 i jest to jedyna istotna różnica w stosunku do zwykłęgo ethernetu.

Niezła szybkość transmisji danych między urządzeniami nie wzbudziła mojej czujności; to, że coś chyba jest nie w porządku zacząłem podejrzewać dopiero po ostatnim teście, po podłączeniu jednego z końców kabla do routera. Dane z internetu pobierały się zwyczajnie wolno i… nie miało to pokrycia w testach syntetycznych. W tym momencie uprzedzę fakty i od razu napiszę, że przy zalecanym połączeniu wyniki w ostatnim teście były identyczne jak na kablu. Ale to już w kolejnym wpisie.

Na koniec słowo o zużyciu energii, ponieważ są to urządzenia aktywne. Podłączyłem urządzenie do watomierza. Bez podłączonego komputera pokazał 1,5W, po podłączeniu komputera i podczas transmisji danych 2,2-2,3W. Jeśli wyłączymy komputer, PLC po paru minutach przechodzi w stan uśpienia i pobiera wówczas 0,8W.

Jak usprawnić sieć w domu? cz. 1

Wstęp

Wpis jest wstępem do serii mini testów, które przeprowadziłem lub przeprowadzę w najbliższym czasie. Chodzi o rozwiązanie kwestii dostępu urządzeń w domu do internetu i zapewnienia ich łączności pomiędzy sobą. Powodem było moje WiFi, które choć doprowadzone aktualnie do zadowalającej używalności, niekoniecznie było optymalne zarówno jeśli chodzi o stabilność połączenia, jak i oferowane przepływności czy opóźnienia. Na rynku istnieje kilka rozwiązań, które mają za zadanie pomóc w dostarczeniu sieci, niedawny wpis o PLC przypomniał mi, że kiedyś interesowałem się bardziej tematem, a technika poszła naprzód.

Szybkie pytanie na wewnętrznym forum firmowym czy komuś nie zalega parka PLC spotkała się z pozytywnym odzewem (uroki pracy w większej firmie, z otwartymi geekami – ciekaw jestem czego nie dałoby się znaleźć… ;-)) i okazało się, że nie tylko zalega chwilowo, ale są różnego typu, stąd pomysł na porównanie i podzielenie się wnioskami.

Nie ma to być test uniwersalny ani profesjonalny – robię go przede wszystkim dla siebie i w dostępnym mi środowisku (a np. typ ścian czy otoczenie może mieć kolosalne znaczenie dla WiFi, podobnie wygląda kwestia sieci elektrycznej dla PLC), mam jednak nadzieję, że uda się wyciągnąć jakieś wnioski ogólne i może komuś pomoże w wyborze rozwiązania.

O ile nie napisano inaczej, wykorzystywany jest firmware dostarczony z urządzeniami. Systemy nie są specjalnie tuningowane – ot, linuksowy default. Z oczywistych względów trudno mi wypowiadać się na temat stabilności poszczególnych rozwiązań w dłuższym okresie czasu.

Topologia sieci

Topologia sieci jest następująca: modem ISP (kablówka) w przedpokoju, podłączony ethernetem do routera. Router (obecnie TL-841) z wgranym OpenWRT/LEDE dostarcza internet reszcie urządzeń po WiFi. Przedpokój to w miarę centralny punkt w mieszkaniu, odległość od urządzeń końcowych (laptopy, smartfony) ok. 7 metrów, część urządzeń pracuje w 802.11n, część w 802.11g i tak zostanie – modernizacja czy wymiana końcówek są nieopłacalne.

Dla jasności: to działa od lat i w zasadzie wystarcza, jeśli chodzi o przepływność. Wystarczało i na 802.11g, gdy transfery (do mojego laptopa) wynosiły 15-18 Mbps (wg speedtest.net). Po zmianie routera na nowszy jest lepiej – 30 Mbps. Nadal jest to gorzej niż to, co oferuje operator (60 Mbps), ale w zupełności wystarcza do transferów „z zewnątrz”. Zobaczymy jednak, czy są jakieś alternatywy i czego się spodziewać.

Ani mieszkanie w kamienicy, ani dość zaszumiony eter na 2,4 GHz, nie pomagają w dobrym działaniu WiFi, więc nieco gorzej wygląda sytuacja, jeśli chodzi o stabilność. Rzadko, bo rzadko, ale zdarzały się problemy (straty do routera, wzrost czasów odpowiedzi). Zwykle, w czasach gdy korzystałem z oryginalnego firmware producenta, wystarczał restart routera lub sprawdzenie jak wygląda sytuacja w eterze przy pomocy WiFi Analyzera i zmiana kanału na wskazany jako najlepszy (czyli najmniej używany).

Swoją drogą zmiana kanału na nieużywany jest najprostszym sposobem na poprawę zasięgu czy jakości WiFi, więc jeśli ktoś szuka odpowiedzi na pytanie jak poprawić sygnał WiFi, to zdecydowanie polecam zacząć od tego.

Pomiary

Wykonywane są cztery testy wewnętrzne, oraz ogólny test przy pomocy speedtest.net (beta, czyli bez Flash). Testy wewnętrzne wykonywane były w dwóch wariantach: krótkim (w założeniu ok. 60s) i długim (ok. 3600s).

  1. iperf3 -u -b 0 -t 60 -c 192.168.10.126
  2. iperf3 -t 60 -c 192.168.10.126
  3. ping -i 0.1 -c 600 192.168.10.126
  4. ping -s 1500 -i 0.1 -c 600 192.168.10.126
  5. iperf3 -u -b 0 -t 3600 -c 192.168.10.126
  6. iperf3 -t 3600 -c 192.168.10.126
  7. ping -i 0.1 -c 36000 192.168.10.126
  8. ping -s 1500 -i 0.1 -c 36000 192.168.10.126
  9. speedtest.net

Jak widać jest to pomiar przepływności przy użyciu pakietów UDP, TCP oraz pomiar opóźnień przy pomocy ping ze standardową oraz maksymalną (MTU 1500) wielkością pakietu. Ostatni test to „realne” połączenie z internetem. Wykorzystywane serwery mojego ISP oraz Orange, który często był wskazywany jako najlepszy.

Za klienta służy mój laptop z Debianem, za sondę posłużyło Banana Pi (jedyny SoC z gigabitowym portem, który miałem pod ręką). W obu systemach wykorzystany iperf3. Pomiar nie był jedyną czynnością wykonywaną przez laptopa, ale – poza testami WiFi – był wykorzystany osobny interfejs, a obciążenie było typowe, bez ekstremów.

Dodatkowo mogą pojawić się uwagi, jeśli coś nieplanowanego podczas testów rzuci mi się w oczy.

Wyniki bazowe

Na wstępie spiąłem oba urządzenie kablem „na krótko” i uruchomiłem testy. Synchronizacja oczywiście 1 Gbps.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec  6.07 GBytes   869 Mbits/sec  0.136 ms  592341/795464 (74%)
2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  5.47 GBytes   784 Mbits/sec  138             sender
[  4]   0.00-60.00  sec  5.47 GBytes   783 Mbits/sec                  receiver
3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62319ms
rtt min/avg/max/mdev = 0.291/0.372/0.549/0.031 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62290ms
rtt min/avg/max/mdev = 0.427/0.549/24.612/0.996 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec   374 GBytes   893 Mbits/sec  0.220 ms  36944269/49033499 (75%)
6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec  8735             sender
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec                  receiver
7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745436ms
rtt min/avg/max/mdev = 0.278/0.369/40.914/0.398 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745111ms
rtt min/avg/max/mdev = 0.260/0.500/2.861/0.046 ms

9.
Inea Orange [1]

Jak widać bez większych niespodzianek – osiągnięte wyniki wynikają raczej z ograniczenia samego Banana Pi. Mimo to widać, że jest szybko, czasy odpowiedzi niskie i jest stabilnie.

[1] W przypadku pomiaru łącz topologia była nieco inna – laptop wpięty po kablu do portu routera (port 100 Mbps). W zasadzie dokładniej byloby wpiąć go bezpośrednio w modem kablowy, ale router jest stałym elementem zestawu w pozostałych topologiach… Dostawca internetu (Inea) deklaruje 60/10 Mbps.

Debian over Tor – HOWTO

Jakiś czas temu dowiedziałem się, że Debian oficjalnie zapewnia dostęp do wielu swoich zasobów poprzez sieć Tor, jako zasoby wewnętrzne tejże sieci. Tutaj dostępna jest lista usług Debiana dostępna poprzez Tor wraz z adresami, a poniżej przykład zastosowania, czyli zmiana konfiguracji apt tak, aby pobierał pakiety za pośrednictwem Tora.

Po pierwsze, należy zainstalować pakiet umożliwiający aptowi korzystanie z Tora:

apt-get install apt-transport-tor

Po drugie, należy usunąć istniejące wpisy dotyczące repozytoriów i zastąpić je wersją dla sieci Tor:

deb  tor+http://vwakviie2ienjx6t.onion/debian          stretch            maindeb  tor+http://vwakviie2ienjx6t.onion/debian          stretch-updates    maindeb  tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates    main

Jak widać zmiana dotyczy zarówno adresu, jak i dodania przed adresem prefiksu tor+.

Nie jest to jedyny sposób, można także ustawić proxy HTTP przekierowujace ruch na Tor i zostawić wpisy bez prefiksu tor+, ale z wpisami .onion, albo przekierować cały ruch HTTP przez sieć Tor, jednak rozwiązanie z instalacją transportu jest najprostsze.

Tutoriale (patrz źródła) zalecają dodanie mirrora lub fallbacka dla repozytoriów security, ale IMO zależy do czego jest używana maszyna i jak wykonywane są update’y. Jeśli robisz je ręcznie i sprawdzasz powodzenie, można sobie odpuścić.

Pozostaje pytanie, po co komu coś takiego. Nie ukrywam, że trudno mi sobie wyobrazić wiarygodny scenariusz, kiedy takie rozwiązanie mogłoby być przydatne w naszych realiach. Być może w innych krajach wygląda to trochę inaczej i są np. obostrzenia w zakresie systemów, których wolno używać. Niemniej rozwiązanie działa i możliwość pobierania pakietów Debiana przez Tor istnieje.

Źródła:

Entropia w Linuksie – HOWTO

Dawno temu pojawił się mit, że w Linuksie /dev/random jest źródłem prawdziwej entropii, a /dev/urandom jest gorszy. Pokutuje on do dziś i część softu za źródło danych przyjmuje właśnie /dev/random, niezależnie od realnych potrzeb. Ilość losowych danych w systemie nie jest nieskończona i zależy od dostępnych źródeł i zdarzeń zewnętrznych. Dopóki komputery były głównie fizyczne, często obsługiwane przez ludzi, problem był nieco mniejszy. W epoce wirtualek systemy i ruch są coraz bardziej powtarzalne, więc z „prawdziwą” entropią są problemy. A entropia nadal jest w systemach aplikacjom potrzebna – słusznie lub nie, chyba nawet bardziej niż kiedyś, bo szyfrowanie wszystkiego jest coraz bardziej popularne i wykorzystywane są coraz silniejsze algorytmy.

Od pewnego czasu (okolice wersji 3.7) kernel Linuksa potrafi co prawda korzystać ze sprzętowych modułów (TPM) zapewniających źródła losowych danych, o ile takie są obecne. Nie każdy sprzęt jest jednak w to wyposażony, nie każda wirtualka posiada dostęp do danych z hypervisora i obecność modułu nie oznacza jeszcze, że dane będą dostępne dla programów, więc problem nadal pozostaje.

Sprawdzenie dostępnej entropii

Jeśli nie wiemy, czy faktycznie system ma problem z dostępną entropią, możemy to w prosty sposób sprawdzić. Aktualną ilość można odczytać przez wydanie polecenia:

cat /proc/sys/kernel/random/entropy_avail

Oczywiście jest to wartość chwilowa, zmieniająca się w czasie, żeby z całą pewnością stwierdzić, jak system stoi z entropią, trzeba by poobserwować w dłuższym czasie, a najlepiej monitorować ją, np. przy pomocy Zabbiksa. Wartość powyżej 1000 oznacza, że na pewno problemu nie ma, wartości poniżej 300 oznaczają, że prawie na pewno są niedobory, mogące wpływać na pracę usług.

rngd

Istnieją dwa rozwiązania, które pomogą zwiększyć ilość dostępnych danych losowych w systemie. Pierwsze z nich, to rngd z pakietu rng-tools. Jego zadanie jest proste – dostarczać dane do napełniania /dev/random korzystając ze wskazanego źródła.

Jeśli platforma posiada sprzętowy moduł dostarczający dane losowe, rngd warto skonfigurować, by z niego korzystał. W tym celu w pliku

/etc/default/rng-tools

należy umieścić linię

HRNGDEVICE=/dev/hwrng

Natomiast w przypadku braku takiego modułu, sugerowane jest dodanie linii

HRNGDEVICE=/dev/urandom

 

Kontrowersje korzystania z /dev/urandom

Korzystanie z /dev/urandom jako źródła danych dla /dev/random powoduje kontrowersje. Główne zarzuty to niegwarantowana losowość danych w /dev/urandom (ale patrz mit), oraz powstawanie sprzężenia zwrotnego, co łącznie może powodować okresowość, a zatem teoretyczną możliwość przewidzenia stanu generatora liczb pseudolosowych. Podkreślam, że jest to możliwość czysto teoretyczna, nie wykazana w praktyce.

Alternatywa dla rngd

Istnieje drugie popularne rozwiązanie programowe, które pozwala na zwiększenie dostępnej w systemie entropii. Jest to demon haveged z pakietu o tej samej nazwie. Korzysta on z faktu, że czas wykonania kodu przez procesor jest mało powtarzalny i zależy od wielu czynników. Jest to rozwiązanie obecne w dystrybucjach od wielu lat, proste w użyciu.

Wybór rozwiązania

Jeśli system posiada moduł sprzętowy, to bym z niego korzysał, za pośrednictwem rngd. Czy haveged jest lepszy od rngd zasilanego z /dev/urandom? Nie podejmuję się odpowiedzi na to pytanie. Oba zapewniają najważniejszą sprawę, czyli dostępność danych losowych. Oba rozwiązania spełniają proste testy badające losowość danych. Osobiście uważam, że w większości przypadków rozwiązanie korzystające z rngd jest wystarczające. Tam gdzie do losowości danych przykładana jest duża waga, nie jest nie powinno być problemu z dostępem do sprzętowych generatorów, a niedobory entropii zawsze są bardziej szkodliwe, niż jej teoretycznie niższa jakość.

Linki

Na koniec zbiór linków, zarówno źródła jak i dalsza lektura, czyli ciekawe linki (kolejność losowa):

Raspbian i uruchomienie modemu GSM Huawei E3131

Uruchomienie modemu Huawei E3131 (hilink) pod Debianem opisałem wcześniej, ostatnio pisałem o perypetiach związanych z tym, że na Debianie działa, na Raspbianie nie działa. Dziś zagadka została rozwiązana.

Udałem się na kanał IRC Raspbiana, w nadziei, że dostanę wskazówki w czasie kiedy będę przeprowadzać debug. Czasami nie ma się co męczyć, bo po prostu można o czymś nie wiedzieć, jak miało to miejsce w przypadku uruchomienia SSH na Raspbianie. Poza tym, takie pytanie o pomoc i dostarczenie pełnych danych o problemie działa trochę jak gumowa kaczuszka.

Nim dobrze skończyłem pisać, dostałem namiar na ten wpis. Wygląda paskudnie? Ano wygląda. Ale działa – po wydaniu podanego polecenia pojawił się interfejs eth1 w systemie. Ale być może wystarczy doinstalować sg3-utils? Niestety nie – opisany sposób działa tylko do rebootu Raspberry Pi czy też do wyjęcia i włożenia modemu (nie pamiętam, oba mało akceptowalne…). Od biedy mógłbym z tym żyć, bo prosty skrypt do crona załatwi sprawę, ale… na Debianie jest bardziej elegancko, więc drążyłem temat.

Skoro przyszło do pakietów, to zauważyłem, że na desktopie mam zainstalowany pakiet:

ii  modemmanager                              1.6.4-1                                                 amd64        D-Bus service for managing modems

Brzmi obiecująco, tym bardziej, że dotyka D-Bus. Na Raspbianie tego pakietu nie było… Doinstalowałem pakiet, reboot Raspberry Pi i… Działa. Nie jest identycznie jak w Debianie, bo nadal interfejs to eth1 i IP pobiera automatycznie z DHCP, ale to detale – najważniejsze jest działające wyjście na świat.

Podsumowując: aby działały modemy typu dongle USB w Raspbian, należy doinstalować pakiet modemmanager.

Wpis pojawia się w kategorii DSP2017 z racji tego, że płytka z ARM będzie robiła za stację testową. Jeśli wszystko pójdzie dobrze, jeszcze dziś…

Huawei E353/E3131 w Debianie

Kiedyś opisywałem uruchomienie Aero2 z modemem Huawei E3131. Kupiłem „taki sam” model i dziś przyszedł. Po podłączeniu do komputera spodziewałem się, że będzie tak samo, jak w poprzednim, ale nie, więc może komuś oszczędzę walki, na którą straciłem dziś dobry kwadrans, jak nie lepiej.

Otóż nowy modem przedstawia się w lsusb:

Bus 002 Device 016: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

Natomiast po wpięciu do portu USB w dmesg widać:

[11264.677637] usb 2-1.2: new high-speed USB device number 15 using ehci-pci
[11264.787001] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=1f01
[11264.787005] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11264.787007] usb 2-1.2: Product: HUAWEI HiLink
[11264.787009] usb 2-1.2: Manufacturer: HUAWEI
[11264.788426] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[11264.788583] scsi host6: usb-storage 2-1.2:1.0
[11265.736276] usb 2-1.2: USB disconnect, device number 15
[11268.517690] usb 2-1.2: new high-speed USB device number 16 using ehci-pci
[11268.627263] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=14db
[11268.627267] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11268.627269] usb 2-1.2: Product: HUAWEI HiLink
[11268.627271] usb 2-1.2: Manufacturer: HUAWEI
[11268.630336] cdc_ether 2-1.2:1.0 eth0: register 'cdc_ether' at usb-0000:00:1d.0-1.2, CDC Ethernet Device, 58:2c:80:XX:XX:XX
[11268.707401] cdc_ether 2-1.2:1.0 enx582c80xxxxxx: renamed from eth0

Co prawda świtało mi coś o hilink i zauważyłem kartę sieciową w systemie, ale stwierdziłem, że to tylko jeden z trybów i można używać „po staremu” z /dev/ttyUSB0 i wvdial, który to sposób mam obcykany. Zmyliło mnie też to, że nie mogłem wejść na wskazywany przy opisach wersji hilink adres 192.168.1.1.

Robiłem różne cuda, o których pisać nie będę, na szczęście zapytałem na IRCu i dobrzy ludzie naprowadzili me zawiłe rozumowania na proste tory.

No więc ostatecznie „po staremu” mi się nie udało, natomiast żeby uzyskać adres IP wystarczy wydać polecenie:

dhclient enx582c80xxxxxx

 

I wtedy po wpisaniu w przeglądarkę 192.168.1.1 mamy dostęp do klikalnego interfejsu zarządzania modemem i wszystko działa od kopa.

Niestety, opisy są chyba obliczone albo na ludzi, którzy robią wszystko z ręki, albo na tych, którzy mają wszystko automatycznie. Pobieranie IP z DHCP też.

Blox.pl – feed RSS dla pojedynczej kategorii

Wymaganiem udziału w konkuresie DSP2017 jest podanie feedu RSS zawierającego wyłącznie posty związane z konkursem. Blox.pl spłatał mi niemiłego figla i dał wybór – albo stary, paskudny wygląd, albo brak możliwości pobrania feedu RSS dla pojedynczej kategorii. Sprawę zgłosiłem, ale znając czasy realizacji stwierdziłem, że mam trzy możliwości: zrezygnować z DSP2017, postawić osobnego bloga specjalnie dla DSP2017 albo zrobić coś samemu.

Pierwsze dwie możliwości odrzuciłem. Jakoś nie widział mi się blog z 20 postami, kolejnego prowadzić mi się nie chce, a Blox ma swoje zalety i do porzucenia jeszcze nie dojrzałem. Spojrzałem co też mam do dyspozycji pod ręką, bo w pewne parsowanie feedu RSS bawiłem się już przy pomocy Perla (patrz zawartość mojego konta na blabler.pl). Niestety, stwierdziłem, że niezbyt się to nadaje do użytku.

Poza tym, przeszedłem na Pythona, więc pomyślałem o małej rozgrzewce. Pierwszym pomysłem było przeparsowanie całego feeda i złożenie RSS. Znalazłem przykłady parsowania XML z użyciem beautifulsoup4, z którego zresztą trochę wcześniej korzystałem. Wyciąganie zawartości poszczególnych postów poszło bardzo dobrze.

Stwierdziłem, że zamiast się bawić w tworzenie feedu kolejnym modułem, w ramach eksperymentu dodam przy pomocy chamskich printów nagłówki od XML. O dziwo zadziałało, Firefox widział coś, co wyglądało prawie jak oryginał. Jedynym problemem było kodowanie – zdecydowanie był problem z pl-znakami. Rzecz w tym, że Blox używa iso-8859-2, a Python wypluwa UTF-8. Wystarczyła szybka zmiana deklaracji kodowania w nagłówku XML i już było OK.

Kolejny problem wyszedł przy przepuszczeniu feeda przez validatory feedów RSS. Okazało się, że beautifulsoup4 zamienia wszystkie znaki w tagach na lowercase i – wierząc szybkiemu sprawdzeniu – nie ma prostego sposobu, by go od tego odwieść. Podjąłem próbę zamiany moduł na inny, ale szybko zrezygnowałem na rzecz brzydkich, ale skutecznych sedów na wyniku działania skryptu.

Na koniec zostało dodanie wywołania (z użyciem utworzonego na tę okoliczność virutalenv) do crona:

*/15 * * * * /home/rozie/dsp2017/bin/python /home/rozie/rss_from_category_blox.py 2>/dev/null | /bin/sed s'/pubdate/pubDate/g' | /bin/sed 's/lastbuilddate/lastBuildDate/g' > /tmp/dsp2017.xml && /bin/mv -f /tmp/dsp2017.xml /var/www/dsp2017.xml
*/15 * * * * /home/rozie/dsp2017/bin/python /home/rozie/rss_from_category_blox.py 2>/dev/null > /tmp/dsp2017.xml && /bin/mv -f /tmp/dsp2017.xml /var/www/dsp2017.xml

Całość wrzucam na GitHub, na wypadek, gdyby miało się komuś przydać.

UPDATE: Zgodnie z sugestią z komentarza, parsuję XML prawidłowo i pozbyłem się sed poprawiającego wyjście.