Veni, Vidi, VISA

So hat mir das $Admin erklaert und mir auch gleich ein non-working example gezeigt:

$ pkg_add -v php5-core

parsing php5-core-5.2.6

Dependencies for php5-core-5.2.6 resolve to: libiconv-1.12, libxml-2.6.32p1, gettext-0.17 (todo: libxml-2.6.32p1)

php5-core-5.2.6:parsing libxml-2.6.32p1

Dependencies for libxml-2.6.32p1 resolve to: libiconv-1.12

found libspec c.48.0 in /usr/lib

found libspec iconv.5.0 in package libiconv-1.12

found libspec m.3.0 in /usr/lib

found libspec z.4.1 in /usr/lib

php5-core-5.2.6:libxml-2.6.32p1: complete

[...]

Error: truncated archive

php5-core-5.2.6: complete

can't open /usr/local/lib/php/libphp5.so: No such file or directory at /usr/libdata/perl5/OpenBSD/md5.pm line 27.

Mein Vorschlag war das er einfach PKG_PATH auf einen anderen Server setzen soll, aber das hat er kurz ueberlegt und sich dran erinnert das er das auch schon versucht hat und es nicht geholfen hat. Komich, denn

$ export PKG_PATH="http://artfiles.org/openbsd/4.4/packages/i386"

$ pkg_add -v php5-core

parsing php5-core-5.2.6

Dependencies for php5-core-5.2.6 resolve to: libiconv-1.12, libxml-2.6.32p1, gettext-0.17

found libspec c.48.0 in /usr/lib

found libspec crypto.14.0 in /usr/lib

found libspec iconv.5.0 in package libiconv-1.12

found libspec intl.4.0 in package gettext-0.17

found libspec m.3.0 in /usr/lib

found libspec pthread.11.0 in /usr/lib

found libspec ssl.11.0 in /usr/lib

found libspec stdc++.45.0 in /usr/lib

found libspec xml2.10.0 in package libxml-2.6.32p1

found libspec z.4.1 in /usr/lib

installed /var/www/conf/php.ini from /usr/local/share/examples/php5/php.ini-recommended****************************************************************                                                    | 72%

installed /var/www/conf/modules.sample/php5.conf from /usr/local/share/examples/php5/php5.conf

php5-core-5.2.6: complete

--- php5-core-5.2.6 -------------------

To enable the php5 module please create a symbolic

link from /var/www/conf/modules.sample/php5.conf

to /var/www/conf/modules/php5.conf.



ln -s /var/www/conf/modules.sample/php5.conf \

        /var/www/conf/modules



The recommended php configuration has been installed

to /var/www/conf/php.ini.



Don't forget that the default OpenBSD httpd is chrooted

into /var/www by default, so you may need to create support

directories such as /var/www/tmp for PHP to work correctly.

$ php --version

PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 12 2008 12:07:27) 

Copyright (c) 1997-2008 The PHP Group

Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies

    with Suhosin v0.9.20, Copyright (c) 2002-2006, by Hardened-PHP Project

sieht fuer mich so aus als wuerde das das Problem beheben.
War wahrscheinlich schlechtes Karma seinerseits..

Mittels .htaccess hat man ja die Moeglichkeit den Webserver zu veranlassen, andere/eigene Fehlermeldungen auszugeben. Das funktioniert auch, aber es gibt einen kleinen Bug an der Sache. Wenn man

ErrorDocument 404 /errors/404.php

verwendet, wird zwar die Datei 404.shtml ausgegeben, aber ein ggf. darin enthaltenes <?php echo $REQUEST_URI; ?> wird nicht korrekt abgearbeitet. Bei obiger Angabe in der .htaccess enthaelt $HTTP_SERVER_VARS['REQUEST_URI'] naemlich dann den String http://domain.invalid/errors/404.php.
Mit einem Errorhandler kann man das ganze beheben:

<?php

switch ($_GET['type']) 

{

    case 404:

    include("404.php");

    break;



    case 403;

    incllude("403.php");

    break;



    [....]

}

?>

und anstelle des obigen Beispieles kommt folgendes in die .htaccess

ErrorDocument 404 /errors/error.php?type=404

und dann funktioniert es so wie es soll.. vielleicht.

// edit
Laestert nicht ueber das PHP-Gemurkse. Das ist ein schneller Hack nach 30mins Dokumentation lesen.

Wenn session.save_path nicht korrekt gesetzt ist, kann es durchaus passieren, dass man solche Fehlermeldungen zu Gesicht bekommt:

Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of 

session.save_path is correct  (/foo/bar/sessions) in Unknown on line 0

Das kann daran liegen, dass man der Webserver in einer chroot() laeuft und session.save_path innerhalb der chroot() absolut definiert werden muss. Also session.save_path = "/tmp" und nicht session.save_path = "/var/www/tmp/". Wenn der Fehler dann noch immer nicht verschwunden ist, sollte man die Rechte der Verzeichnisses ueberpruefen damit der Webserver dort auch Schreibrechte hat.
Und was ganz wichtig ist: Man muss die richtige php.ini editieren!

http://secunia.com/advisories/26347/ bzw. http://blog.s9y.org/archives/178-Serendipity-1.1.4-released,-security-bug-in-entryproperties-plugin.html; ein neues Release indem der Bug behoben wurde, steht mit Serendipity 1.1.4 zum Download bereit.

$ cd /usr/pkgsrc/lang/php5

$ make PKG_OPTIONS.php="fastcgi" install clean ; make clean-depends

$ cd /usr/pkgsrc/www/lighttpd ; make install clean

$ $EDITOR /usr/pkg/etc/lighttpd/lighttpd.conf

mod_fastcgi auskommentieren, bin-path in 

"bin-path" => "/usr/pkg/libexec/cgi-bin/php" in fastcgi.server aendern; 

anschliessend lighttpd=YES in die /etc/rc.conf reinschreiben und lighttpd starten

$ /etc/rc.d/lighttpd start

Als Software fuer muttng - Wiki verwende ich PmWiki und das ist auch ausreichend komfortabel und funktionell, aber ..

Damit externe Links in einem neuen Fenster geoeffnet werden, hab ich in der ./local/config.php folgende Variable verwendet

$UrlLinkFmt = "<a class='urllink' target='_blank' href='\$LinkUrl'>\$LinkText>/a<";

Das funktioniert auch so wie ich mir das vorstelle; danach wollte ich noch mailto:foo@bar.invalid Links etwas aufpeppen und hat

a.mailto{



        background: transparent url(http://www.strcat.de/images/mail_icon.gif) 0px 1px no-repeat;



        padding: 1px 0px 1px 16px;



        color:#436976;



        text-decoration:none;



}

in das dazu gehoerende CSS-File eingefuegt. Das komische daran ist nur, dass PmWiki mailto:foo@bar.invalid Links genauso behandelt wie normale http://.. Links und die Grafik nicht verwendet. Manchmal saugt wirklich alles

So wie ich das sehe, bleib ich in Zukunft lieber bei Perl (hab ich eigentlich schon erwaehnt das PHP saugt? :>)