500er Fehler nach Kundenerstellung und Login

[ofox]

@joximu
Probiert es aus. Bei mir kam der "Error 500!" vom ispCP wegen den Rechten. Bei 777 auf maildrop kam dann keine. Das ist aber nach dem Serverumzu passiert! Auf dem "alten" Server war alles ok, nur auf dem neuen ist das Problem aufgetaucht.
(!)Obwohl alle Gruppen/User/Rechte 1:1 wie auf dem altem System eingestellt sind.
Configuration: Debian 5, ispCP 1.0.0 stable. Reiner Webserver, nichts weiter!

Falls meine "Lösung" jeamndem geholfen hat, gibt mir bitte sofort bescheid. Der Fehler mus behoben werden, ich weis nur nicht wie, hier ist die Programmierung/Entwickler gefragt.

[joximu]

@ofox - hab dir ja schon geschrieben:

das bedeutet ja, dass die Webanwendung auf diesen Ordner zugreifen will - das darf nicht sein.

Und das kommt bei allen Seiten, die danach eine Mail versenden?

Hm, seltsam... ispcp verwendet immer die mail() funktion - und diese greif sicher nicht direkt auf diesen Ordner zu - es sei denn, dass da sonst was nicht stimmt.
- ist postfix drauf (und nicht exim, was bei debian default ist?)
- ist in der php.ini was in Sachen mail geändert worden?
- funktioniert postfix einwandfrei?

Irgendwas muss auf diesem neuen System falsch sein.

/J

[ofox]

(10-26-2009 11:53 PM)joximu Wrote:  1. Und das kommt bei allen Seiten, die danach eine Mail versenden?

Hm, seltsam... ispcp verwendet immer die mail() funktion - und diese greif sicher nicht direkt auf diesen Ordner zu - es sei denn, dass da sonst was nicht stimmt.
2. - ist postfix drauf (und nicht exim, was bei debian default ist?)
3. - ist in der php.ini was in Sachen mail geändert worden?
4. - funktioniert postfix einwandfrei?
5.Irgendwas muss auf diesem neuen System falsch sein.

/J

Das mit der mail() von PHP hast du ja recht.
Ich habe jetzt auf das aktuelle Nightly Build ein Update gemacht, das Problem besteht weiterhin. Verwende immer noch 777 vorerst und suche nach einer entgültigen Lösung.

1. Ja.
2. Postfix.
3. Nein.
4. Noch keine Fahler entdeckt. Es wurden bis jetzt auch keine von den Kunden gemeldet.
5. Ja, ich habe aber den Umzug 2 Wochen lang simuliert und immer mit dem gleichen Ergebnis.

Soll ich mal php.ini oder irgend welche Logs posten?

[joximu]

Ich würde so rangehen:
- lauft der mail() Befehl bei den Kunden - mit und ohne 777 auf maildrop?
- lauft der mail() Befehl in der master domain (eigene php datei im ispcp-document root testen) - mit und ohne 777 auf maildrop?

falls da unterschiede bestehen, dann würde ich doch die php.ini vom master prozess genauer untersuchen.

/J

[ofox]

(10-27-2009 06:04 AM)joximu Wrote:  1. lauft der mail() Befehl bei den Kunden - mit und ohne 777 auf maildrop?
2. lauft der mail() Befehl in der master domain (eigene php datei im ispcp-document root testen) - mit und ohne 777 auf maildrop?

falls da unterschiede bestehen, dann würde ich doch die php.ini vom master prozess genauer untersuchen.

/J

1. ja
2. ja
es wird immer auf maildrop zugegriffen. Wo soll ich in der php.ini schauen, und wonach suchen?

[joximu]

Also in beiden Fällen muss maildrop die 777 haben (auch bei Kundendomains?), um den mail() Befehl zu nutzen...

Hm, sehr seltsam...

Und apache-Fehler, suexec-fehler oder php-fehler gibt's keine dazu?

/J

[fulltilt]

(07-15-2009 09:33 PM)Sascha833 Wrote:  

Code:

FATAL: Could not load /lib/modules/2.6.29.5-vs2.3.0.36.14-beng/modules.dep: No such file or directory

Da fehlen auf jeden Fall einige Kernel Module ... hatte ich auch mal bei einer XEN Installation, am besten Kernel Upgrade machen mit neueren Sourcen.
Wie hast Du den Umzug durchgeführt?
DB importiert und dann die ISPCP confs und User neu generiert ...
Sieht nach einem Berechtigungs Problem aus - UID von vmail in der /etc/passwd gleich mit der in Deiner ispcp.conf ?

[ofox]

(10-28-2009 10:29 AM)joximu Wrote:  Also in beiden Fällen muss maildrop die 777 haben (auch bei Kundendomains?), um den mail() Befehl zu nutzen...

Hm, sehr seltsam...

Und apache-Fehler, suexec-fehler oder php-fehler gibt's keine dazu?

/J

apache-Fehler, suexec-fehler oder php-fehler - habe ich keine entdeckt nur den 500! und im default.log stand halt postdrop: permission denied..

[joximu]

Echt seltsam, dass im web-log (default.log ist ja vom apache... oder?) der postdrop vorkommt...

hast du schon http://www.ureader.de/msg/12012646.aspx gelesen?