Jeden niegrzecznych PeeLDowiec znalazł na SourceForge programik gnaughty. Pochwalił się na
pld@chat.chrome.pl i zaraz uznano, że do tego speca trzeba
zrobić, bo w PLD nie może być takich braków. Spec oczywiście powstał i zasilił
repozytorium PLD. Ciekawe kiedy ten pakiecik trafi na oficjalne FTP...
Pakiety porn-get i pornview już tam są.
7 komentarzy do wpisu „ Niegrzeczni PeeLDowcy, niegrzeczni...”
Wczoraj ejabberd zaczął mi
szaleć. Nic z serwera nie przychodziło, to co się pisało szło efektywnie do
/dev/null, a nowe połączenia były odrzucane. Po restarcie zaczęło
działać, ale po godzinie znowu się zepsuło, tak samo.
Na serwerze miałem zainstalowanego dość starego Erlanga (R9C-2) jak i samego ejabberd (0.7.5). Skoro działało, to po co zmieniać. Jednak, gdy zaczęły się problemy, to aż głupio byłoby szukać supportu do takich wykopalisk. Postanowiłem więc zrobić upgrade, ale bałem się. Skok o kilka wersji przecież nie może przejść bezboleśnie.
Wczoraj wieczorem przygotowałem paczki PLD z najnowszym
Erlangiem i ejabberd. Poszło gładko, tylko
jeden mały patch był potrzebny. Ostatnim razem gdy próbowałem było gorzej,
w szczególności wychodziły jakieś problemy na AMD64. Dzisiaj postanowiłem te
nowe paczki zainstalować na serwerze. Przy okazji postanowiłem wypróbować
opcję --repackage RPMa, żeby mieć do czego wrócić, jak coś
pójdzie nie tak.
[root@serwus RPMS]# /etc/rc.d/init.d/ejabberd stop Stopping ejabberd service..........................................[ DONE ] [root@serwus RPMS]# rpm --repackage -Uvh erlang-R10B_7-0.1.amd64.rpm ejabberd-0.9.8-1.amd64.rpm Preparing... ########################################### [100%] Repackaging... 1:erlang ########################################### [ 50%] 2:ejabberd ########################################### [100%] Upgrading... 1:erlang ########################################### [ 50%] 2:ejabberd warning: /etc/jabber/ejabberd.cfg created as /etc/jabber/ejabberd.cfg.rpmnew ########################################### [100%] Updating component authentication secret in ejabberd config file... Generating erl authentication cookie... Run "/etc/rc.d/init.d/ejabberd start" to start ejabberd server. [root@serwus RPMS]# /etc/rc.d/init.d/ejabberd start Starting ejabberd service..........................................[ DONE ]
Niemożliwe. To nie mogło być takie proste. A jednak, wygląda na to, że działa. Hmmm...
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ć
i serial 0
.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.
Rano moje dziewczyny wyjechały na wakacje, więc ja zostałem słomianym wdowcem. Wdowieństwo zacząłem od sprzątania — skoro mam robić bajzel, to muszę mieć gdzie. Gdy mniej-więcej posprzątałem mieszkanie, to zjadłem śniadanie i poszedłem po zakupy. Jeszcze mi paru drobiazgów brakowało do dokończenia selwelka. Gorąco było — w mieście byłem właściwie w samo południe. Kupiłem co chciałem, a nawet coś więcej i wróciłem do domu, robić bajzel.
Bajzel był naprawdę niezły, ale po paru godzinach udało mi się złożyć serwerek do końca. Podłączyłem i nawet ruszył. Pojawił się problem: jak zainstalować na tym system nie mając ani stacji dyskietek ani CDROMu. Przekładać dysku mi się nie chciało. Właściwie, to nie chciało mi się nawet przepinać (tymczasowo) monitora i klawiatury, ale jednak ta maszynka za kilkaset złotych to nie Sun Fire za ponad dziesięć tysięcy i nie ma ułatwiaczy typu Sevice Processor, czy BIOS na konsoli szeregowej. Postanowiłem przez sieć zabootować system z którego zainstaluje sobie PLD. Do setupu BIOSu musiałem więc wejść chociażby po to, aby włączyć bootowanie z sieci. Niestety, musiałem monitor podłączać jeszcze kilka razy potem, żeby zobaczyć co się dzieje, jak nie chciało się bootować.
Pogooglałem za PXE PLD
i dowiedziałem się, że RescueCD obsługuje PXE. I nic więcej,
żadnej informacji jak to RescueCD z tego PXE wystartować. Poszukałem trochę ogólniej i znalazłem
jakieś HOWTO do instalacji Debiana przez PXE. Zaczynając od tego artykułu, używając obrazów RescueCD
i LiveCD, metodą prób i błędów i z lekką pomocą autora RescueCD, w końcu udało mi się zabootować
system i rozpocząć instalację. Dalej było z górki, więc opiszę dokładniej (w kolejnym wpisie) tylko
jak wygląda bootowanie RescueCD przez sieć.
Jakiś czas temu zaproponowano mi pracę dla pewnego Holendra. Pierwszy mail od zleceniodawcy nie nastawiał optymistycznie. Jednak dostałem to zlecenie, wraz z widokami na następne. Chodzi o przygotowanie Linuksowego systemu dla pewnego urządzenia. Nieśmiało zasugerowałem, żeby to zrobić na PLD (w końcu to znam najlepiej, a i PLD ma parę zalet, które w takim zastosowaniu mogą mieć znaczenie), a Holender na to poszedł. PLD mnie nie zawiodło, a ja, jak na razie, nie zawiodłem zleceniodawcy. Podstawowy system bootuje się, nie tylko w QEMU, ale i na docelowym sprzęcie (z karty Compact Flash). Pierwsze zadanie zostało zaliczone, dostałem już dwa kolejne...
Układ jest bardzo wygodny. W uproszczeniu: zleceniodawca mówi co chce, ja ile mi to zajmie godzin roboczych. W ten sposób jest zadanie wycenione (ustalona stawka godzinowa). Jeśli wynik zadowala zleceniodawcę, to ja dostaję zaliczkę (połowa ustalonej kwoty), zaczynam robotę, a gdy skończę, to dostaję resztę. Jak napracuję się mniej niż zakładałem, to strata Holendra, jeśli więcej to moja. I właściwie dokładnie tak to działał w przypadku dwóch pierwszych zadań (postawienia systemu i doinstalowanie aplikacji). Trochę bardziej komplikuje się to w przypadku trzeciego zadania — konfiguracji serwerów Holendra...
No właśnie. Dostałem do administracji dwie maszyny. Z Debianem, którego nie znam
(no, do przedwczoraj nie znałem), skonfigurowane przez kogoś innego i z jakimiś
dziwnymi aplikacjami do skonfigurowania (GForge, OpenExchange). Tu nie jestem
w stanie stwierdzić ile mam roboty, póki się w to nie wgryzę. A wgryzanie się
robię aktywnie, od razu naprawiając co mi się nie podoba i próbując robić co
mam do zrobienia. Ale chyba jakoś się z wyceną dogadamy...
Mam trochę mieszane uczucia co do tej roboty. Cały czas przecież pracuje na pełny etat tam gdzie pracuję. Więc na robotę dla Holendra muszę poświęcić moje popołudnia, wieczory (kiepski ze mnie geek, do rana nie siedzę) i weekendy. Odbywa się to kosztem rodziny, moich opensourcowych projektów i innych rzeczy. Dwanaście godzin pracy dziennie to dla mnie trochę dużo i daje w kość. Ale gdy pieniądze wpływają na konto, to jest fajnie. I też pewną frajdę sprawia mi praca dla kogoś, kogo na oczy nie widziałem i pewnie nie zobaczę, kto jednak docenia moją pracę (w firmie, gdzie pracuję na stałe, coraz rzadziej to się zdarza) i do tego przyzwoicie (jak na nasze warunki) płaci. Podoba mi się też to, że robota te nie jest związana z jakimiś długoterminowymi zobowiązaniami. Mam coś do zrobienia, zrobię to w tydzień, czy dwa, a kolejnej roboty mogę po prostu nie wziąć.
Zaczynam też się zastanawiać, czy robota wolnego strzelca
na większą
skalę nie podobałaby mi się bardziej niż etat w jednej firmie. Konkretne
zlecenia, za które dostawałbym konkretne pieniądze (takie na jakie zapracuję),
a nie siedzenie przepisowych ośmiu godzin przy biurku, czasem nie wiadomo po
co, żeby zarobić tak sobie
, czasem nie wiadomo za co. No i nie musiałbym
słuchać poleceń szefa, ani szefowej (to ostatnie najbardziej kuszące). Ale
stała posada w jednym miejscu ma swoje zalety. Przede wszystkim robotę,
nawet jeśli durną, zapewnia szefostwo. Sam mógłbym sobie nie poradzić, w końcu
nie zawsze zleceniodawcy będą mi spadać z nieba jak ten Holender. No
i nie wiem, czy szukanie zleceniodawców i wszelkie związane z robotą
formalności nie dałyby mi bardziej w kość, niż obecna robota...
Wracam z pracy, zabieram się za odgrzewanie obiadu, a tu już telefon.
Jakiemuś ważnemu klientowi coś nie działa i trzeba to sprawdzić. Odpowiadam,
że za jakieś pół godziny sprawdzę. W końcu obiadek gotowy. Jem sobie, przy
laptopiku oczywiście, delektując się chwilą spokoju. Jednak nie długo. Dorwał
mnie ktoś na Jabberze i pisze, że ten BTS
z PLD (nad robieniem którego zarwałem kiedyś kilka nocy) w ogóle nie
działa
. Że jest do dupy, że
Bugzilla byłaby lepsza i po co w ogóle było coś innego tam pisać jak jest
gotowe rozwiązanie. Wrr....
Bugzilla była w PLD lata temu i nikt tego nie używał, bo toporne i zupełnie niedopasowane do czegoś takiego jak dystrybucja. Potem pojawił się jakiś nasz własny, prymitywny BTS. Ale nikt się nim nie zajmował, nie uaktualniał, aż wkońcu zaczął on zarzynać maszynę na której chodził i został wyłączony. Przez wiele tygodni w ogóle nie było gdzie zgłaszać błędów w PLD. Co jakiś czas pojawiała się na ten temat dyskusja, z której nic nie wynikało (poza tym, że wielu developerów nie chce Bugzilli). W końcu nie wytrzymałem i mimo, że nie mam dość wolnego czasu, postanowiłem coś zrobić. Wziąłem Flyspraya, poprzerabiałem, żeby pasowało do dystrybucji i było nieco bardziej zgodne ze standardami. Uruchomiłem tak, aby działały podstawowe funkcje, a kod wrzuciłem do SVN. Tyle byłem w stanie zrobić i to było dużo więcej niż ktokolwiek zrobił w tej sprawie. Przekonałem się przy okazji, że kod Flyspraya jest straszny, że słusznie PHP nie lubię. Wiedziałem, że to co zrobiłem jest pełne niedoróbek, i że ja ich raczej nie poprawię. Ale uznałem że to lepsze niż nic. I nawet ludzie zaczęli z tego korzystać — pojawiły się nowe zgłoszenia błędów, niestety mało kto je próbował zamykać.
A teraz czytam, że to co zrobiłem jest do niczego. I to jeszcze w momencie, gdy chcę po prostu odpocząć po ciężkim tygodniu pracy, a nie jakiś pluskw szukać. Człowiekowi się wszystkiego w takiej chwili odechciewa, ale z drugiej strony jedyny sposób, żeby odeprzeć zarzut to przynajmniej znaleźć błąd będący źródłem tej opinii i go poprawić (potem można rzucić projekt w cholerę, skoro jest do niczego i wszyscy mają to w dupie). Okazało się, że błąd występował gdy ktoś zgłaszał buga bez podania wersji błędnego pakietu. Zamiast odpowiedniego komunikatu generowany był nieprawidłowy kod XHTML. Mozilla wyświetlała odpowiednią informację, że XML nie jest well-formed, a Konqueror, podobno, nie wyświetlał nic. Poprawiłem, co miałem robić? A tak... odpocząć po ciężkim tygodniu... eh... Następnym razem jak będzie coś podobnego do zrobienia, to chyba ja się do tego nie zgłoszę, szkoda nerwów.
![[szpieg]](http://stats.jajcus.net/record.png?site=jogger_jajcus&page=index)
Jesteście obserwowani...