Beiträge von Robert

Scheinbar funktioniert das nicht, denn sonst hätte die Beschränkung auf 16 MB aus deinem ersten Beitrag ja auch für die phpinfo gelten müssen, die über die Hauptdomain abgerufen wurde.

Gibt es nicht vielleicht noch eine Einstellung bei der Subdomain, in der du das Memory Limit einstellen kannst? Wenn nicht, kannst du noch versuchen, eine .htaccess in das Verzeichnis zu legen mit diesem Inhalt:

php_value memory_limit 64M

Falls das auch nicht geht, kann ich wohl auch nicht weiterhelfen, dann kannst du höchstens beim Support nachfragen, ob sie dir das Memory Limit auch für die Subdomain einstellen können.

Oh, man kommt bei einem Webhosting-Paket an die php.ini ran? Wenn ich auf meinem vServer Änderungen an der php.ini vornehme, muss ich danach den Apache reloaden, damit der das übernimmt. Und wenn du die php.ini von der Hauptdomain übernimmst? Irgendwo her müssen die 64 MB ja kommen.

Zitat von Th.W;2981

Nennenswert ist eigentlich nur die Veränderung des memory_limit.

Ja genau, und das ist ja auch das Problem hier. Wenn man über den Ordner reingeht, hat man 64 MB Speicher zur Verfügung, über die Subdomain nur 16 MB, und die reichen wohl nicht aus. Wo hast du denn die Sachen eingestellt, die du im ersten Beitrag unter "php.ini" gepostet hast? Versuch doch mal, das Memory Limit wegzulassen bzw. höher zu setzen.

644 reicht auch, das ist 755 ohne Ausführungsrechte, die hier sowieso nicht gebraucht werden.

Liegt vielleicht eine .htaccess-Datei mit im Verzeichnis, die z.B. eine Deny-Anweisung hat?

Funktionieren andere Subdomains? Dann könnte es helfen, die Dateien auszulagern, die Subdomain zu löschen und neu anzulegen und dann die Dateien wieder zurückzuspielen.

Achso. Da du die php.ini gepostet hattest, dachte ich, es sei ein vServer.

Die Fehlermeldung kommt wie gesagt, sobald man einen Beitrag anklickt, z.B. den hier. Ich hatte dann gar nicht mehr weiter ausprobiert, mit dem Ordner geht es... sehr merkwürdig. Du könntest mal eine Datei mit [PHP]<?php phpinfo(); ?>[/PHP] in den Ordner legen und vergleichen, ob irgendwelche Werte sich je nach Zugriffsart unterscheiden. Danach am besten gleich wieder löschen.

Die Standardrechte müssten 755 sein, also rwxr-xr-x. Ist das bei dir der Fall? Dann müsste der Apache die Dateien zumindest lesen können. Vollständig hochgeladen sind alle Dateien?

Die error.log befindet sich je nach System und verwendetem Control Panel (Confixx, Syscp..) an anderen Stellen. Mögliche Anlaufstellen sind aber /var/log/apache2 und das Verzeichnis für die Seite (ich habe bei mir z.B. auf gleicher Ebene wie der httpdocs-Ordner einen Ordner logs mit den Logs für diesen vHost eingerichtet). Oder hast du ein Webhosting-Paket? Dann weiß ich nicht, ob man da überhaupt dran kommt... Ist die URL der Seite denn geheim? Wenn nicht, könntest du sie mal posten?

Wenn man einen Beitrag von der funktionierenden Adresse aufrufen will, kommt diese Fehlermeldung:

Zitat

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 275 bytes) in /var/www/web66/html/wpb/wp-includes/gettext.php on line 167

Versuch es als einfach mal mit

memory_limit = 32M

Falls das deine komplette php.ini ist, solltest du die vielleicht noch etwas erweitern, exec deaktivieren und so.

Hat sich durch den Serverwechsel die URL geändert? Dann musst du diese Angaben in den Optionen ändern. Falls du da auch nicht rankommst, kannst du die Werte auch in der Datenbank ändern (Tabelle [prefix]_options, bei "siteurl" und "home"). Allerdings dürfte das eigentlich keinen 403 auslösen...

Welche Rechte sind denn momentan gesetzt? Rechteprobleme gibt es normalerweise nur beim Schreibzugriff, das reine Lesen ist normalerweise bei neuen Dateien für jeden (also auch den Apache) erlaubt. Findet sich in der error.log ein Hinweis, auf welche Datei/Verzeichnis der Zugriff verweigert wurde?

Wie mountest du denn ein Laufwerk auf einem vServer?

Wie sim4000 schon korrekt aus der Fehlermeldung herausgelesen hat, liegt das Problem auf Dateiebene, der Apache-Benutzer (bei dir komischerweise wwwrun, das ist nicht Debian-Standard) hat nicht die nötigen Zugriffsrechte auf die Datei. Die Zeile bedeutet, dass der Besitzer (testuser) die Datei lesen (r) und schreiben (w) kann, aber sie nicht ausführen (x). Letzteres ist auch nicht nötig, es ist ja kein Shell-Skript. Die Gruppe (users) und der Rest der Welt (sprich auch dein Apache) haben aber keinerlei Zugriffsrechte. Daher müsste die Datei mindestens lesbar für alle sein, oder du steckst den Apache mit in die Gruppe users und gibst der Gruppe Leserechte. Ich würde aber ersteres empfehlen. Der Befehl dafür steht zwei Beiträge weiter oben, in Kurzschreibweise

chmod 755 datei.jpg

Ansonsten werden die Standardrechte beim Anlegen neuer Dateien soweit ich weiß mit umask festgelegt. Wenn ich einfach "umask" ausführe, erscheint bei mir "0022", was 777 (alle Rechte für jeden) minus 755 ist. Proftpd hat da aber eine eigene Einstellung für.

Was mir aber gerade auffällt: Welche Datei rufst du denn auf? Im Errorlog steht ja eine andere Datei als in deinem Beispiel. Wird da irgendwas per mod_rewrite umgeschrieben? Und hast du eigentlich Debian oder Open Suse?

Zitat von DavidR;2890

Also Leute erstmal muss ich sagen das das mit dem RAM verbrauch natürlich quark von euch war. Genau wie ich vermutet habe.

Könntest du dich bitte etwas vorsichtiger ausdrücken? Wir werden nicht dafür bezahlt, dass wir hier antworten.

Die Werte habe ich damals von top abgelesen. Ich hatte mir einen CalDAV-Server installiert (müsste Chandler gewesen sein), der Java benötigt. Ich habe mich dann gewundert, warum der Server so langsam wurde und habe mit top festgestellt, dass der normale RAM voll war und schon einiges in den Swap ausgelagert werden musste. Bei java standen dann die erwähnten 260 MB, was mich dazu veranlasst hat, alles schnellstens wieder runterzuschmeißen. Wenn es bei dir funktioniert ist das ja um so besser.

Bist du sicher, dass du Java auf einem vServer installieren willst? Ich habe das auch mal versucht, aber Java dann schnellstens wieder runtergeschmissen, als es allein ~260 MB RAM belegt hat. Dazu kamen natürlich noch Apache etc.

Der Vollständigkeit wegen noch diese Konfiguration für rinetd:

localhost	12345 server.domain.de	80

Bzw. mit dem Eintrag in /etc/services:

localhost	meinservice	server.domain.de	80

Dürfte für eine reine Weiterleitung übersichtlicher sein.

Ich hab noch rinetd laufen: "rinetd redirects TCP connections from one IP address and port to another".

Ich habe quota installiert, allerdings ist die /etc/fstab leer, in der spezielle Optionen (usrquota und grpquota) eingetragen werden müssen. Dementsprechend schlägt auch die Berechnung des momentan belegten Speicherplatzes fehl. Kann ich da irgendwas tun? Hilft es etwas, wenn ich ein Ticket an den Support schreibe? Generell scheinen Quotas auf vServern ja möglich zu sein (siehe hier).

Ich weiß nicht warum, aber wenn ich 127.0.0.1 vom Server aus anpinge, bekomme ich Antworten...

Zitat von sim4000;2806

Ob das sinn macht, ist mir aber auch erst mal nebensächlich. Das Hauptproblem ist halt, wie ich den DNS Servern meines ISPs die Einträge meines BINDs mitteile.

Sind das spezielle Einträge? Ich habe gerade bei meinen Domains mal geschaut, dort gibt es eine API, die z.B. mit PHP angesprochen werden kann (nicht nur, es sind halt Webservices). Dort gibt es unter anderem diese Methode:

Record im Nameserver bearbeiten
real			required	Gibt an, ob die Aktion durchgeführt werden soll
record_id		required	ID des Records, wird bei QueryDomainDetails / AddRecord zurückgegeben
name			required	Name des Eintrages
type			required	A, AAAA, CNAME, HINFO, MX, NAPTR, NS, PTR, RP, SOA, SPF, SRV, TXT, URL
content			required	Abhängig von $type
prio			optional	Bei MX erforderlich

Zitat von dfroe;2799

Ansonsten wüsste ich aber nicht, was für Misstrauen man gegenüber DynDNS & Co. haben sollte. Du musst ja für den DynDNS-Account nicht unbedingt das selbe Passwort wie für dein Mailkonto etc. verwenden. Und allein die IP-Adresse, die dort hinterlegt wird, ist ja sicherlich kein Geheimnis.

Sehe ich auch so. Es ist ja genau das Ziel von DynDNS, dass die IP nicht mehr geheim bzw. unbekannt ist. Das schlimmste was da eigentlich passieren könnte, ist dass die Domain auf einen andere IP umgestellt wird, wenn sie z.B. stark frequentiert ist. Das soll aber keinesfalls eine Unterstellung sein, dass das so praktiziert werden würde, das ist nur der meiner Meinung nach Worst Case.

Könnte man da nicht auch selbst ein Skript schreiben, das beim Start des Servers angestoßen wird?

Bei mir hat es auch im Großen und Ganzen funktioniert, die meisten Probleme hat mein individuell konfigurierter Apache bzw. PHP gemacht. Nun läuft aber alles wieder.