Fehler bei PEAR-Installation

[Gast]

Hallo,

nachdem mir hier letztens ein PEAR-Paket für ein Problem empfohlen wurde, wollte ich nun einmal PEAR installieren.

Die Anleitung ist ja nicht soooo prickelnd ausführlich. Aber ich habs mal probiert....

Gleich bei der Installation des Grund-Pakets kommen schon die ersten Fehlermeldungen:

Extracting installer..................ok


Warning: popen() has been disabled for security reasons in /www/htdocs/v127822/PEAR/temp/gopetSbbhO/OS/Guess.php on line 248



Warning: fgets(): supplied argument is not a valid stream resource in /www/htdocs/v127822/PEAR/temp/gopetSbbhO/OS/Guess.php on line 250



Warning: pclose(): supplied argument is not a valid stream resource in /www/htdocs/v127822/PEAR/temp/gopetSbbhO/OS/Guess.php on line 258

warning: pear/PEAR requires package "pear/Archive_Tar" (version >= 1.3.1)
warning: pear/PEAR requires package "pear/Console_Getopt" (version >= 1.2)

...

Warning: ini_restore() has been disabled for security reasons in /www/htdocs/v127822/PEAR/go-pear.php on line 804

Danach kam dann noch

Thanks for using go-pear!

Start Web Frontend of the PEAR Installer >>

Heißt das nun, dass PEAR korrekt installiert wurde oder sind die Meldungen schwerwiegend?

Der Link, der hinter "Start Web Frontend..." steckt, ist auch gleich mal falsch. Statt /PEAR/PEAR/index.php gibt es nur für /PEAR/index.php auch wirklich eine Datei.

Dort wird als erstes gleich mal die nächste Warnung ausgespuckt:

WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update

Wo ich das benutzen soll, wird natürlich mal wieder nicht erwähnt. Einen gleichnamigen Menüpunkt konnte ich mal nicht finden. Es sieht auch eher nach einem Shell Kommando aus.

Der Unterpunkt "List avail. Upgrades" bringt auch nichts zu Tage, was so ähnlich aussieht.


Da ich ein Paket installieren will, das noch als beta gekennzeichnet ist, geht es gleich zur Anpassung der Konfiguration.
Nach dem Versuch, die Änderun abzuspeichern, kommt die nächste Fehlermeldung:

config-set (Filename, /www/htdocs/v127822/PEAR/pear.conf, user) failed, channel pear.php.net

Kann mir mal jemand verraten, ob die Fehlermeldungen ignoriert werden können, oder schwerwiegend sind?
Und wie ich dieses Update des Protokolls durchführen kann? Die Meldung taucht auf jeder Seite oben auf.

[Forumsgast]

Also über den PEAR Installer hab ich PEAR auch nicht installiert bekommen damals.
Ich machs jetzt so, dass ich mir die PEAR Klasse [1] installiere und den PEAR-Pfad als include_path setze.

<?php
set_include_path(get_include_path() . PATH_SEPARATOR . PATH_TO_PEAR);
?>

Danach installier ich mir die Pakete von PEAR die ich brauche. Musst dabei drauf achten, dass du sie in die richtige Ordner-Struktur legst, also /pear/HTTP/Request.php zB, wenn du das HTTP_Request-Paket benötigst. Abhängigkeiten unter den Paketen nicht vergessen.
Und eigentlich kanns dann auch schon losgehen.

[1] http://pear.php.net/package/PEAR

[Gast]

Das Include-Verzeichnis hab ich mit .htaccess hinzugefügt. Das klappt also eigentlich.

Die Datei guess.php, in der die ersten Fehler aufgetreten sind, ist nach der Installation auch nicht mehr vorhanden.

Auf den ersten Blick hat die Installation der Pakete danach funktioniert, aber ein richtig gutes Gefühl hab ich damit nicht.

Welche Zugriffsrechte soll man dem PEAR-Verzeichnis geben?
Ich hab mal per .htaccess nur Zugriff mit Authentifizierung gemacht. Ist das so OK?

Und wie kriegt man das Ding normalerweise wieder komplett los?
Zugriffsrechte sind so gesetzt, dass ich das per FTP nicht löschen kann.
Bei meinem ersten Fehlversuch hab ich mir dann extra ein Script geschrieben, dass die Verzeichnisse entsorgt.
Das empfinde ich aber nicht als akzeptable Lösung.

[Forumsgast]

Auf den ersten Blick hat die Installation der Pakete danach funktioniert, aber ein richtig gutes Gefühl hab ich damit nicht.

Was heißt das? funktioniert das Paket PEAR:: DB (nach der Installation)?
Wenn du es so machst wie Zergling(ini_set), sollte es nach dem include der DB.php keinerlei Warnings oder Notices geben.

Welche Zugriffsrechte soll man dem PEAR-Verzeichnis geben?

0777 ???

Und wie kriegt man das Ding normalerweise wieder komplett los?

rm -rf * :wink:
Ich habe damlals beim Hoster angerufen, weil ich ca. 50 tmp Dateien rumhängen hatte, die nicht mehr löschen gingen(dein safe_mode scheint on zu sein!?)...

Ich mache das so(wenn ich denn mal auf so ner beschnittenen Kiste arbeiten muss), dass ich mir auf meine lokale Kiste son Wamp, Xampp oder so drauf mache und dann den kompletten PEAR Ordner synce....So klappt auch mit den Abhängkeiten....Installiern lkann man ja dann lokal über die Shell(ode rim schlimmsten Fall über die Windoze-CMD)

Der PEAR-Webinstaller hat bei mir noch nie funktioniert...(auf 3 Servern getestet)

[Gast]

Hmmm. Safemode ist laut phpinfo() aus.

Vom Paket PEAR:B hab ich keine Ahnung.
Wozu brauch ich DB.php?

Ich habe mal einen Blick auf die nachher vorhandenen Dateien geworfen und zumindest wurde für mein Wunsch-Paket was installiert und beim Einbinden der entsprechenden Datei in ein eigenes Script kamen keine Fehlermeldungen.

Der Webinstaller kriegt das mit den Abhängigkeiten auch nicht selber hin. Da kommt nur im Fehlerfall ein Fenster, dass was fehlt. Aber der Inhalt des Fensters besteht aus bergeweisem Müll bevor nach langem Runterscrollen mal die eigentliche Meldung erscheint.

[Forumsgast]

Hmmm. Safemode ist laut phpinfo() aus.

Sorry, das hat in dem Fall auch überhaupt nix zu sagen. Mein Fehler...

Aber wie gesagt, das gleiche wie bei mir. Auf meinem lokalen System hat es einmal geklappt. Allerdings hat das Installieren eines Pakets bis zu 5 Minuten gedauert.

Vom Paket PEARB hab ich keine Ahnung.
Wozu brauch ich DB.php?

Das ist normalerweise das erste Paket mit dem man anfängt, weil es ein super Abstraktionslayer für Datenbankgeschichten ist. DB ist bei mir nicht mehr wegzudenken. Allerdings wurde DB mittlerweile duch MDB2 ersetzt, welches aber genauso funktioniert wie DB aber noch etws mächtiger ist.
Alle Pakete die mit Datenbanken zu tun haben setzen auf DB o. MDB/2 auf.

Wenn dein Paket läuft und es auf PEAR aufsetzt, scheint alles zu gehen.
meist weden von PEAR die Exception-Handler(PHP5) oder die Error Handler benutzt. Wenn diese Klassen nicht da sind gibts eh Mecker...

[Forumsgast]

Die Fehlermeldung ist doch klar: popen() und ini_restore() sind nicht benutzbar (ini_get('disable_functions')). Ich würde den Mist auch einfach lokal installieren und hochkopieren.

Und sichern? Natürlich nicht ins doc_root (da haben ja eh nur eine index.php, statische Bilder, css-Dateien und sowas etwas verloren) und die Rechte so setzen, dass die übrigen Kunden auf dem Server die Dateien nicht beschreiben können, aber das ist ja selbstverständlich. Also nichts besonderes eben.

Und löschen? Einfach mit ftp oder ssh via chmod wieder schreibbar machen und löschen. Wo hakt es denn da? Laufen die Skripte unter anderem Benutzer, als dem deines ftp-Accounts? Im Notfall eben via php (unlink()).

Basti

[Gast]

Die Fehlermeldung ist doch klar: popen() und ini_restore() sind nicht benutzbar (ini_get('disable_functions')). Ich würde den Mist auch einfach lokal installieren und hochkopieren.

Dass die Funktionen nicht benutzbar sind, weiß ich auch. Ich wollte wissen, ob das Scheitern des Aufrufs einen kritischen Fehler darstellt oder ob das Script damit klar kommt.

Das Script kann Fehler ja auch abfangen wenn es sauberer programmiert ist. Ob hier das Abfangen vergessen wurde oder nur die Ausgabe nicht unterdrückt wurde, aber das Ergebnis korrekt ausgewertet wurde, weiß ich ja eben nicht.

Lokal installieren halte ich für eine recht unbrauchbare Variante.
Laut Anleitung zu PEAR gibt es auch OS-abhängige Teile.
Der Dateiname OS/Guess.php deutet darauf hin, dass in dem Script versucht wird, das Host-OS rauszufinden. Nachsehen kann ich nicht, weil die Datei nach der Installation nicht mehr vorhanden ist.

Wenn ich mir das lokal mit Windows installiere bringt mir das also auf einem Linux-Server nicht recht viel.

Und sichern? Natürlich nicht ins doc_root (da haben ja eh nur eine index.php, statische Bilder, css-Dateien und sowas etwas verloren) und die Rechte so setzen, dass die übrigen Kunden auf dem Server die Dateien nicht beschreiben können, aber das ist ja selbstverständlich. Also nichts besonderes eben.

Damit der Apache das ausführen kann, muss ich wohl mindestens allen Leserechte geben. Bei Verzeichnissen noch Ausführrechte. Ob irgendwer was schreiben muss, weiß ich nicht.

Und löschen? Einfach mit ftp oder ssh via chmod wieder schreibbar machen und löschen. Wo hakt es denn da? Laufen die Skripte unter anderem Benutzer, als dem deines ftp-Accounts? Im Notfall eben via php (unlink()).

Wie ich geschrieben habe, kann ich es per FTP nicht löschen.
Mein FTP-Benutzer ist ein anderer als der Apache.
Shell-Zugang habe ich keine. Nur FTP.
Der Webinstaller ist laut Installationsanleitung genau für solche Umgebungen vorgesehen, wo man eben nicht an der Shell was installieren (oder eben löschen) kann. Da sollte das Ding vielleicht auch so clever sein, die Zugriffsrechte etwas großzügiger zu setzen.

Wenn ich per Shell etwas löschen könnte, hätte ich nicht diese Installationsvariante genommen.

[Forumsgast]

Der Dateiname OS/Guess.php deutet darauf hin, dass in dem Script versucht wird, das Host-OS rauszufinden.

mmmh normalerweise nicht. das ist eine Konstante:

if (substr(PHP_OS, 0, 3) == 'WIN') {
    define('OS_WINDOWS', true);
    define('OS_UNIX',    false);
    define('PEAR_OS',    'Windows');
} else {
    define('OS_WINDOWS', false);
    define('OS_UNIX',    true);
    define('PEAR_OS',    'Unix'); // blatant assumption
}

[Forumsgast]

Die Fehlermeldung ist doch klar: popen() und ini_restore() sind nicht benutzbar (ini_get('disable_functions')). Ich würde den Mist auch einfach lokal installieren und hochkopieren.

Dass die Funktionen nicht benutzbar sind, weiß ich auch. Ich wollte wissen, ob das Scheitern des Aufrufs einen kritischen Fehler darstellt oder ob das Script damit klar kommt.

Das Script kann Fehler ja auch abfangen wenn es sauberer programmiert ist. Ob hier das Abfangen vergessen wurde oder nur die Ausgabe nicht unterdrückt wurde, aber das Ergebnis korrekt ausgewertet wurde, weiß ich ja eben nicht.

Lokal installieren halte ich für eine recht unbrauchbare Variante.
Laut Anleitung zu PEAR gibt es auch OS-abhängige Teile.
Der Dateiname OS/Guess.php deutet darauf hin, dass in dem Script versucht wird, das Host-OS rauszufinden. Nachsehen kann ich nicht, weil die Datei nach der Installation nicht mehr vorhanden ist.

http://viewcvs.php.net/viewvc.cgi/pe...23&view=markup

Hier wird versucht, die Version der glibc rauszufinden. Für die PEAR-Klassen sollte das völlig Wurscht sein (würde mich schwer wundern, falls nicht *g), sondern eben nur für PECL interessant sein. Für deinen gemieteten Webspace in jedem Fall egal.

Was es genau mit dem ini_reset('include_path') auf sich hat, weiß ich nicht, kannst dich ja aber auch natürlich selbst einlesen (ist ja alles quelloffen):

http://pear.php.net/go-pear

Wenn ich mir das lokal mit Windows installiere bringt mir das also auf einem Linux-Server nicht recht viel.

Spielt für PEAR soweit ich weiß keine Rolle. Ich hab bei PEAR noch nie unterschiedliche Downloads für unterschiedliche OS gesehen. Gibt auch einen Punkt im Manual, wie man eine lokale Installation auf den Server verfrachtet (mittels pake).

Und sichern? Natürlich nicht ins doc_root (da haben ja eh nur eine index.php, statische Bilder, css-Dateien und sowas etwas verloren) und die Rechte so setzen, dass die übrigen Kunden auf dem Server die Dateien nicht beschreiben können, aber das ist ja selbstverständlich. Also nichts besonderes eben.

Damit der Apache das ausführen kann, muss ich wohl mindestens allen Leserechte geben. Bei Verzeichnissen noch Ausführrechte.

Scherzkeks! *g

Ob irgendwer was schreiben muss, weiß ich nicht.

Prinzipiell sind das einfach nur Klassen, die sich (hoffentlich) nicht einfach selbst umschreiben. Aber es wird natürlich ein temporäres Verzeichnis benutzt werden und ich schätze mal, dass hier das Standard-Verzeichnis (z.B. /tmp) genommen wird, falls nichts anderes angegeben wird. Wie ganu das läuft sollte eigentlich im Handbuch stehen (Instalation, Konfiguration oder auch bestimmte Parameter bei der Benutzung). Womöglich brauchst du ja auch garkein tempdir...

Ich benutze z.B. seit langem eigentlich nur PEAR::Mail für die validierung von Mail-Adressen. Ich hab mich mit PEAR nie sonderlich anfreunden können, hab daher nicht so den Einblick.

Und löschen? Einfach mit ftp oder ssh via chmod wieder schreibbar machen und löschen. Wo hakt es denn da? Laufen die Skripte unter anderem Benutzer, als dem deines ftp-Accounts? Im Notfall eben via php (unlink()).

Wie ich geschrieben habe, kann ich es per FTP nicht löschen. Mein FTP-Benutzer ist ein anderer als der Apache.
Shell-Zugang habe ich keine. Nur FTP.
Der Webinstaller ist laut Installationsanleitung genau für solche Umgebungen vorgesehen, wo man eben nicht an der Shell was installieren (oder eben löschen) kann.

Hätte ja sein können, dass nur die Rechte falsch gesetzt sind. Da hilft dann nur dein Skript, klar.

Da sollte das Ding vielleicht auch so clever sein, die Zugriffsrechte etwas großzügiger zu setzen.

Ob das wirklich so clever wäre? Wie sollte das Skript denn die Konfiguration der Serverumgebung rauskreigen? Mich ärgert mein Provider übrigens nicht mit so einem Mist.

Viel Glück.
Basti

[Forumsgast]

PS:

Hier wahrsceinlich der Grund, warum dein ISP ini_restore() verbietet:

http://securityreason.com/achievement_securityalert/42

Basti

[Gast]

Aha. Danke für den Link.