VPN L2TP/IPSEC między PLD Linuksem i Androidem

Jeszcze się tu nie chwaliłem, ale kupiłem sobie mojego pierwszego smartfonika (Samsung Galaxy S Plus). Oczywiście odkąd go mam (nieco ponad dwa tygodnie) bawię się wszelkimi możliwymi jego funkcjami… W głębi menu „ustawienia” znalazłem „sieci VPN”. W sumie dobrze by było mieć w komórce dostępne bezpieczne połączenie do domowej sieci lokalnej…

Telefonik fabrycznie obsługuje cztery opcje: „PPTP”, „L2TP”, „L2TP/IPSec PSK” i „L2TP/IPSec CRT”. PPTP jakoś źle mi się kojarzy (nie wiem czemu i nie wnikam), zerknąłem na opis L2TP w Wikipedii i uznałem, że L2TP/IPSec to będzie sensowny wybór, szczególnie że IPSec pewnie niedługo będę przerabiał w robocie. Od razu postanowiłem też użyć uwierzytelniania za pomocą certyfikatu.

Od początku zdawałem sobie sprawę, że zapewne dużo prościej byłoby znaleźć OpenVPN na Androida i tym tunel zestawić… ale to nie byłoby żadne wyzwanie ;-). Nie sądziłem jednak, że uruchomienie L2TP/IPSec będzie aż takim problemem…

Zacząłem tradycyjnie, jak to się w PLD robi: „poldek:/all-avail> ls *l2tp*„. Nic. „search -a *L2TP*” pokazało nie wiele więcej, nic czego bym szukał. Kolej na Google… tu parę różnych tekstów… Że w PLD obecnie do IPSec mamy tylko ipsec-tool i ten pakiet mam opanowany, to pominąłem wszystkie HOWTO dotyczące OpenSWAN/FreeSWAN itp… Zresztą, nie tylko mnogość implementacji IPSec była problemem. Samego L2TP też było wymienionych kilka implementacji i chyba żadna aktywnie nie rozwijana…

Znalazłem jakiś obiecujący opis użycia l2tpd… było tam wspomniane, że ten demon już nierozwijany, ale jest jakaś kontynuacja – xl2tpd. O, nawet w PLD spec był… okazało się, że niedokończony… a właściwie nawet dobrze nie zaczęty. Dokończyłem, zbudowałem, zainstalowałem…

IPSec w ogóle nie skonfigurowałem, chciałem tylko to xl2tpd wypróbować, a nawet nie do końca wiedziałem czy IPSec działa pod, czy nad L2TP (potem doczytałem – transmisja L2TP odbywa się wewnątrz IPSec, a więc IPSec należałoby skonfigurować najpierw). Telefon się nawet łączył, xl2tpd coś w logach pisał, ale wyglądało to, jakby telefon próbował otworzyć jeden tunel za drugim, żadnego nie zestawiając do końca. Późno już było, dałem sobie z tym spokój.

Wczoraj pogooglałem dalej i trafiłem na openl2tp. Projekt prawie żywy, ostatnie wydanie sprzed roku. Zrobiłem pakiet dla PLD. Żeby kod się skompilował wystarczyło „-Werror” z Makefile wywalić. Demon się uruchamiał, l2tpconfig działał.

Tym razem postanowiłem najpierw uruchomić IPSec. Racoonem już się kiedyś bawiłem, ale wciąż jego konfiguracja nie jest dla mnie całkiem jasna. Posiłkowałem się gotowcem z Quick Start Guide openl2tp, uzupełniłem tylko konfigurację, żeby uwierzytelnianie było zrobione certyfikatami (co wymagało wielu prób i błędów). Niby już było wszystko ok, ale:

racoon: ERROR: no policy found: 192.168.1.10/32[0] 192.168.0.1/32[1701] proto=udp dir=in
racoon: ERROR: failed to get proposal for responder.

…okazało się, że to błąd w rzeczonym Quick Start. Kolejność parametrów w skrypcie setkey była zła. Powinno być:

#!/usr/sbin/setkey -f
flush; 
spdflush;

spdadd 0.0.0.0/0 192.168.0.1 [1701] udp -P in ipsec esp/transport//require;

(192.168.0.1 to będzie adres serwera VPN, 192.168.1.10 – klienta) Policy ‚out’ na serwerze nie potrzebne, bo odpowiednie wpisy openl2tpd powinien dodać sam, dla konkretnych połączeć.

Po poprawieniu tego, Racoon uraczył mnie kolejnym błędem:

racoon: ERROR: long lifetime proposed: my:3600 peer:28800
racoon: ERROR: not matched
racoon: ERROR: no suitable policy found

Do było proste, trzeba było znaleźć „lifetime” w racoon.conf i poprawić na wartość oczekiwaną przez Androida.

Jak już poprawnie przychodziły requesty z telefonu po IPSec, przyszedł czas skonfigurować openl2tpd

. Jednak ten już przy starcie wołał:

openl2tpd[12257]: IPSec support disabled. No setkey found.

…i nie bardzo dalej działał. Nie podobało mi się to, ale od razu domyśliłem się o co chodzi – openl2tpd miał zaszytą złą ścieżkę do setkey. Szybko odnalazłem odpowiedni fragment kodu, w plugins/ipsec.c:

#define IPSEC_SETKEY_CMD        "/sbin/setkey"
#define IPSEC_SETKEY_FILE       "/tmp/openl2tpd-tmp"
#define IPSEC_SETKEY_ACTION     IPSEC_SETKEY_CMD " -f " IPSEC_SETKEY_FILE

Poprawka była oczywista (w PLD setkey leży w /usr/sbin), ale nie spodobało mi się coś innego… Moje obawy potwierdziły się niżej w kodzie:

FILE *f = fopen(IPSEC_SETKEY_FILE, "w");

…ciekawe co by było jakby jakiś user zrobił np. „ln -s /bin/sh /tmp/openl2tpd-tmp”…

Załatałem to (przenosząc plik tymczasowy do /var/run/openl2tp) razem z poprawkę ścieżki do setkey, ale trochę zaufania do tego kodu już utraciłem…

Połatany openl2tp już poprawnie ustawiał policy dla wysyłanych pakietów, ale znowu Racoon zaczął marudzić:

racoon: ERROR: phase1 negotiation failed due to send error. b842e7fcf5598054:0000000000000000
racoon: ERROR: failed to begin ipsec sa negotication.

To już była bardziej tajemnicza sprawa. Nawet bardziej szczegółowe logi nie mówiły nic konkretnego. Dopiero w źródłach udało mi się znaleźć co może powodować ten błąd, bez żadnego innego sensownego komunikatu. Dzieje się tak, gdy Racoon nie może znaleźć socketu z którego ma wysłać pakiet. Testowałem połączenie z sieci lokalnej, ale łączyłem się na zewnętrzny adres mojego routera i tylko do tego zewnętrznego adresu kazałem się Racoonowi przyczepić. A openl2tpd na żądania z sieci lokalnej odpowiadał z adresu lokalnego. Racoon próbował zestawić sesję IPSec z tego samego adresu i mu się nie udawało. Problem udało się rozwiązać wywalając całą sekcję „listen” z racoon.conf (sam niepotrzebnie tam adresy pododawałem – nadgorliwość się mści) oraz ustawiając ‚src_ipaddr’ w profilu tuneli openl2tpd. Dla pewności, że to samo nie będzie mi dalej zawadzać, dalsze próby robiłem z pominięciem lokalnego WiFi.

Problem Racoona rozwiązałem, ale openl2tpd dalej się nie łączył. Podobnie, jak w przypadku xl2tpd było widać wiele prób zestawienia tunelu, ale żadna nie kończyła się sukcesem. Żeby przyjrzeć się ruchowi tcpdumpem wyłączyłem IPSec i próbowałem kontynuować „gołym L2TP”.

Wymiana pakietów wyglądała mniej-więcej tak:

KLIENT -> SERWER:   UDP port xxxx -> port 1701
SERWER -> KLIENT:   UDP port yyyy -> port xxxx
KLIENT -> SERVER:  ICMP port xxxx unreachable

Winnym okazał się feature openl2tpd – demon domyślnie wykorzystuje „efemeryczne” porty UDP dla każdego połączenia. Żądanie przychodzi na port 1701, ale odpowiedź serwera już wychodzi z nowego, losowego portu. Najwyraźniej Android tego się nie spodziewa i odpowiada błędem „port unreachable”, jakby to po jego stronie czegoś brakowałem. Na szczęście można ten feature wyłączyć przez l2tpconfig:

tunnel profile modify profile_name=default our_udp_port=1701

Potem było już z górki… jeszcze jeden błąd z openl2tpd:

openl2tpd[9952]: PROTO: tunl 23305: STOPCCN error 5/0: The protocol version of the requester is not supported - no challenge response AVP received

Już nie pamiętam czym dokładnie to rozwiązałem, ale jakąś zmianą w konfiguracji openl2tpd. Potem pomarudził jeszcze pppd:

The remote system is required to authenticate itself
but I couldn't find any suitable secret (password) for it to use to do so.
(None of the available passwords would let it use an IP address.)

Tu wystarczyło poprawić /etc/ppp/pap-secret. Gdy już się telefon z serwerem połączył jeszcze takie w logach w kółko leciały:

pppd[14786]: sent [CCP ConfReq id=0x1 ]
pppd[14786]: rcvd [CCP ConfReq id=0x2]
pppd[14786]: sent [CCP ConfAck id=0x2]
pppd[14786]: rcvd [CCP ConfRej id=0x1 ]
pppd[14786]: Received bad configure-rej:  12 06 00 00 00 00

…najwyraźniej kolejne głupie rozszerzenie PPP do Microsoftu, nie wiedzieć czemu domyślnie włączone. Pomogło „nomppe” w /etc/ppp/options

Jeszcze tylko wyregulowanie firewalla i tunel wydaje się działać jak należy. Przynajmniej ze strony telefonu, w drugą nawet ping za bardzo nie chodzi, bo Android odpowiada z innego IP niż ten pingowany przez tunel. Ale z tym już raczej nic nie zrobię.

Ostatecznie moja konfiguracja wygląda mniej-więcej tak:

/etc/racoon/racoon.conf:

path include "/etc/racoon";
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/cert";
padding
{
        maximum_length 20;
        randomize off;
        strict_check off;
        exclusive_tail off;
}

timer
{
        counter 5;
        interval 20 sec;
        persend 1;
        phase1 30 sec;
        phase2 15 sec;
}

remote "l2tpclient"
{
        exchange_mode main;
        doi ipsec_doi;
        situation identity_only;

        ca_type x509 "cacert.pem";

        my_identifier asn1dn;
        certificate_type x509 "cert.pem" "key.pem";

        verify_identifier on;
        verify_cert on;
        peers_identifier asn1dn "CN=*, emailAddress=jajcus@example.com";
        peers_identifier user_fqdn "jajcus@example.com";
        peers_identifier asn1dn "CN=*, emailAddress=jajcus@example.org";
        peers_identifier user_fqdn "jajcus@example.org";

        nonce_size 16;
        initial_contact on;
        proposal_check strict;

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2;
        }
}

sainfo anonymous
{
        lifetime time 12 hour;
        encryption_algorithm aes 256, rijndael 256, blowfish 448, 3des;
        authentication_algorithm hmac_sha256, hmac_sha1, hmac_md5;
        compression_algorithm deflate;
}

/etc/racoon/setkey.conf:

#!/usr/sbin/setkey -f
flush;
spdflush;

spdadd 0.0.0.0/0 192.168.0.1 [1701] udp -P in ipsec esp/transport//require;

/etc/openl2tpd.conf:

# system

# peer profiles
peer profile modify profile_name=default \
        lac_lns=lns \

# tunnel profiles
tunnel profile modify profile_name=default \
        auth_mode=none \
        host_name=tropek \
        src_ipaddr=192.168.0.1 \
        our_udp_port=1701 \

# ppp profiles
ppp profile modify profile_name=default \
        auth_mschapv1=no \
        auth_mschapv2=no \
        auth_eap=no \
        local_ipaddr=10.0.0.1 \
        ip_pool_name=l2tp \

# locally created tunnels and sessions

/etc/ipoold.conf:

# ip pools
pool create pool_name=l2tp \

pool address add pool_name=l2tp first_addr=10.0.0.100 num_addrs=100 \
        netmask=255.255.255.0

/etc/ppp/options:

ms-dns 192.168.0.1
ms-dns 192.168.0.2
asyncmap 0
auth
crtscts
lock
modem
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4
noipx
nomppe

/etc/ppp/pap-secrets:

username hostname "passsword"        *

I jeszcze w firewallu regułka dla pewności sprawdzająca użycie IPSec (domyślna regułka u mnie to DROP dla wszystkiego):

iptables -A INPUT -p udp --dport 1701 -m policy --pol ipsec --dir in -j ACCEPT

Tak więc, działać już mi ten VPN działa i pozostaje mieć nadzieję, że jest bezpieczny. A wszystko to tu opisałem, żeby następnym razem wujek Google umiał pomóc, gdy ktoś tak jak ja będzie się męczył…

Update: Proste testy sugerują, że ze strony telefonu to ten VPN niespecjalnie bezpieczny jest. To się pobawiłem, ale na razie używać tego chyba nie będę na poważnie.

Update 2:: Tak, tak zestawiony tunel nie jest specjalnie bezpieczny, ale można sobie z tym poradzić (o ile telefon jest zrootowany).

Reklamy

Dofus pod PLD Linux

…czyli walki z Adobe AIR.

Przeglądając The Linux Game Tome natrafiłem na opis gry Dofus. MMORPG, z ładną grafiką, ale bez zbytnich wymagań do sprzętu (grafika 2D) – wyglądało zachęcająco, postanowiłem więc spróbować.

Ściągnąłem instalator, uruchomiłem… i nic, okazuje się że RPMowych dystrybucji nie obsługuje. Jak to tak?! Odpaliłem z opcją ‚–keep’, żeby zobaczyć co jest w środku i ewentualnie zainstalować ręcznie. W środku trochę plików, skrypt instalacyjny, deinstalacyjny i jakaś binarka „UpLauncher”. Spróbowałem odpalić binarkę, brakowało starej wersji libjpeg. W PLDowych CVS na szczęście jest spec, to dobudowałem, doinstalowałem i coś ruszyło. Ruszyło, „uaktualniło grę”, ale odpalić już się nie dało. Okazało się, że czegoś brakuje…

Znalazłem logi (po francusku) i rzeczywiście jakby jakiś plików brakuje. Zajrzałem do skryptu instalacyjnego (komentarze częściowo po francusku) i zrozumiałem, że to miało sobie jeszcze Adobe AIR zainstalować, potem tym Adobe AIR zainstalować grę z plików *.air, a dopiero to ostatecznie jest uruchamiane…

Udałem się więc do Adobe po to całe AIR. Do wyboru paczki ‚deb’, ‚yum’, ‚rpm’ i ‚bin’. Wybrałem ostatnie, nie licząc na kompatybilność tego RPMa z PLD. Okazało się jednak, że to ‚bin’ to niby samo-rozpakowujące-się-archiwum, ale potem i tak próbuje budować i instalować RPM. Budować w PLD tym bardziej nie umie, więc nic z tego nie wyszło. Wziąłem więc paczkę rpm (albo jednak z tego ‚bin’ coś wykopałem, nie pamiętam)… coś się zainstalowało.

Zainstalowanym „Adobe AIR Application Installer” próbowałem zainstalować „Dofus.air” i „Reg.air” jak to miał robić skrypt instalacyjny Dofusa. Nie udało się. Okazało się, że ten cały „application installer” też próbuje jakieś RPMy budować, co mu nie wychodzi. Czemu nie można jak np. z javowymi aplikacjami „java -jar cośtam.jar”? Ja rozumiem, że developerzy postawili sobie za cel zrobić tak, że user dwa razy kliknie w paczkę i mu się zainstaluje jak każda inna aplikacje, ale żeby to osiągnąć strasznie przekombinowali jednocześnie zapewniając sobie kompatybilność tylko z kilkoma konkretnymi dystrybucjami, właściwie uniemożliwiając użycie tego w innych…

W końcu, jakoś strasznie hackując udało mi się to jednak opanować i grę zainstalować tak, że zadziałała. Właściwie zadziałało wszystko poza dźwiękami i urwanymi tekstami NPC już w samej grze (ten drugi problem najwyraźniej doskwiera też innym linuksowym użytkownikom Dofusa). Skoro zadziałało, to sobie trochę pograłem. I spodobało mi się. Prawie że noce nad tym zarywam, jak kiedyś nad Crossfire ;-)

Wciąż jednak nie dawało mi spokoju pytanie: „czy na prawdę nie dałoby się prościej”. I dzisiaj wygooglałem coś takiego: Adobe® AIR on Gentoo Linux. Artykuł ten mówi jak można uruchamiać aplikacje AIR używają ichniejszego SDK. Bez żadnych śmiesznych „instalatorów” próbujących budować paczki. Sprawdziłem, rzeczywiście działa. Przygotowałem też „uproszczoną procedurę” instalacji Dofusa pod prawie każdym Linuksem (poniżej). Co więcej, tym razem udało mi się uzyskać także dźwięk! :-)

Instalacja Dofusa pod ulubioną dystrybucją

  1. Ściągnijmy Adobe AIR SDK z http://www.adobe.com/cfusion/entitlement/index.cfm?e=airsdk
  2. Zainstalujmy Adobe AIR SDK (tutaj do /opt, więc potrzebne prawa roota):
    mkdir -p /opt/AdobeAIRSDK
    cd /opt/AdobeAIRSDK
    tar xjvf AdobeAIRSDK.tbz2
    cat >/usr/local/bin/adl <<'EOF'
    #!/bin/sh
    
    exec /opt/AdobeAIRSDK/bin/adl "$@"
    EOF
    
  3. Ściągnij instalator Dofusa dla Linuksa ze strony gry i rozpakuj do tymczasowej lokalizacji. To (i wszystko następne) już z prawami zwykłego użytkownika.
    mkdir /tmp/dofus-inst
    cd /tmp
    wget http://dl.ak.ankama.com/games/dofus2/setup/DofusInstall.run
    chmod a+x DofusInstall.run
    ./DofusInstall.run --keep --noexec --target /tmp/dofus-inst
    
  4. Stwórz katalog dla gry (tutaj w $HOME/Gry/Dofus) i rozpakuj tam aplikacje AIR:
    mkdir -p ~/Gry/Dofus
    cd ~/Gry/Dofus
    mkdir -p share/reg
    cd share
    unzip /tmp/dofus-inst/Dofus.air 
    cd reg
    unzip /tmp/dofus-inst/Reg.air
    cd ../..
    
  5. Stwórz pliki wykonywalne dla tych aplikacji:
    mkdir -p bin share/reg/bin
    cat >bin/Dofus << 'EOF'
    #!/bin/sh
    
    exec /opt/AdobeAIRSDK/bin/adl -nodebug ~/Gry/Dofus/share/META-INF/AIR/application.xml ~/Gry/Dofus/share
    EOF
    chmod a+x bin/Dofus
    cat >share/reg/bin/Reg << 'EOF'
    #!/bin/sh
    
    exec /opt/AdobeAIRSDK/bin/adl -nodebug ~/Gry/Dofus/share/reg/META-INF/AIR/application.xml ~/Gry/Dofus/share/reg
    EOF
    chmod a+x share/reg/bin/Reg
    
  6. Oryginalny instalator robi jakieś dziwne symlinki. Więc i my je zróbmy:
    mkdir share/reg/share
    ln -s ../Reg.swf share/reg/share/Reg.swf
    ln -s ../content share/reg/share/content
    
  7. Teraz skopiujmy pliki z instalatora:
    cp /tmp/dofus-inst/UpLauncher share
    cp /tmp/dofus-inst/games.xml share
    chmod a+x share/UpLauncher
    
  8. I zróbmy skrypt do uruchamiania gry:
    cat > start-dofus << 'EOF'
    #!/bin/sh
    
    cd ~/Gry/Dofus/share
    exec ./UpLauncher
    EOF
    chmod a+x start-dofus
    
  9. Teraz można spróbować uruchomić grę:
    ./start-dofus
    

    To może się nie udać, jeśli w systemie brakuje odpowiednich bibliotek w odpowiednich wersjach. W PLD Th np. trzeba było zbudować i doinstalować libjpeg6.

    Po doinstalowaniu brakujących bibliotek powinien się Launcher uruchomić i zacząć „uaktualniać” grę. Gdy Launcher ściągnie najnowszą wersję Dofusa będzie go można uruchomić.

Fajnie jest, gdy praca bawi :-)

Ostatnio miałem problemy z cieszeniem się pracą. Właściwie kombinowałem
tylko co by robić, żeby nic nie robić i jak dotrwać do weekendu. W końcu jednak
klient (czyli szef) sprowadził cztery serwery (dwa Sun Fire i dwa jakieś
Supermicro) dla swoich klientów i miałem na tym postawić nasz system. Właściwie
to miały być dwie instalacje – dla każdego klienta dwa serwery z których
jeden miał zastępować drugi w razie awarii. Czyli miałem zrobić dwa klastry HA
(High Availability).

Prawdę mówiąc nie miałem większego pojęcia na ten temat, więc się trochę
bałem, czy w ogóle się uda. Na początku więc po prostu postawiłem cztery
identyczne serwery. Potem szef zepsuł jedną maszynę Sun Fire i mogłem spokojnie
się skoncentrować na budowie jednego klastra :-). Warto zaznaczyć,
że wszystkie te maszyny stoją w Amsterdamie, a ja mam do nich dostęp tylko
przez sieć: SSH (także do konsoli szeregowych) oraz interfejs WWW do zdalnego
wyłącznika zasilania.

Nasz system oparty jest na Xenie, na listach Xena przeczytałem, że do zapewnienia
redundancji dobrze mieć DRBD (dla dla
replikacji dysków), albo iSCSI lub inne rozwiązanie SAN (jeśli przestrzeń
dyskowa miałaby być współdzielona). Wyszło mi na to, że dla nas lepsze będzie
DRBD. Zacząłem czytać o DRBD. Dowiedziałem się, że DRBD dobrze byłoby używać
wraz z Heartbeatem. To się zabrałem za
szykowanie pakiecików…

Po kilku przeróbkach PLDowych pakietów, po kilku kompilacjach kernela,
Heartbeata i DRBD, w końcu udało mi się coś uruchomić. Najpierw niespecjalnie
to działało, a ja kompletnie nie wiedziałem co sie na moich serwerach dzieje.
Ale po trochu to rozpracowywałem. W końcu usługi się uruchamiały tam gdzie
trzeba, a jak maszynę wyłączyłem, to przeskakiwały na drugą. Super.
:-)

… ale to wszystko w konfiguracji Heartbeat w wersji pierwszej, która
już podobno nie jest zalecana. No to włączyłem wersję drugą (crm
yes
w /etc/ha.d/ha.cf) i zabawa zaczęła się od początku:
wszystko przestało działać, przestałem rozumieć co się dzieje i dalej trzeba
było pakiet heartbeat poprawiać. Ale i to opanowałem i muszę przyznać, że
sprawiło mi to niezłą frajdę. :-)

Ciekawe co jeszcze mogę w tym klastrze poprawić… bo inne rzeczy co
czekają w kolejce, niestety, nie są już takie fascynujące… No cóż, kiedyś
nuda musi wrócić.

No i ciekawe jak te klastry będą się zachowywać w warunkach produkcyjnych…

Kamerka pod Linuksem

Żonka ostatnio wspominała, że chciałaby mieć kamerkę internetową. Ja lubię
takie zabawki, więc od razu podchwyciłem pomysł i postanowiłem jej kamerkę
kupić. No to zajrzałem na Allegro co tam mają… cała masa do wyboru… no to
biorę parę z brzegu i Googlam za ich wsparciem w Linuksie. Ciężko to idzie. Nic
na temat wsparcia w Linuksie dokładnie tych urządzeń co znalazłem na Allegro w
Google nie było. Jak
coś znalazłem, co miało wsparcie, to albo tego na Allegro nie było, albo
kosztowało więcej niż byłem w stanie zapłacić. Na Allegro był tak wielki wybór,
że nie sposób było sprawdzić wszystkiego. Podobnie na wygooglanych listach
sprzętu obsługiwanego przez Linuksa. Oczywiście każdy producent chipsetu
zrobił interfejs po swojemu (urządzenia oparte o standard UVC się dopiero
pojawiają i do tych najtańszych nie należą), a który chipset jest w której
kamerce to dopiero po podłączeniu można stwierdzić…

Na Allegro i tak nie chciałem tego kupować (w końcu to kot w worku),
uznałem, że wybiorę się do sklepu. Normalnie wziąłbym ze sobą listę
obsługiwanego sprzętu, żeby porównać z tym co jest na półkach. Ale dostępne
listy są olbrzymie… a i tak niekompletne… Poszedłem więc bez listy, parę
popularniejszych nazw zapamiętałem, a w ogóle, to uznałem, że może trafię. I
umówię się ze sprzedawcą, że jak nie uruchomię tego, to zwrócę…

No więc przyszedłem do sklepu. Przerażanie w oczach – chyba z
dziesięć różnych kamerek na półce, żadna nie przypomina niczego o czym
czytałem… No nic, mówię, że chcę kamerkę i nieśmiało dodaję ale taką,
żeby działała pod Linuksem
. A sprzedawczyni, ku mojemu zaskoczeniu, bierze
jedną kamerkę z półki (i to chyba taką, jakiej żonka oczekuje – na
laptopa, z klipsem) i mówi, że ta będzie na pewno działać. Okazało się, że był
tam już jeden klient z takimi wymaganiami, przyszedł z laptopem i na miejscu
sprawdził. Zapytałem jeszcze o parametry, bo kosztowała mniej niż byłem
przygotowany na to wydać. Pani zaproponowała, że może podłączyć do jakiegoś
laptopa i pokazać. Już brała jednego laptopa, ale stwierdziła: Ale ten ma
zainstalowaną tę kurewską… oj, przepraszam… na nim jest ta Vista
.
Kobieta była rzeczywiście przerażona, że jej się takie słowo wymsknęło. Widać
szczerze. :-D

W końcu dała mi jakiegoś laptopa z Windows XP, żebym sobie podłączył i sprawdził.
Taaa… równie dobrze mogłaby mnie posadzić przed sterami helikoptera, żebym
się przeleciał ;-). Ale jakoś sobie w tym egzotycznym systemie, i
to jeszcze z jakimiś dodatkowymi przeszkadzajkami, poradziłem. Kamerka
zadziałała, obraz był zadowalający (przynajmniej jak na tą cenę). Biorę.

Za sterownikami rozglądałem się wcześniej, więc jakiś miałem już w pracy
skompilowany, dla najnowszego kernela PLD AC. Okazało się, że pasuje do tej
kamerki. Załadował się bez problemu i xawtv pokazało obraz. Ale Ekiga
marudziła, że nie może otworzyć urządzenia. Bałem się, że kamerka z Ekigą
niezgodna (może dlatego, że JPEG)… ale okazało sie, że po prostu ten
sterownik to V4L1, a w Ekidze miałem załadowane tylko V4L2. Doinstalowałem
libpw-vide-v4l i ruszyło!

Teraz trochę danych praktycznych:

  • Kamerka to:
    A4Tech Evo Cam Note
  • Sterownik do niej to: gscpav1
    (wersja: 20070110)
  • Aby ręcznie zbudować ten sterownik na PLD Ac trzeba:
    • Zainstalować pakiet kernel-module-build w wersji zgodnej z
      używanym kernelem (zrobić upgrade kernela i zainstalować najnowszy
      kernel-module-build)
    • Rozpakować źródła sterownika gdzieś w katalogu domowym.
    • Poprawić Makefile:

      Zamienić:

      default:
              $(MAKE) -C $(KERNELDIR) SUBDIRS=$(PWD) CC=$(CC)
      modules

      na (w przypadku używania kernela up, zamienić wszystkie smp na up):

      default:
              mkdir -p o/include/linux
              ln -sf $(KERNELDIR)/config-smp o/.config
              ln -sf $(KERNELDIR)/Module.symvers-smp o/Module.symvers
              ln -sf $(KERNELDIR)/include/linux/autoconf-smp.h
      o/include/linux/autoconf.h
              $(MAKE) SYSSRC=$(KERNELDIR) SYSOUT=$(PWD)/o O=$(PWD)/o -C $(KERNELDIR)
      CC=$(CC) prepare scripts
              $(MAKE) SYSSRC=$(KERNELDIR) SYSOUT=$(PWD)/o O=$(PWD)/o -C $(KERNELDIR)
      SUBDIRS=$(PWD) CC=$(CC) modules
    • Przelogować się na roota, skopiować zbudowany gspca.ko do
      /lib/modules/`uname -r`/misc, zmienić mu właściciela na
      root:root, odpalić depmod -a.

Dopiero teraz zobaczyłem, że w repozytorium PLD jest gspca.spec i
się nawet buduje, więc można zapomnieć o tym, co napisałem wyżej i po prostu
zbudować sobie pakiet. Wersja w specu jakby trochę inna, jeszcze nie sprawdzałem czy
działa, najwyżej trzeba by speca nieco poprawić.

Update: Nagrałem mały testowy filmik, żeby pokazać co kamerka może. No, nie do końca pokazuje on co chciałem – podczas nagrywania obraz stracił nieco na jakości, bo nie znalazłem jeszcze sposobu na nagrywanie z tego w optymalnej jakości. Na bezpośrednim podglądzie w spcaview/xawtv/mplayer obraz jest odrobinę lepszy.

Rewolucja w kompie

Niedawno pojawiło się nowe XFCE: 4.4.
Najpierw chciałem to w pracy sobie zainstalować, ale okazało się, że ani tego
nie ma w PLD Ac, ani nie da się w tym Ac zainstalować. Instalacji Th wolałem
nie ryzykować na maszynie która służy mi do pracy… co innego w domu, tam
ostatnio używam jedynie CJC i Firefoksa. Uznałem, że dwie aplikacje jakoś do
działania doprowadzę.

Upgrade nie był prosty. Masy rzeczy w repo Th brakuje. Wiele zależności
jest zepsutych. Cała masa pakietów zbudowanych w Ac wymaga X11-*, albo
XFree86-*, których w Th już nie ma (wystarczyłyby zależności od libX*, które
pociągnęłyby odpowiednie pakiety xorg-*). Dodatkowo, żeby nie było za prosto,
mam u siebie pomieszane pakiety 32- i 64-bitowe. Ale jakoś się udało…

Pierwsze co chciałem odpalić, to Xy. W końcu dla nowego XFCE jest ta cała
szopka… Poprzednio używałem 64-bitowego X-serwera i zamkniętych sterowników
ATI. Otwarte nie dawały akceleracji, a zamknięte nie działały, gdy X-serwer był
32-bitowy (generalnie większość systemu mam 32-bitowe), a kernel 64-bitowy (bo
tylko taki pozwala mi odpalać binarki i 32- i 64-bitowe). Teraz chciałem
spróbować z serwerem 32-bitowym i sterownikami Open Source, w końcu między X.org
7.0, a 7.2 coś mogło się zmienić…

Jedno się nie zmieniło – sterownik z X.org wciąż nie rozpoznaje mojej
karty (ATI Technologies Inc RV370 secondary [Sapphire X550 Silent]) i obsługuję
ją dopiero po dodaniu do xorg.conf: ChipId 0x5b60. Akceleracja 3D też nie
ruszyła, chociaż sterownik DRM w kernelu się załadował i kartę poprawnie
wykrył… logi sugerowały, że znowu może być coś z tymi bitami… Zainstalowałem
więc 64-bitowy X-serwer z 64-bitowymi sterownikami. DRI ruszyło. Rozszerzenie
„Composite” też. Mogłem podziwiać piękną przezroczystość w XFCE. Najpierw
działało to strasznie wolno, ale po poprawieniu paru opcji da się tego używać.
Jednak z OpenGL coś wciąż było nie tak… mimo że glxinfo pokazywało, że
wszystko jest OK i nawet Direct rendering: yes. To glxgears nie działało.
Znaczy się działało, ale nic nie wyświetlało. Podobnie wszystkie inne aplikacje
3D…

Spróbowałem więc zamkniętych sterowników… musiałem przebudować, bo w Th
były stare, niekompatybilne z nowymi Xami. Nowe się zbudowały, nawet działały,
ale bez akceleracji 3D. Linker dynamiczny nie mógł znaleźć jakiegoś symbolu od
DRI w modułach X-serwera… pewnie te zamknięte binarki nie są zgodne z naszym
buildem X.org… no cóż, tym razem lepiej wypadły sterowniki otwarte.

Wróciłem do otwartych sterowników i spróbowałem jeszcze czegoś:
zainstalowałem 64-bitowe glxgears… i ruszyło. Czyli tym razem, pod 64-bitowym
kernelem, nie tylko X-serwer musi być 64-bitowy, ale i wszystkie aplikacje
OpenGL. Przykre… ale chwilowo mogę z tym żyć. Ostatnio i tak wiele takich
aplikacji nie używam. Właściwie, to tylko StepManię.

Dzisiaj więc postanowiłem sobie skompilować StepManię na 64-bity. Środowisko
do budowania zrobiłem sobie w chroocie z czystym 64-bitowym Th. Zainstalowałem
co StepMania potrzebowała i zacząłem budowanie. Od razu się wykrzaczyło… SM
jest w C++, a C++ ma to do siebie, że kod napisany dla starszego kompilatora
często nie da się skompilować nowszym. W PLD Th mamy GCC 4.2 i to GCC kodu
StepManii nie polubiło. Jednak potrzebnych poprawek nie było dużo i większość
z nich była nawet dla mnie (nie znającego i nie lubiącego C++) oczywista.
W końcu się skompilowało. I nawet dało się uruchomić.

Skompilowana przez mnie StepMania działała, ale tak jakby nie do końca. Nie
dało się wejść do ustawień gry, a rozpoczętej gry nie dało się wygrać. Jak się
poprawnie przeszło którąś piosenkę, to maszyna puszczała ją od początku.
Można by się było zajechać ;-). Podczas kompilacji widziałem
warningi dotyczące, między innymi, strict aliasing rules, więc
postanowiłem spróbować kompilacji z innymi opcjami. Okazało się, że skrypt
configure StepManii na sztywno ma wpisane -O3. To już mogło sprawiać
problemy. Zmieniłem na -O2 i dodałem -fno-strict-aliasing i całość
skompilowałem od nowa. Podczas kompilacji ćwiczyłem sobie na tej niedorobionej
binarce – ciekawie się gra, gdy komputer się czasem zagapi i nie
zauważy
, że się strzałkę wcisnęło na czas. ;-)

Po kilkunastu minutach miałem nową 64-bitową binarkę gotową. I tym razem
działa dobrze. To sobie jeszcze kiedyś poskaczę. :-)

W kolejce czeka zbudowanie GComprisa dla
Krysi, bo stare wyleciało razem z Ac (w Th tego brak).

fstab-sync zniknął?

Miesiąc temu opisałem jak
sprytnie skonfigurowałem sobie czytnik kart w moim nowym komputerku
. Dzisiaj
chciałem sobie tym sposobem zgrać zdjęcia z karty CF. Wkładam kartę,
robię mount /media/cf… i nie ma takiego katalogu. W fstabie
też żadnej wzmianki o włożonej karcie, mimo że wciąż jest nagłówek: #
This file is edited by fstab-sync - see 'man fstab-sync' for
details
. Chciałem spróbować odpalić fstab-sync ręcznie… ale
nigdzie nie ma czegoś takiego…

Szukam poldkiem po pakietach – nie ma. Zaglądam do hal.spec
i dowiaduję się, że fstab-sync zostało usunięte ze źródeł. Zaglądam do
ChangeLog i dowiaduję się tylko tyle, że zostało usunięte. Ani słowa na temat
dlaczego i co w zamian. Na stronach Hala wyszukiwanie
hasła fstab-sync nie pokazuje nic.

No pięknie… niech ja jeszcze się kiedyś jakąś ciekawą technologią
zainteresuję… Ciekawe, czy jak skonfiguruję udev, żeby mi robiło symlinki
dla urządzeń czytnika kart, to też to za miesiąc przestanie działać…

Zmiany, zmiany, zmiany…

Zaczęło się

tak niepozornie
… Jednak od tamtego czasu trochę dla tego gościa
zrobiłem… I w sobotę przyleciał do Gliwic z Amsterdamu, specjalnie, żeby
omówić sprawę ewentualnego zatrudnienia mnie na pełen etat… Dzisiaj
aktualnemu pracodawcy złożyłem wypowiedzenie.

Od chyba ośmiu lat pracuję jako administrator w jednej firmie. Robota
administratora zasadniczo mi odpowiada, ale potrafi dać w kość. Szczególnie
dyżurna komórka jest stresująca, nawet jeśli rzadko dzwoni. Poza tym,
sama firma też mi dała w kość. Nie na tyle, żeby już dawno z niej uciec,
gdziekolwiek indziej, ale wystarczająco, by nie mieć wielu wątpliwości gdy
pojawia się lepsza oferta. Jednak wątpliwości były – najbardziej szkoda
tej całej infrastruktury którą stworzyłem, właściwie od zera –
konfiguracja serwerów, architektura sieci, oprogramowanie/oskryptowanie które
to wszystko napędza…

Bez wątpienia w dotychczasowej pracy wiele się nauczyłem. Zarobki spokojnie
wystarczają na życie na całkiem sensownym poziomie. Mając dostęp do firmowej
infrastruktury mogłem rozwijać swoje pasje, mogłem też wspomóc inne projekty
– np. PLD builderem AMD64 i systemem zgłaszania błędów. Wciąż tam mam
swój JID…

Koledzy obiecali, że zaopiekują się serwerem Jabbera. Infrastruktura PLD
może i też mogłaby zostać, ale, że nikt blisko związany z PLD w firmie nie
zostaje, to pewnie jednak będzie to trzeba gdzieś przenieść. Swoją pocztę
i swoje WWW wyniosłem już dawno. Przeniesienie list dyskusyjnych moich
projektów to tylko kwestia czasu.

Szef moje wypowiedzenie przyjął spokojnie. Najbardziej zaskoczony był
kolega, który nie spodziewał się tak szybkiego awansu. Koleżanki się
zapłaczą… ;-)

Nową pracę zacznę jak mi się skończy okres wypowiedzenia, czyli na początku
lipca, albo wcześniej, jeśli koledzy wcześniej uznają, że poradzą już sobie
sami. Prawdopodobnie doczekam jeszcze pierwszej instalacji światłowodowej
w firmie :-).

W nowej pracy też będę trochę adminował, ale nie to ma być moim głównym
zadaniem. Trudno właściwie powiedzieć kim dokładnie będę. Chyba po prostu
developerem w szerokim tego słowa znaczeniu. W tym programistą, chociaż
tego chciałem uniknąć. Do tego analitykiem, projektantem i czymśtam jeszcze, po
trochu.

Mimo, że płacę mam ustaloną w Euro, to pracować mam tutaj, na miejscu.
Dostanę jakieś malutkie biuro, z biurkiem i komputerem i jakoś będę miał sobie
radzić. Jak szefa dwa razy do roku zobaczę na oczy, to będzie dobrze. Zresztą,
po roku mogę już tej pracy nie mieć, jeśli to przedsięwzięcie nie wypali (co
zapewne będzie w dużej mierze zależało ode mnie). Jednak mam zamiar spróbować
– warunki są, jak dla mnie, jak najbardziej zachęcające.

Klamka zapadła… zobaczymy co będzie dalej…