In English

    Tips & Tricks II

    Note to myself.

    Thanks to morr from #netbsd.pl who pointed me to this.

    How many times You forgot to notice after installing package what was in MESSAGE file?

    How many MESSAGES information You miss while upgreading lots of packages?

    Of course You can always revive it by pkg_info -D package_name, but there is simply yet brilliant way to have MESSAGE info in mail.

    Just add to /etc/mk.conf

    PKGSRC_MESSAGE_RECIPIENTS?=login or mail adress

    and when package have something to say in MESSAGE You have it on Your mail :)

    Read /usr/pkgsrc/mk/defaults/mk.conf for details.

    Job / Praca

    Update NetBSD do wersji 4.0_STABLE

    W końcu przyszedł czas aby się ustabilizować. W tym krótkim howto postaram się dość szczegółowo opisać jak to wykonać i nie strzelić sobie w stopę a jak już się strzeli jak się połatać.

    W moim przypadku upgrade był przeprowadzony z systemu z gałęzi -current do -stable a konkretnie z 4.99.32 do 4.0_STABLE.

    Zaczynamy od ściągnięcia źródeł systemu odpowiedniej gałęzi.

    Wchodzimy do /usr

    cd /usr/

    Ustawiamy w jaki sposób będziemy łączyć się z serwerem cvs

    setenv CVS_RSH ssh
    setenv CVSROOT :ext:anoncvs@anoncvs.NetBSD.org:/cvsroot

    I ściągamy (w katalogu /usr!) źródła

    cvs checkout -r netbsd-4 -P src

    jeśli pominiemy -r netbsd-4 ściągniemy gałąź -current, możemy się także cofnąć do netbsd-3 (nie polecane :). Po całej operacji mniej lub bardziej czasochłonnej w katalogu /usr/src będziemy mieli wszystkie źródła potrzebne do budowy systemu. Jeśli masz kiepskie połączenie z Internetem możemy dodać po cvs flagę -zx gdzie x to liczba od 1 do 9 określająca stopień kompresji. Pamiętać należy jednak, że kompresja po stronie serwera dość poważnie go obciąża.

    Możemy sprawdzić czy ściągnęliśmy dobrą wersję wykonując skrypt osrelease.sh w katalogu /usr/src/sys/conf/

    cd /usr/src/sys/conf/
    sh osrelease.sh
    4.0_STABLE

    Wszystko gra.

    Teraz musimy przygotować katalogi do budowy systemu, /usr/tools i /usr/obj są obligatoryjne i kiedy ich nie ma budowa systemu nie zostanie przeprowadzona, build.sh powinien je stworzyć ale dla pewności lepiej zadbać aby były dostępne dla systemu. katalog gdzie faktycznie będą przechowywane setsy po budowie jest dowolny w moim przypadku nazywa się tak jak wersja NetBSD – /usr/4.0_STABLE

    mkdir /usr/tools /usr/obj /usr/4.0_STABLE

    Teraz zbudujemy sobie toolsy czyli narzędzia do budowy NetBSD. build.sh jest oczywiście na tyle sprytny, że sprawdza czy w systemie są odpowiednie narzędzia i jeśli ich nie ma to je buduje i korzysta z nowych, ale oczywiście na tym etapie mogą także pojawić się nieprzewidywane trudności więc dla pewności wskażemy konkretny katalog i powiemy co build.sh ma budować:

    cd /usr/src/
    ./build.sh -T /usr/tools/ tools

    Zależnie od szybkości naszej maszyny, może to potrwać od kilku minut to kilku godzin.

    U mnie na p3 500 Mhz i 256 Mb ram toolsy jak widać budowały się godzinę z kilkoma minutami.

    ===> Tools built to /usr/tools
    ===> build.sh ended: Fri Dec 21 15:04:39 CET 2007
    ===> Summary of results:
    build.sh command: ./build.sh -T /usr/tools/ tools
    build.sh started: Fri Dec 21 13:58:46 CET 2007
    NetBSD version: 4.0_STABLE
    MACHINE: i386
    MACHINE_ARCH: i386
    Build platform: NetBSD 4.99.32 i386
    HOST_SH: /bin/sh
    No /usr/tools/bin/nbmake, needs building.
    Bootstrapping nbmake
    TOOLDIR path: /usr/tools
    DESTDIR path: /usr/src/destdir.i386
    RELEASEDIR path: /usr/src/releasedir
    Created /usr/tools/bin/nbmake
    makewrapper: /usr/tools/bin/nbmake-i386
    Updated /usr/tools/bin/nbmake-i386
    Tools built to /usr/tools
    build.sh ended: Fri Dec 21 15:04:39 CET 2007
    ===> .

    Po wybudowaniu toolsów możemy zbudować sobie system:

    ./build.sh -D /usr/4.0_STABLE -O /usr/obj -T /usr/tools -u build

    ===> Successful make build
    ===> build.sh ended: Fri Dec 21 21:53:03 CET 2007
    ===> Summary of results:
    build.sh command: ./build.sh -D /usr/4.0_STABLE -O /usr/obj -T /usr/tools -u build
    build.sh started: Fri Dec 21 15:07:38 CET 2007
    NetBSD version: 4.0_STABLE
    MACHINE: i386
    MACHINE_ARCH: i386
    Build platform: NetBSD 4.99.32 i386
    HOST_SH: /bin/sh
    TOOLDIR path: /usr/tools
    DESTDIR path: /usr/4.0_STABLE
    RELEASEDIR path: /usr/obj/releasedir
    makewrapper: /usr/tools/bin/nbmake-i386
    Updated /usr/tools/bin/nbmake-i386
    Successful make build
    build.sh ended: Fri Dec 21 21:53:03 CET 2007
    ===> .

    A po wybudowaniu systemu potrzebujemy jeszcze kernel zgodny z wersją naszego NetBSD który będziemy instalować. Najlepiej jest zbudować oczywiście GENERIC, ale możemy oczywiście go trochę zmodyfikować (np. poprzez dodanie PF który nie jest domyślnie kompilowany)

    vim sys/arch/i386/conf/GENERIC
    (oczywiście dla innych architektur trzeba zmienić katalog określający architekturę np amd64, sparc, sparc64 itp.)

    Kernel możemy wybudować następnie tak jak stara szkoła karze, poprzez config, make depend, make, make install, ale build.sh również pozwala nam go budować więc użyję właśnie tego narzędzia:

    ./build.sh -O /usr/obj -T /usr/tools -u kernel=GENERIC
    ===> Kernels built from GENERIC:
    /usr/obj/sys/arch/i386/compile/GENERIC/netbsd
    ===> build.sh ended: Fri Dec 21 23:00:27 CET 2007
    ===> Summary of results:
    build.sh command: ./build.sh -O /usr/obj -T /usr/tools -u kernel=GENERIC
    build.sh started: Fri Dec 21 21:58:15 CET 2007
    NetBSD version: 4.0_STABLE
    MACHINE: i386
    MACHINE_ARCH: i386
    Build platform: NetBSD 4.99.32 i386
    HOST_SH: /bin/sh
    TOOLDIR path: /usr/tools
    DESTDIR path: /usr/obj/destdir.i386
    RELEASEDIR path: /usr/obj/releasedir
    makewrapper: /usr/tools/bin/nbmake-i386
    Updated /usr/tools/bin/nbmake-i386
    Building kernel without building new tools
    Building kernel: GENERIC
    Build directory: /usr/obj/sys/arch/i386/compile/GENERIC
    Kernels built from GENERIC:
    /usr/obj/sys/arch/i386/compile/GENERIC/netbsd
    build.sh ended: Fri Dec 21 23:00:27 CET 2007
    ===> .

    Po wybudowaniu kernela musimy jeszcze tylko go podmienić backupując nasz stary (i działający ! ;) kernel.

    mv /netbsd /onetbsd3
    mv /usr/obj/sys/arch/i386/compile/GENERIC/netbsd /

    Teraz jesteśmy gotowi na reboot i sprawdzenie czy nowy kernel podniesie nam system (błędami przy starcie usług na razie się nie przejmujemy)

    Pamiętaj, rebootuj system poprzez shutdown -r now a nie reboot, ponieważ shutdown prawidłowo stopuje usługi z /etc/rc.conf

    System wstał (mam nadzieję, że u Ciebie też :). Większość usług u mnie nie odpaliło się, ale np NAT z PF działał. Możemy więc zainstalować nowy system:

    ./build.sh -D /usr/4.0_STABLE -O /usr/obj -T /usr/tools -u install=/

    make installworld started at: Fri Dec 28 10:12:33 CET 2007
    make installworld finished at: Fri Dec 28 10:17:43 CET 2007
    ===> Successful installworld to /
    ===> build.sh ended: Fri Dec 28 10:17:44 CET 2007
    ===> Summary of results:
    build.sh command: ./build.sh -D /usr/4.0_STABLE/ -O /usr/obj -T /usr/tools -u install=/
    build.sh started: Fri Dec 28 10:12:29 CET 2007
    NetBSD version: 4.0_STABLE
    MACHINE: i386
    MACHINE_ARCH: i386
    Build platform: NetBSD 4.0_STABLE i386
    HOST_SH: /bin/sh
    TOOLDIR path: /usr/tools
    DESTDIR path: /usr/4.0_STABLE
    RELEASEDIR path: /usr/obj/releasedir
    makewrapper: /usr/tools/bin/nbmake-i386
    Updated /usr/tools/bin/nbmake-i386
    Successful installworld to /
    build.sh ended: Fri Dec 28 10:17:44 CET 2007
    ===> .

    Została jeszcze jedna rzecz, należy przeprowadzić update plików konfiguracyjnych, wydajemy polecenie etcupdate i uważnie (bardzo!) sprawdzamy o co nas pyta system. Polecam przekopiowanie /etc w bezpieczne miejsce! Mamy do wyboru kilka opcji przy każdym pliku. Najwazniejsze do i – install i d – don’t install. Wszystkie pliki, w których nie przeprwadzaliśmy zmian możemy śmiało zainstalować, tak samo wszystkie pliki które oznaczone są jako missing. Należy zwrócić szczególną uwagę na pliki z uzytkownikami i grupami, ponieważ jeśli nie opacznie damy install to zostaną zainstalowane czyste pliki tak jak po świeżej instalacji i nie będziemy mogli się zalogować ponieważ nasz uzytkownik nie będzie istniał.

    etcupdate

    Po etc update przeleci postinstall i powie co się udało a co nie i podpowie jakie komendy należy uruchomić aby pozbyć się niepotzrebnych rzeczy typu obsolete.

    Po zakończonej operacji dajemy shutdown -r now i teoretycznie wszystko powinno działać. Teoria jednak mija się z praktyką i np u mnie wymagane było przeinstalowanie niektórych aplikacji (perl, mysql). To jest jednak dosyć proste do wykonania gorzej kiedy po etcupdate dostajemy błąd, że nie odnaleziono libc.so.12 co skutkuje brakiem możliwości zrobienia czegokolwiek łącznie z zalogowaniem się lub chociażby ls. A po restarcie dostajemy kernel pannic z powodu init died…

    man init nie podaje nam wesołych wiadomości:

    The role of init is so critical that if it dies, the system will reboot
    itself automatically. If, at bootstrap time, the init process cannot be
    located, the system will panic with the message ``panic: init died
    (signal %d, exit %d)''.

    Powodem tego jest to, że kernel przy starcie zna jedynie partycję / i w pierwszej kolejności odpala init który dalej inicjuje pozostałe partycje, i odpala skrytpty rc.d. Z koleii init do działania potzrebule /lib/lib.co.12 oraz /libexec/ld.elf_so. Jeśli z jakichś powodów nie może ich zlokalizować dostejemy init died. Plik /lib/lib.co.12 jest linkiem do innego pliku:

    lrwxr-xr-x 1 root wheel 14 Dec 21 15:53 libc.so.12 -> libc.so.12.149

    Ja upgreadując z gałęzi -current miałem zamiast libc.so.12.149 plik libc.so.12.150, a libc.so.12 nie zlinkował się prawidłowo z plikiem od 4.0 stąd problem.

    Najprostrzym rozwiązaniem tego problemu jest wybootowanie z płyty instalacyjnej NetBSD i z menu narzędziowego uruchomienie /bin/sh, nastepnie podmontowanie / i stworzenie właściwego linku, lub też oprócz podmontowania / podmontowanie /usr (jeśli jest na innej partycji) i przekopiowanie całego /usr/4.0_STABLE/lib na miejsce /lib. Po takim zabiegu system wstał bez żadnego problemu.

    Koniec stabilizacji, all done, bye bye ;)



    Job / Praca

    NetBSD 4.0 RELEASE

    OSowy prezent gwiazdkowy – NetBSD 4.0 po roku a może i więcej przygotowań, po dwóch BETACH, pięciu Release Candidatach w końcu jest Release :) Jedna z tych rzeczy którą w swojej monotonii i powtarzalności (kila serwerów do upgread’u) bardzo lubię. Co do nowości to przede wszystkim PF+ALTQ natywnie bez LKMów czy patchy. Protokół CARP z OpenBSD czyli redundantne rutery :) Oczywiście obsługa nowego sprzętu, obsługa Bluetooth i NDIS (to bardziej na desktop).



    In English

    Tips & Tricks

    Note to myself.
    I found that my /var/amavis/tmp has thousends of files.

    du -sg tmp/
    26 tmp/

    Actually 26Gb of crap. Now, how to delete all files excluding these with current date and one day before?

    Here is one line magic spell:

    find /var/amavis/tmp -type f -mtime +1 -exec rm -f {} \;

    Results?

    du -sm tmp/
    9 tmp/

    Bingo! ;)
    Thx to aniou #netbsd.pl



    Job / Praca

    Kup 4, jeden dostaniesz gratis?

    Dzisiaj na biurku wylądował nowiutki Proliant 380 G5, po upgrade’dzie RAMU i dysków wygląda tak:

    Proliant 380 G5

    Zbliżenie na to co ważniejsze w dalszej części wpisu:

    Dyski

    Pomijając, że serwery HP są zajeb**** zwłaszcza przez ILO, ten egzemplarz oferował coś gratis :)

    Otóż, fizycznie są 4 dyski SAS (2x 74GB i 2x 146GB). Kontroler RAID widzi *cztery* dyski z których można zbudować różne macierze. Natomiast NetBSD (4.99.34) w sysinstall’u pokazuje co następuje:

    Dyski w sysinstall

    Dla mniej spostrzegawczych:

    Dyski zbliżenie

    Tak, 5 dysków! Przyznam, że odpaliłem będąc już w kurtce i jedną nogą za firmą, i wyjaśnienie może być banalne (1 dysk wewnątrz, ale z tego co wiem to nie ma w serwerach hotswapowych dysku w środku obudowy), niemniej jednak bardzo mnie ciekawi dlaczego NetBSD widzi 5 dysków. Jutro zgłębię temat :)



    Job / Praca

    Raidframe a wydajność

    Akurat mam komputer, na którym musi ze względów oszczędnościowych być RAIDFrame. Postanowiłem porównać wydajność w kompilowaniu kernela na różnych wersjach jądra i na pojedynczym dysku oraz RAIDFrame. Komputer to – dmesg

    Oto wyniki kompilowania kernela GENERIC.MP:

    KERNEL GENERIC (1 CPU) na wd0 (jeden dysk)
    build.sh started: Fri Aug 10 10:18:20 UTC 2007
    build.sh ended: Fri Aug 10 10:29:27 UTC 2007
    Łączny czas: 11:07

    KERNEL GENERIC.MP (2 CPU) na wd0 (jeden dysk)
    build.sh started: Fri Aug 10 11:01:50 UTC 2007
    build.sh ended: Fri Aug 10 11:13:34 UTC 2007
    Łączny czas: 11:43

    KERNEL GENERIC.MP (2 CPU) na raid0 (mirror wd0 i wd1)
    build.sh started: Mon Aug 13 14:17:58 UTC 2007
    build.sh ended: Mon Aug 13 14:29:42 UTC 2007
    Łączny czas: 11:44

    Jak widać różnice są praktycznie żadne przy GENERIC.MP, trochę może dziwić 40 sekundowe przyśpieszenie na pojedyńczym procesorze, ale należy pamiętać że p4 z HTT to tylko emulacja drugiego procesora i w niektórych sytuacjach korzystniej wyłączyć HT w biosie. Zapewne wzrost wydajności byłby widoczny kiedy uruchomiłoby się więcej niż jedna kompilacja na raz. Dla mnie najważniejsze jednak jest to że RAIDFrame sprawuje się naprawdę nieźle nie licząc fatalnego instalowania go (dlaczego nie ma w sysinstallu?!) i dość długiego czasu rekonstrukcji macierzy – podstawowy zainstalowany system i src zabrało półtora godziny aby uzyskać:

    # raidctl -S raid0
    Reconstruction is 100% complete.
    Parity Re-write is 100% complete.
    Copyback is 100% complete.

    Natomiast narzędzie raidctl bardzoi fajnie działa i podaje dużo przydatnych informacji:

    # raidctl -s -v raid0
    Components:
    /dev/wd0a: optimal
    /dev/wd1a: optimal
    No spares.
    Component label for /dev/wd0a:
    Row: 0, Column: 0, Num Rows: 1, Num Columns: 2
    Version: 2, Serial Number: 2007081401, Mod Counter: 91
    Clean: No, Status: 0
    sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
    Queue size: 100, blocksize: 512, numBlocks: 488396928
    RAID Level: 1
    Autoconfig: Yes
    Root partition: Yes
    Last configured as: raid0
    Component label for /dev/wd1a:
    Row: 0, Column: 1, Num Rows: 1, Num Columns: 2
    Version: 2, Serial Number: 2007081401, Mod Counter: 91
    Clean: No, Status: 0
    sectPerSU: 128, SUsPerPU: 1, SUsPerRU: 1
    Queue size: 100, blocksize: 512, numBlocks: 488396928
    RAID Level: 1
    Autoconfig: Yes
    Root partition: Yes
    Last configured as: raid0
    Parity status: clean
    Reconstruction is 100% complete.
    Parity Re-write is 100% complete.
    Copyback is 100% complete.

    Pomijając wady związane z implementacją to praktycznie zerowym kosztem posiadamy w pełni funkjonalny RAID 1 odporny na awarię jednego dysku (można oczywiście dołożyć kolejne dyski i wtedy bezpieczeństwo wzrasta), można łatwo sprawdzić wypinając jeden dysk, uruchomić system, touch plik, zamknąć ssytem, podłączyć drugi dysk, wybootować, zamknąć, odłączyć drugi dysk, wybootować i stworzony plik powinien być na swoim miejscu :)

    Instalacja RAIDFrame: http://netbsd.org/docs/guide/en/chap-rf.html

    Wielkie podziękowania dla lamy z #netbsd.pl za pomoc – czekam na liveCD :)

    Fun

    How Lucky(?) I Am ;)

    So, there is this regexp (in bash) [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo „Still alive”

    I survived 4 times, wanna try ? :)

    If You cannot see what’s on the movie – here is what it looks like:

    bash-3.2# [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "Still alive"
    Still alive
    bash-3.2# [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "Still alive"
    Still alive
    bash-3.2# [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "Still alive"
    Still alive
    bash-3.2# [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "Still alive"
    the end :/
    rm: /usr/home: Device busy
    rm: /usr: Device busy
    rm: /var: Device busy
    rm: /kern/boottime: Read-only file system
    rm: /kern/copyright: Read-only file system
    rm: /kern/hostname: Read-only file system
    rm: /kern/hz: Read-only file system
    rm: /kern/loadavg: Read-only file system
    rm: /kern/msgbuf: Read-only file system
    rm: /kern/pagesize: Read-only file system
    rm: /kern/physmem: Read-only file system
    rm: /kern/rootdev: Read-only file system
    rm: /kern/time: Read-only file system
    rm: /kern/version: Read-only file system
    rm: /kern: Device busy
    rm: /: Device busy
    Still alive
    bash-3.2# the end :/
    bash: the: command not found
    bash-3.2# ls
    bash: ls: command not found
    bash-3.2# cd /
    bash-3.2# ls
    bash: ls: command not found
    bash-3.2#

    NetBSD

    Szpec od SMP w Fundacji NetBSD!

    Przeklejam całość z netbsd.pl ponieważ jest mojego autorstwa :)

    Fundacja NetBSD zatrudniła specjalistę od SMP
    Andrew Doran będzie pracował na pełen etat

    Angaż był możliwy za sprawą dotacji od Force10 Networks.

    Andrew Doran jest niezależnym ekspertem UNIXowym mieszkajacym na stałe w Dublinie. W kręgu jego zainteresowań leży przede wszystkim budowa skalowalnych systemów operacyjnych. Andrew był developerem NetBSD od 1999 roku. Teraz dzięki jego pracy NetBSD będzie przygotowane na wielojajeczne ;) procesory jutra.

    Szczegóły po angielsku w notce prasowej – http://netbsd.org/foundation/press/hiring-ad.html

    No to się dużo będzie działo w SMP w -current, yupi!

    P.S. Przy okazji wymyślania tytułu do newsa powyżej padła propozycja (nawiązująca do wcześniejszego newsa) – „Theo martwi się stanem procesorów Core2Duo a NetBSD opanowuje wielojajeczne procesory jutra”. Prawda, że śliczne ? :)

    P.S.2 Jeśli nie wiesz co to NetBSD, Theo, Core2Duo i wielojajeczny procesor to nie pisz w komentarzach, że bezsensu ;)

    Job / Praca

    dziwny mk.conf

    sami zobaczcie co się stało:

    ./usr/home/cancer/public_html/flo/horde-3.0.4/lib/
    Horde/DataTree/null.php^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@0100644^
    @0001750^@0000000^
    @00000020777^@10632233431^@0026175^@0^@^@^@^@^@^@^@^@^@
    ^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@ustar ^@cancer^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@wheel^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
    ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
    ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
    ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
    @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
    ^@^@

    A stało sie po spakowaniu /etc i innych katalogów z jednej maszyny i przezuceniu ich przez nfs na drugą.

    Teraz pytanie - z którym dyskiem zaczyna się dziać coś złego? czy to tylko wypadek tar'a przy pracy?

    Related Posts with Thumbnails
    Add your widget here