PLD RescueCD i PXE

Po pierwsze trzeba mieć serwer DHCP (ten z pakietu dhcp,
zresztą chyba nie mamy innego w PLD) i TFTP. Uwaga serwer z paczki
tftpd nie chciał działać z syslinuxem, więc należy
zainstalować tftpd-hpa. Oprócz tego trzeba mieć bootloadera
umiejącego ładować system przez sieć. W moim przypadku był to
syslinux. No i potrzebna jest płytka RescueCD, z obrazem systemu do
uruchomienia. Trzeba użyć oficjalnego obrazu (datowanego
2004-07-18) dostępnego ze strony RescueCD. Nowsza wersja
(beta z 2005-06-19) się co prawda bootuje, ale nie można się
do niej zalogować.

Montujemy płytkę RescueCD i kopiujemy z niej pliki vmlinuz i rescue.sqf do
/var/lib/tftp. Dla pełniejszej funkcjonalności można tez skopiować
boot.msg, help.msg i memtest. Część plików jest w katalogu
głównym płytki, część w boot/isolinux. Z katalogu /usr/lib/syslinux
kopiujemy plik pxelinux.0 (część syslinux służąca do bootowania przez sieć), też do
/var/lib/tftp. Pozostaje przygotować plik konfiguracyjny dla pxelinux. W tym celu
tworzymy katalog /var/lib/tftp/pxelinux.cfg, a w nim plik default (nazwą
pliku może też być np. adres MAC maszyny którą będziemy bootować, szczegóły w dokumentacji
syslinuxa). Plik ten tworzony jest na podstawie isolinux.cfg
z RescueCD. U mnie wygląda on tak (i to powinno działać z tą wersją RescueCD u każdego):

serial 0
prompt 1
timeout 99
default pxe
label pxe
 kernel vmlinuz
 append initrd=/rescue.sqf init=/linuxrc root=/dev/ram0  ramdisk_size=54000  console=tty0 console=ttyS0,9600n81
 ipappend 1
label mem
  kernel memtest

Ta konfiguracja jest oczywiście przygotowana do użycia z konsolą szeregową. Jak ktoś chce standardową konsolę VGA,
to powinien wywalić serial 0 i console=tty0 console=ttyS0,9600n81.

Gdy już mamy przygotowane pliki dla startowanej maszyny, musimy je jej wskazać. Robi się to przy pomocy
serwera DHCP, jednocześnie przydzielając adres IP. W moim przypadku załatwiał to poniższy wpis w /etc/dhcpd.conf,
w odpowiedniej deklaracji podsieci:

host pxeinstall {
	hardware ethernet 00:40:63:c3:99:a9;
	fixed-address 10.253.0.99;
	filename "pxelinux.0";
}

Adresy MAC i IP należy oczywiście dostosować do swoich potrzeb. Nazwa pliku jest względna do
katalogu /var/lib/ftp i może być właściwie dowolna. Większość wspomnianych wyżej
ścieżek w /var/lib/tftp jest konfigurowalna. Wyjątkiem jest katalog
pxelinux.cfg.

To właściwie tyle konfiguracji. Należy jeszcze się upewnić, że serwery TFTP i DHCP działają
i używają właściwej konfiguracji (dhcpd trzeba zrestartować), włączyć na maszynie do
wystartowania bootowanie przez PXE i uruchomić ją. Po chwili powinna dostać adres IP, pobrać parę
plików po TFTP i uruchomić system.

Z licencji…

Oto co znalazłem w licencji (nawet niespecjalnie długiej i wymyślnej) do
firmware i sterowników dla serwera Sun Fire v20z:

You acknowledge that Software is not designed, licensed or intended for use in
the design, construction, operation or maintenance of any nuclear facility.

Na tą licencję trzeba się zgodzić, klikając na Accept aby ściągnąć
firmware i sterowniki. Żeby było śmieszniej wstęp do tej licencji mówi, że należy ją zaakceptować przed otworzeniem
opakowania z oprogramowaniem którego dotyczy. A samo oprogramowanie jest w większości na GPL. Na szczęście to akurat
ta licencja na ściąganie uwzględnia. Ale już sam do końca nie wiem, czy jak ściągnę od nich to oprogramowanie
(GPL) to mogę przy jego użyciu budować bombę atomową, czy nie… no i jak otworzyć to opakowanie…;-)

Opieka nad projektem…

Jakiś czas temu dostałem łatę na JJIGW dodającą obsługę
subskrypcji obecności użytkowników IRCa. Rzecz fajna, przydatna, aczkolwiek
z powodu specyfiki IRCa (zmieniające się nicki), ciężka do zaimplementowania.

Dzisiaj wreszcie znalazłem czas, żeby przejrzeć tego patcha. I nie
spodobał mi się. Parę rzeczy psuł (łamiąc specyfikację XMPP i MUC), parę innych robił nia tak jakbym
chciał. Ale zawierał też pewne poprawki mojego kodu. Najbardziej dokuczyły mi:
brak dokumentacji dodanego kodu i coding style. Ale tego nie
śmiałem się za bardzo czepiać — mój kod JJIGW sam
z siebie jest kompletnie pozbawiony dokumentacji, a i śliczny nie jest.

Napisałem swoje uwagi do autora patcha. W sumie, nawet jakby nie chciał
tego poprawić, to bym patcha nałożył. Ręcznie, w większości po swojemu, ale
dodałbym te zmiany. Jednak gotowy kod, to zawsze coś. Szkoda, że rzadko dostaję
gotowe ulepszenia do moich projektów. No, ale cóż. Sam sobie też jestem winien
— komu się chce grzebać w zawiłym i nieudokumentowanym kodzie? Z drugiej
strony, jakbym się uparł, żeby wszystko udokumentować, to ten kod by pewnie
w ogóle nie powstał — zabawa mogłaby przestać być zabawna. Dobrze, że
przynajmniej API PyXMPP jakoś
udokumentowałem.

Lokalizacja po mozillowatemu…

Gdy instalowałem sobie Firefoksa 1.0 na domowym komputerku, to wybrałem
sobie angielską (brytyjską, nie amerykańską!) wersję językową. Co prawda
disc zamiast disk trochę kłuło w oczy
(w terminologii komputerowej niestety przywykłem do amerykańskiego), ale
przynajmniej colour itp. jest normalnie. W każdym razie
z tą lokalizacją jest mi całkiem dobrze, ale…

Gdy przychodzi czas na upgrade okazuje się, że nowa wersja jest na
początku tylko po amerykańsku. Na angielską wersję językową trzeba długo
czekać, mimo że w przypadku poprawek bezpieczeństwa nie powinno się czekać ani
chwili. Do Fx 1.0.5 jeszcze wersji brytyjskiej nie ma.

Pojawia się pytanie, czemu w takim razie nie zainstaluję sobie po prostu
wersji amerykańskiej. Ano temu, że po jej zainstalowaniu Fx przestaje działać
z moim obecnym profilem, a swoich ustawień i rozszerzeń nie chcę się pozbywać.
Każdy normalnie tłumaczony projekt (czyt. tłumaczony przy użyciu gettexta) ma
fallback do języka domyślnego (zwykle amerykańskiego). W takim przypadku może
się pojawić nowa wersja bez czekania na uaktualnienia lokalizacji —
w najgorszym wypadku będzie brakowało kilku napisów. A jak ktoś chce zmienić
język to po prostu wybiera nowy, ewentualnie instalując wcześniej pliki
tłumaczeń. Niestety w oprogramowaniu Mozilli to tak nie działa — muszą być
zasoby w wybranym języku albo całość się wypieprza na brakujących
encjach. Już nie mówiąc o tym, jak się sprawy komplikują, gdy z jednej
instalacji Firefoksa mieliby korzystać użytkownicy różnych języków.

No i nie wiem. Czekać dalej na Fx 1.0.5 w wersji English (British),
czy instalować domyślną i hackować swój profil (zdaje się, że poprzednio przy
tym poległem)?

Teledyski…

Reklamy w radiu zachęciły mnie do zajrzenia na teledyski.interia.pl. Ciężko u nas
o darmową/tanią dobrą muzykę (wiem jestem nienormalny, ale pirackich MP3
nie lubię), więc możliwość dostępu do takiej i to z teledyskami, cieszy.

Na stronie rzeczywiście jakieś teledyski, nawet interesujące. Wybrałem
pierwszy z brzegu, zespołu Homo Twist. Pojawiła się strona z ładnym
puzzlem — oczywiście brakuje plugina, który oczywiście nie jest
dostępny pod Linuksem. Nie poddałem się jednak. Zajrzałem do źródła strony
w poszukiwaniu jakiegoś URLa to właściwego teledysku. Kod strony to oczywiście
koszmarek — niby XHTML, ale uzupełniany JavaScriptem i to jeszcze przez
document.write(). Po cholerę uzywać XHTML jak się ma zamiar go
używać w sprzeczności z podstawowymi założeniami XML (XML to nie ciąg znaków,
do którego można coś dopisywać gdzie popadnie — XML to drzewo
elementów). W każdym razie wprost z kodu trudno było URLa wyciągnąć, ale już
wiedziałem gdzie szukać…

… Otworzyłem więc okienko informacji o stronie i rzeczywiście,
w zakładce media był URL do playlist2.html z jakimiś parametrami.
Ściągnąłem to sobie jako plik, oczywiście nie HTML, ale nawet
prawie-well-formed XML. A w środku już normalny URL, do strumienia
mms://. Pozostało spróbować odpalić to w mplayerze…. i ruszyło!
Hip-hip, hurra! Tylko czy musi to być takie trudne? Naprawdę nie można po
prostu dać URLa do strumienia? W Windows by się w Media Playerze odpaliło,
a na wszystkim innym w czym kto chce. A może po prostu trzeba znaleźć
odpowiedniego plugina pod Linuksa? Jakiś mplayer-plugin, abo co? Tylko że nie
chcę sobie niepotrzebnie przeglądarki zaśmiecać. A może Greasemonkey?

Żegnajcie Tabbrowser Extensions i Adblock

Żona się skarżyła, że na laptopie jej się Firefox na niektórych stronach
(w szczególności na stronach MBanku)
wysypuje. Już wcześniej miała problemy z obrazkami na Allegro, które to
problemy rozwiązywało wyłączenie Tabbrowser Extensions. Okazało się, że po
wyłączeniu TBE Firefox już się nie wykłada. Fajnie… Tyle, że po pierwsze
— przeglądarka nie powinna się wysypywać (SIGSEGV) z powodu błędnego
rozszerzenia (XUL/JavaScript/CSS), a po drugie standardowa obsługa zakładek
w Firefoksie IMHO i IMWHO nie nadaje się do użytku…

Problem nie występował na naszym dużym komputerze. Ale tutaj dawno
nie uaktualnialiśmy Tabbrowser Extensions. Uaktualnień trochę się bałem, bo
kolejne wersje to snapshoty, o których autor pisze, że u niego działa, a jak
u kogoś nie, to go nie obchodzi. Póki działa ok, ale nigdy nie wiadomo kiedy
się spieprzy. Dla pewności, czy to nowa wersja TBE psuła Firefoksa zrobiłem
upgrade… i u mnie też zaczęło się wysypywać. Postanowiłem więc poszukać
alternatywy. Tab
Mix
wyglądało zachęcająco, więc zainstalowałem. Zaraz po instalacji
rozszerzenia (i oczywiście po restarcie przeglądarki, wrrrr…) Firefox
zaczął się zachowywać w miarę normalnie (w porównaniu do Firefoksa bez żadnych
zakładkowych ulepszeń). Większość rzeczy działała tak, jak je sobie wcześniej
w TBE konfigurowałem. Po zmianie kilku opcji (w przejrzystym okienku, a nie
potworze z milionami ustawień, jak w TBE) właściwie mam wszystko co potrzeba.
Jeszcze sobie tylko Session
Saver
a zainstalowałem i mam wszystko do czego było mi Tabbrowser
Extensions potrzebne. Przy okazji zobaczyłem jaki Firefox może być szybki.
Nie sądziłem, że tamto paskudztwo mogło aż tak spowalniać przeglądarkę.

Jak już zakładki działały, to dla pewności sprawdziłem stronę MBanku.
I znowu się wysypało… No to wyłączyłem wszystkie stare rozszerzenia…
przestało się wywalać. Metodą eliminacji znalazłem winnego (bo wina
jest oczywiście po stronie samego Firefoksa) — Adblock. Wersja ta sama
co na addons.mozilla.org, więc upgrade odpada. Najwyraźniej Adblock plus
jakiekolwiek sensowne zarządzanie zakładkami powoduje problemy (usuwanie
obrazków z okienka, które właśnie zostało zamienione na zakładkę?). Adblock
tak bardzo do szczęścia potrzebny mi nie jest (największe syfy Flashblock
blokuje), więc się go pozbyłem. Wygląda na to, że teraz Firefox działa jak
należy… ciekawe jak długo…

Wnioski są takie: Firefox to paskudny gniot (ale to chyba wszyscy
wiedzą), ale można sobie z nim poradzić. Dla mnie to wystarczy.

P.S. Mam wrażenie, że z tego wpisu też straszny gniot mi wyszedł… 😉

XP w PLD c.d.

Już miałem wysłać bug-report w sprawie tego problemu z zegarem XP pod
QEMU, zapisałem się na odpowiednią listę dyskusyjną, ale jeszcze zerknąłem do
archiwum. Okazało się, że wczoraj ktoś zrobił na to patcha. Założyłem łatkę
i rzeczywiście, zegar działa dużo lepie. Odrobinę się spóźnia, ale to już nie
jest taki duży problem. No i ntpd się na tym nie wykrzacza,
chociaż zniwelować odchyłki czasu mu się nie udaje.

Po naprawieniu zegara przyszło zainstalować jakąś konkretną aplikację,
znaczy się, tego nieszczęsnego Płatnika. Na początku instalator Płatnika mnie
okrzyczał, że rozdzielczość mu się nie podoba i musi być co najmniej 800×600.
Czas więc było pożegnać się z opcją -std-vga i zasymulować Cirrus
Logic. Windows XP po tej zmianie nawet nie jęknął, tylko od pierwszego
uruchomienia zaczął używać 256 (zamiast wcześniejszych 16) kolorów. Hmmm…
mógłby w sumie napisać, że karta się zmieniła. Przełączenie na 800×600
i 16-bitowy kolor też nie było problemem, tyle że tło się trochę kaszaniło.
Ale to już chyba wina emulatora i po jego restarcie było OK. Płatnik dał się
zainstalować (BTW. jego wymagania co do hasła administratora są IMHO lekko
przesadzone) i wygląda na to, że działa. Tyle że wolno. Ale to już żonka musi
stwierdzić, czy da się w tym pracować, czy nie.

Teraz instaluje się SP2, wcześniej pociągnąłem przez Windows Update jakieś
mniejsze poprawki. Sieć w tym chodzi bardzo wydajnie, a i łącze w domu mamy
niezłe, więc to akurat bardzo szybko idzie. Może jutro żona spróbuje tego
używać i okaże się, czy to w ogóle miało sens, czy jest to sztuka dla sztuki.

Update: Zapomniałem jeszcze napisać jak Windows widzi tę emulowaną maszynę: Unknown Processor Intel P6, 4.1Ghz (laptop ma 1.13GHz)

Windows XP pod Linuksem…

Żonka już się chwaliła swoim służbowym
laptopem
. Podstawowy system tam to oczywiście Linuks, PLD. Niestety…
żona w pracy zajmuje się, między innymi, ZUSem, a więc Windowsa też mieć musi.
Pół biedy mieć Windowsa na laptopie, gorsza jest konieczność wyłączania
Linuksa, żeby z niego skorzystać. Postanowiłem więc zainstalować Windowsa XP pod
Linuksem.

Już kiedyś bawiłem się VMWare, ale to komercyjne i pierońsko drogie
oprogramowanie, a już ostatnio gdy tego próbowaliśmy z darmowymi licencjami
nie było tak fajnie jak kiedyś, gdy można było co miesiąc sobie je po prostu
odnawiać. Darmowych wirtualnych pecetów jest kilka, jednak zwykle wiele im
brakuje. Najbardziej zachęcający wydał mi się QEMU szczególnie, że pojawił się
do niego akcelerator pozwalający na uruchamianie kodu na rzeczywistym,
a nie wirtualnym, procesorze. Dzięki temu wirtualny komputer może być znacznie
szybszy.

Legalny Windows XP OEM przyszedł razem z laptopem. Najpierw próbowałem
tego zainstalowanego już Windowsa odpalić z kopii partycji Windowsowej. Coś
tam niby się ładowało, ale zatrzymywało się na czarnym ekranie. Uznałem więc,
że trzeba w wirtualnej maszynie zainstalować system od nowa. Sądziłem, że
któraś z płytek dołączonych do komputerka zawiera wersję instalacyjną Windows.
Jednak nie, tam były tylko obrazy dysków i program do odtwarzania tego,
odmawiający współpracy na czymkolwiek innym niż taki sam laptop do jakiego
płytki były dołączone. Maszyna wirtualna QEMU nie spełniała tego warunku. Już
myślałem, że z instalacji nici, ale się okazało, że gotowa instalka leży
normalnie na dysku, na partycji Windowsowej, obok zainstalowanego systemu.

Zrobiłem obraz dysku z partycją FAT32, przegrałem tam instalkę, dorzuciłem
ten obraz jako drugi dysk, obok virtualnego dysku docelowego. Instalację udało
się uruchomić startując z jakiejś dyskietki startowej Windows 95. Szło to dość
powoli, ale praktycznie bezbłędnie do momentu pierwszego planowego restartu.
Instalacja po restarcie, dalej w trybie tekstowym, zaczęła się sypać. Jakichś
plików instalator nie mógł znaleźć, a potem wywalał się z Bus error.
Wyczytałem gdzieś, że na Bus error pomaga odpowiednie ustawienie
wielkości pamięci maszyny wirtualnej (powinno być tego trochę mniej niż
wynosiła wielkość /dev/shm), ale żeby od razu wykluczyć wszelkie problemy
i nie zaczynać wiele razy od nowa, wyłączyłem dla pewności też
kqemu (akcelerator). To drugie było raczej
niepotrzebne. W każdym razie instalacja się udała, tyle że trwała ponad 24h. Z
włączonym akceleratorem pewnie byłoby parę razy szybciej.

Teraz system się uruchamia i działa ładnie, tyle że strasznie wolno. Ale
największym problemem jest zegar — w Windows na wirtualnej maszynie
chodzi nawet grubo ponad 10 razy szybciej niż powinien. To pewnie powoduje
dodatkowe obciążenie (pewnie w Windows też coś w rodzaju crona chodzi),
a niektóre rzeczy przez to po prostu nie działają (timeout dla operacji, która
nawet nie zdążyła się rozpocząć). Na listach QEMU sugerowali NTP. Najpierw
spróbowałem klienta wbudowanego w Windows. Ale to porażka. Po ręcznym
ustawieniu czasu mniej-więcej udało się zsynchronizować zegar przez
NTP, ale ta synchronizacja polegała na jednorazowym ustawieniu czasu
z komunikatem, że kolejna będzie za tydzień. To zupełnie mnie nie
satysfakcjonowało. Zainstalowałem więc Windowsowy port normalnego
ntpd. Przynajmniej było widać, że ten stara się czas na bieżąco
ustawiać, ale przy tak rozjechanym zegarze najwyraźniej też zgłupiał
i przestawił mi zegar jeszcze o parę godzin. Chyba będzie trzeba poczekać aż
w samym QEMU jakoś ten problem rozwiążą…

Teraz spróbuję jeszcze zmienić wirtualną kartę graficzną ze zwykłego VGA
na SVGA Cirrus Logic — ciekawe jak to się odbije na wydajności. No
i czy tego się będzie dało w ogóle praktycznie używać.

Historia padu pewnego dysku…

W piątek rano jeden z naszych serwerów nagle przestał odpowiadać, nawet na
konsoli szeregowej. Kumpel przeszedł się na serwerownie zobaczyć co jest.
Komputer nie reagował, a po resecie nie widział jednego dysku (tego z którego
miał się startować system). Uznałem, że dysk mógł się zawiesić na
twardo
i zaproponowałem odłączenie komputera całkowicie z zasilania na
chwilę. Po tej operacji system wystartował normalnie z właściwego dysku.

Jak już system działał postanowiłem dyskom bliżej się przyjrzeć.
smartctl -a stwierdził OK. scsinfo -a nie
wykazało żadnych bad sektorów. Zapuściłem jeszcze
SMART Extended Self Test i uznałem, że problem został
zażegnany. Niestety po chwili serwer zaczął się zachowywać dziwnie. Dawał
błąd read-only filesystem przy dowolnej próbie zapisu na głównej
partycji. W logach było jedynie nic nie mówiące Journal aborted. Gdy
chciałem sprawę bliżej zbadać, okazało się, że bash nie widzi podstawowych
binarek. Jakież było moje zdumienie, gdy się okazało, że ls -l /
nie pokazuje nic. Ale już np. ls -l /bin/ls
pokazywało poprawne informacje o pliku. Nie było co się więcej zastanawiać,
tylko downować serwer i lecieć na serwerownię.

Na serwerowni powtórzyliśmy operację, która poprzednio przywróciła maszynę
do życia. Bez skutku — system już nie startował z tego dysku. Co prawda, BIOS
kontrolera widział dysk, ale z Media format error i go od razu
wyłączał. Wyciągnęliśmy więc serwer z szafy i zanieśliśmy do biura.

Dysk podłączony do innej maszyny też nie działał, więc zabraliśmy się za
ratowanie systemu, wykorzystując to co zostało. Na szczęście okazało się, że
większość najistotniejszych plików (/var i /home)
leży na drugim, ocalałym dysku. Znalazło się też tam miejsce na odtworzenie
/ + /usr z backupu.

Backupy wszystkich naszych serwerów zapisujemy na tasiemkach przy pomocy
oprogramowania Bacula (It comes by
night and sucks the vital essence from your computers.
). Ten wspaniały
zestaw narzędzi pozwala nam zdalne backupowanie wszystkich systemów na jednym
streamerze, zachowując informacje o tym co, gdzie i kiedy zostało
zarchiwizowane. Niestety okazało się, że przy odtwarzaniu z tych kopii
zapasowych to już nie działa tak ładnie…

Pierwszy problem to to, że gdy Bacula skończył odtwarzanie z jednej
tasiemki, to nie poprosił o włożenie kolejnej, tylko wszedł w jakiś dziwny
stan w którym nic nie mógł przeczytać, ani nie dało się kasetki wyciągnąć.
Dało się to obejść rozpoczynając kolejny proces odtwarzania, tylko danych z
tej drugiej (chronologicznie pierwszej) tasiemki.

Gorszy był drugi problem. Odtwarzanie przerwało się gdzieś w środku (na
jakimś /dev/rd/cośtam. Puściłem jeszcze raz, omijając dane już
odtworzone, oraz katalog na którym się wywalił. Niby wszystko odzyskaliśmy,
ale okazało się, że prawa dostępu do wielu katalogów, utworzonych w tym
przerwanym procesie, są co najmniej dziwne. Np. 744 na /usr albo
777 na /usr/local/bin. Udało się to jednak RPMem do porządku
doprowadzić. Ostatecznie udało się, jeszcze w piątek, uruchomić na serwerze
podstawowe usługi, w tym Jabbera i pocztę, bez żadnych strat w danych.

Od razu, gdy stwierdziliśmy, że dysk padł, zamówiliśmy nowy. Była pewna
szansa, że przyjdzie w sobotę i plan, żeby w tę sobotę odzyskać resztę systemu
(w tym builder AMD64 dla PLD). Jak nie w sobotę, to w poniedziałek od rana.
Dysk przyszedł w poniedziałek (dzisiaj), ale dopiero w południe.
Spartycjonowałem go, założyłem wolumeny LVM i przegrałem większość danych z
tego ocalałego dysku. Zacząłem też odtwarzanie pozostałych danych z backupu.
Wszystko w trybie single, aby działające usługi (w tym Jabber i poczta)
nie nabruździły mi w tym. Niestety odtwarzanie z backupu nie zdążyło się
skończyć przed moim wyjściem z pracy. Koledzy zostali w pracy, aby po
zakończeniu operacji przywrócić serwer do życia. Niestety Bacula znów się
wywalił. Serwer działa (tyle co w piątek udało się odpalić), ale część danych
wciąż nie jest odzyskana. Jutro będę miał jeszcze z tym sporo roboty…