Forum

servus flash,

ich hab das technisch schon richtig verstanden.... und kann ja auch bei mir rumwursteln wie ich will - für mich ist das also ist überhaupt kein thema.

trotzdem finde ich es - für den "normalen" opn benutzer der einen standard hoster verwendet - abschreckend.
ich meine damit nicht, das das system nicht in einer standardisierten umgebung sofort funktioniert, sondern manuell nachgebessert werden muss - einige wenige hoster bieten ja sowas an - das ist für mich kein thema.
aber wie gesagt es sind einige wenige.... und einmal den hoster anschreiben ist ja auch ok - wenn er denn reagiert....und dann überleg ich mir 3 wochen später ich hätte jetzt gerne noch das opn-modul xy installiert? neuer cache ordner - alles nochmal von vorn? wie oft macht da wohl der freundliche hoster mit?

ich fände es schade dadurch potentielle user abzuschrecken, anstatt wieder einen begeisterten anhänger mehr zu haben der herumläuft und für ein geiles system werbung macht.....

deswegen auch meine frage ob es ein fehler wäre - oder andersherum - gibt es keine möglichkeit die arbeitsweise von opn so zu verändern, dass es diese stolperstelle nicht gibt ?


lg
go

trotzdem finde ich es - für den "normalen" opn benutzer der einen standard hoster verwendet - abschreckend.

Das Problem habe auch die Leute von Nuke, Typo3, WBB usw.

Sehe es so, wenn ein Hoster sein Server richtig konfiguriert und auch die Rechte richtig vergibt, dann ist das kein Problem.

und einmal den hoster anschreiben ist ja auch ok - wenn er denn reagiert....und dann überleg ich mir 3 wochen später ich hätte jetzt gerne noch das opn-modul xy installiert? neuer cache ordner - alles nochmal von vorn? wie oft macht da wohl der freundliche hoster mit?

auch hier das gleiche, er muss das richtig konfigurieren in den Servereinstellungen, dann geht das.
Das hat nichts mit dem installen von Modulen etc zu tun. Der Hoster kann da aucht nicht einfach nur mal schnell irgendein CHMOD oder so ändern damit das geht.
Das muss der in der httpconf oder phpini anpassen und das nur einmal, dann funzt das auch.

gibt es keine möglichkeit die arbeitsweise von opn so zu verändern, dass es diese stolperstelle nicht gibt ?

hm, denke kaum dass das einfach so möglich ist, denn das sind ja PHP Befehle die das bewirken.
bin da jetzt auch nicht der Profi der dier das beantworten kann.
Weil da gibt es noch eine Menge mehr zu beachten.
- safe mod
- Sicherheitslücken
- wie ist PHP installiert (läuft über CGI)
- subPHP

und so weiter und so fort.

Guck mal unter Admin - Diagnostic - Information - Config Test

Da prüft OPN genau diese Einstellungen.
(Achtung ist erst in der Trunk verfügbar)

Flash

Flash schrieb am 05.01.2007 um 22:25:33 Uhr folgendes:

>> Das muss der in der httpconf oder phpini anpassen und das nur einmal, dann funzt das auch.

Wenn dem so ist..... ;-)Gibt´s dazu irgend einen Link oder Doku?

LG
go

Hallo,

habe den selben "Stolperstein"

ftp leget webx:webx: an und PHP wwwdata:wwwdata, ist natürlich nicht möglich damit zu arbeiten.
Einen Link, Info oder Anleitung würde mich zu dem Problem auch sehr interessieren.

ich vermute mal das ich das gleiche Problem hab, ohne das ich wirklich durchsehe.

Flash hat das ganze zwar sehr gut erklärt, aber ich wüsste nichteinmal was ich dem Hoster schreiben soll.

Und wo könnte man das im Confixx evtl selbst ändern. Ich hab meim neuen Hoster *Plesk*

Kann es nur bestätigen was Flash geschrieben hat. Ich hatte je Anfangs auch Schwierigkeiten. Aber seit dem ich den Hoster gewechselt habe, funzt alles.
Will hier keine Werbung für den Hoster machen, könnt Ihr aber auf meiner Seite erkennen.

Flash schrieb am 05.01.2007 um 19:54:27 Uhr folgendes:

Nabend Go

versteh ich das so, dass das ein schwerwiegender Fehler und damit ein Fall fürs BT ist ?

>
> Hier handelt es sich nicht um einem bug von OPN.
>
> Versuche hier mal ein wenig Licht ins dunkle zu bringen.
>
> Normalerweise werden PHP Scripte immer unter dem Benutzer ausgeführt unter dem der Webserver arbeitet. Meist haben die den Namen "nobody", "apache", "wwwrun" und so weiter.
>
> Die OPN Scripte welche per FTP auf den Server übertragen werden gehören dem FTP Benutzer. Wenn ihr nun eine PHP Datei im Browser aufruft, also auf dem Server vom Benutzer "wwwrun, "nobody" etc. ausgeführt.
> Dieses Script versucht nun eine Datei ins cache zu schreiben, kopieren etc.
> Da das Script vom "wwwrun" ausgeführt wurde, ist bei der neu angelegten Datei der "wwwrun" als Dateieigentümer eingetragen. Versucht das PHP script nun erneut (egal ob lesend oder schreibend) auf die gerade angelegte Datei zuzugreifen, merkt PHP, dass die beiden Dateien unterschiedliche Eigentümer haben (die eine gehört dem FTP-Benutzer, die andere dem Webserver). Da der Safe-Mode aber nur Zugriffe auf Dateien erlaubt, die dem gleichen Eigentümer gehören wird in diesem Fall der Zugriff auf die gerade erstellte Datei verboten.
>
>
> Bei Datei Ordner verhält sich das genau gleich. Erstellt OPN ein Ordner im Cache
> gehört dieser dem Webserver. OPN darf nun in diesem Ordner aber keine Dateien erstellen oder kopieren, da sich auch hier der Dateieigentümer unterscheidet.
>
> Werden PHP Scripte im Safe-Mode vom Benutzer "Webserver" ausgeführt ist es ohne Änderungen durch den Serveradministrator nicht möglich mit PHP Scripten Dateien zu schreiben.
>
> Im Klartext heisst das, das weder OPN noch andere PHP Skripte auf solchen Systemen korrekt laufen.
>
> Ändern kann das nur der Serverdadministrator. Bei einigen Anbietern ist es jedoch möglich per Confixx das als User selber zu ändern.
> Weiter besteht auch bei einigen Hoster die Möglichkeit, dass man als User Änderungen in der phpini oder sogar am Apache selber vornehmen kann.
>
> Kontakiert diebezüglich eure Hoster, wenn ihr damit Probleme habt. Ein guter Hoster wird euch da immer eine Lösung haben.
>
> Flash
>
>
>

Im Großen und ganzen versteh ich davon nicht viel... aber ich versuch´s.

Hab mich im Plesk umgeschaut und unter den Optionen *Benutzer*/*Einstellungen kann ich:

Skriptausführung durch Web-Benutzer erlauben

Das ist aktiviert.

Ich hoffe mal das es das ist, allerdings funktioniert´s dennoch nicht.