Egipt.

Nie będę pisał o (dramatycznej) sytuacji politycznej Egiptu (celowo mirror, źródło oryginalne działa, ale…), skupię się tylko na aspekcie technicznym i przekazywaniu informacji. Po pierwsze, jak wiadomo, został odcięty cały dostęp Egiptu do Internetu. Z tego co wiadomo, na poziomie sesji BGP, bez wpływu na linie tranzytowe. Wygaszanie wygląda na zaplanowane, z upewnianiem się co do braku wpływu na zagranicznych operatorów. Wygląda, że dążą do tego, aby ukryć to, co dzieje się wewnątrz kraju, bez dawania powodów krajom zewnętrznym do angażowania się.

Dodatkowo, wyłączone zostały najpierw SMSy, a potem sieci komórkowe. W takiej sytuacji wszelkie tunelowania są bezużyteczne. Odcięcie na poziomie BGP oznacza, że TOR nic nie pomoże. Przez chwilę, nie znając dokładnie sytuacji, liczyłem, że wewnętrznie Internet działa z jakimś proxy dla zapytań DNS, co umożliwiłoby tunelowanie w zapytaniach DNS, ale nie.

Okazało się, że z działających rzeczy zostały tylko stare technologie: modemy dial-up (linie analogowe i wyjścia za granicę nie zostały odcięte, przynajmniej nie wszystkie) i ham radio. Pojawiły się oczywiście problemy z retransmisją odebranych sygnałów – poczynając od tego, że ktoś nie bardzo ma możliwość, bo jest w pracy, przez brak sprzętu lub możliwości (internet domowy w USA to jakaś pocięta parodia). Część transmisji była odbieranych alfabetem Morse’a, część głosowo. W przypadku odbieranych Morsem pojawiał się problem dekodowania (mało kto zna, jeszcze mniej zna płynnie). Istnieją automaty do tego, ale płatne i podobno słabo radzące sobie z zaszumionym sygnałem.

Większość ww. rzeczy robią ochotnicy, czasami z pomocą ISP, którzy zapewniają dostęp wdzwaniany. Z kolei TV, które są masowo dostępne, pokazują informacje tendencyjnie, często przeinaczając.

Podsumowując: mimo obecnej techniki (a może właśnie przez nią), szanse na wolne, nieocenzurowane przekazywanie informacji są niewielkie, jeśli rząd zechce coś wyciszyć. Na organizowanie niezależnej łączności jest za późno, gdy jest ona potrzebna – możliwości są niewielkie.

Apt-p2p – ostateczny test.

Krótko o apt-p2p.

Apt-p2p spodobał mi się od razu, gdy tylko o nim usłyszałem. Jest to bardzo ciekawe podejście, w którym pobieranie pakietów deb odbywa się przy pomocy P2P (protokół bittorrent), zamiast z tradycyjnych centralnych repozytoriów (HTTP, FTP). Centralne repozytoria są wykorzystywane wyłącznie w przypadku, kiedy pakiet nie jest dostępny przez P2P lub nie jest wystarczająco popularny (za mało peerów).

Kiedyś zrobiłem krótki test apt-p2p, ale trudno go nazwać miarodajnym – maszyna była bardzo słaba, demon ma spory apetyt na zasoby i nie udało mi się wtedy zmusić go do działania jako proxy dla innych maszyn, a sam test nie trwał długo. Od tamtej pory minęło trochę czasu. Maszynka robiąca za router została wymieniona na coś bardziej współczesnego, znalazłem sposób na uruchomienie apt-p2p jako lokalnego proxy (brzydki, bo wymaga gmerania w kodzie, ale się da i działa). Program dostał drugą szansę.

Efekty działania.

Demon był testowany (czyli po prostu używany) w sumie na trzech maszynach, przez parę tygodni. Pierwsza maszyna, działająca 24/7, w zasadzie base system + parę pakietów, Lenny, publiczne IP, robiła też za proxy dla kolejnej (desktop, Lenny). Apt-p2p w wersji 0.1.5:

Transport

Mirror Downloads Peer Downloads Peer Uploads
This Session 0.0B 0.0B 0.0B
Session Ratio 0.00% 0.00% 0.00%
All-Time 108MiB 32.5MiB 50.4MiB
All-Time Ratio 76.85% 23.15% 35.86%

 

Maszyna druga (mój desktop), Squeeze, za NAT, bez przekierowanych portów. Apt-p2p w wersji 0.1.6:

Transport

Mirror Downloads Peer Downloads Peer Uploads
This Session 47.4MiB 119KiB 0.0B
Session Ratio 99.75% 0.25% 0.00%
All-Time 1.07GiB 340MiB 0.0B
All-Time Ratio 76.33% 23.67% 0.00%

Statystyk trzeciej maszyny nie zaprezentuję – napotkałem na dziwny problem z pobieraniem plików, być może mający związek z uruchomieniem tunelu IPv6 (MTU? brak wsparcia dla IPv6 w apt-p2p?) i cache był czyszczony przy okazji prób rozwiązania problemu. Jak patrzyłem wcześniej, to nic specjalnie różniącego się od powyższych nie zauważyłem.

Inne uwagi.

Pierwsze, co rzuca się w oczy po zmianie sposobu pobierania, to fakt, że pobieranie jest znacznie wolniejsze, niż normalnie. Widać to szczególnie na szybszych maszynach, z lepszym łączem. Prawda jest taka, że zwykle z tradycyjnych repozytoriów pakiety lecą z pełną prędkością. W przypadku skorzystania z apt-p2p widać przy każdym pliku laga, zapewne chodzi o sprawdzanie, czy peery posiadają dany pakiet. Nie jest to drastyczne dla aktualizacji systemu, ale drażni, jeśli potrzebujemy szybko doinstalować jakiś pakiet.

Jeśli chodzi o pobieranie, to jak widać na tej mizernej próbce, stosunek pakietów pobieranych tradycyjnie do pobieranych przez P2P jest w miarę stały i wynosi około 3 do 1. Całkiem niezły wynik, szczerze mówiąc liczyłem na znacznie mniej pobieranych przez P2P.

Widać też wyraźnie, że przekierowanie portu jest absolutnie niezbędne, jeśli nie chcemy być leecherem. Szczerze mówiąc, liczyłem, że coś tam będzie się wysyłać zza NAT do peerów z publicznym IP, tak jak przy tradycyjnym P2P, ale widocznie implementacja protokołu niestety nie pozwala na to.

Pakiet ma sporo błędów, a autor nie spieszy się z ich usunięciem. Wspomniany wcześniej brak prostego sposobu na uruchomienie apt-p2p jako lokalnego proxy to jeden z przykładów. Do tego dochodzą nieciekawe defaulty związane z miejscem zajmowanym przez logi czy problemy z działaniem przy zmianie IP lub utracie łączności z Internetem.

Na szybką poprawę błędu związanego z możliwym DDoSem przez klientów P2P też pewnie nie ma co liczyć… Nawet nie zgłaszałem tego, bo na inne błędy zero reakcji autora. Taki brak odpowiedzi jest okrutnie demotywujący, fajnie jest usłyszeć choćby, że będzie poprawione w następnej wersji, albo że nie uważa tego za (poważny) błąd.

Ewidentnie brakuje silnego community wokół projektu, najlepiej ze znajomością Pythona (przyznaję, próbowałem nieco z powyższych poprawić przez dodanie opcji, ale prawda jest taka, że ciężko i długo robi się coś w języku, którego się nie zna).

Zapewne wszystko wiąże się z tym, że apt-p2p jest mało popularny. Widać to choćby na kanale IRC poświęconym programowi. Zapewne prędkość pobierania byłaby wyższa, gdyby peerów było więcej, pewnie udałoby się poprawić część błędów, a autor miałby większą motywację do pracy widząc, że program jest popularny.

Podsumowanie.

Uważam, że w tej chwili apt-p2p jest mocno zapuszczony, słabo przetestowany i IMHO nadaje się wyłącznie dla geeków. Jeśli są chętni (najlepiej ze znajomością Pythona) do zabawy z tym programem, to dajcie znać. Jest dobry moment na popularyzację tego rozwiązania, przy okazji pewnie dałoby się odciążyć nieco mirrory przy wydaniu Squeeze’ego (i zapewnić szybszy upgrade do nowego systemu – tak przynajmniej twierdzono w swoim czasie w przypadku Ubuntu). Jeśli chętnych brak, to nie pozostaje nic innego, jak wyłączyć apt-p2p i znowu poczekać parę lat… Może coś się zmieni.

Linux w stacji ładującej telefony komórkowe.

Linuksa widzieliśmy już we wrocławskich automatach biletowych, na gdańskich wyświetlaczach rozkładu jazdy. Jakiś czas temu w Poznaniu w jednej z galer(ii) handlowych pojawiło się dziwne urządzenie. Nie widziałem, by ktoś z niego korzystał, z opisu miała to być stacja do ładowania i dezynfekcji(?) telefonów komórkowych.

Postało jakiś czas, potem się zepsuło (albo nigdy nie zostało uruchomione – te kabelki zawsze tak na wierzchu były – żadnego zamknięcia…), ujawniając, że pod spodem działa Linux. Takie zepsute postało jeszcze parę dni i… zniknęło. Czyżby nie było biznesu w ładowaniu i dezynfekcji telefonów komórkowych? W sumie nie zdziwiłbym się, gdyby w mieście nie było – do ładowarki blisko, a miejsce nie wygląda na pewne. Ja bym nie zostawił telefonu GSM tak bez nadzoru…

W każdym razie, dowód, że pod spodem Linux (sorry za jakość, komórką klikane szybko):

Urządzenie do ładowania telefonów - pełny widok.

I zbliżenie ekranu – GRUB z komunikatem błędu w całej okazałości:

Komunikat błędu na ładowarce.

Flashowanie BIOS spod Linuksa – flashrom.

Dla jasności: poniższy wpis nie ma charakteru poradnika, bardziej jest opisem geekowej zabawy i jako taki należy go traktować, chociaż parę porad też się znajdzie.

Przeczytałem wpis o flashowaniu BIOS bez użycia Windowsa i stwierdziłem, że brakuje tam opisu natywnego linuksowego rozwiązania, czyli programu flashrom. Przy okazji wyszło też na jaw, że grzejnik korzysta z BIOSu w wersji 1.90, jak go fabryka wypuściła, a na stronie producenta dostępna jest wersja 2.80. Co prawda don’t fix it, if it ain’t broken, ale ponieważ flashrom chwali się wsparciem dla płyty ASRock K7S41 a u mnie jest ASRock K7S41GX, to pomyślałem, że spróbować trzeba, bo nazwa podobna, a GX kojarzy się z grafiką. 😉 Do sprawdzania wersji BIOS, płyty itd. korzystamy oczywiście z programu dmidecode.

Na początek rozczarowanie – wersja flashrom ze Squeeze nie wspiera tej płyty. Ale na stronie projektu flashrom podany jest namiar na kanał IRC, gdzie w razie problemów można uzyskać pomoc. Od razu zaznaczę, że kanał jest bardzo pomocny, ale techniczny. Czyli chłopaki (znaczy: developerzy) chcą dużo paste’ów z verbose mode. 😉 Opisałem problem, dostałem sugestię, by skorzystać z wersji SVN, co uczyniłem.

Jest nieco lepiej, ale nadal nie działa, bo nie rozpoznaje płyty, ale jakiś postęp jest. Dostaję pytania o wersję chipa z BIOSem (wymaga otwarcia puszki, zdarcia nalepki i odczytania napisów z chipa), prośbę o użycie programu superiotool, zaczynam pomału orientować się w temacie, z grubsza kojarzyć co tam się przy tym flashowaniu tak naprawdę odbywa, jak wyglądają płyty (taaak, chipy z BIOSem drastycznie się zmieniły odkąd ostatnio grzebałem w sprzęcie, choć i ten nie jest najnowszy)…

Okazuje się, że super I/O chip jest obsługiwany, chip BIOSu też… Dłuższe przejrzenie stron z opisem płyt K7S41 i K7S41X oraz źródełek flashrom ujawnia, że to bardzo podobne konstrukcje, z tym samym super I/O chipem i tym samym chipem BIOS. Okazuje się też, że udaje się odczytać aktualny BIOS do pliku:

flashrom -c W49F002U/N -m Asrock:K7S41 -VV -r test.dmp -f

Co prawda wymuszając wszystko na sztywno i z wymuszeniem operacji, ale działa. Co prawda niewiele to daje – chłopaki twierdzą, że musi wykrywać automatycznie, inaczej o flashowaniu można zapomnieć.

W przypływie dobrego humoru i odwagi, postanawiam wziąć sprawy w swoje ręce, skoro już tyle wiem o sprzęcie. Lekka zabawa z linią odpowiedzialną za dopasowanie (skopiuj linię dla K7S41, zmień na K7S41GX, skompiluj, spaczkuj checkinstall, przerzuć na docelową maszynę, zainstaluj, uruchom) i… wykrywa bez błędów.

Calibrating delay loop... OK.
No coreboot table found.
Found chipset "SiS 741", enabling flash write... OK.
This chipset supports the following protocols: Non-SPI.
Disabling flash write protection for board "ASRock K7S41GX"... OK.
Found chip "Winbond W49F002U/N" (256 KB, Parallel) at physical address 0xfffc0000.

Szybki test – odczyt działa, md5sum identyczna jak poprzednio. Weryfikacja zawartości BIOS z plikiem – passed. No to zaryzykujmy i wrzućmy to, co wyciągnęliśmy z chipa:

Flash image seems to be a legacy BIOS. Disabling checks.
Erasing and writing flash chip... Done.
Verifying flash... VERIFIED.

Wygląda, że działa. Na koniec wrzuciłem najnowszą wersję BIOSu. Ponownie bez problemu. Odczyt dmidecode – nadal widzi starą wersję, ale może restart jest wymagany? No to jazda z restartem… Chwila prawdy czyli reboot.

No i tu dobre wiadomości się kończą – po reboocie maszynka nie wstała i piszczy nietypowo. Chłopaki z IRCa mówią, że powinno być niekrytycznie, skoro weryfikacja się powiodła, być może wymagane wyłączenie zasilania lub reset CMOS. Niestety, żadne z nich nie pomogło. Trzeba skołować monitor i klawiaturę i zobaczyć, co też on tam wyświetla (rada: nie polecam zabawy z flashowaniem bez dostępu do monitora i klawiatury). Może jakiś błąd typu No keyboard. Press F1 to continue?

Zobaczymy niebawem. Dramatu nie ma, bo od biedy mam dostęp do identycznej płyty, więc przy odrobinie zabawy przełoży się kość BIOSu i przeflashuje się tam. Wkrótce dam znać, co ostatecznie wynikło (mam nadzieję, że uruchomię sprzęt, a flashrom zyska obsługę nowej płyty).

Tak czy inaczej, zabawa przednia (stąd kategoria Rozrywka), a flashowanie z użyciem flashrom bardzo przyjemne, proste i wygodne. Oczywiście jeśli sprzęt jest wspierany. 😉

UPDATE: Wiele się nie pomyliłem. Faktycznie trzeba było nacisnąć F1, tyle, że dwa razy. Raz, aby przywrócić wartości domyślne BIOSu (nie wiem, czy reset zworką nie zadziałał, czy po prostu trzeba), drugi, aby ominąć błąd związany z MAC. Ten drugi jest poważniejszy i objawia się komunikatem Mac address are invalid in both APC and DMI Press F1 to Resume i raczej zasługuje na oddzielny wpis. W każdym razie grzejnik znów grzeje (na razie na starym BIOSie).

Paczkomaty 24/7 czyli jak nie robić promocji.

InPost zrobił promocję swojej nowej usłudze, czyli Paczkomatom. Taką promocję pełną gębą, trendy i social. Z użyciem Facebooka, oczywiście. Aplikacja na FB, konkurs Paczkozagadka, do wygrania coś tam. Pełna integracja systemów. Zasadniczo, dnia 16 grudnia skusiły mnie trzy rzeczy: nad kartą FreeM (do zabawy) myślałem już wcześniej, miałem w perspektywie nieco czasu wolnego i sama idea usługi mi się spodobała, więc chciałem wypróbować w praktyce działanie.

Szybkie klik klik i założyłem konto w portalu. Co prawda już sam początek nie napawał optymizmem bo i null null w aplikacji, i wymagany Flash, ale OK… Chwilę później nadszedł mail z potwierdzeniem, a w nim:

Oczekuj sms-a oraz emaila z informacją o nadaniu Twojej przesyłki do wybranego przez Ciebie Paczkomatu. W przesyłce na pewno znajdziesz Twoją nagrodę gwarantowaną – zestaw startowy ogólnopolskiej sieci komórkowej FreeM z darmowym dostępem do Facebooka i komunikatorów internetowych na zawsze, bez doładowań i nawet z zerowym kontem oraz kupony rabatowe o łącznej wartości 1169 zł do wykorzystania w sklepach internetowych!

Możliwe, że oprócz karty FreeM oraz kuponów rabatowych, w Paczkomacie będzie czekała na Ciebie nagroda główna! Trzymamy kciuki! Znajdziesz ją wtedy w Paczkomacie razem z nagrodą gwarantowaną!

Wkrótce również otrzymasz wiadomość, gdy przesyłkę dostarczymy do wybranego przez Ciebie paczkomatu. W zależności od liczby zgłoszeń może potrwać to nawet kilka dni. Zapewniamy Cię jednak, że już w tej chwili siedzimy i zawijamy paczki jak te świstaki 24/7.

Czekałem cierpliwie. Tydzień. Potem drugi. W międzyczasie padła strona konkursu… Prawie dobiłem do miesiąca… W końcu nie zdzierżyłem i skomentowałem na FB wpis, gdzie proponowali wgapianie się w jakiś obrazek. O dziwo, pomogło. Znaczy się, na FB dbają o wizerunek, Blipa mają… Gdzieś pewnie mają, bo obserwowanie tagów swoich produktów i firmy jak widać InPost przerosło.

Sugestia kontaktu mailowego i… poszło! Co prawda twojej małą, na co zwróciłem uwagę i trochę głupio by tak było ściągać przesyłki metodą pull, ale dobrze, niech przyjdzie.

W sumie dostarczenie poszło bardzo szybko, bo już następnego dnia po porannym kontakcie mailowym i popołudniowej informacji o wysyłce, dostałem informację (tak, SMS i email…) o tym, że paczka jest gotowa do odbioru.

I teraz zaczyna się gigantyczny WTF. Odebrałem, ale w przesyłce była tylko książeczka rabatowa. Nie było zamówionego zestawu FreeM. Dostałem za to maila o następującej treści:

Witamy
Jeśli jest Pan zainteresowany otrzymaniem karty FreeM
to prosimy o podanie danych na które ma karta zostać wysłana.
Tzn : Imię Nazwisko, adres (ulica, nr domu/mieszkania, kod pocztowy,
miejscowość)

Pozdrawiamy
BOK FreeM

Zastanawiam się, czy ktoś na głowę upadł czy jak? Obiecaliście zestaw startowy, gwarantowany w konkursie? Obiecaliście. Obiecaliście, że dojdzie w tej paczce? Obiecaliście. To gdzie on jest? Nie tylko ja nie dostałem. A może InPost nie ufa swojej usłudze na tyle, by wysłać nią swój zestaw startowy, hę?

W każdym razie, jedyne do czego nie mam zastrzeżeń, to kontakt mailowy na info@… przy wyjaśnianiu całej sprawy. Ale chyba jakby nie na tym usługa ma polegać.

Dla jasności: nie chodzi o kiepską, z null null, wymagającą Flash aplikację. Nie chodzi o termin dostarczania przesyłek (czy też całkowite zniknięcie zamówienia w systemie, bo podejrzewam, że o to chodziło), nie chodzi o twojej, nie chodzi w końcu o samą kartę, którą – jak InPost pisze – mogę zamówić do domu, albo pewnie nawet którą by – po wysłaniu stosownego maila – dostarczono paczkomatem, a którą aktualnie i tak nie mam już czasu się bawić. Chodzi o całokształt promocji, która – jeśli o mnie chodzi – przyniosła skutek odwrotny do zamierzonego.

Dnsmasq – DHCP i DNS dla małych i średnich sieci i nie tylko.

DHCP od ISC, którego opis konfiguracji zamieszczono niedawno na jakilinux.org jest świetny, popularny, skalowalny, o bardzo szerokich możliwościach, ale… jest też stosunkowo skomplikowany, szczególnie dla kogoś, kto po prostu chce nadawać adresy w swojej sieci. Nie jest to jednak jedyna implementacja opensource’owego serwera DHCP. Do godnych uwagi rozwiązań należy dnsmasq, czyli prosty i lekki serwer DHCP oraz forwarder DNS (de facto – DNS cache’ujący). Na dodatek obsługujący IPv6 (tylko dla DNS). Klient TFTP gratis. Co prawda tylko read only, ale do bootowania po sieci z użyciem PXE wystarczy, poza tym, to celowy zabieg w założeniu zwiększający bezpieczeństwo.

Co prawda na stronie projektu wspomina się o działaniu dnsmasq nawet na 1000 hostach, ale osobiście odradzam – cache DNS nie jest specjalnie pojemny (limit w kodzie, poza tym, co można skonfigurować) i przy większej ilości zapytań demon nie wyrobi się z odpowiedziami DNS (źródło: doświadczenia własne, kilka lat temu…) i trzeba będzie przeprosić się z czymś standardowym (bind, djbdns itp.). Natomiast dla kilkudziesięciu czy nawet małych kilkuset hostów powinien działać bardzo dobrze, przy minimalnym nakładzie pracy, a dając sporo opcji i możliwości (cache DNS, przygotowanie do IPv6), kosztem minimalnego tylko zużycia zasobów.

Główna zaleta dnsmasq to moim zdaniem prostota konfiguracji. Cały konfig, z definicjami zakresu, z jakiego ma przydzielać IP w DHCP, interfejsami, na których ma słuchać i określeniem wielkości cache DNS to… trzy linie. Mimo prostoty, rozwiązanie jest dość elastyczne i pozwala na parę przydatnych w sieci lokalnej tricków.

Wszystkie opcje są bardzo dobrze, z przykładami, opisane w pliku konfiguracyjnym /etc/dnsmasq.conf (Debian), do którego lektury, podobnie jak do man dnsmasq oczywiście odsyłam, poniżej przegląd kilku niezbędnych, podstawowych opcji i dodatkowo kilka najciekawszych.

Nieśmiertelna instalacja:

apt-get install dnsmasq 

Interfejs (inny, niż loopback, na którym słucha domyślnie), na którym demon ma słuchać zapytań DHCP i DNS:

interface=eth0

Oczywiście można zdefiniować więcej niż jeden, wystarczy dodać kolejne, analogiczne linie.

Zakres przyznawanych IP z DHCP, maska, czas dzierżawy:

dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,1h

Ustawienie rozmiaru cache DNS:

cache-size=150

To ustawienie (domyślne) raczej dla małej sieci, ale dzięki temu użytkownicy będą mieli kilka-kilkadziesiąt ms mniej na każdym zapytaniu DNS. I tak naprawdę te trzy linie w konfigu to wszystko, co jest potrzebne, by po prostu działało przydzielanie IP z DHCP na wskazanym interfejsie oraz cache DNS, czyli to, czego będzie potrzebować 99% korzystających. W takiej – domyślnej – konfiguracji zapytania kierowane są do serwerów DNS określonych w /etc/resolv.conf (można to zmienić).

Pora na parę troszeczkę bardziej zaawansowanych, ale przydatnych opcji (czyli nadchodzi przepisywanie manuala ;-)). Wyłączenie nasłuchu DHCP na wskazanym interfejsie (DNS nadal działa):

 no-dhcp-interface=eth1 

Oczywiście wcześniej musiałaby istnieć linia interface=eth1, żeby zadziałało.

Popularne bindowanie, czyli przypisanie IP do MAC (dany MAC zawsze otrzyma dany adres IP):

dhcp-host=11:22:33:44:55:66,192.168.0.60

Wykluczenie hosta o danym MAC z DHCP (nigdy nie otrzyma dzierżawy):

dhcp-host=11:22:33:44:55:66,ignore

Inna przydatna funkcja to umożliwienie manipulowania odpowiedziami uzyskiwanymi z serwerów DNS. Przykładowo, jeśli chcemy, by wszystkie zapytania o daną domenę były resolvowane na adres lokalny:

address=/doubleclick.net/127.0.0.1

Oczywiście linii może być więcej, czyli de facto można zrobić mały, lokalny DNS blackholing. Odpowiadać można zarówno adresami IPv4, jak i IPv6. Powyżej rozwiązanie dla reklam, ale równie dobrze można tym sposobem popsuć trochę szyki malware’owi, albo dać znać użyszkodnikom, że admin czuwa i NK w trakcie pracy to niekoniecznie dobry pomysł…

W przypadku IPv4 można też „naprawiać” odpowiedzi otrzymywane z nadrzędnych serwerów DNS:

alias=1.2.3.4,5.6.7.8

Dzięki powyższemu odpowiedź 1.2.3.4 zostanie przetłumaczona na 5.6.7.8.

Działa także dla całych zakresów:

alias=1.2.3.0,5.6.7.0,255.255.255.0

Powyższe powoduje, że każdy adres 1.2.3.x jest mapowany do 5.6.7.x

Teraz bonus dla wytrwałych czytelników, czyli opcja zwiększająca bezpieczeństwo, której nie ma w przykładowym konfigu (jest w manie, daje się dodać do konfiga).

stop-dns-rebind 

Chodzi o blokadę (i logowanie) odpowiedzi z nadrzędnych DNSów, które są adresami prywatnymi (stosowane do ataków na sieci lokalne, np. do zmiany konfiguracji routerów). Warto jednak doczytać o pozostałych opcjach typu rebind w manualu, żeby np. nie zepsuć DNS blackholingu na upstreamowych DNS…

Podstawowe opcje związane z TFTP

enable-tftp

powoduje włączenie TFTP. Można podać interfejs, na którym ma słuchać TFTP

enable-tftp=eth0

Można też ustawić różne katalogi TFTP obsługiwane na różnych interfejsach. W tym celu należy użyć

tftp-root=/katalog,eth0
tftp-root=/katalog2,eth1

Ostatnia przydatna opcja to

log-queries

które spowoduje logowanie zapytań DNS do pliku. Przydatne np. przy debugu, statystyce odpytywanych domen i przy permanentnej inwigilacji.

I tak naprawdę to koniec popularniejszych opcji (choć opcji jest dużo więcej). Moim zdaniem tyle wystarczy, by zachęcić do przyjrzenia się temu rozwiązaniu na mniejszych sprzętach i/lub sieciach. W wielu przypadkach nie ma sensu stosowania „dużych” rozwiązań typu dhcpd od ISC czy „pełny” serwer cache’ujący DNS.

Z innych, bardziej systemowych zastosowań dnsmasq – może być przydatny dla środowisk chroot z nieskonfigurowanym /etc/resolv.conf. Jeśli w /etc/resolv.conf nie ma żadnego działającego nameserwera, to odpytywany jest loopback. Dnsmasq domyślnie słucha na loopbacku, więc zapewni działające DNSy systemom w chrootach. Źródło: Simple DNS in chroots.

Jeszcze inną – ciekawą z punktu widzenia sysadminów – właściwością dnsmasq jest fakt, że domyślnie zapytania DNS kierowane są jednocześnie do wszystkich serwerów DNS. Bez żadnego, najmniejszego opóźnienia (czego AFAIK nie da się uzyskać przy korzystaniu wyłącznie z /etc/resolv.conf). Dla tych zastosowań, dla których działanie DNS jest krytyczne i nawet 1 sekunda w odpytaniach jest niedopuszczalna, dnsmasq być sposobem na zrównoleglenie odpytań serwerów DNS.

Na koniec odpowiedź na pytanie, jak sprawdzić, czy dnsmasq w ogóle działa. Należy wydać polecenie kill -USR1 `pidof dnsmasq`, następnie można sprawdzić w syslogu, co się pojawiło – grep dnsmasq /var/log/syslog. Powinny tam się znaleźć linie w stylu (nie ma hitów, bo niski uptime):

wielkość pamięci podręcznej: 2000; 0 z 212 miejsc aktualnych wpisów użyto ponownie.
171 zapytań przesłanych dalej, 467 odpowiedzi udzielonych samodzielnie

UPDATE: Dodane info i przykłady dla TFTP.

UPDATE: Dodany przykład jak uzyskać statystyki wykorzystania pamięci cache.

Licencja wpisu: CC BY-NC-SA (wyjątkowo, specjalnie dla jakilinux.org z okazji dyskusji nt. wpisu o DHCP od ISC). W związku ze zmianą licencji globalnie, w dodatku na bardziej liberalną, zapis ten nie ma już sensu.

6 stycznia wolny – zysk czy strata dla pracowników?

Od pierwszego stycznia zmieniają się prawo pracy, a konkretnie zasady udzielania dni wolnych. Do tej pory, jeśli dzień wolny od pracy przypadał w sobotę, to pracownikowi przysługiwał w zamian za niego dzień wolny. Od 1 stycznia 2011 nie ma tego, za to do świąt dołącza 6 stycznia jako Objawienie Pańskie.
Zasadnicze pytanie: czy pracownicy na tym zyskują, czy tracą? Odpowiedź na to pytanie wbrew pozorom nie jest oczywista.
  • 1 stycznia
  • 1 maja
  • 3 maja
  • 15 sierpnia
  • 1 listopada
  • 11 listopada
  • 25 grudnia
  • 26 grudnia

(pomijam 4 święta ruchome, które w Polsce nigdy nie wypadają w sobotę), a do tego dochodzi od tego roku 6 stycznia.

Nie wdając się w matematykę (jakoś nie mam głowy do matematyki kalendarzowej, a nic sensownego mi nie wyszło przez chwilę namysłu), korzystam z metody najdoskonalszej, czyli pełnego przeglądu (AKA brute force) wg algorytmu: jeśli któreś z dotychczasowych świąt wypadnie w sobotę, to pracownicy tracą dzień, jeśli 6 stycznia nie wypadnie w sobotę ani w niedzielę, to pracownicy zyskują dzień.  I sumowanie strat i zysków…

Całość to nieładny bash (funkcja date) napędzana perlem, pisany na szybko.

Wynik? Miłe złego początki – przez najbliższe 10 lat stracimy, jako pracownicy, średnio rocznie 0,1 dnia wolnego, a w pierwszych 3 latach nawet będzie niewielki zysk, ale dla 25 lat – o ile przepisy się nie zmienią – stracimy łącznie 8 dni wolnych, czyli 0,32 dnia wolnego rocznie. Szczerze mówiąc, nie jest tak źle jak myślałem…

Ale zmiana jest ewidentnie niekorzystna dla pracowników. Gdyby miała miejsce w 1990 roku, to do tego roku tracilibyśmy średnio ponad pół dnia wolnego rocznie.

I skrypt do obliczeń:

Flattr – nowe funkcje.

Powoli zbliża się moment, kiedy chcę zacząć ponownie korzystać z Flattr po tym, jak stwierdziłem, że nie jest gotowy do korzystania z niego. W międzyczasie pojawiły się nowe funkcje:

  • wypłata do Moneybookers – dla tych, którzy nie lubią PayPala. BTW ciekawe na ile jest to związane z przyłączeniem się PayPala do blokady Wikileaks
  • subskrybcja, czyli automatyczne flattrowanie w kolejnych miesiącach (IMO bardzo fajna opcja dla projektów Open Source),
  • opcja donate w profilu użytkownika, czyli natychmiastowe przekazanie kwoty 2-50 euro (z dostępnych, nie przeznaczonych na dany miesiąc środków),
  • Flattr w wersji offline – no, może niezupełnie offline, bo tak naprawdę chodzi po prostu o QRcode, a połączenie będzie potrzebne, ale już np. na plakacie reklamującym imprezę czy koncert może się znaleźć taki „przycisk” znaleźć…

Tak więc zmniejsza się ilość rzeczy, na które narzekał KosciaK w swoim wpisie nt. Flattr i komentarzach do niego. Konkretnie: są podane organizacje charytatywne, jest opcja donate dla większych kwot (niestety z widełkami i prowizją, ale IMO dobra alternatywa dla PayPala).

Pozostało mi czekać, aż coś wpłynie na mojego PayPala, żeby móc znów uruchomić Flattr…

Jak nie szukać pomocy (na IRC).

Co prawda dotyczy IRC, ale przypuszczam, że dla różnego rodzaju forów będzie prawdziwe. Oto krótki przepis, jak nie szukać pomocy w Internecie (zwł. IRCu):

  1. Wejdź na kanał poświęcony jakiejś dystrybucji.
  2. Pochwal się, że własnoręcznie zrobiony kernel nie działa.
  3. Zapytaj dlaczego?
  4. Oświadcz, że UUID są do niczego.
  5. Zapytaj czego nie wkompilowałem?
  6. Oświadcz, że na kernelu dystrybucyjnym działa, ale jest on do niczego, bo coś innego nie działa, a poza tym własny kernel jest boski i überzoptymalizowany.
  7. Nie podawaj żadnych szczegółów nt. niedziałania czegoś innego, w szczególności – mimo próśb – nie podawaj opcji w swoim kernelu, które sprawiają, że działa.
  8. Zaproponuj twierdzącym, że jednak coś innego powinno działać, żeby sami uruchomili coś innego, totalnie im niepotrzebnego.
  9. Oświadcz pomagającym, że nie umieją (chociaż im działa, także na własnym kernelu) i nie jesteś jasnowidzem, żeby wiedzieć, czemu Twój kernel nie działa, bo nie wiesz co się pozmieniało między wersjami dystrybucji.
  10. Wklej linka do bug reporta, gdzie jest fragment z logów, gdzie jak wół stoi, którą opcję trzeba zmienić przy kompilacji.
  11. Oświadcz, że nie czytasz release notes.
  12. Powiedz pomagającym, że są irytujący, zapytaj ich, czy wydaje im się, że są Linux guru i wiedzą, co jest dobre a co złe.
  13. Zaproponuj opisanie sytuacji na blogu.
  14. Nie dziękuj i wyjdź.

W razie wątpliwości: marudź, nie odpowiadaj na pytania lub rób to wymijająco, nazywaj rozwiązania stosowane w dystrybucji głupimi. Przecież wiesz lepiej. Jak najczęściej pytaj dlaczego nie działa?, konkrety podawaj tylko w ostateczności.

MSPANC