Beiträge von Seppelchen

    Der Server lautet: server.domain1.tld .
    Wenn man nun die Anleitung KB #13 betrachtet ließt man folgendes:

    Zitat

    Die Verwendung dieser Protokolle erfordert leider einige manuelle Einstellungen, welche im Folgenden beschrieben werden:


    Sie benötigen eine Subdomain, auf welcher die Autokonfigurations-Anfragen bearbeitet werden können - z.B. autodiscover.musterhost.com. Richten Sie in LiveConfig (z.B. als admin unter Mein Hosting) auf irgend einem Webserver einen Hosting-Vertrag mit dieser Subdomain ein. Dieser Vertrag benötigt lediglich ein MB Webspace, ansonsten nichts (kein PHP, kein CGI, etc.).


    Richten Sie außerdem ein SSL-Zertifikat für diese Subdomain ein, so dass ein Zugriff via HTTPS möglich ist. Achten Sie darauf, dass das Zertifikat von einer offiziellen Zertifizierungsstelle (CA) ausgegeben wurde, da es ansonsten während der Autokonfiguration zu irritierenden Warnmeldungen kommt.


    Der Satz: "SSL-Zertifikat für diese Subdomain ein" --> sagt mir Schütze per SSL deine Muster - Sudomain im speziellen Fall mailconfig.domain1.tld --> Das haben wir ja eigentlich getan.


    Der Server selbst nennt sich wie erwähnt: server.domain1.tld. Für diesen wurde ebenfalls per LC ein Zertifikat hinterlegt. (lt. KB Anleitung wie man den Server per SSL schützt)


    Deshalb stellt sich mir nun die Frage, wie nun das SSL Zertifikat genau sein muss, damit kein Fehler mehr kommt.


    Der CNAME: autoonfig war falsch es sollte igentlich autoconfig und autodiscover werden. ;)


    Wozu soll der Eintrag sein: . IN MX 10 mail oder ähnliches1

    Hallo,derzeit lautet der Eintrag
    Einträge
    CNAME: autoconfig und autodiscover CNAME mailconfig.domain1.tld
    MX: leerer Wert MX server.domain1.tld
    A: mail A IP des Servers


    Der Server nennt sich server.domain1.tld


    In CN: http://www.mailconfig.domain1.tld und SAN mailconfig.domain1.tld


    Sollte das Zertifikat nur für mailconfig.domain1.tld sein ? Theoretisch spielt das ja keine Rolle oder?


    domain1.tld stellt ein Bsp dar.

    Hallo, wir haben in unserem Kundenaccount folgende .htaccess Datei gelegt:


    Apache Configuration
    AddDefaultCharset UTF-8
    
    
    RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l
    RewriteRule .* index.php [L]


    Leider funktioniert diese Regel aber nicht... mod_rewrite ist aktiviert.


    P.s. Ein Test rewrite zu google geht aber. Wir haben auch das 1:1 von Confixx kopiert da ging es aber noch.


    Im Log ist nur das zu sehen:
    [Sat Aug 31 11:40:14 2013] [error] [client xxx] Negotiation: discovered file(s) matching request: /var/www/web123/htdocs/index (None could be negotiated)., referer: https://www.subdomain.domain.de/


    -> Daraufhin habe ich in .httpd.conf folgendes eingefügt:


    Code
    AddType application/x-httpd-php .php


    Dann geht es. Fazit: Es sollte ggf. dieser o.g. AddType automatisch beim erstellen eines Vertrages gesetzt werden.
    Ist das möglich oder ist bei mir da nur ein Fehler?

    Das war die Antwort die wir beim senden erhalten hatten:


    Final-Recipient: rfc822; blabla-test@freenet.de
    Action: failed
    Status: 5.0.0
    Remote-MTA: dns; mx.freenet.de
    Diagnostic-Code: smtp; 550 inconsistent or no DNS PTR record for 62.***.4*.***
    (see RFC 1912 2.1)


    Diese o.g. IP Adresse war die alte IP die vorher aktiv war. Also muss die IP ja theoretisch noch wo gestanden haben....

    Hallo Herr Keppler, das haben wir getan. Derzeitige Erkenntnis:
    Es wird kein Fehler geschrieben, da bei einem Updateprozess, generell der erste Satz zum Update auftaucht. Nur danach zeigt er nichts weiter an, sprich deaktivieren Plugin, aktivieren Plugin.
    Er zeigt somit lediglich die Schritte nicht an, machen tut er es aber. (das Update)
    Wenn wir dann von der selbst installierten PHP 53 zu dem Server PHP 54 umstellen wird es ja angezeigt. Wir finden jedoch den Fehler nicht.


    Denn der Error Log spuckt nichts dazu aus.
    --> Wir haben gerade nochmal Ihre Vorgehensweise geprüft und es wird noch immer kein Fehler erstellt. Bsp. bei einer Installation bleibt er beim Punkt:
    Installiere Plugin: Signature Watermark 1.7.11
    Runterladen des Installationspakets von http://downloads.wordpress.org/plugin/signature-watermark.1.7.11.zip…


    stehen und dann macht er nicht weiter. Installieren tut er es trotzdem... Nur der Text fehlt wo man u.a. auf Plugin jetzt aktivieren klicken kann.


    Wenn man dann das gleiche auf der von Haus aus installierten PHP 54 probiert geht es. Nur bei der im Nachgang installierten PHP 53 geht es nicht.


    Da muss irgendwo LC oder PHP ein Problem haben...:/

    Hallo,


    wir haben derzeit bemerkt, dass es bei Änderungen welche an der php.ini über das LC gemacht werden 2x speichern klicken bedarf, bis es die Änderungen beim Kunden übernimmt.


    Sprich wenn wir ein was ändern wollen müssen wir es speichern und Vorlage übernehmen klicken und dann das gleiche nochmal bis die Änderung übernommen wird.


    Wir nutzen Debian Seq.


    Oder dauert das immer nur eine Weile?

    Hallo, wir haben nun hier mal einen Auszug aus dem error log:


    [Fri Aug 30 13:04:09 2013] [notice] Graceful restart requested, doing restart
    [Fri Aug 30 13:04:12 2013] [emerg] [client 93.197.21.34] (22)Invalid argument: mod_fcgid: can't lock process table in pid 14376, referer: http://www.domain.de/domain-ad…?action=do-plugin-upgrade
    [Fri Aug 30 13:04:12 2013] [warn] RSA server certificate CommonName (CN) `http://www.subdomain.domian.tld' does NOT match server name!?
    [Fri Aug 30 13:04:12 2013] [notice] Apache/2.2.22 (Debian) mod_fcgid/2.3.6 PHP/5.4.4-14+deb7u3 mod_ssl/2.2.22 OpenSSL/1.0.1e configured -- resuming normal operations
    [Fri Aug 30 13:04:12 2013] [warn] long lost child came home! (pid 14355)


    Wir haben nun hier lediglich die Domains umgeschrieben.


    --> Mit dem RSA ist komisch, dass die Meldung kommt, weil da drinne die Autoconfig Adresse / Domain steht...


    Und bei dem anderen Rest sehe ich auch kein Bezug zu dem Wordpress beschriebenen Problem.

    Hallo, das kenn ich den Beitrag, aber wenn ich das nicht setze kommt es dazu das wir diese weiße Seite sehen und nichts an Inhalt. Das Plugin aktualisiert sich trotzdem. Wenn wir den Eintrag drinnen haben sehen wir keine weiße Seite sondern den Update Prozess. Das tmp ist aus Info.php ersichtlich (seitens php.ini LC)
    Aber trotzdem eigenartig. Denn im Confixx vorher ging es noch ohne Probleme .


    Selbst eine frische WORDPRESS Installation hat das Problem mit dem Plugins wenn man es auf LC nutzt.

    Ich denke es musste erstmal Die Frage gestellt sein, ob WP überhaupt den TMP Ordner ohne Modifikation den bereitgestellten LC tmp Ordner nutzen kann. Aber keine Ahnung wie wir das rausfinden.

    Schau ich mir dann nochmal an. Muss ich wider ein Test System nehmen wir haben die Änderung gestern Abend schnell wieder rückgängig gemacht. :) oder ich auch die mal noch raus.

    Als suPHP. Welche Rechte sollen nicht stimmen? Die von WP sind alle ok. Die frage ist eher warum geht es nur wenn ich den tmp Ordner in wp-content (wo man sonst keinen tmp Ordner hat) anlege und es in der wp-config schreibe. Siehe ersten Post. Das ist für mich fraglich warum es nicht auch ohne diesen Nachtrag geht...:(