Adam Kuczablogger czy logger?

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ą 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


Unique visitors to post: 1

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.


Unique visitors to post: 76

0 mailto z button’a

Adam Kucza to Internet, JavaScript, PHP  

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.


Unique visitors to post: 14

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.


Unique visitors to post: 4

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.


Unique visitors to post: 12

off Upgrade WordPress’a

Adam Kucza to Internet, Wordpress  

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.


Unique visitors to post: 2

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.


Unique visitors to post: 128

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!


Unique visitors to post: 6

off Nowy serwer

Adam Kucza to Aktualności  

Drodzy internauci. Chciałbym poinformować, że praktycznie już od wczoraj serwis śmiga na nowym serwerze.
Jest to platforma niczego sobie, bowiem: IBM x330, 2x Intel 1.4GHz Tualatin, 2x 1024MB RAM, 2x 36GB SCSI, 1x CD-ROM, 1x FDD, 2x USB, 2x Ethernet 10/100Mbit.


Unique visitors to post: 4

Nie wszyscy lubią system Windows Vista. Nie wszyscy są nim zachwyceni z uwagi na zasobożerność. Nie wszyscy lubią Windowsy.
Należę jednak do tej mniejszości, która potrafi poradzić sobie z każdym systemem, nawet z Vistą.

Od początku maja w repozytorium Microsoft Windows Update widnieje paczka Service Pack 1.
Dopiero dzisiaj udało mi się ją bezproblemowo zainstalować.

Otóż problem pojawiał się w momencie instalacji Etapu 3/3, gdzie w 78% postepu instalacji system się zawieszał.
Jedyną drogą powrotną było przywrócenie systemu do jakiegoś punktu przywracania z przeszłości.

Jak się okazuje, po uważnym przeczytaniu strony Microsoft Support (http://support.microsoft.com/kb/947366), wpadłem na pomysł totalnego wyłączenia antywirusa NOD32 oraz firewalla Jetico.

Dopiero teraz aktualizacja przebiegła pomyślnie. Wam również życzę powodzenia.


Unique visitors to post: 5