Nazwa.pl kupiła webhostingtalk.pl i zmienia swoją ocenę

Serwis webhostingtalk.pl traktujący o polskim hostingu został kupiony przez Nazwa.pl. Więcej można przeczytać na Wykopie i na samym forum. Nie pisałbym o tym, ale mam przeczucie, że na skutek intensywnego zamiatania pod dywan różnymi sposobami link może zniknąć, więc w ramach mirrora będzie wpis.

Forum było jakie było, ranking też. Wiadomo, że przy swobodnej wypowiedzi ludzie zamieszczają różne opinie i że są to tylko opinie pojedynczych osób. Do których jak najbardziej mają prawo. Wiadomo też, że człowiek, żeby coś zrobić, potrzebuje bodźca. Niemniej, część firm posiadała wysokie oceny, a samo forum było neutralne i funkcjonujące na przejrzystych zasadach.

Tymczasem po kupnie, oceny Nazwa.pl zostały zmodyfikowane. Oczywiście na korzyść firmy. Z 49 opinii o Nazwa.pl istniejących we wrześniu 2016 zostało 31. Średnia ocena zmieniła się z 2,27 na 4,07. Co ciekawe, było 18 osób poleca i  31 nie poleca. Teraz jest 26 poleca, 5 nie poleca. Oczywiście nie sposób wykluczyć, że naturalnie pojawiło się w tym czasie 8 pozytywnych opinii, ale biorąc pod uwagę dotychczasowe ilości, jest to bardzo mało prawdopodobne. Bardzo prawdopodobna jest za to manipulacja, mająca na celu wybielenie Nazwa.pl.

Pojawił się też wątek wzrostu liczby domen, który powoduje, że Nazwa.pl wskoczyła na pierwsze miejsce w rankingu, ale to trochę bardziej skomplikowane, więc z braku czasu pomijam.

Linki, screeny, źródła:
Web Archive opinie o firmie Nazwa.pl wrzesień 2016


Opinie o Nazwa.pl wrzesień 2016

Powyżej screenshot z WebArchive

 

 

Opinie o Nazwa.pl 06.09.2017

Powyżej screenshot wykonany dziś, podczas pisania wpisu

Przerwa majowa

Uważni czytelnicy dostrzegli, że w zeszłym tygodniu nie pojawił się żaden wpis. Regulamin DSP2017 dopuszcza przerwy w prowadzeniu projektów i… zeszły tydzień należy potraktować jako przerwę. Zresztą ponad tydzień, bo w zasadzie majówka cała nieprojektowa, z małym wyjątkiem, o którym zaraz. W każdym razie z konkursu się nie wycofałem i mam nadzieję, że tygodni roboczych będzie wystarczająco dużo. Nie liczyłem ile jest dokładnie, a zarejestrowałem się z opóźnieniem. Tak czy inaczej, nie chodzi o to by złowić króliczka…

Przerwy są dobre, czy to w pracy jako urlop, czy przy projekcie. Można spojrzeć z boku, wyskoczyć z utartych torów i nabrać energii. W każdym razie zeszły tydzień był mocno pracowity, a wypełnianie PITów, to nie jest coś, co warto odkładać na ostatnią chwilę, powiadam wam. Zresztą warto wcześniej sprawdzić, czy ma się komplet papierów, jak się okazuje. W każdym razie zdobyłem kolejny skill w zakresie obsługi podatków. Ale ostatecznie wszystko w miarę wyprostowane.

Potem był czas dobrych imprez i intensywnego chodzenia po sklepach celem urządzenia oświetlenia – powiedzmy, że 20% zrobione. A w międzyczasie doglądanie zewnętrznych rzeczy – a to serwer się zaczął restartować bez przyczyny (odpowiedź ISP rozwaliła, ale restarty ustały, hm…), a to ktoś zepsuł format danych, z których korzystam… Chwilę trwało, zanim przyswoili, że błąd zgłasza osoba z zewnątrz, a nie pracownik. Fun, fun, fun. Tylko czasu szkoda.

Udało mi się zrobić dwie związane z projektem rzeczy: przetestować uruchomienie programu na czystym systemie z ARM (działa, czemu miałby nie działać?) oraz wstawić Raspberry Pi zamiast Banana Pi jako router, czyli odzyskać właściwą sondę. Co prawda to ostatnie nie udało się w 100%, bo robiłem na szybko, trochę czasu zeszło na ustalenie, że NAT lepiej działa, jak się włączy forwarding, a po wszystkim okazało się, że logowanie przy pomocy autossh coś nie działa, ale powiedzmy, że wariant minimum jest zrobiony. Z powodu małej ilości czasu nie zaryzykowałem też wpięcia drugiego modemu.

Przerwa i programowanie w pracy skłoniło ku refleksji, że może jednak lepiej będzie docelowo przepisać to obiektowo. Głównie chodzi o łatwość wykorzystania kodu w innych projektach – dokładnie to przerabiam w pracy. W cele projektu oficjalnie tego nie wpisuję póki co, ale jeśli tylko starczy czasu, to będzie próba refaktoringu kodu.

Nginx z automatycznym odnawianiem certyfikatu SSL, HTTP/2 i A+

Artykuł na z3s o automatycznym odnawianiu darmowego certyfikatu SSL od Let’s Encrypt przypomniał mi, że nie skończyłem sprawy z nginx i certyfikatami SSL. Po pierwsze, brakowało mi wpisu w cronie. Trzy miesiące to jednak kawał czasu, a na serwer i tak się logowałem, więc certyfikaty były odświeżane ręcznie. No ale jak robić to porządnie, czyli w pełni automatycznie.

Wpis do crontab, którego używam to:

43 3 * * 2 /usr/bin/certbot renew --post-hook "service nginx reload" >> /var/log/certbot.log

Nie jest idealny – przede wszystkim restart nginx będzie wykonywany przy każdej próbie przeładowania, czyli raz na tydzień. Wydaje mi się, że przedładowanie konfiguracji nie będzie stanowiło problemu, ale jeśli komuś przeszkadza, to polecam zainteresowanie się opcją –renew-hook, zamiast –post-hook, która wykonuje się tylko przy odświeżeniu certyfikatu (czyli raz na kwartał). Z tym, że mam kilka certyfikatów i nie jestem przekonany, że restart nginx podczas odświeżania certyfikatu to jest to, co chcę robić, a testować mi się nie chce, tym bardziej, że na sucho średnio jest jak.

Rozwiązałem sprawę nie do końca działającego HTTP/2 (problemy z Firefox) opisaną w poprzednim wpisie. Przyczyna wskazana w komentarzach była trafna, żeby było ciekawiej, korzystałem dokładnie z

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL';

tyle, że zapewne podczas zabaw ze zwiększaniem kompatybilności z przeglądarkami zmieniłem to na wersję z gotowca, a potem odkręciłem ale… nie wszędzie. Poza tym, dopisanie http2 w każdej linii listen zawierajacej ssl i jest HTTP/2. Trochę sztuka dla sztuki, jak pokazały testy szybkości, ale wynika to głównie z tego, że same strony są małe i lekkie. Albo, jak Planeta Joggera, korzystają głównie z zasobów zewnętrznych, więc zmiany na moim serwerze nic nie dają.

W każdym razie powyższe szyfry i włącznie HSTS wystarczają do uzyskania oceny A+ na teście SSL, czego w nadchodzącym 2017 wszystkim życzę, korzystając z tego, że wpis przeleżał w szkicach nieco dłużej, niż planowałem.

Goodbye lighttpd

Do niedawna korzystałem na prywatnych gratach z lighttpd jako serwera WWW. Lekki, fajny, składnia pliku konfiguracyjnego powiedzmy perlowa, działał. Niby wszystko OK, ale… raczej nie jest wykorzystywany w różnych nowych projektach, jeśli ktoś daje narzędzia czy instrukcje, to raczej można się nie spodziewać znalezienia wersji dla lighttpd.

W międzyczasie troche bliżej miałem okazję zetknąć się z nginx i zrobił na mnie bardzo dobre wrażenie – dla kilku vhostów bardziej przejrzysty konfig, nieźle wspierany w dokumentacji różnych projektów (apache to to nie jest, ale jest dobrze). Gwoździem do trumny dla lighttpd okazał się brak wsparcia dla HTTP/2, a nawet brak planów w tym zakresie. I łatwość włączenia obsługi HTTP/2 na nginx – wystarczy jedna dyrektywa w pliku konfiguracyjnym (przy odpowiednio nowej wersji nginx – jest w backportach debianowych). Trochę na zasadzie „wykorzystać, nie wykorzystać, możliwość mieć można”.

Nic dziwnego, że pojawił się pomysł przesiadki na prywatnych gratach z lighttpd na nginx. Brakowało motywacji, bo po pierwsze istniejąca wersja działała, po drugie konfiguracja była lekko zakręcona, po trzecie brak czasu. Ostatecznie któregoś razu zebrałem się, wymyśliłem, że uruchomię oba serwery WWW równolegle, na różnych portach i zrobię szybki benchmark lighttpd vs nginx. Który to benchmark oczywiście wykaże, że nginx jest szybszy i potwierdzi słuszność przesiadki[1]. 😉

Jak już się zebrałem, to okazało się, że w sumie nie ma aż tak wielu rzeczy skonfigurowanych, a z wielu można/wypadałoby zrezygnować. Głównym wyzwaniem okazało się skonfigurowanie nginx tak, żeby HTTP słuchało na niestandardowym porcie i jednocześnie przekierowywało na HTTPS, również na niestandardowym porcie. Znalazłem rozwiązanie, ale machnąłem ręką – dziwne, nieprzystające do normalnego konfiga, a przydatne tylko na moment, przy benchmarku. Za to przydać się może ładny gotowiec do przekierowań z wersji z www na bez www i odwrotnie.

Przy okazji instalacji SSL dowiedziałem się, że w końcu istnieje oficjalna paczka z klientem Certbot dla certyfikatów SSL od Let’s Encrypt w Jessie (trzeba skorzystać z backportów). Plus, strona daje gotowe instrukcje instalacji dla popularnego oprogramowania (znowu: nginx jest, lighttpd nie ma). Czyli w certyfikatach też został zrobiony porządek. Dla pamięci: znalazłem stronkę z gotowcem, jak uzyskać A+ na popularnym teście SSL. Nieco przestarzała, ale nadal przydatna.

W zasadzie poszło zaskakująco dobrze, najwięcej niespodzianek wyszło na rzeczach najprostszych – a to serwer nie kompresował treści (tu jest o włączaniu kompresji), a to był problem z przetwarzaniem skryptów PHP. W końcu jest sensowna obsługa haseł na dostęp do stron (ew. miałem to wcześniej zrobione słabo).

Z rzeczy, które powinny działać, a nie działają – HTTP/2. Nie wiem, czy bardziej kwestia konfiguracji, wersji nginx, czy Firefoksa, ale wg testu HTTP/2 działało, a w Firefoksie (i na niektórych testach, zapewne korzystają z Firefoksa) strona się nie otwierała. Na innych przeglądarkach działało OK, ale do czasu rozwiązania problemu wyłączam HTTP/2.

Ponieważ wygląda, że publiczne motywatory działają: następna w kolejce jest przesiadka z chronicle na pelican na Wattmeter. Robi dobre wrażenie i jest w Pythonie. 😉

[1] Na przykładzie strony nextbike.tk i prostego testu przy pomocy ab -n 2000 -c 20 okazało się jednak, że różnicy większej niż błąd pomiaru nie ma. Być może kwestia wielkości małej wielkości pliku i narzutu na transmisję, być może kwestia obciążenia serwera, konfigi serwerów też nie były ani identyczne, ani optymalizowane. W każdym razie dla mnie szybciej nie będzie.

Drobne zmiany na planecie

Tak jest zawsze. Wszystko może działać od wieków stabilnie, ale jeśli tylko zrobię restart maszynki, mając mało czasu, to wychodzą kwiatki. Tak było i wczoraj z routerem (o tym kiedyś…), tak było i dziś z planetą Joggera. Restart dedyka przed wyjściem do pracy (o dziwo wstał bez problemu), bo już trochę długo działał i kernel stary, a ciągle zapominałem, odpalam stronę w tramwaju w drodze do pracy i… już gdzieś to widziałem.

Okazało się, że skrypt zaciągnął stare wpisy z jednego z feedów[1]. Początkowo podejrzewałem czyszczenie cache planety, który leżał w /tmp albo cache lighttpd (w ramach motywacji: wkrótce przejście na nginx), ale szybko wykluczyłem tę drugą możliwość. Cache planety był w /tmp i z tym nic nie zrobię, bo /tmp jest czyszczony przy restarcie, więc pomyślałem, że trudno i wkrótce się wyrówna.

Ale po powrocie do domu siadłem jednak do debugu. Na oko dziwna struktura feedu, który lądował na początku, ale validatory mówią, że tak może być i generalnie feed poprawny. Jedyne co się rzuca w oczy to lastBuildDate równe z datą pobrania pliku. Nie wiem, czy błąd, czy home made SEO, w każdym razie w połączeniu z brakiem informacji o dacie publikacji poszczególnych postów skutecznie chwilowo popsuło planetę[2].

W ramach mitygacji (nie kalkując z angielskiego: łagodzenia) zrobiłem dwie rzeczy. Po pierwsze, liczba postów na planecie z danego feedu jest ograniczona do trzech. Po drugie (i tego w repo nie będzie), cache wylądował poza /tmp. Czy się sprawdzi? Pożyjemy, zobaczymy. Gdyby ktoś zauważył jakieś problemy z ilością wpisów z feedu – proszę o kontakt.

[1] Dokładnie http://karbownicki.com/rss.xml

[2] Jeśli to możliwe, proszę o poprawienie tej daty.

KVM i task blocked for more than 120 seconds – solved

Sprawę miałem opisać już jakiś czas temu i zapomniałem, a jest szansa, że komuś się przyda. Był sobie serwer, na którym działało trochę VPSów. Wszystkie KVM, wszystkie z systemem plików ext4 i obrazem dysku qcow2. Czyli standard. Sprzęt nie pierwszej młodości, ale działały względnie stabilnie. Poza jedną, w sumie najbardziej obciążoną, bo działał w niej jeden z serwerów Zabbixa, niespecjalnie obciążony w porównaniu z innymi, w których jednak żaden nie działał w KVM.

Tej jednej zdarzał się zaliczyć zwis, z komunikatami:

kernel: INFO: task XXX blocked for more than 120 seconds.kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Wymagany był reboot wirtualki. Dotyczyło to różnych tasków, a całość działa się losowo – potrafiło działać przez kilka tygodni, a potrafiło wywalić się co parę dni, co nie ułatwiało diagnostyki. Początkowo działo się to na tyle rzadko, że sprawa została zignorowana, ale w miarę wzrostu obciążenia maszyny fizycznej, problem się nasilał. Objaw był taki, że operacje wymagające zapisu na dysk nie wykonywały się (czyli monitoring zdychał). Zacząłem szukać przyczyn – pierwotnie podejrzenie padło na coś, co wykonuje się z crona, bo sporo procesów crona wisiało, ale przejrzenie skryptów pokazało, że niespecjalnie mogą one być przyczyną

Wyglądało, jakby momentami coś nie wyrabiało się dostępem do dysków w momentach większego obciążenia. Z tym, że znowu – widać było, że nie jest to deterministyczne. Ponieważ maszyny jak wspomniałem starawe, to podejrzenie padło na sprzęt – problemy z dostępem do dysków potrafią robić cuda. SMART pokazywał, że wszystko OK, ale sprawdzić nie zawadzi… Przeniesienie wirtualki na inną, mniej obciążoną maszynę fizyczną nie przyniosło rezultatów – wieszało się nadal, chociaż rzadziej.

Oczywiście wyłączenie komunikatu, które jest w nim wspomniane, nie rozwiązuje problemu. W międzyczasie trafiłem na opis rozwiązania problemu, czyli zmniejszenie vm.dirty_ratio oraz vm.dirty_backgroud_ratio. Tylko że… to nie pomogło. Nie pomogło także zwiększenie kernel.hung_task_timeout_secs początkowo do 180, potem do 300 sekund. Było trochę lepiej, ale problem nadal występował. Pół żartem, pół serio zacząłem się zastanawiać nad automatycznym rebootem po wystąpieniu problemu (zawsze to krótsza przerwa), ale to brzydkie obejście, nie rozwiązanie. Tym bardziej, że w miarę wzrostu obciążenia i VPSa, i maszyny fizycznej na której on działał, problem zaczął występować częściej – góra co parę dni. Paradoksalnie, dobrze się stało, bo i motywacja większa, i sprawdzanie efektu wprowadzonych zmian łatwiejsze.

Z braku opisów w sieci, pomocy znajomych adminów i innych pomysłów zacząłem sprawdzać po kolei wszystko. Od fsck systemu plików, przez nowsze wersje kernela, zarówno na maszynie fizycznej, jak i na wirtualce – a nuż coś poprawili. Bez rezultatu. Ostatecznie postanowiłem zmienić format dysku wirtualki z qcow2 na raw i… trafiony, zatopiony – wirtualka zaczęła działać stabilnie.

Dla pewności wróciłem jeszcze z raw z powrotem na qcow2, na wypadek, gdyby chodziło o jakieś błędy, których nie wykrywało narzędzie do sprawdzania qcow2, ale… problem natychmiast wrócił. Gwoli ścisłości: ww. tuning dotyczący parametrów kernela z serii vm.dirty został zachowany.

Mumble, czyli alternatywa dla TeamSpeak

Powody dla powstania wpisu są dwa. Po pierwsze, pogrywam sobie czasem w World of Tanks, ostatnimi czasy niekoniecznie sam, a częściej w plutonie. Oczywiście można grać przy pomocy porozumiewania się wbudowanym chatem, czyli pisząc i używając wbudowanych komend i tak długi czas z K. graliśmy, ale przyszedł M. i namówił nas na zorganizowanie mikrofonów i słuchawek. I faktycznie, w przypadku komunikacji głosowej fun jest nieporównywalnie większy.

Korzystaliśmy z wbudowanego w grę mechanizmu, który wymaga wciśnięcia klawisza, jeśli chce się coś powiedzieć. Wykonalne, ale palców jest ograniczona ilość i w czasie gry mają lepsze zajęcia, niż obsługa głosu. Zdarza się, że się zapomni o wciśnięciu klawisza czy po prostu nie ma czasu go wcisnąć. I komunikat ginie.

Trochę zaczęliśmy myśleć o alternatywach. Ostatecznie gracze z jakiegoś powodu korzystają z TeamSpeaka… W klanie K. jako system komunikacji głosowej obowiązywał nie TeamSpeak, ale Mumble, którego nazwa zupełnie nic mi nie mówiła.

Logo Mumble

Źródło: https://en.wikipedia.org/wiki/File:Icons_mumble.svg

Rzuciłem okiem i okazało się, że jest natywna wersja linuksowa, a software to open source. I tu drugi powód powstania wpisu: TeamSpeak jest dostępny (zarówno klient, jak i serwer) na Linuksa, ale nie jest open source i dostarczana jest binarka. Tylko dla architektur i386 oraz amd64 w Debianie. Niedawno na kanale IRC ktoś pytał o tego typu chat grupowy z możliwością uruchomienia serwera na procesorze ARM. Mumble jako open source oczywiście jest dostępne także na architektury armel oraz armhf. Poza tym, lubię testować alternatywy.

Zainstalowałem serwer (można ograniczyć dostęp hasłem, domyślna konfiguracja jest prosta i wystarczająca do uruchomienia…), choć można skorzystać z serwerów publicznych. W konfiguracji serwera można też zgłosić swój serwer do katalogu publicznych.

Instalacja klienta jest równie prosta, jedyne co trzeba zrobić, to wyskalować dźwięk przy pomocy wizarda. Klient ma trzy metody włączania nadawania: non-stop (mikrofon cały czas „zbiera” – średnio wygodne dla reszty uczestników), znana z WoT aktywacja klawiszem oraz tryb najlepszy, czyli aktywacja głosem. I po to jest kalibracja, żeby przy odpowiednim natężeniu dźwięku (czyli gdy coś mówimy) klient zaczynał transmisję, ale nie zbierał cały czas tła.

Najważniejsze cechy Mumble:

  • szyfrowana komunikacja (domyślnie)
  • niskie opóźnienie
  • open source
  • wieloplatformowość (Linux, Windows, OS X)
  • niskie wymagania zasobów (serwer; jest nawet wersja serwera dla OpenWrt)
  • usuwanie echa
  • pozycjonowane audio (słychać z którego kierunku mówi osoba)
  • in-game overlay (jest wyświetlane, kto mówi)

Z ostatnich trzech nie korzystam, bo – kolejno – gramy na słuchawkach, nie ma potrzeby/nie zauważyłem, zupełnie nie mam potrzeby. Jeśli chodzi o jakość dźwięku i opóźnienie jestem bardzo zadowolony (póki co testowane na dwóch osobach na kanale, większą ilością się nie zebraliśmy). Jakość dźwięku lepsza zarówno niż w WoT, jak i na Skype (skoro VoIP porównujemy). Nie wiem na ile w tym zasługi łącz, a na ile klienta, ale jeśli tylko wszyscy w plutonie mają zainstalowanego klienta Mumble, to korzystamy z tego rozwiązania. Polecam.

Więcej o Mumble można poczytać na angielskiej stronie Wikipedii. Ale nie ma co czytać, trzeba instalować. 😉

Boot once w GRUB

Czasami jest potrzeba, żeby uruchomić maszynę z danym kernelem, ale tylko raz. W przypadku niepowodzenia chcemy mieć uruchamiany z powrotem stary, sprawdzony kernel. Zwykle taka potrzeba pojawia się, gdy testujemy nowy kernel i nie mamy fizycznego (lub zbliżonego) dostępu do maszyny, a np. mamy pod ręką kogoś, kto w razie problemów niekoniecznie pomoże z debugiem, ale chociaż wciśnie reset. Dziś pojawiła się u mnie taka potrzeba, za sprawą dedyka pod Piwika i chęci zmiany kernela z nieco starego z OVH na dystrybucyjny.

Okazało się, że wypadłem z tematu. Ostatni raz miałem potrzebę jednorazowego uruchomienia kernela chyba w okolicach LILO jako używanego bootloadera. Nie pamiętam jak to dokładnie w LILO wyglądało, ale mam wrażenie, że było proste, intuicyjne (w końcu jeden konfig) i – przede wszystkim – dobrze udokumentowane.

Poszukałem chwilę i znalazłem polecenie grub-reboot, któremu jako parametr podaje się numer wpisu w /boot/grub/grub.cfg i które ma powodować jednokrotne uruchomienie kernela o podanym wpisie. Ucieszyłem się, że pomyśleli o mnie i tak prosto. Maszynka niekrytyczna, kernel dystrybucyjny, więc raczej wstanie, wydałem więc stosowne polecenie, następnie reboot i… system wstał! Ze starym kernelem.

Nawet niezbyt się zirytowałem. Po prostu odpaliłem testowego kompa w domu i zacząłem się bawić. Ustawiam numer wpisu, który ma się włączyć, reboot i… to samo. Dłuższa chwila szukania i znalazłem opis na niezawodnym wiki Arch Linux:

This requires GRUB_DEFAULT=saved in /etc/default/grub (and then regenerating grub.cfg) or, in case of hand-made grub.cfg, the line set default=”${saved_entry}”.

Jak na lata doświadczeń przystało, wyboru kernela nie pozostawiam przypadkowi i w moim /etc/default/grub były ustawione na sztywno numery kerneli do uruchomienia. Zmieniam na powyższe na testowej maszynie w domu, grub-reboot potem reboot i… wstał! Z nowym kernelem. Świat wydaje się piękny, więc reboot, by wrócić na stary kernel i… tak dobrze nie ma. Uruchamia się za każdym razem z nowym.

Nawet niezbyt się zirytowałem, po prostu rebootnąłem zdalną maszynkę na nowy kernel. Skoro dystrybucyjny to raczej wstanie. Stosowne zmiany, reboot i… maszynka wstała, z nowym kernelem, wszystko wydaje się działać. Misja zakończona, cel osiągnięty.

I tu byłby koniec wpisu, ale w międzyczasie zacząłem rozmowę na ten temat na kanale IRC #debian (@freenode). Tam dowiedziałem się o /boot/grub/grubenv i o tym, że może (będzie) się tak dziać, jeśli nie jest ustawione prev_saved_entry. I faktycznie, nie było. I dowiedziałem się, że można to ustawić wydając polecenie grub-reboot więcej, niż raz.

Czyli, żeby zrobić boot once dla GRUBa, trzeba kolejno:

  • ustawić GRUB_DEFAULT=saved w /etc/default/grub
  • grub-reboot <wpis, gdzie ma być default>
  • grub-reboot
  • sprawdzić /boot/grub/grubenv na wszelki wypadek
  • reboot

I pomyśleć, że przy LILO była to szybka edycja konfiga plus lilo dla wprowadzenia zmian w życie… Znaczny postęp poczyniliśmy! 😉

Skoro już wpis na tematy linuksowe… Archa nie próbowałem, ale ludzie (w tym jeden DD) chwalą. Bardzo dobra dokumentacja. Poza tym, jest taka inicjatywa jak debianfork.org. I cieszę się, że jest. Bo skoro Debian może mieć więcej niż jedną architekturę, więcej niż jeden kernel (tak kFreeBSD), to czemu nie miałby móc mieć różnych, równorzędnych demonów do startu usług?

5 sposobów na efektywne korzystanie z emaila

Nie lubię wpisów o produktywności, ale z poczty elektronicznej korzysta wiele osób i przerażająca część robi to w sposób tragicznie nieefektywny. Przynajmniej moim zdaniem. Ponieważ email jest dla mnie od paru lat w pracy jednym z podstawowych sposobów komunikacji i narzędzi pracy, pozwolę sobie na opisanie paru prostych sposobów na efektywniejsze korzystanie z niego.

1. Korzystaj z IMAP

Jeśli zdarzyło się komuś stracić bezpowrotnie zawartość skrzynki z powodu utraty komputera czy padu jego dysku, korzystać z poczty elektronicznej w różnych miejscach czy na różnych komputerach i nie mieć dostępu do jakiegoś maila czy swojej odpowiedzi na jakiegoś maila bo został na innym komputerze to znaczy, że warto zacząć korzystać z IMAP[1].

Dodatkowa zaleta jest taka, że jeśli przesuniemy ręcznie maila do folderu (o tym zaraz), to będzie on w tym folderze wszędzie, a nie tylko na komputerze, na którym przesuwamy, ale wszędzie.

Wiem, że rada może wydać się dziwna, ale wiele osób, zwłaszcza tych, które zaczynały korzystać z poczty dawno temu, nadal korzysta z POP3. Szczególnie, że kiedyś IMAP nie był dostępny w darmowych usługach (przynajmniej większości z nich).

2. Foldery i filtry do sortowania poczty

Praktycznie każdy klient poczty umożliwia tworzenie reguł, na podstawie wielu kryteriów i wykonywanie na ich podstawie różnych czynności, takich jak usuwanie maili czy też przenoszenie ich do stosownego folderu. Zwykle ogranicza się to do kasowania spamu lub przenoszenia go do folderu spam, ale nic nie stoi na przeszkodzie, by sortować np. maile z przedszkola do folderu przedszkole, a maili z ciągiem znaków faktura czy vat do folderu faktury. Jeśli ktoś korzysta z list mailowych albo dostaje powiadomienia z automatów, to na pewno zna.

Oczywiście sortować można także ręcznie, po prostu przenosząc maile do odpowiednich folderów, posortowanych zagadnieniami. Zwykle jednak, szczególnie przy większej skali, wygodniej jest używać filtrów.

3. Sortowanie poczty na serwerze

Teraz zaprzeczę sam sobie, bo przed chwilą pisałem o filtrach w kliencie pocztowym. Rozwinięciem tego jest skorzystanie z filtrów na serwerze. Czyli takich definiowanych w panelu naszego ISP pocztowego. Mogą mieć mniejsze możliwości konfiguracji (m. in. dlatego warto mieć proste filtry, przy okazji łatwiej je zaprogramować i utrzymywać), ale sortowanie odbędzie się w momencie wejścia poczty na serwer, czyli wiadomości będą zawsze posortowane, a poza tym unikniemy problemu z synchronizacją filtrów. Kto ma dobre filtry w programie pocztowym, dużo poczty przychodzącej i musiał szukać ważnego maila przez webmail w nieposortowanych na pewno doceni. Rozwiązanie ma wadę – filtry dostępne na serwerach mogą być uboższe od tych wbudowanych w programy pocztowe, ale IMO warto się dostosować.

4. Wątkowanie

Warto korzystać z programu pocztowego, który umożliwia przełączenie się na widok z wątkami. O ile sam domyślnie sortuję pocztę chronologicznie, o tyle często przełączam się na widok z wątkowaniem, jeśli muszę znaleźć konkretnego maila w rozgałęzionym wątku. Niby cytowanie całości ma eliminować potrzebę cofania się do starszych wiadomości, ale zwyczajnie nie działa w przypadku rozgałęzień. Poza tym, w widoku z wątkami od razu widać kto, kiedy i komu odpowiadał, więc wygodniejsze i szybsze, niż grzebanie w cytatach.

5. Notatnik zawsze przy sobie

Jeśli już korzystamy z programu pocztowego i jest on zawsze otwarty, to można wykorzystać edytor maili jako… notatnik. Brak jakiegokolwiek szukania programu do zrobienia notatki, czekania na uruchomienie, problemów z wyborem miejsca, gdzie zapisać plik (wiadomo, że notatka trafi do folderu szkice/drafts; warto nadać tytuł odpowiadający treści). Formatowanie jak w edytorze mailowym jest zwykle wystarczające[2], chociaż osobiście uważam, że przy szybkich notatkach nie warto bawić się w jakiekolwiek formatowanie, co najwyżej można użyć punktowania. Co więcej, jeśli korzystamy z IMAP, to taka notatka jest niezależna od komputera, na którym ją piszemy – nie trzeba jej przesyłać, będzie od razu dostępna z różnych maszyn. Zresztą notatki i tak zwykle robię po to, żeby wysłać później maila.

PS. Kiedyś napisałem i leżało w szkicach. Może komuś się przyda.

[1] W zasadzie z IMAPS, czyli jego szyfrowanej wersji, ale po pierwsze to oczywiste, a po drugie wpis ma traktować o efektywniejszym korzystaniu z poczty email, a nie o bezpieczeństwie. Konsekwentnie odpuszczam ten temat w całym wpisie.

[2] Jeśli ktoś korzysta z HTML. Jeśli ktoś pisze – jak ja – w plain text, to temat formatowania zupełnie odpada, zresztą uważam, że formatować warto na końcu, jak mamy całą treść.

Własna namiastka dyndns

Po ostatniej akcji Microsoftu z przejęciem i zablokowaniem domen należących do No-IP miałem przez moment umiarkowany problem z dostępem do jednej z moich maszyn, bo nie znałem IP. Nic krytycznego i szybko rozwiązałem, ale stwierdziłem, że warto by się zabezpieczyć na przyszłość. Początkowo chciałem uruchomić po prostu innego dostawcę dyndns, z inną domeną, co dałoby całkiem niezłą – jak mi się wydaje – redundancję w tym względzie, ale prowizorycznie uruchomiłem coś innego, własnego i znacznie prostszego. W komentarzu do poprzedniego wpisu padło pytanie co dokładnie zrobiłem, więc opisuję.

Tak się składa, że mam serwer dedykowany ze stałym IP (nie jest konieczne zamiast tego można skorzystać z domeny), na którym stoi serwer WWW (lighttpd). Na wszystkich maszynkach potrzebujących dyndns mam dostęp do crona (zresztą, korzystałem z crona już przy zwykłym koncie dyndns, patrz update wpisu). Rozwiązanie jest proste: klient wywołuje okresowo unikatowy URL na moim serwerze, serwer okresowo parsuje log w poszukiwaniu tego unikatowego ciągu znaków i zapisuje IP z którego nastąpiło odwołanie w określonym pliku.

Poniżej wklejki ze wszystkimi onelinerami (gotowiec dla lighttpd, w przypadku innego serwera WWW trzeba dostosować):

# po stronie klienta*/5 * * * * /usr/bin/wget -4 -q -O /dev/null http://mojadomena.com/losowyciagznakow4346456543324645 > /dev/null
 # po stronie serwera*/5 * * * * /usr/bin/awk '/losowyciagznakow4346456543324645/ {ip=$1} END {print ip}' /var/log/lighttpd/access.log > /var/www/dyndns_host1.txt
 # pobranie IPwget -O - http://mojadomena.com/dyndns_host1.txt

Po namyśle, rozwiązanie nawet lepsze niż drugi dostawca dyndns. Mniej kont, prostsza konfiguracja, mając stałe IP na upartego można całkowicie uniezależnić się od DNSów, jeśli ktoś odczuwa potrzebę.

Oczywiście nie od razu tak to wyglądało, w szczególności po stronie serwera był grep, awk, tail w użyciu. Ale skoro da się wszystko załatwić awk (a nie tylko wyświetlanie określonej kolumny, chyba najczęstsze zastosowanie awk…), to czemu nie? Tu polecam zbiór przydatnych onelinerów w awk.

UPDATE: IPv6 się popularyzuje. Okazało się, że mój skrypt nie działa poprawnie, bo łączenie między maszynami następuje po IPv6. Dodany parametr -4 do wget w celu naprawy tego problemu.

CryptoLocker – polski akcent

Istnieją poważne poszlaki, że za ransomware o nazwie CryptoLocker stoją… Polacy. Malware ów został zbadany i opisany na blogu [deadlink] (polecam lekturę całego wpisu), autor uzyskał dostęp do bazy (niestety dość pustej) i widać w kodzie tekst:

define('DBPASS', 'Be6mybCWhpFpgG4u');//Dostep do sql zamiana!!!

Swojsko brzmiący komentarz, prawda? Swoją drogą ładny przykład na to, że korzystanie z Tor nie oznacza braku możliwości namierzenia, gdzie stoi serwis, chociaż w tym przypadku autorowi wpisu nie udało się uzyskać adresu IP systemu.

UPDATE: Jak donosi Zaufana Trzecia Strona, malware nie nazywa się CryptoLocker, a CryptorBit. Polecam ich wpis – dużo więcej informacji i po polsku.

Wirtualna Polska zamyka kolejny serwis.

Po niedawnym zamknięciu serwisu mp3.wp.pl przez Wirtualną Polskę, przyszła pora na spik.wp.pl, czyli serwer jabbera utrzymywany przez WP.pl. W zasadzie była to podstawka pod ich komunikator Spik, którego rozwój został zatrzymany jakiś czas temu. Wczoraj rano dostałem na jabberze wiadomość:

Drogi Użytkowniku Spika, Komunikatora WP,
Dziękujemy za wieloletnie korzystanie ze Spika, za liczne propozycje rozwoju i wsparcie jakie od Was otrzymaliśmy.
Niestety, ze względów biznesowych, podjęliśmy decyzję o zamknięciu Komunikatora WP, w tym serwera jabber.wp.pl.
Mamy nadzieję, że pozostaniecie z nami korzystając z innych usług Wirtualnej Polski, http://wp.pl
Poniżej nota prawna niezbędna do zamknięcia usługi od strony formalnej:
„Wirtualna Polska” S.A. z siedzibą w Gdańsku wypowiada Panu/i umowę o świadczenie Komunikatora WP, określonego postanowieniami Regulaminu korzystania z Komunikatora WP, z zachowaniem jednomiesięcznego okresu wypowiedzenia.
„Wirtualna Polska” S.A w Gdańsku przy ul. Traugutta 115 C, wpisana do Krajowego Rejestru Sądowego – Rejestru Przedsiębiorców prowadzonego przez Sąd Rejonowy Gdańsk – Północ w Gdańsku VII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem KRS 0000068548, posiadająca kapitał zakładowy w wysokości 67.980.024,- złotych (wpłacony w całości) i Numer Identyfikacji Podatkowej 957-07-51-216.”

Zastanawiam się, jak bardzo źle musi być u nich z kasą, skoro killują takie serwisy. Być może niszowe i nie przynoszące wielkich pieniędzy, ale – jak dla mnie – kreujące wizerunek firmy i odróżniające ją od konkurencji. O ile serwis mp3.wp.pl mógł być kosztowny w utrzymaniu ze względu na ilość danych, to serwer jabbera to raczej – od strony technicznej – drobiazg. Tak, wiem, na stronie technicznej nie kończy się utrzymanie usługi. Nie tylko ja zastanawiam się, jaki będzie następny serwis zamykany przez WP.

Myślę, gdzie się zmigrować, bo do tej pory był to mój podstawowy serwer jabbera. Jakieś sugestie (nie Google, niekoniecznie musi być polskie, niekoniecznie musi być darmowe)?

I jakoś tak smutno mi się zrobiło, że kończy się ta usługa – w końcu można powiedzieć, że z nią zaczynałem zabawę z Internetem. Człowiek się starzeje.

Blokada portu 25 w Netii.

Netia dołączyła do grona największych[1] (wcześniej, jako pierwsza zrobiła to TPSA, potem – z większych operatorów – port 25 zablokował Dialog) i zablokowała port 25 dla użytkowników. Znowu późno się późno się zorientowałem, bo po blisko miesiącu i pewnie nie napisałbym o tym, gdyby nie to, że jest to zrobione… źle.

Netia wprowadziła blokadę w najgorszy sposób dla użytkownika, tj. bez możliwości usunięcia blokady przez użytkownika. Nie da się jej usunąć ani samodzielnie, w sposób automatyczny (tak można to zrobić w przypadku Neostrady), czy w sposób zupełnie ręczny (telefon na infolinię), jak w Dialogu.

Poza tym, blokowanie portu 25 miało duży sens parę lat temu. TPSA była 3,5 roku temu pionierem, była to reakcja na realny problem spamu (Polska była w światowej czołówce wysyłających spam) i były realne efekty. Taki okres w IT to niemal epoka. Obecnie (niestety) coraz więcej spamu jest rozsyłanych w inny sposób, w szczególności przez soft kradnący hasła do skrzynek pocztowych. Ale lepiej późno, niż wcale.

Po drugie, blokada dotyczy tylko IP przydzielanych dynamicznie. Spam z łącz biznesowych będzie płynął dalej (a zmiana typu łącza na biznesowe to – zdaniem rzecznika – prosta sprawa[2]). Gwoli ścisłości, z tego co pamiętam, to samo zrobiła TPSA, bo – wbrew temu co pisze rzecznik Netii – blokada dotyczyła tylko Neostrady, ale już nie Internet DSL.

Po trzecie, brak możliwości zdjęcia blokady przez użytkownika. Co prawda opinia UKE w tej sprawie była pozytywna (czyli, że wolno tak zrobić – kiedyś wysłałem pytanie; nie oznacza to, że użytkownik nie ma możliwości rozwiązania umowy – tu już powinien wypowiadać się IMO UOKiK lub sąd), ale nie dawanie wyboru użytkownikom, jest słabe (choć prostsze technicznie). Szczególnie, że technicznie jest taka możliwość. W połączeniu z argumentacją usługi z dynamicznym IP nie są stworzone po to, żeby na nich stawiać serwery pocztowe[3] jest żenujące[4]. Uważam, że TPSA podeszła do tematu o dwie klasy lepiej.

[1] Przepraszam, ale ten zwrot mi się bardzo ostatnio spodobał, choć tu akurat bez podtekstu jest. Informacja o blokadzie portu 25 na blogu Netii.

[2] Komentarz nr 18:

12.02.2013, 10:39
@maniek552 Nie ma z taką zmianą żadnego problemu. Przechodzi się na ofertę biznesową nadpisując dane w systemie i sprawa załatwiona. Ceny są praktycznie takie same.
[3] Komentarz nr 29:
@maniek552 Z tym, że TP i Dialog wycięli wszystkim (również stałym IP) a my blokujemy tylko dynamicznym. Jest różnica i to duża. Usługi z dynamicznym IP nie są stworzone po to, żeby na nich stawiać serwery pocztowe.
[4] Stawianie serwerów nie jest podstawowym przeznaczeniem takich łącz – tu zgoda. Ale idąc tym tokiem rozumowania za moment okaże się, że można zablokować możliwość jakichkolwiek połączeń przychodzących na dynamicznych łączach (nawiasem, Orange tak robi z mobilnym internetem), albo w ogóle dopuścić tylko WWW i pocztę (w końcu SSH to „biznesowe” zastosowanie, c’nie? jeszcze NTP by się przydało i DNS, żeby w miarę sensownie działało). A tymczasem coraz częściej w domach pojawiają się „serwery”. Czy to gier, czy WWW. Często są one uruchamiane w taki sposób, że użytkownik nawet nie wie, że są, on po prostu udostępnia muzykę czy zdjęcia…

Koniec grup news (NNTP) w Polsce?

Dawno, dawno temu, w czasach, gdy Internet nosiło się w wiaderkach[1] i kosztowało to sporo, korzystałem z grup news. Obok WWW i email była to główna forma aktywności w Internecie, perwersje typu portale społecznościowe, blogi i µblogi zwyczajnie nie istniały. Nawet mam skonfigurowany czytnik news (XPN), który powiedzmy, że daje radę. Ale newsy umarły, na rzecz innych form komunikacji. Ludzie przenieśli się na ww. formy platformy (tak, naprawdę sporą część ludzi widzianych na blogach i µblogach kojarzę z news)…

Dziś na IRC (który jakoś tam nadal żyje) padło pytanie czy subskrybuje ktoś z was newsy, bo coś dziwnego mi się dzieje. Do subskrybcji średnio się poczuwam (raz na parę tygodni odpalę czytnik, od dawna nic nie piszę), ale postanowiłem zerknąć, bo w sumie mój klimat. Otóż nie wysyłają się posty przez serwery news.onet.pl i news.gazeta.pl. Klik, klik, telnet na 119 – nic. Ping – nic. Wejście na niusy.onet.pl i wszystko jasne. Potem poczytałem pl.news.admin i poza ww. serwerami wyłączony został jeszcze news.lublin.pl. Ale bolą głównie te dwa, były chyba najpopularniejszą metodą wysyłania postów dostępną za darmo i dla wszystkich (po zalogowaniu), bez względu na ISP. 

Tak, wiem, to jeszcze temat z zeszłego roku, ale dopiero teraz się dowiedziałem. Co też o czymś świadczy.

[1] Serio. Były narzędzia do ściągania news w jednym miejscu i przenoszenia do komputera, na którym się je czytało. Albo narzędzia pozwalające na pobranie skompresowanych (i IIRC przefiltrowanych) postów. I płaciło się za każdą minutę/sekundę połączenia, nie za ilość pobranych danych. Potem TPSA (obecnie działająca pod marką Orange – kolejny znak czasów) wprowadziła pakiety i w końcu stałe łącza do domu.

UPDATE: Wygląda, że pogłoski o wyłączeniu news.gazeta.pl były przesadzone. Faktycznie przed chwilą nie odpowiadał, ale teraz:

200 news.gazeta.pl InterNetNews NNRP server INN 2.3.5 ready (posting ok).