das nicht schlau wird aus den anderen antworten

Sorry, für euch Pro's ist das wahrscheinlich alles lächerlich, aber die bisher gefundenen Artikel haben mir nicht wirklich weitergeholfen, vllcht versteh ichs einfach nicht

Also folgendes ist nun als Fehlermeldung erschienen:
Zur Info:
Das ist kein dedizierter Server sondern "nur" webspace von racer / server4you.

/usr/local/pem/vhosts/2159/ <- auf diesen Teil bzw. darunter kann ich nicht zugreifen.
/webspace/httpdocs/ASK/ <- auf diesen Teil kann ich natürlich zugreifen (ab webspace)

Der Hoster hat unter /usr/share/pear/ die PEAR eingebunden und in den include_path mit aufgenommen. (include_path .:/usr/share/pear )
Bei open_basedir steht /usr/local/pem/vhosts/2159


So und egal auf welche Ideen ich schon gekommen bin wie ich die DB.php von PEAR aus dem /usr/share/pear/ einbinden will mit require_once(), ich krieg eigentlich wenn überhaupt nur obigen Fehler.

Bin ich jetzt nur dumm, dass ich alle Artikel nicht verstanden habe bis dato oder hat der Hoster da etwas zu sehr verkonfiguriert?

Die Zeilen sahen glaub ich schon so aus:
require_once( 'DB.php' );
require_once( '/usr/share/pear/DB.php' );
require_once( '../../../../share/pear/DB.php' );

Aber nur der Fehler. Aber eigentlich sollte ich doch was aus dem include_path includen können oder?

Über Hilfe wäre ich dankbar Dankbar bin ich auch schon mal über eure Geduld mit diesem scheinbar häufigen Problem

Mister Ad

Der Provider gestattet lediglich keinen Zugriff auf PEAR, sonder sähe open_basedir anders aus. KA., ob Unkenntnis oder Absicht. Allerdings ist S4Y eh keine "gute Adresse".

open_basedir() - diese Warnung kannst du umgehen, in dem du in deine includes und requires ein ./ vor den Dateinamen setzt.

z.b.
require_once('./DB.php');

^^ das hatte ich ja auch schon probiert ... Hab zwar auch bei S4Y ein Ticket aufgemacht, aber die antworten dauern immer ewig.

jein. das ne grundsatz diskussion, aber für 555 Tage kostenlosen server und dem vertraglichen recht, nichts zu zahlen, wenn es auch nur ein prob gibt aber das ist eine andere geschichte


ich dachte mir auch schon fast, dass S4Y sich da ein Ei gelegt hat. Deshalb auch das Ticket. Gibts denn komplett Distris von Pear? Weil unter pear.php.net kann ich anscheinend immer nur einzelne module wie auth oder db ziehen. und meine hp usw baut derzeit schon auf auth und db auf und wird noch um 2-3 komponenten von pear erweitert.

Warning: main(./DB.php): failed to open stream: No such file or directory in /usr/local/pem/vhosts/2159/webspace/httpdocs/ASK/_index.php on line 3

Überprüf mal, ob die datei wirklich im selben Ordner wie das includierende Script liegt UND auch die gleiche groß- und kleinschreibung hast.

Momentan findet er das nämlich gar nicht.

mir wurde mal schon vor ca. einem 3/4 jahr gesagt, dass pear komplett installiert wird/wurde mit allem was dazu gehört. wenn also pear komplett in /usr/share/pear liegt, müsste eigentlich in dem dir auch eine DB.php sein. So wird diese auch schon immer von der PEAR Com benannt, also auch grosses DB und kleines .php ... in die verzeichnisse selber kann ich ja leider nicht reinsehen.

Woran das nur liegen mag: vvv

S4Y ist der Beweis dafür, daß Geiz nicht geil sondern wahnsinnig macht.

phpfriend.de wohnte mal ein paar Monate auf einen vServer dieser Firma. Alle, die diese bittere Zeit mitgemacht haben, sind heilfroh, daß das heute nicht mehr der Fall ist.

Wenn im include_path der Path zu PEAR mit angegeben ist, dann hat der gefälligst auch im open_basedir aufgeführt zu werden, weil es sonst nix als Verar.schung ist. Sicher haben die Künstler noch Deinen session.save_path auf /tmp gelegt, damit Du die nächste Frage stellen kannst, warum Deine Sessions nicht funktionieren, weil PHP dort dann ebenfalls nicht lesen darf.

hat nix mit geiz zu tun gehabt. egal. mittlerweile hat sich spürbar was getan finde ich und man kann für kleine zwecke wie diese hier (also meine hp von nem mmorpg gamer clan) das machen was man will...

zum thema sessions .. session.save_path /usr/local/pem/vhosts/2159/tmp
die funzen ^^

Freu Dich - Andere hatten da weniger Glück. :wink:

Das ist einer der Gründe, weshalb ich bei Sessionproblemen immer erst das phpinfo sehen will.

ich zitiere jetzt mal einfach hier rein :

und

naja .. ging ja noch .. unter 24h reaktionszeit ^^ wundert mich selbst etwas


so -> done .. could be closed