Hallo Herr Tänzer,
ich suche as Ticket gleich mal heraus.
Konkrete Termine für Features lassen sich aber naturgemäß leider nicht nennen. HostingDomainDelete() steht aber für das übernächste Update (v2.3.1) im Projektplan, aktuell arbeiten wir mit Hochdruck an Fertigstellung von v2.3.0.
Viele Grüße
-Klaus Keppler
Glaskugel oder /var/log/mail.log bitte. 
Ist schon bekannt, wann das nächste Update kommt ??
Einen fixen Termin kann ich noch nicht nennen, wir sind aber dabei die v2.3 fertig zu stellen (d.h. "feature freeze", es werden aktuell nur noch die Tests angepasst und Probleme beseitigt).
In den nächsten 2-3 Tagen sollte die Preview fertig sein.
Viele Grüße
-Klaus Keppler
Angenommen die Datei exestiert nicht darf man sie dann nacherstellen?
Welche Datei meinen Sie? Die dovecot.local.conf existiert standardmäßig nicht, daher müssen Sie die (bei Bedarf) anlegen und anschließend im LiveConfig unter Serververwaltung -> Mail die Dovecot-Konfiguration noch mal neu speichern (dann wird die dovecot.local.conf per Include mit aufgenommen).
Siehe Handbuch: http://www.liveconfig.com/de/h…tml#advanced.mail.dovecot
New StartSSL certificates aren't trusted any more, so this is no solution.
We will add DNS authorization within the next 3-4 months, which will be a "clean" solution. Until this feature is available, you can possibly run a minimal NGINX on your mail server (don't need no PHP nor MySQL).
(Actually we do this on our mail servers and redirect visitors to the webmail URL)
Let's Encrypt requires some authorization to prove that you "own" the domain. This authorization can me made via HTTP or DNS, but LiveConfig currently only supports HTTP.
To use eg. "mail.example.org" with Let's Encrypt, you need to set up some (small) webspace and configure the domain with it. The web space can be on another server than the mail server (if you run a multi-server setup) and does not require any features, just 1 MB webspace. You can even configure a redirect eg. from mail.example.org to http://www.example.org.
Then you can configure a Let's Encrypt certificate with LiveConfig and use this with Dovecot & Postfix.
Best regards
-Klaus Keppler
Undzwar habe ich folgende Probleme: Wenn ich mit Let's Encrypt ein SSL Zertifikat erstelle, und die Autokonfiguration davon mit anklicke (alle 3 Kästchen) zeigt die Webseite mir dann an "Sie wurden zu oft weitergeleitet" an was kann das liegen, in der Webseite sind keine http Weiterleitungen etc.
Läuft die Website zufällig mit WordPress?
Unserer Erfahrung nach ist ein häufiges Problem, dass im WordPress-Backend noch die "falsche" Domain aus Haupt-URL hinterlegt ist, und somit die Weiterleitungen im Kreis laufen.
LiveConfig macht nur das, was man über die Oberfläche einstellt. Wenn Sie selbst also keine Weiterleitungen "im Kreis" eingerichtet haben, dann muss das von der Website kommen.
Was genau passiert lässt sich auch ziemlich einfach z.B. mit Firebug o.ä. testen (einfach mal schauen bei welcher URL auf welche URL weitergeleitet wird).
Viele Grüße
-Klaus Keppler
kk: mir fehlt die Dokumentation zu den PHP-Einstellungen (wann welchen Typ, ...) im Handbuch. Habe ich da was übersehen oder gibt es den Teil noch nicht?
Hmm, stimmt... :-| Für uns war das wohl bislang zu selbstverständlich. Wir nehmen das ins nächste Handbuch-Update mit auf (neues Kapitel "php.ini-Einstellungen").
Wenn es ein Problem mit dem E-Mail-Empfang ist, sollte dieses Thema auch so heißen - oder?
Die einzelne Zeile aus dem Log alleine reicht nicht - welche Meldungen tauchen denn sonst noch so auf?
Im Zweifelsfall suchen Sie mal nach der Message-ID ("grep 0019BC12CD /var/log/mail.log").
Bitte posten Sie keine kompletten Log-Files im Forum - besser per Mail an support@liveconfig.com
Update ist aktuell in Arbeit, ich gebe Bescheid sobald es online steht.
Viele Grüße
-Klaus Keppler
Hallo,
hat jemand eine Ahnung wie genau ich opcache für ein bestimmten Webkunden via LC deaktivieren kann? Global geht es ja via opcache.enable=0 aber wie bekomme ich es hin, nur einen bestimmten Kunden zu deaktivieren?
Eigentlich ganz einfach:
Sollte eigentlich reibungslos funktionieren. Ansonsten hilft nur ein Blick in eine phpinfo() (um zu sehen welche php.ini geladen wird).
Viele Grüße
-Klaus Keppler
Ach ja: für FastCGI muss mod_fcgid und mod_suexec aktiviert sein. Prüfen Sie bitte beides (wird in Serververwaltung -> Web angezeigt). Wenn etwas davon fehlt, z.B. mit "a2enmod suexec" aktivieren und optional LiveConfig anschließend neu starten (damit es die Module neu einliest).
Wenn die Seite einfach "weiß" bleibt deutet das meist auf einen Fehler bei der PHP-Ausführung hin.
Die ersten Schritte wären:
Nach ca. 30 Sekunden die Website erneut aufrufen. Unter "Hosting" -> "Webspace" -> Fehlerprotokoll anzeigen sollte dann irgendwas auftauchen, was weiterhelfen könnte.
ich habe in Spamassassins diverse Anpassungen am X-Spam-Status gemacht. Leider werden diese nicht übernommen. Liegt das am LCSAM ?
Ja, der "X-Spam-Status:"-Header wird durch lcsam geschrieben und nicht von SpamAssassin, daher ist der nicht konfigurierbar.
ZitatLeider sind bei mir die "tests" im Mailheader immer leer, obwohl Listen angeschlagen haben.
X-Spam-Status: No score=1.9 tagged_above=3.0 required=5.0 tests=[]
Das war ein Fehler, der mit Version 2.3.0-r4354 behoben wurde (siehe auch bei GitHub) - mit dem nächsten LC-Update ist das also behoben.
Ich habe das irgendwo anders schon mal ausführlich beschrieben. Das ist kein Fehler im klassischen Sinn, sondern eine wohl "suboptimale" Darstellung.
Wenn jemand eine Domain anlegt ("example.org") werden automatisch zwei Subdomains erzeugt: einmal die mit dem Hostnamen "www", und einmal die mit einem leeren Hostnamen ("").
Löscht man nun http://www.example.org, bleibt logischerweise nur noch die Subdomain mit dem leeren Hostnamen (example.org) übrig.
Löscht man auch diese Subdomain, wäre streng genommen nur eine "leere" Domain übrig. LiveConfig kann das derzeit noch nicht separat hervorheben - daher sieht die "leere Domain" genauso aus wie eine Subdomain mit leerem Hostnamen (alles klar soweit?)
Legt man nun eine Subdomain "www" an, dann existiert nur http://www.example.org, nicht aber example.org.
Ich hoffe, etwas Licht in die Sache gebracht zu haben. 
Viele Grüße
-Klaus Keppler
Kurz zur Info: bei einem Update der Zeitzonen-Datenbank sind offenbar einige Verknüpfungen kaputt gegangen 
Im kommenden LiveConfig-Update ist das korrigiert, künftige Zeitzonen-Updates werden wir "anders" machen.
Viele Grüße
-Klaus Keppler
Es sollte eine Subdomain angelegt werden in diesem Fall nbv.mk-xxx.de
Das Problem war, das keine DNS Einträge gemacht wurden somit die Domain keinen DNS Eintrag hat bzw keinen A Eintrag, weil LiveConfig eben eine Subzone angelegt hat anstatt eine Subdomain. Somit funktioniert die Subdomain nicht da kein A-Eintrag vorhanden war.
Woran haben Sie ausgemacht, dass der A-Record nicht angelegt wurde?
Das Bearbeiten von DNS-Einträgen läuft ausschließlich über dynamische DNS-Updates. In der Zonendatei (/var/lib/bind/<Zone>.db) ändert sich dabei in der Regel nichts. Es wird aber von BIND eine Journal-Datei (binär) erzeugt, welche alle Updates protokolliert.
Mit anderen Worten: der Inhalt der Zonen-Datei alleine ist erstmal nicht aussagekräftig. Man kann die Zonendatei aber durch BIND neu schreiben lassen (z.B. mit "rndc freeze <zone>", "rndc thaw <zone>").
LiveConfig schreibt selbst auch keine $ORIGIN-Abschnitte, das macht BIND selbst. Und das ist - wie gesagt - völlig ok und normal. Das geschieht manchmal etwa wenn nur einzelne DNS-Einträge eine abweichende TTL aufweisen. Ohne die vollständige Zonendatei kann ich an dieser Stelle auch nur herum raten...
Die ausnahmslos einzige Möglichkeit um zu prüfen, ob ein gewünschter DNS-Eintrag angelegt wurde ist, diesen direkt beim Primary DNS per "dig" abzufragen:
dig @[I]primary.dns.server[/I] [I]name.der.subdomain[/I] ANYViele Grüße
-Klaus Keppler
Alles anzeigenNein hat er nicht, wir hatte es selber mit einer Test Subdomain probiert und da war es das selbe.
hevert A 79.143.XXX.XXX
hhvision A 79.143.XXX.XXX
house A 79.143.XXX.XXX
insert A 79.143.XXX.XXX
msh A 79.143.XXX.XXX
$ORIGIN nbv.mk-XXX.de.
$TTL 300 ; 5 minutes
So sah die Abfrage auch, die nbv.mk wurde ganz normal als Subdomain angelegt, unsere Test Subdomain sah genauso aus. Nach einem Bind restart und löschen der Subdomain funktioniert es dann wieder wie es sollte. Trotzdem komisch wie sowas passieren konnte.
Ich verstehe das Problem irgendwie noch nicht ganz, mit den Daten kann ich leider nichts anfangen.
Was für eine Subzone nochmal? Wenn BIND eine Zonen-Datei aktualisiert, dann ist es völlig normal dass er identische Subzonen in eigene $ORIGIN-Abschnitte gruppiert.
Bitte beschreiben Sie, was genau gemacht wurde, was genau passiert ist und was daran falsch war.
Also der Syslog gibt folgende Information zurück:
CodeNov 2 10:10:24 web1 named[14531]: dns_dnssec_findzonekeys2: error reading private key file meindomainname.xyz/NSEC3RSASHA1/59090: file not found
Das sagt doch eigentlich schon alles...
Prüfen Sie bitte mal, ob auf Ihrem Primary DNS die Dareien /etc/bind/keys/K<Domain>.+007+<Id>.(key|private) vorhanden sind.
Falls diese nicht mehr existieren (auch nicht im Backup), dann müssen Sie einen neuen DNSSEC-Key für diese Domains anlegen und diesen auch beim Domainregistrar aktualisieren.
Viele Grüße
-Klaus Keppler
Also wir hatten es heute das ein Kunde eine Subdomain angelegt hat und LiveConfig diese als Subzone angelegt hat, wie kann sowas passieren?
Was genau meinen Sie mit "Subzone"?
Wie hat der Kunde die Subdomain angelegt? Hat er evtl. die Berechtigung, eigene Domains hinzuzufügen, und hat dann die Subdomain als Domain angelegt?
