Beiträge von WebOscar

Ich freue mich auf Eure Rückmeldungen!

Nachtrag und Zusammenfassung!

Wenn man zusätzlich noch CNAME-Records für mail, smtp und imap anlegt, funktioniert die einfache Einrichtung - quasi para-autoconfig - auch mit eMail-Programmen, die stumpf ausprobieren! Mit Aquamail habe ich es gerade ausprobiert und das lief rund.

Zusammengefasst also so: (vereinfacht - Umsetzung entsprechend eingesetztem DNS-Frontend)

autodiscover.kundendomain.tld        A      0.0.0.0
autoconfig.kundendomain.tld          CNAME  autodiscover.anbieterdomain.tld


_autodiscover._tcp.kundendomain.tld  SRV    100 443 autodiscover.anbieterdomain.tld


mail.kundendomain.tld                CNAME  mx-server.anbieterdomain.tld
imap.kundendomain.tld                CNAME  mx-server.anbieterdomain.tld
smtp.kundendomain.tld                CNAME  mx-server.anbieterdomain.tld

Viel Erfolg damit!

An einigen Stellen, hier im Forum, wurde das Thema bereits angeschnitten. Richtet man Autodiscover so ein, wie es im kb#13 beschrieben ist, funktioniert es grundsätzlich. Nur Outlook wirft jedes Mal einen Zertifikatsfehler, da das Zertifikat der Domäne, die das Autodiscover-XML ausliefert, nicht zur Domäne des Nutzers passt.

Wir haben diese Einträge:

autodiscover.kundendomain.tld cname autodiscover.anbieterdomain.tld
autoconfig.kundendomain.tld cname autodiscover.anbieterdomain.tld

Outlook fragt per default https://autodiscover.kundendomain.tld und bekommt zur Antwort das Zertifikat von autodiscover.anbieterdomain.tld.

Nun wird hier und da angemerkt, dass sich dieses Problem lösen ließe, wenn ein SRV-Record angelegt wird, da Outlook diesen vorziehen würde:

_autodiscover._tcp.kundendomain.tld. 14400 IN SRV  0 0 443 autodiscover.anbieterdomain.tld

Das ist aber leider nicht so. Outlook prüft erst, ob ein solcher Record existiert, nachdem es die HTTPS-Abfrage durchführt. Es kommt also wieder zum Zertifikats-Fehler.

Da offensichtlich ausschließlich Outlook nach autodiscover.kundendomain.tld sucht, könnte man den entsprechenden CNAME-Record doch einfach löschen. In der Folge müsste Outlook nach dem SRV-Record suchen.

Ja - fast! Ich gehe mal davon aus, dass die allermeisten hier per default einen Wildcard-Record für jede Domain setzen, wenn - wie bei uns - ein eigener DNS verwendet wird und nicht die DNS-Funktionalität in LiveConfig. Letztere würde das Problem lösen, da es dann tatsächlich nur Records für existierende Sub-Domains des Kunden anlegen würde. Da es aber bisher keine brauchbare Template-Verwaltung gibt um default-Einträge zu verwalten, fällt das zumindest bei uns aus.

Also, besteht ein WildCard-Record für die Kunden-Domäne und der CNAME-Record autodiscover.kundendomain.tld ist NICHT vorhanden, wird das i. d. R. ebenfalls nicht funktionieren, wenn der WebServer mindestens ein SSL-Zertifikat installiert hat. (Anderes Thema, wurde aber hier auch schon besprochen). In diesem Fall (probiert es gerne einmal aus) führt ein HTTPS-Request dazu, dass - selbst wenn für die angefragte Domain kein Zertifikat eingerichtet ist - der WebServer offensichtlich das alphabetisch erste Zertifikat nimmt und damit antwortet. Somit bekommt der Kunde ggf. ein völlig fremdes Zertifkat ausgeliefert, was (wiederholt) zu besorgten Anfragen führt.

Abgesehen davon liefert der WebServer dann auch kein Autodiscover-XML aus.

Lösung (vielleicht nicht schön, aber läuft):

Ich habe bei den Kundendomains, mit denen ich getestet habe, den CNAME-Record autodiscover.kundendomain.tld gegen einen A-Record auf 0.0.0.0 getauscht. Der CNAME-Record autoconfig.kundendomain.tld auf autodiscover.anbieterdomain.tld bleibt aber bestehen, damit Thunderbird bedient werden kann! Außerdem habe ich natürlich den o. g. SRV-Record gesetzt.

Voilà! Ab jetzt gibt es keine gruseligen Zertifikats-Fehler mehr. Outlook richtet ohne Meckern bei Angabe von eMail-Adresse und Passwort das Konto ein.

Hoffe, diese Problemanalyse nebst Lösungsansatz hilft weiter!

Grüße,

Oskar

Genau die gleiche Frage wollte ich auch gerade stellen.

Die Vorteile eines durch LC verwalteten DNS liegen auf der Hand. Kein manuelles Nachsteuern mehr, wenn der Kunde von Apache auf nginx wechselt. A-Records für Sub-Domänen werden automatisch aktualisiert. Perfekt! Aber die Möglichkeit von Zonen-Templates für eben genau den von bfal angeführten Zweck und SPF-Records (!) (oder noch andere) fehlt.

Gibt es dazu ggf. schon ein "undocumented Feature" oder ist das zumindest in Arbeit?

Grüße,
Oskar

Jup! Stichwort: "Server erfordert Authentifizierung". Zu finden in den SMTP-Einstellungen.

Grüße,

Oskar

Hallo,

das Problem dürfte allen hier bekannt sein. Kunde betreibt x Domains und legt für jede Domain eine Catchall-Adresse an, die er dann an sein Postfach bei AOL, GMX, 1&1 usw. weiterleitet.

Jeder SPAM, der ja leider nicht von Spamassassin gefiltert wird, wird so dem letzten Server angelastet, der die Nachricht bei dem fremden Postfach abliefert. Dies führt regelmäßig zu Schwierigkeiten bei der Zustellung regulärer Mails unserer Kunden an Empfänger der fremden Mailanbieter bis hin zu Blacklisting.

Daher die Frage: Wie kompliziert ist es, eine Routine in LC einzubauen, die eben Catchall-Weiterleitungen in eigene Postfächer zulässt aber auf externe Postfächer grundsätzlich verbietet?

Hallo Herr Keppler. Ich bin schon etwas empört über diese Frage! Aber es gibt Fragen, die man einfach stellen muss!

Selbstredend ist das so eingestellt. Aber - jetzt wird's peinlich für mich - meine Kurzssichtigkeit mit der bereits deutlich spürbaren Altersweitsicht hat mich etwas anderes übersehen lassen.

Wenn man bei einer Domain also HTTPS-Zugriff aktiviert, ist per Default "Webspace deaktiviert" ausgewählt. Und da kein Unterverzeichnis ausgewählt werden muss, ist mir das nicht aufgefallen.

Anstatt jetzt zu schrieben, dass es "wie von Geisterhand plötzlich geht", entschuldige ich mich für meine selektive Blindheit und Ihre verbrannte Zeit. Oh je - wie blind kann man sein?

Vielen Dank für Ihre Bemühungen!

Hallo Herr Keppler,

vielen Dank schonmal.

Ich hatte oben vergessen zu erwähnen, dass ich via netstat kontrolliert habe, ob überbaupt auf 443 gelauscht wird. Ja, wird! Auf der Apache-Default und auf der explizit zugewiesenen IP. mod_ssl ist ebenfalls an.

Dann habe ich die sites-enabled/ mit dem anderen WebServer verglichen, ob da noch irgendwelche Leichen zu finden sind. Nein, abgesehen natürlich von den Kunden-Configs gibt's nur die 000-default und die entspricht auch jeweils dem anderen Server. Allerdings ist gibt es da schon unterschiede im <IfModule mod_ssl.c>-Block.

Auf dem älteren lcclient (Debian squeeze) sieht der Bereich so aus:

<IfModule mod_ssl.c>
  SSLHonorCipherOrder on
  SSLCipherSuite !aNULL:!eNULL:!EXPORT:!ADH:!DES:!DSS:!LOW:!SSLv2:RC4-SHA:RC4-MD5:ALL
  Listen x.x.x.70:443
  NameVirtualHost x.x.x.70:443
  Listen x.x.x.81:443
  NameVirtualHost x.x.x.81:443
  Listen x.x.x.84:443
  NameVirtualHost x.x.x.84:443
</IfModule>

auf dem jüngeren, mit Debian wheezy so:

<IfModule mod_ssl.c>
  SSLProtocol ALL -SSLv2
  SSLHonorCipherOrder on
  SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK
  Listen x.x.x.49:443
  NameVirtualHost x.x.x.49:443
  Listen x.x.x.59:443
  NameVirtualHost x.x.x.59:443
</IfModule>

Also deutlich mehr Spezifikation.

Ich habe keine Ideen mehr und hoffe auf den entscheidenden Hinweis von Ihnen.

Hallo,

Ein Kunde benötigt für seinen Umzug auf unseren Server SSL (nicht SNI) für seine Seite. Dazu habe ich für den betroffenen Server eine neue IP-Gruppe mit der exklusiven IP angelegt. Diese Gruppe habe ich dem Reseller-Vertrag exklusiv zugeordnet.

Im Reseller habe ich die IP-Gruppe exklusiv dem Kundenvertrag zugeordnet.

Im Kundenbereich wurde, nachdem Schlüssel, Zertifikat und CA importiert wurden, die Domain auf die exklusive IP umgestellt und das SSL aktiviert.

Bei dem Versuch die Seite via https aufzurufen kommt der Fehler "Fehlercode: ssl_error_rx_record_too_long".

Daraufhin habe ich die Konfiguration des Kunden unter /etc/apache2/sites-available/xyz123.conf kontrolliert. Es wird zwar der Bereich "# IP group 'xyz123ssl'" angelegt, aber ein :443-Bereich fehlt gänzlich. Auch nachdem ich MEHRFACH die Domain editiert habe, das SSL-Zertifikat gelöscht und neu angelegt, sogar die IP-Gruppe von Grund auf entfernt und unter anderem Namen wieder angelegt habe, ändert sich daran nichts.

Schließlich habe ich versucht, über die LC-eigene Funktion ein SSL-Zertifikat zu erstellen. Es wird zwar alles klaglos angenommen aber im Ergebnis ändert sich nichts.

Auch ein Versuch über die Standard-IP des Servers und SNI blieb erfolglos.

Die SSL-Zertifikats-Dateien werden auch nicht in den entsprechenden /etc/ssl/-Verzeichnise angelegt.

Während aller Versuche habe ich mehrfach den LiveConfig Server-Dienst und alle Client-Dienste durchgestartet. In den Logfiles findet sich kein Hinweis auf ein Problem.

System:

LiveConfig Server: Debian Squeeze, liveconfig: 7.3 R2934
LiveConfig Client: Debian Wheezy, lcclient: 7.3 R2934

Auf diesem Server wurde bisher kein Kunde mit SSL angelegt. Auf dem LiveConfig-Server selbst und einem anderen Client laufen Präsenzen mit SSL - sowohl SNI, als auch exklusiv. Und seit der Anlage des letzen SSL-Zertifikats hat es einige LiveConfig-Updates gegeben. Daher wage ich mich jetzt auch nicht auszuprobieren, was passiert, wenn ich auf einem der beiden anderen WebServer ein Zertifikat ändere/anlege/zuordne.

Ich bitte dringend um Prüfung!

Viele Grüße,

Oskar Groh

Hallo,

ohne entsptrechendes Plugin, dass die Verbindung über LiveConfig -> SMTP und IMAP-Server herstellt, gibt es da keine Möglichkeit. Mir ist jetzt auch nicht bekannt, dass sich da schon jemand mit beschäftigt hat.

Spricht denn etwas dagegen, den Nutzern die Anmeldung über ihre eMail-Adresse in das LiveConfig-Panel zu gestatten?

Grüße!

Stimme zu!

Funktioniert eigentlich recht einfach. A-Record für die (Sub-)Domain auf die IP setzen, TTL abwarten, läuft.
Weil es recht häufig vorkommt, dass Kunden keine Verbindung zu anderen Ports, als den http und https Standard-Ports aufbauen können (z. B. aus Firmennetzen heraus), haben wir dem LC-Server eine zusätzliche IP spendiert und lassen LC dort auf standard-Port 443 lauschen. Funktioniert nicht, wenn sich der Webserver und der LC-Login eine IP teilen! Wenn dem so ist, dann muss LC auf einem anderen Port lauschen. Der A-Record (oder auch ein CNAME-Record) funktionieren aber auf jeden Fall.

Zusätzlich noch saubere SSL-Zertifikate für die (Sub-)Domain und alles läuft rund.

Hallo Moritz,

kurze Antwort: Nein.

Lösungsansatz: Sub-Domain.

Grüße,
Oskar

Unzip ist installiert. Die Dateien sind ja auch da - nur eben nicht fertig vorkonfiguriert.

"Überwiegend" FastCGI. Bin mir jetzt nicht sicher, ob ein Nutzer auch eine andere Variante im Vertrag hat. Bei meinem Account um den es gerade geht läuft FastCGI.

Hallo Herr Keppler,

das erste Problem war ein altes: http://www.liveconfig.com/de/f…%BChrt-Apache-ins-Nirvana
Auch dieser Thread bietet keine Lösung: http://www.liveconfig.com/de/f…-mit-xcache-Konfiguration
Das Problem tritt ja schon auf, wenn ein rohes System aufgesetzt wird - ohne xcache, apc oder ioncube. Nur ein Debian 7 oder 8, Apace und Zend Guard Loader. Reload - Apache 100% und Ende! Das ist jetzt aber nicht Thema.

Nachdem ich nun den Zend Guard Loader rausgeschmissen habe, läuft die installation zumindest schon bis zum Punkt "wird entpacht...". Dann wieder nix. Die grünen Häkchen springen wieder zur Sanduhr um und die Installaton zeigt einen Fehler an. Fehler: Gallery installation failed.

Die Datenbank wird jedoch angelegt und auch das App-Verzeichnis wird nun, da der Zend Guard Loader nicht mehr stört, angelegt. Wenn ich die Sub-Domain aufrufe, erscheint die Gallery-Ijstallation aber einen Schritt zu früh. Ich werde nach Pfad und Datenbank gefragt. Die unvollständige Installation lässt sich jetzt auch wieder über LC entfernen. Nicht jedoch die von gestern

Und jetzt kommts: Kein Fehler im liveconfig.log. Nur der Eintrag, dass eine Datenbank angelegt wurde.

Ich habe, wie von ihnen beschrieben das Verzeichnis ~/logs/priv angelegt und es in Nutzer und Gruppe dem entsprechendem Nutzer übergeben. Ich habe sowohl unter ~/conf/php5 als auch - da der Nutzer eine angepasste php.ini besaß - unter ~/.php5 chattr -i auf php.ini ausgeführt und log_errors auf on gesetzt. Jedes Mal ein Apache Restart hinterher und ein neuer Install-Test. Schließlich habe ich ~/.php5 rausgeschmissen, eine Änderung über LC auf einer der Domänen des Nutzers gespeichert und erneut probiert.

Es bleibt dabei. Abbruch der unvollständigen Installation und keine Anlage eines Logfile unter ~/logs/priv - auch nicht, nachdem ich in meiner Verzweifelung das Verzeichnus auf mod 777 gesetzt habe.

Für weitere Vorschläge bin ich zu haben!

Viele Grüße,

Oskar Groh

Hallo,

nachdem ich die Suche bereits mit diversen Begriffen bemüht habe und schließlich spätestens hier "terminated with exit code 11" ein Treffer hätte auftauchen müssen - melde ich hiermit ein Problem.

Auf unserem LiveConfig-Business-Server ist es unmöglich Apps zu installieren. Auf den Basic-Servern unter lcclient läuft es hingegen problemlos. Ich finde das Problem nicht. Anmerkung: Es lief bereits auf dem Server. Es sind einige Apps installiert.

Problem: Egal welche App! Die Installation beginnt nach der Abfrage benötigter Daten mit dem Download ... die Sanduhr wird zum Kreisel und wieder zur Sanduhr und dann passiert nichts mehr. "Anlegen der Datenbank" und "Entpacke Anwendung" bleiben mit der Sanduhr stehen.

Version: 1.6.4-r2534

Im /var/log/liveconfig/liveconfig.log findet sich dann sowas:

[2013/10/20 18:43:17.942299] [2359|2361] Program 'wai-gallery-3.0.9-1.php' terminated with exit code 11

oder - falls das Install-File noch nicht im Cache ist:

[2013/10/20 18:45:15.878440] [2359|2360] Connecting to update.liveconfig.com ([88.198.223.75]:443)...

[2013/10/20 18:45:15.907622] [2359|2360] Requesting installer file 'wai-wordpress-3.6.1-1.php.gz'...

[2013/10/20 18:45:34.364330] [2359|2362] Program 'wai-wordpress-3.6.1-1.php' terminated with exit code 11

Im Verzeichnis /var/cache/liveconfig/downloads finden sich die entsprechenden Files, auch nachdem ich sie vorher gelöscht habe.
Im Verzeichnis /var/cache/liveconfig/installer finden sich die entpackten .php-Files, auch nachdem ich sie vorher gelöscht habe.

Die Datenbanken werden in der Übersicht des Nutzers angezeigt, aber mit einer Sanduhr dahinter (wird angelegt). Die Sanduhr verschwindet erst nach einem Restart von LiveConfig.

Die App-Verzeichnisse im Nutzerordner apps/ werden nicht angelegt.

Die Anwendungen werden angezeigt mit dem Status: Fehler: Error while downloading package

Es ist unmöglich über das Panel die Anwendungen wieder zu löschen. Bei dem Versuch werden folgende Zeilen ins Log geschriben:

[2013/10/20 19:08:32.000621] [3376|3376] Can't chdir() to '/var/www/prv1/apps/wp2test': No such file or directory
[2013/10/20 19:08:33.001376] [3255|3256] Program 'wai-wordpress-3.6.1-1.php' terminated with exit code 256

Die Anwendung bleibt dann bis in alle Ewigkeit im Status "Deinstallation..." hängen.

Ich weiß nicht, was ich noch kontrollieren soll.

Bitte dringend um Unterstützung.

Viele Grüße,

Oskar Groh

Ja schon. Allerdings habe ich den Test hier lokal mit Debian 7 auf der HyperVM mit dem Net-Install-Image von Debian installiert. Dürfte auf's gleiche rauskommen. Probieren werde ich das aber auch nochmal.

Also, frisch installiertes Debian 7 - nur der Apache, PHP5 und ZendGuradLoader als HyperV-Instanz - gleiches Problem.
Diese Installation mit dem letzten Testing-Kernel 2.6.32-042stab078.22 - gleiches Problem.

Verzweifeln! ... Eingebung!

Ich habe auf dem scharfen Server, auf dem das Problem zum ersten Mal von mir erkannt wurde, mod_php entfernt, da es ohnehin nicht genutzt wird und alles über fastcgi läuft. Problem verschwunden, gSales läuft, keine sporadischen SegFaults im Apache-Error-Log!

Nur eines bleibt:

:/# php5 -v
PHP 5.3.26-1~dotdeb.0 with Suhosin-Patch (cli) (built: Jun 9 2013 03:35:34)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2013 Zend Technologies
with Zend Guard Loader v3.3, Copyright (c) 1998-2010, by Zend Technologies
with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH
Segmentation fault

Ich weiß noch nicht, ob mich das nun sorgen soll oder nicht. Ich lasse es jetzt erst mal so laufen.

Gute Nacht!

Dankeschön! Also der ionCube kann's nicht sein, weil er garnicht geladen wird. Das Problem tritt ja schon auf, wenn nach der Grundinstallation nur der ZendGuardLoader geladen wird. Dann gibt's, wie problay.de geschrieben hat, den 100%-Apache-Prozess. Allerdings nur in der VE, nicht auf der Hardware, da steigt der Apache einfach aus. Sowohl in der VE als auch auf der Node selbst mit einem Segmentation Fault im Apache Error-Log.

Was ich jetzt sehe, ist dass problay.de einen Testing-Kernel nutzt während ich doch etwas konservativer den letzten Stable nutze. Auch ich hab' den mit alien konvertiert.

Aber das ist ein Ansatz. Während ich gerade im Hintergrund auf einer HyperV ein Debian 7 installiere um den Test nochmal zu machen, ziehe ich mir mal den letzten Testing-Kernel auf die echte Maschine und probier's mal damit. Aber ich werde wohl gleich vom Stuhl kippen... morgen mehr.

Inzwischen bin ich ziemlich sicher, dass es eine Unverträglichkeit zwischen ZendGuardLoader und dem RHEL6-Kernel aus den OpenVZ-Quellen gibt.

Was ich für gewöhnlich nicht mache, nämlich den Apache auf dem Root-Server ohne Virtuelle Instanz selbst zu installieren, bringt das gleiche Problem. Nur, dass hier der Apache nicht hängen bleibt, sondern sich mit einem SegFault einfach verabschiedet. Auf Hardware-Level ist er also einfach neu zu starten und er läuft dann bis zum nächsten reload.

In der VE kann der Apache auch neu gestartet werden, wenn vorher ein killall -KILL apache2 abgesetzt wird.

ein php5 -v ergibt sowohl auf der Hardware-Node als auch in der VE:

PHP 5.4.4-14 (cli) (built: Mar  4 2013 14:08:43)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
    with Zend Guard Loader v3.3, Copyright (c) 1998-2013, by Zend Technologies
Segmentation fault

Also bereits hier ein SegFault.

Ich gebe für's Wochenende auf. Ich werde es dann am Montag nochmal mit strace versuchen. Außerdem noch richtig pervers: Ich werde unter VMWare ein Debian Installieren und hier einmal mit dem Kernel aus Debian und anschließend nochmal mit dem Kernel von OpenVZ probieren, ob es zum selben Ergebnis kommt.

Hallo Herr Keppler,

exakt so wie in Ihrem Beispiel, nur in meinem Fall ein anderer Pfad zum ZendGuardLoader.so und FastCGI, als mich das Problem zum ersten Mal traf.

Inzwischen habe ich es in allen Kombinationen aus Squeeze, Wheezy, mit und ohne FastCGI, suPHP und mod_php auf verschiedenen Maschinen, Original-PHP aus Debian oder aktuelle aus dotdeb.org und mit absolut sauberen Apache-Installationen probiert. Die Einzige Konstante ist, dass es sich dabei immer um OpenVZ-Container handelt und ich die Kernel aus den OpenVZ-Quellen nutze und nichtg die veralteten Debian-Kernel.

Ich werde das gleich mal stumpf auf meinem Notebook unter Linux Mint probieren.

Viele Grüße,

Oskar Groh