My new phone cover

Jesień zawitała do nas na dobre, a wraz z nią chłodne wieczory. W ostatnich miesiącach zaniedbałem nieco prowadzenie mego bloga, więc postaram się przeznaczyć wieczorny czas wolny na napisanie tutaj kilku (w miarę możliwości zwięzłych) notatek o tym co ostatnio chodzi mi po głowie. Zacznę może od tego co wychodzi mi najlepiej... narzekania. Rozpoczął się nowy semestr akademicki, a wraz z nim przyszła fala zgłoszeń, telefonów i maili o niedziałającej sieci i usługach. O stosie podań o założenie konta na serwerze studenckim, która zalała moje biurko już nie wspomnę. Taka praca administratora sieci - raz się jest szeryfem walczącym o prawo i porządek na serwerach, a raz biurokratą przekładającym kartki z stosu na stos. By całkiem nie oszaleć od siedzenia przed komputerem powróciłem do robienia czegoś manualnie. Kiedyś robiłem całą masę origami, a teraz częściej szkicuję lub próbuję pracy z nowymi dla mnie materiałami. No i tu jest mała zagadka. Cóż takiego mogłem zrobić z rzeczy które znajdują się na poniższym zdjęciu?

Jak nietrudno się domyślić po tytule notatki wyszedł z tego pokrowiec na mojego smartfona. Poprzedni pokrowiec, który kupiłem w saturnie rozpadał mi się już na czynniki pierwsze od ciągłego wyciągania i wsadzania telefonu. A ponieważ, zaczynam się przeistaczać w "androidowego fanboya" nie mogłem odpuścić sobie okazji wykonania unikatowego pokrowca jednoznacznie wskazującego na czym śmiga mój telefon. Jak na moją pierwszą zabawię z filcem to uważam, że wyszła z tego rzecz, która jest zarówno piękna jak i pożyteczna.

Selective syslog-ng remote logging with Tomato

Załóżmy, że posiadamy własną sieć (np. 192.168.0.0/24) w której działają między innymi bezprzewodowe rutery oparte o Tomato pełniące funkcję punktów dostępowych z których chcielibyśmy zbierać logi centralnie na jednej maszynie za pomocą syslog-ng. Maszyna na której zbierane będą logi posiada adres IP 192.168.0.50, a rutery adresy odpowiednio 192.168.0.1-15. Oto krótki przepis jak to zrobić.

Konfiguracja routerów

W pierwszej kolejności należy przekierować sysloga routera na zewnętrzny adres. Wybieramy Administration ▶ Logging i zaznaczamy opcję Log To Remote System oraz w polach IP Address / Port wpisujemy adres 192.168.0.50 oraz port 514.

Wpisy w syslog-ng.conf

Samo przekierowanie logów to tylko połowa pracy. Na serwerze dodajemy wpis zbierający zdalne logi:

source tomatoAP {
    internal();
    udp(ip("0.0.0.0")
    port(514));
};

Dodajemy zestaw filtrów do kierowania zapisem logów z każdego rutera. Dla pierwszych dwóch wpisów IP musimy dodać $ po adresie IP, aby ograniczyć filtr tylko do jednego hosta. Jeśli tego nie zrobimy w szablon wpasowane będą także np. takie adresy jak 192.168.0.193, czy 192.168.0.27.

filter f_tom01 { host("192.168.0.1$"); }; 
filter f_tom02 { host("192.168.0.2$"); };
filter f_tom03 { host("192.168.0.3"); };
filter f_tom04 { host("192.168.0.4"); };
filter f_tom05 { host("192.168.0.5"); };

Dodajemy wpisy gdzie mają być zapisywane logi z poszczególnych routerów...

destination d_tom01 { file("/var/log/tomato/ap-01.log"); };
destination d_tom02 { file("/var/log/tomato/ap-02.log"); };
destination d_tom03 { file("/var/log/tomato/ap-03.log"); };
destination d_tom04 { file("/var/log/tomato/ap-04.log"); };
destination d_tom05 { file("/var/log/tomato/ap-05.log"); };

..., a następnie zbieramy wszystko w całość w spójne regułki dla każdego rutera.

log { source(tomatoAP); filter(f_tom01); destination(d_tom01); };
log { source(tomatoAP); filter(f_tom02); destination(d_tom02); };
log { source(tomatoAP); filter(f_tom03); destination(d_tom03); };
log { source(tomatoAP); filter(f_tom04); destination(d_tom04); };
log { source(tomatoAP); filter(f_tom05); destination(d_tom05); };

Na koniec restartujemy syslog-ng i zaparzamy zasłużoną kawę ]:) Finito.

3-city biking

Wraz z dziewczyną postanowiliśmy kupić sobie rowery na lato. Sylwia kupiła sobie rower miejski, a ja górski rekreacyjny. Częściowo nasza decyzja wynikała z chęci aktywnego spędzenia lata, a częściowo z stanu dróg w Gdańsku. Dla niewtajemniczonych powiem, że remontowana jest teraz linia tramwajowa wzdłuż alei Grunwaldzkiej. Szybciej człowiek dojedzie rowerem niż komunikacją miejską (pomijając możliwość wdychania świeżego powietrza, a nie zapachu czyiś spoconych pach w autobusie). Jednej rzeczy jednak nie potrafię zrozumieć. Rower mam już od ok. 2 tygodni, a już dwa razy musiałem łatać dętkę. W porównaniu z góralem, którego zostawiłem na opolskim gruncie to bardzo mnie to dziwi. Tamten rower wytrzymał 8 lat jazdy po polskich drogach, lesie i wyrobisku skały wapiennej, a chyba tylko raz musiałem łatać dętkę. Mój obecny góral ma nieco cieńszą oponę oraz mniejsze bieżniki, ale za to jeżdżę nim po drogach rowerowych w Gdańsku, które są w naprawdę dobrym stanie. Dziś nie wytrzymałem i pojechałem kupić sobie dętkę samouszczelniającą się. W każdym razie mimo problemów technicznych złapała mnie "zajawka" na kolarstwo. W miarę możliwości oglądam też relacje na żywo z Tour de France 2011. Jak już jesteśmy przy temacie TdF to jako geek oczywiście zainstalowałem sobie oficjalną aplikację Tour de France 2011 na androida. Przydatna sprawa dla każdego fana tego wyścigu, ale aplikacja dała mi nieco do myślenia. Skoro mój telefon HTC ma wbudowany odbiornik GPS to może jest jakaś aplikacja na Androida, która by nadawała się do zbierania statystyk jazdy rowerem. Jak się okazało nie musiałem długo szukać i znalazłem całkiem ciekawą aplikację stworzoną przez Google - My Tracks. Aplikacja pozwala na rejestrowanie przejechanej trasy, oblicza czas spędzony w jeździe (dobra opcja przy poruszaniu się po mieście metodą stop-and-go), oraz liczy statystyki takie jak średni czas jazdy, minimalna/maksymalna prędkość itp. Oto kilka zrzutów z jak to wygląda na telefonie: Ciekawą opcją jest możliwość eksportu do Google Maps. No dobrze. Dosyć blogowania na dziś. Trzeba się, wyspać by jutro w pełni sił pojechać do pracy rowerem ]:D

udev rules for my tv card

Od wczoraj pod chochlika mam podpiętą kamerkę internetową. Jak się dziś okazało, znalezienie dla niej działających sterowników na Linuksa to najmniejszy problem. Ponieważ mam też kartę telewizyjną (Pinnacle PCTV) dla obu urządzeń tworzone są pliki urządzeń o nazwach /dev/video0 oraz /dev/video1. Wszystko ładnie, tylko że po restarcie systemu raz video0 to karta tv, a raz kamerka internetowa. Całe szczęście można to bardzo prosto rozwiązać pisząc własne reguły udev, co też zrobiłem. Najpierw przyda się zdobycie trochę informacji za pomocą narzędzia udevadm:

$ udevadm info -a -p $(udevadm info -q path -n /dev/video1)

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1e.0/0000:04:01.0/video4linux/video1':
    KERNEL=="video1"
    SUBSYSTEM=="video4linux"
    DRIVER==""
    ATTR{name}=="saa7133[0] video (Pinnacle PCTV"
    ATTR{index}=="0"

  looking at parent device '/devices/pci0000:00/0000:00:1e.0/0000:04:01.0':
    KERNELS=="0000:04:01.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="saa7134"
    ATTRS{vendor}=="0x1131"
    ATTRS{device}=="0x7133"
    ATTRS{subsystem_vendor}=="0x11bd"
    ATTRS{subsystem_device}=="0x002e"
    ATTRS{class}=="0x048000"
    ATTRS{irq}=="19"
    ATTRS{local_cpus}=="ff"
    ATTRS{local_cpulist}=="0-7"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""

  looking at parent device '/devices/pci0000:00/0000:00:1e.0':
    KERNELS=="0000:00:1e.0"
    SUBSYSTEMS=="pci"
    DRIVERS==""
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x244e"
    ATTRS{subsystem_vendor}=="0x1458"
    ATTRS{subsystem_device}=="0x5000"
    ATTRS{class}=="0x060401"
    ATTRS{irq}=="0"
    ATTRS{local_cpus}=="ff"
    ATTRS{local_cpulist}=="0-7"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS=="

Ponieważ mam tylko jedno urządzenie firmy Pinnacle, więc reguła oparta jest o dość prosty atrybut, a mianowicie nazwę widoczną dla systemu. Do pliku /etc/udev/rules.d/10-local.rules dodałem następującą linię: KERNEL=="video*", ATTR{name}=="*Pinnacle PCTV", NAME="%k", SYMLINK="video_tvcard" Po restarcie maszyny w katalogu /dev utworzyło się dowiązanie symboliczne video_tvcard wskazujące na kartę tv. Teraz wystarczyła drobna zmiana konfiguracji programów takich jak tvtime, by odwoływały się do /dev/video_tvcard za każdym razem gdy chcę sobie pooglądać TV. Tych którzy chcą pisać własne reguły odsyłam do artykułu na Arch wiki, który okazał się być bardzo przydatny oraz manuala udevadm.

Autum Lady

Niedzielne popołudnie. Za oknem piękna pogoda, a we mnie znów się budzi ochota wysmarowania arkuszy papieru pastelowym pigmentem... Zobaczymy co z tego wyjdzie. Z braku laku (czasu zresztą też) prezentuję trochę starszą pracę.