Adam Kucza

Zapewne znane jest Wam potężne narzędzie VirtualBox, dzięki któremu można uruchamiać aplikacje i programy na innych systemach operacyjnych aniżeli bieżącym.

Naszło mnie ostatnio na uruchomienie wielu instancji VBOX przy czym każda z nich posiada inną dystrybucję Linux/Unix (oczywiście OpenSource/GNU).
Kiedyś, gdy VBOX było niezależnym narzędziem (nie ze stajni Oracle), w sieci dostępne były na tyle proste dystrybucje systemów OpenSource, że po czystej instalacji sterowniki do kart graficznych automatycznie konfigurowały i ustawiały największą rozdzielczość uzależnioną od przydzielonej w VirtualBoxie pamięci grafiki (tak przynajmniej było u mnie).
Natomiast obecnie po czystej instalacji systemu np. Ubuntu dostaje się dość małe okienko (800×600px) z defaulta.

Problem pojawia się w momencie gdy chcemy zwiększyć rozmiar tego okienka i jednocześnie zyskać nieco na wolnej przestrzeni pulpitu.

Oczywiście zaglądamy do ustawień Ubuntu:

System -> Preferencje -> Monitory

lecz niestety mamy słabe możliwości:

- 800×600 (4:3)
- 640×480 (4:3)

Pomyślałem sobie: aha, dałem za mało pamięci Video dla instancji VBOXa. W starszych wersjach VBOXa i Linux/Unix im więcej pamięci przydzielałem, tym większą rozdzielczość mogłem ustawić w VirtualBox (testowałem na sławnym Redhat Manhattan).
Jednak w moim obecnym przypadku gdy dałem 512MB dla grafiki VBOX, nadal nie mogłem zwiększyć rozdzielczości w wirtualce Ubuntu 11.04.
W Windows mając tyle pamięci video można spokojnie ustawić przynajmniej 1600×1200px.
Poszperałem trochę w Google i okazało się, że od którejś wersji VBOX ma takie cudo jak:

VBoxGuestAdditions.iso (43,37 MB)

Jeśli chcemy zwiększyć rozdziałkę w wirtualce należy zainstalować dodatki VirtualBox (dostępny razem z Oracle VirtualBox).
Jednak zanim zamontujemy dodatki powinniśmy przygotować system do tego – w Ubuntu z poziomu konsoli instalujemy pakiet DKMS:

sudo apt-get install dkms

Gdy zapytaj o hasło, podajemy hasło SuperUsera (tj. root’a).
Następnie montujemy ISO bezpośrednio w VBOX:

menu: Urządzenia -> Zainstaluj Dodatki (Guest Additions)

Ubuntu powinien wykryć nośnik automatycznie i wyświetlić okienko z pytaniem o uruchomienie.
Intuicyjnie wybieramy odpowiedzi twierdzące i po chwili Additions są już zainstalowane (konfigurowane są moduły kernela odpowiedzialne m.in. za resolution).
Jeśli nie uda się jakoś automatycznie tego zainstalować, to w konsoli można uruchomić jako root oczywiście znajdując się w katalogu głównym zamontowanego ISO:

sudo sh ./VBoxLinuxAdditions.run

Do pełni szczęścia potrzebny jest reset instancji wirtualki poprzez restart Ubuntu (z ikonek systemowych wystarczy).

Powyższe czynności instalują w instancji rozszerzone sterowniki m.in. grafiki dające więcej możliwości, np. możliwość zmiany rozdzielczości pulpitu naszej wirtualki.
W moim przykładzie – Ubuntu 11.04 Niebiańska Nimfa – od razu po restarcie miałem duże okno z wirtualką (ustawiona była od razu rozdzielczość maksymalna z możliwych, np. 1440×1050px).

Więcej informacji znajdziecie na stronie manuala do VirtualBox: .

Po zainstalowaniu czyściutkiego nowego systemu FreeBSD 8.0-RELEASE, pracując już po SSH (putty) podczas instalowania odpowiednich portów (polecenie: make install clean), system zaczął się dziwnie i niestabilnie zachowywać. Skutkiem niestabilności były restarty systemu w zasadzie z niewyjaśnionych przyczyn.
Przykład: port się kompiluje i nagle restart, putty traci łączność z serwerem, ponownie zalogowanie do systemu, sprawdzenie uptime, gdzie z reguły było kilka sekund/minut. Na koniec dmesg, który potwierdzał restart serwera.
Po każdym restarcie szukałem informacji w logach (/var/run, /var/log). Jedynie co znajdywałem to informację o restarcie.
Ciekawostką było to, że restarty pojawiały się w dowolnym momencie i tylko podczas pracy dysku (read/write). A czasami w logach nie widać nieprawidłowej pracy dysków.
Nieufność do nowych dysków Caviara (tylko 320GB) pokierowały moją intuicją, aby sprawdzić logi S.M.A.R.T. (portem smartmontools). Ale niestety, niczego złego tam nie znalazłem (No Errors Logged).
Zmieniłem kable. Żadnych zmian. Podłączyłem monitor i… przy restartach miałem coś takiego:

Jan 19 09:13:41 fox syslogd: kernel boot file is /boot/kernel/kernel
Jan 19 09:13:41 fox kernel: dev = ad0s1f, block = 1, fs = /usr
Jan 19 09:13:41 fox kernel: panic: ffs_blkfree: freeing free block
Jan 19 09:13:41 fox kernel: cpuid = 0
Jan 19 09:13:41 fox kernel: Uptime: 44m25s
Jan 19 09:13:41 fox kernel: Cannot dump. No dump device defined.
Jan 19 09:13:41 fox kernel: Automatic reboot in 15 seconds – press a key on the console to abort
Jan 19 09:13:41 fox kernel: Rebooting…

Może powinienem ustawić inny poziom logowania demona syslogd? Może wtedy zobaczyłbym powyższe zapisy w logach?
Jednakże z powodu braku czasu zarzuciłem temat wyszukiwarce google.
Okazało się, że freeing free block podczas pracy systemu i dysku, to bug samego systemu, z którym już od kilku lat borykają się autorzy dystrybucji freeBSD.
Wg ich sugestii należało wyłączyć tzw. softupdates dla danego systemu plików (u mnie native freebsd –> ufs).
Podobno softupdates przyspiesza pracę na dysków zwalniając odpowiednie bloki (freeing free blocks) wg zaawansowanych algorytmów.
Sprawdziłem więc jak było u mnie:

fox# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)

Postanowiłem wyłączyć softupdates dla /usr, na którym występował problem.
Nie można tego było zrobić on-the-fly (podczas pracy systemu), ponieważ /usr była w użyciu, a fix można wykonać tylko i wyłącznie na odmontowanej partycji. Jedyna droga to boot‘owanie systemu w trybie Single user mode.
Polecenie

#tunefs -n disable /usr

wyłącza softupdates na /usr.
Jeszcze szybko sprawdziłem aktualny stan ustawień systemu plików

fox# mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local)
/dev/ad0s1d on /var (ufs, local, soft-updates)

i reboot.
Jakoś do dzisiaj nie widać wyraźnego spadku wydajności pracy dysku po wyłączeniu softupdates.
Ważniejszym jest, że restartów już nie ma. Nic tylko się cieszyć.
Jako ciekawostkę mogę dodać, iż serwerów freeBSD postawiłem już całkiem sporo, a taki przypadek pojawił się po raz pierwszy.
Może to jednak ten Caviar? Może powinienem wybrać Seagate albo Maxtor?

p.s. polecam też HandBook‘a freeBSD o Tuning Disks: http://www.freebsd.org/doc/handbook/configtuning-disk.html

Dobry administrator zawsze i dokładnie czyta logi, z akcentem na dokładnie .

Kilka dni temu miałem dość ciekawy przypadek automatycznego restartu serwera na skutek wykonywania prostych poleceń, np. find lub locate.
Co ciekawsze, serwer “wywalał” się zawsze na tym samym katalogu. Z początku myślałem, że to wina usługi samba i udostępnionych plików/katalogów, jednak po wnikliwym wczytaniu się w logi systemowe, przekonałem się, że byłem w błędzie.

Błąd był widoczny już w samym dmesg (logi systemowe)

/dev/ad0s1: bad dir usr 25789343 AT OFFSET 1024: MANGLED ENTRY
panic: ufs_dirbad: bad dir

Z tego wynika, że mamy do czynienia z wadliwym katalogiem usr.

Niby prosta rzecz, wchodzimy do single user mode (wtedy dyski/partycje nie są zamontowane).
Sprawdzamy tzw. mount point poleceniem

cat /etc/fstab

i traktujemy zamontowaną etykietkę (label) jako katalog /usr poleceniem fsck

# fsck -y /dev/ad0s1f

(u mnie /usr jest zamontowany jako ad0s1f).

Na koniec skanowania powinno nam się wyświetlić

***** FILE SYSTEM MARKED CLEAN *****

Po ponownym uruchomieniu serwera sprawdzamy czy wszystko jest OK przykładowymi poleceniami

# find / -type d -exec ls -ld {} ;
# find / -type d -exec stat {} ;
# find / -type d -exec touch {}/mydummyfilenamewhichshouldnotexist ;

Najwyraźniej fsck nie poradziło sobie z tym dziwnym przypadkiem, ponieważ freeBSD nadal się restartuje (panic) podczas wykonywania powyższych testów.

Na szczęście jest sposób aby to naprawić, ale może wystąpić sytuacja, że z uszkodzonego katalogu nie odzyskamy danych, aczkolwiek bądźmy dobrej myśli i miejmy pewność, że mamy zrobioną wcześniej kopię zapasową tych danych. Istotą rozwiązania problemu jest naprawienie systemu plików i wyeliminowanie samoistnych restartów systemu freeBSD.

Będąc ponownie w trybie single user mode uruchamiamy narzędzie fsdb (FileSystem DeBugger)

# fsdb /dev/ad0s1f
** /dev/ad0s1f
Editing file system ‘/dev/ad0s1f’
Last mounted on /mnt/ad0s1f
(…)
fsdb (inum: 2)>

Teraz wpisujemy numer tzw. inode, który bierzemy z loga (u mnie był to numer 25789343)

fsdb (inum: 2)> inode 25789343
current inode: directory
I= 25789343 MODE=40777 SIZE=1024
BTIME=May 9 12:52:12 2008 [0 nsec]
MTIME=May 9 12:52:12 2008 [0 nsec]
CTIME=May 9 12:52:12 2008 [0 nsec]
ATIME=May 9 12:52:12 2008 [0 nsec]
OWNER=root GRP=WHEEL LINKCNT=2 FLAGS=0 BLKCNT=4 GEN=157338b7
fsdb (inum: 25789343)>

Nawet gdy stracimy dane, będziemy mieli pewność, że problem zostanie usunięty.
Poleceniem clri debugując inode’a oznaczamy go jako błędny

fsdb (inum: 25789343)> clri 25789343

Wychodzimy z narzędzia debugowania.

fsdb (inum: 25789343)> quit

**** FILE SYSTEM STILL DIRTY *****
*** FILE SYSTEM MARKED DIRTY
*** BE SURE TO RUN FSDK TO CLEAN UP ANY DAMAGE
*** IF IT WAS MOUNTED, RE-MOUNT WITH -u -o reload

Będąc nadal w single user mode uruchamiamy ponownie fsck

# fsck -y /dev/ad0s1f

** /dev/ad0s1f
** Last Mounted on /usr
** Phase 1 – Check Blocks and Sizes
** Phase 2 – Check Pathnames
UNALLOCATED I= 25789343 OWNER=root MODE=0
SIZE=1024 MTIME May 9 12:52:12 2008
NAME=/_new2????

REMOVE=YES

** Phase 3 – Check Connectivity
** Phase 4 – Check Reference Counters
(…)

Podczas skanowania pojawiały się jeszcze inne różne błędy, które naprawiały się automatycznie dzięki parametrowi -y, np.

LINK COUNT DIR I=2 OWNER=root MODE=40777
SIZE=1024MTIME=May 9 12:52:12 2008 COUNT 21 SHOULD BE 20
ADJUST? yes
(…)
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
(…)
SUMMARY INFORMATION BAD
SAVLAGE? yes
(…)
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

Na końcu pojawił się komunikat

***** FILE SYSTEM MARKED CLEAN *****

***** FILE SYSTEM WAS MODIFIED *****

Ale czy to wszystko? Zdecydowanie tak.
W moim przypadku było dużo szczęścia i wszystkie dane były na swoim miejscu.
Po prostu fsck jakimś dziwnym trafem nie potrafił poradzić sobie z błędnym inode o numerze 25789343.
Oczywiście ponownie przetestowałem find’em czy przypadkiem coś jeszcze nie zostało do naprawienia. Tym razem wszystko było jak należy.
Jednak gdyby nadal były restarty typu panic: ufs_dirbad: bad dir, proponuję powyższe czynności powtórzyć dla każdego złego inode’a.

Pozdrawiam

Jakiś czas temu miałem przyjemność borykać się z dziwnym problemem pakietu AMaViS’a komunikującego się z Postfix’em na portach 10024 (nasłuchiwanie AMaViS’a) i 10025 (wysyłanie odpowiedzi do Postfix’a).

Przy uruchamianiu procesu amavisd pojawia się błąd:

fox# /usr/local/etc/rc.d/amavisd start
ERROR: MISSING REQUIRED BASIC MODULES:
IO::Wrap
IO::Stringy
Unix::Syslog
Compress::Zlib
MIME::Entity
MIME::Parser
Net::Server
Net::Server::PreFork
BEGIN failed–compilation aborted at /usr/local/sbin/amavisd line 232.

Dziwnym trafem (to zapewne sprawka upgrade’owania innych portów) brakuje kilku modułów Perl’a do prawidłowego funkcjonowania pakietu AMaViS.

By rozwiązać ten problem należy wejść do konsoli Perl’a poleceniem:

perl -MCPAN -e shell

i w CPAN’ie (konsola Perl’a) instalujemy brakujące moduły (z listy powyżej) zgodnie z poleceniem

install [nazwa modułu], np. install Net::Server

Po ponownym skompilowaniu brakujących modułów (startując amavisa można zweryfikować jakich jeszcze brakuje) sprawdzamy czy nasz proces działa:

fox# /usr/local/etc/rc.d/amavisd start
Starting amavisd.
Problem in Amavis::DKIM code: Can’t locate Crypt/OpenSSL/RSA.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9) at (eval 99) line 25.
BEGIN failed–compilation aborted at (eval 99) line 25.

Wydawać się mogło, że ponowna instalacja brakujących modułów rozwiąże problem, a tu jednak zonk.

Wobec powyższego wynika, że wsiąkł również specjalny moduł odpowiedzialny za realizację tzw. DomainKeys Identified Mail (DKIM).
Doinstalowujemy więc port

cd /usr/ports/
make search name=mail-DKIM
(…)
cd /usr/ports/mail/p5-Mail-DKIM
make install clean

I ponownie sprawdzamy czy amavisd działa

fox# /usr/local/etc/rc.d/amavisd start
Starting amavisd.
Problem in antispam SA code: Can’t locate Mail/SpamAssassin.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.9/BSDPAN /usr/local/lib/perl5/site_perl/5.8.9/mach /usr/local/lib/perl5/site_perl/5.8.9 /usr/local/lib/perl5/5.8.9/mach /usr/local/lib/perl5/5.8.9) at (eval 118) line 63.
BEGIN failed–compilation aborted at (eval 118) line 63.

Teraz łapiemy się za głowę, bowiem okazuje się, że brakuje SA (SpamAssasin’a).

Wchodzimy ponownie do konsoli Perl’a i instalujemy SA

perl -MCPAN -e shell
install Mail:SpamAssassin

Po instalacji SA uruchamiamy proces amavisd kolejny raz aby przekonać się czy jest już wszystko OK.

fox# /usr/local/etc/rc.d/amavisd start
Starting amavisd.

i sprawdzamy czy widać proces

fox# ps aux | grep amavisd
vscan 83335 3.1 3.5 79112 72304 ?? Ss 10:02AM 0:08.15 amavisd (master) (perl)
vscan 83351 0.7 3.6 82116 75068 ?? I 10:03AM 0:01.22 amavisd (ch1-avail) (perl)
vscan 83352 0.0 3.5 79744 72304 ?? I 10:03AM 0:00.03 amavisd (virgin child) (perl)
root 83359 0.0 0.0 1632 844 p0 RL+ 10:03AM 0:00.00 grep amavisd

fox# /usr/local/etc/rc.d/amavisd status
amavisd is running as pid 83335 83351 83352.

Hurra, jest sukces! Udało się! Ale… czy na pewno?
Proces działa, ale poczta nie zostaje dostarczona.

Patrzymy na logi Postfix’a

tail -f /var/log/maillog

i starając się wysłać dowolnego maila widzimy w logach następujące błędy

Oct 13 05:36:16 fox amavis[25159]: (25159-14) (!!)TROUBLE in check_mail: delivery-notification FAILED: temporarily unable to send DSN to : 450 4.4.1 Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=25159-14 at /usr/local/sbin/amavisd line 11386.
Oct 13 05:36:16 fox amavis[25159]: (25159-14) (!)PRESERVING EVIDENCE in /var/amavis/tmp/amavis-20091013T030230-25159
Oct 13 05:36:16 fox postfix/smtp[29075]: 5FF9B6D42B: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1689, delays=1683/0.01/0.01/5.9, dsn=4.5.0, status=deferred (host 127.0.0.1[127.0.0.1] said: 451 4.5.0 Error in processing, id=25159-14, delivery-notification FAILED: temporarily unable to send DSN to : 450 4.4.1 Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=25159-14 at /usr/local/sbin/amavisd line 11386. (in reply to end of DATA command))

Oct 13 06:05:14 fox amavis[28132]: (28132-10) (!)FWD via SMTP: -> , 450 4.4.1 Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=28132-10
Oct 13 06:05:14 fox amavis[28132]: (28132-10) Blocked MTA-BLOCKED, -> , Message-ID: <20091013002640.2B90C6D425@mail.kucza.info>, mail_id: i8vzB+cdas+V, Hits: -2.235, size: 7058466, 127353 ms
Oct 13 06:05:15 fox postfix/smtp[29514]: 2B90C6D425: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=21915, delays=21778/9.7/0.02/127, dsn=4.4.1, status=deferred (host 127.0.0.1[127.0.0.1] said: 450 4.4.1 id=28132-10 – Temporary MTA failure on relaying, Can’t connect to INET4 socket 127.0.0.1: Connection refused, MTA([127.0.0.1]:10025), id=28132-10 (in reply to end of DATA command))

Z powyższych błędów wynika, że jest jakiś problem przy połączeniu na porcie 10024.
Tutaj przyznam się bez bicia, że w configu Postfix’a zmieniłem wcześniej w celach testowych port z 10024 na 10025.

Aby nie mieszać, ustawienia plików konfiguracyjnych powinny być następujące

amavisd.conf

# Port na którym będzie nasłuchiwał AMaViS:
$inet_socket_port = 10024;
# Dopuszczaj połączenia jedynie poprzez lokalny adres IP:
@inet_acl = qw( 127.0.0.1 );

main.cf

# AMaViS
content_filter=smtp-amavis:[127.0.0.1]:10024

master.cf

smtp-amavis unix – - n – 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes

127.0.0.1:10025 inet n – n – - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000

Po doprowadzeniu konfiguracji pakietów Postfix + AMaViS do porządku, wszystko wróciło do normy

Oct 13 06:45:44 fox postfix/cleanup[83006]: 7DDC36D41B: message-id=<000d01ca6824$a61bc6b0$6400a8c0@morozov>
Oct 13 06:45:44 fox postfix/qmgr[38715]: 7DDC36D41B: from=, size=10257, nrcpt=1 (queue active)
Oct 13 06:45:44 fox amavis[80899]: (80899-04) (!!)WARN: all primary virus scanners failed, considering backups
Oct 13 06:45:49 fox postfix/smtpd[83003]: disconnect from unknown[113.169.91.43]
Oct 13 06:45:50 fox amavis[80899]: (80899-04) Blocked SPAM, [113.169.91.43] [113.169.91.43] -> , quarantine: spam-gAJtMJQua0NH.gz, Message-ID: <000d01ca6824$a61bc6b0$6400a8c0@morozov>, mail_id: gAJtMJQua0NH, Hits: 14.836, size: 10257, 11290 ms
Oct 13 06:45:50 fox postfix/smtp[83007]: 7DDC36D41B: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=13, delays=1.6/0/0.01/11, dsn=2.5.0, status=sent (250 2.5.0 Ok, id=80899-04, DISCARD(bounce.suppressed))
Oct 13 06:45:50 fox postfix/qmgr[38715]: 7DDC36D41B: removed
Oct 13 06:45:55 fox postfix/anvil[83004]: statistics: max connection rate 1/60s for (smtp:113.23.24.227) at Oct 13 06:45:44
Oct 13 06:45:55 fox postfix/anvil[83004]: statistics: max connection count 1 for (smtp:113.23.24.227) at Oct 13 06:45:44
Oct 13 06:45:51 fox postfix/anvil[83004]: statistics: max cache size 1 at Oct 13 06:45:44

Po takim długim leczeniu choroby nasuwa się myśl: uwaga na upgrade portów
3mam kciuki. Pozdrawiam.

Dzisiaj coś dla developerów HTML/JavaScript i języków webowych (np. JSP/ASP/PHP).
Może dla niektórych jest to prosta rzecz, aczkolwiek kilka dłuższych chwil zajęło mi rozwiązanie tego problemu, a mianowicie jak z button’a w HTMLu można utworzyć maila w stylu takim jak link mailto

a href=”mailto:info@smartlab.pl?subject=hello world&body=hello world again!” name=”link”

Sprawa okazuje się bardzo prosta i można to zrobić następująco

INPUT TYPE=”button” VALUE=”wyślij maila” onClick=”parent.location=’mailto:adres@domena.pl?subject=to jest tytuł maila&body=a to jest treść maila’”>

Wyjaśniając powyższy kod, należy w metodzie onClick użyć parent.location i przypisać temu to co chcieliśmy wywołać w href’ie.

Po aktualizacji Zend Guarda do nowszej wersji np. 5.0.1 i po przekompilowaniu projektu może pojawić się błąd o następującej treści:

Error: Fatal error: Incompatible file format: The encoded file has format major ID 3, whereas the Optimizer expects 2 in [nazwa_pliku] on line 0

Jednak nie każdy problem taki straszny na jakiego wygląda…

Wystarczy zaktualizować ZendOptimizer’a do wersji 3.3 i Zend Engine do wersji 2.2 i będzie po kłopocie.
Funkcja phpinfo() pomoże sprawdzić załadowaną wersję Zend Optimizer’a.

Skąd ściągnąć aktualizacje powyższych?
Sprawdź w Google.
Powodzenia.

Szczęśliwi posiadacze systemu Windows Vista pewnie nie raz natknęli się na problemy związane z prawidłowym startem systemu.
Przyczyn może być wiele. Moja sytuacja była dość śmieszna, wręcz głupia.
Przez przypadek wyłączyłem nogą UPSa, pod którego był podłączony calutki zestaw komputerowy.
Po włączeniu wszystkiego na ekranie miałem napis w stylu:

Booting ‘Windows Vista’
acpi
Vista Loader 2.1.2
Done!
fallback 1
find –set-root /bootmgr

Error 17: File not found
Booting ‘Windows NT/2000/XP’

fallback 2
find –set-root /ntldr

Error 17: File not found
Booting ‘Enter Command Line’

Boot failed! Press Enter to enter command line.

Są 3 możliwości.

1) reinstalacja całego systemu w płytki instalacyjnej (dla mniej zaawansowanych użytkowników)

2) uruchomienie systemu z płytki instalacyjnej i przejście do wiersza poleceń, gdzie możemy wykonać następujące czynności:

bootrec.exe /fixmbr
bootrec.exe /fixboot

lub jeśli to nie pomoże, to w ostateczności:

X:bootbootsect.exe /nt60 ALL /force

gdzie X, to litera dysku, na którym znajduje się instalacja Visty

inny sposób:

expand bootmgr temp
attrib bootmgr -s -r -h
del bootmgr
ren temp bootmgr
attrib bootmgr -a +s +r +h

W tym momencie stary bootmgr jest nadpisywany przez oryginalny z płytki instalacyjnej i możemy uruchomić nasz system bez żadnych problemów.
Trzeba jednak pamiętać, że bootmgr na płytce jest nieaktywowany, tzn. że po uruchomieniu systemu naszą Vistę należy ponownie aktywować.
W tym momencie przydałby się klucz licencji.

3) ręczne uruchomienie Visty za pomoca poleceń w GRUBie

title Load bootmgr [etykietka]
root (hd0,0) [definicja ścieżki głównej]
chainloader (hd0,0)/bootmgr [załadowanie boot managera]
boot [start bootowania systemu]

i też powinno zadziałać.

Powodzenia.

Postanowiłem wykonać przesiadkę z wersji 2.0.6 na 2.6.2 (duży, śmiały krok).

W pierwszej koleności ściągnąłem najnowszy pakiet WP ze strony autorów.
Następnie wykonałem kopie zapasowe plików poprzedniej wersji i bazy danych.
W zasadzie po wrzuceniu nowych plików do odpowiedniego katalogu WP, na stronie panelu admina WP pojawia się okienko do aktualizacji systemu (skrypt upgrade.php). Czyli wszystko jakby zgodnie z planem.
Po wykonaniu tej czynności przestała działać tylko jedna rzecz – kategorie.
Trochę czasu zajęło mi znalezienie przyczyny braku kategorii. Nie można było ani dodawać ani usuwać ani tym bardziej przydzielać wpisów.

Co się tak właściwie stało?

Otóż okazało się, że brakuje tabel z przedrostkiem wp_term:

wp_term_relationships
wp_term_taxonomy
wp_terms

Chciałem jednak, aby wszystko poszło z automatu, więc aby zachować wszystkie wpisy i strony (tego akurat upgrade nie ruszył i bardzo dobrze), musiałem wyedytować skrypt install.php (http://twoja-domena/wp-admin/install.php) i zakomentować jedną linijkę uruchamiającą funkcje sprawdzające czy WordPress jest już zainstalowany.

// Let’s check to make sure WP isn’t already installed.
if ( is_blog_installed() ) {display_header(); die(’<h1>'.__('Already Installed').'

'.__('You appear to have already installed WordPress. To reinstall please clear your old database tables first.').'

');}

Oczywiście uruchomił się instalator WordPress.
Poszło bez przeszkód w ułamku sekundy z zachowaniem starych tabel i danych (sprawdziłem).
Warto porównać jeszcze czy atrybuty pozostałych tabel są zgodne z tymi z instalatora, ale raczej powinno być wszystko tak jak trzeba.
Warto też odkomentować spowrotem powyższy kod.
Teraz już można się cieszyć funkcjonalnością Kategorii w wersji 2.6.2 WordPressa.

Ale nie ma róży bez kolców.

Nowy WP posiada nowe struktury kategorii i przypisanych do nich wpisów.
Niestety nie wpadłem jeszcze na inny pomysł jak tylko ponowne utworzenie hierarchii kategorii i przypisania wpisów do nich. Tym razem wszystko się zapisze do nowych brakujących wcześniej tabel.
Stara tabela o nazwie wp_categories jest w tym momencie historyczna.

Czasami bywają krytyczne sytuacje w kolejkami postfix’a. Pomocne są wtedy narzędzia będące elementami pakietu (portu) postfix’a. Nie trzeba więc niczego więcej instalować.

Narzędzia kolejek:

postqueue -p
wyświetla listę wszystkich wiadomości w kolejce

postsuper -d (Queue ID)
pozwala usuwać wiadomość z kolejki o danym ID

postsuper -d ALL
usuwa wszystkie wiadomości z kolejki

postsuper -h (Queue ID)
zatrzymanie wiadomośic w kolejce (kolejka hold)

postsuper -H (Queue ID)
przeniesienie wiadomości z powrotem do menadżera kolejek

postsuper -r ALL
zwraca wiadomości z powrotem do kolejki, wiadomości te otrzymują nowe identyfikatory i dodatkowy nagłówek Received

postcat -q
wyświetlanie zawartości pliku kolejki

postqueue -f
wypychanie wiadomości

postqueue -s domena.com
wypychanie wiadomości domeny domena.com

mailq -q /identyczne do sendmail -bp/
lista wiadomości w kolejce do obsłużenia

Bieżący podgląd zawartości loga postfix’a zapewnia polecenie:

tail -f /var/log/maillog

Ostatnie dwa polecenia są bardzo pomocne, jeśli chcemy ręcznie przyspieszyć obsługę kolejek (mailq -q) i jednocześnie przyjrzeć się czy faktycznie postfix coś z nimi robi (tail -f /var/log/maillog).

W sumie o takie czynności zawsze można poprosić administratora.

Aby nasze systemy i aplikacje działały prawidłowo lubimy je aktualizować do najnowszych wersji. Aczkolwiek są różne ’szkoły’: jedni aktualizują a drudzy podziwiają zalety ostatnich zainstalowanych wersji systemów serwerowych nietykając aktualizacji.

Należę do tej pierwszej grupy i zachęcam jednak do korzystania z wszelkich dostępnych aktualizacji istniejących w sieci.
Ale oczywiście wszystko z głową.

Ostatnio postanowiłem zaktualizować Perla do wersji 5.8.8 i dzięki temu przestał działać Openwebmail.
W logach webowego serwera apache widziałem tylko komunikaty typu:

Premature end of script headers: openwebmail.pl

Prawa dostępu do katalogu były ustawione prawidłowo, alias skryptowy CGI (ScriptAlias) również.
Pojawiła się więc zagadka.

Szukając odpowiedzi w sieci natrafiłem na ciekawą informację dotyczącą wykonywania skryptów CGI na serwerze apache:

The most common cause of this problem is the script dying before sending the complete set of headers, or possibly any at all, to the server. To see if this is the case, try running the script standalone from an interactive session, rather than as a script under the server. If you get error messages, this is almost certainly the cause of the “premature end of script headers” message. Even if the CGI runs fine from the command line, remember that the environment and permissions may be different when running under the web server. The CGI can only access resources allowed for the User and Group specified in your Apache configuration. In addition, the environment will not be the same as the one provided on the command line, but it can be adjusted using the directives provided by mod_env.

Źródło: http://httpd.apache.org/docs/1.3/misc/FAQ.html#premature-script-headers.

Chodzi o to, że wykonywane skrypty CGI na serwerze muszą mieć dostęp do otoczenia (environment), które jest przez te skrypty zmieniane, a co za tym idzie musi być załadowany moduł mod_env.
Brakujący moduł doinstalowałem z portu php5-extensions-1.1. Jednak sama instalacja modułu nie pomogła rozwiązać problem.

Okazuje się, że w momencie wykonywania skryptów Perl korzysta z takiej opcji jak SUIDPERL (Set User ID PERL), tj. przydziela identyfikator użytkownika na czas wykonania skryptu.

Można się o tym dowiedzieć czytając informacje o zmianach w nowej wersji Openwebmaila.
Najistotniejsza informacja dla nas:

(…) Perl automatically runs in suid mode if the suid bit is set on the running script AND perl is compiled with the DOSUID option. The openwebmail-*.pl scripts still require suid, so please make sure they are properly chmod’d 4755 as usual (…)

Źródło: http://openwebmail.org/openwebmail/doc/changes.txt.

Lecz mało kto wie, że w wersji 5.8.8 Perla opcja SUIDPERL standardowo jest wyłączona.
Musimy przeinstalować Perla (z portów) z opcją SUIDPERL w następujący sposób:

cd /usr/ports/lang/perl5.8
make deinstall
make ENABLE_SUIDPERL=YES install clean

Gdy krypty perlowe Openwebmaila nadal generują te same błędy, należy jeszcze przeinstalować Openwebmaila.

Powodzenia!