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.

» wpis obejrzano 2949 razy przez 771 internautów «

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!

» wpis obejrzano 1818 razy przez 450 internautów «

Miałem wczoraj możliwość ustawienia ciekawego rozwiązania hashowania skryptów PHP - ionCube oraz ZendOptimizer .
Istotą sprawy było to, że wszystko miałem zainstalowane i dobrze ustawione w pliku php.ini z taką małą różnicą, że phpinfo(); jednak nie pokazywało odpowiednich informacji o tych ustawieniach, co - de facto - również nie działało.

Cóż więc jest nie tak?

Przejrzałem google w wzdłuż i wszerz i niestety nie znalazłem odpowiedzi na to pytanie. Znalazłem natomiast mnóstwo opisów dotyczących prawidłowej konfiguracji tzw. loaderów w pliku ustawień samego deskryptora PHP.

Przejrzałem jeszcze raz konfiguracje i manuale. Okazało się, że PHP nie może być skompilowane z opcją

-enable-debug

wpp. loadery nie ładują się.

Wobec tego ponownie skompilowałem PHP 5.2.0 na freeBSD 6.1 przy czym tym razem nie zaznaczałem opcji debug. Oczywiście należało również pwtórnie skompilować wszystkie używane moduły, gdyż te wcześniejsze były jakby przygotowane dla wspomnianego parametru debug.

Wynik tej akcji zobaczyłem w phpinfo():

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
with the ionCube PHP Loader v3.1.24, Copyright (c) 2002-2006, by ionCube Ltd., and
with Zend Optimizer v3.2.2, Copyright (c) 1998-2006, by Zend Technologies
with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend Technologies

» wpis obejrzano 7720 razy przez 1551 internautów «