Beiträge von kk

Dieser Fehler ("Incorrect datetime value") wird bei jeder MySQL-Version kommen. Es handelt sich dabei eben um fehlerhafte Daten in der Zeitzonen-Datenbank (tzdata). Einfach ignorieren...

Dieser konkrete Fehler kann ignoriert werden (das handelt sich praktisch um fehlerhafte Daten in der Zeitzonen-Datenbank, das spielt für LiveConfig in diesem Fall aber keine Rolle).

Die Verwaltung von MySQL 5.7 wird aber noch nicht unterstützt, insofern LiveConfig dort noch keine Passwörter ändern kann (das Berechtigungs-Schema hat sich da geändert).

Mit der Unterstützung von Ubuntu 16 (in etwas über einer Woche) sollte das dann aber auch erledigt sein.

Viele Grüße

-Klaus Keppler

Dieser Header wird doch bereits gesetzt...?

X-Virus-Scanned: clamav-milter ### at ###
X-Virus-Status: Clean
X-Spam-Flag: NO
[B]X-Spam-Score: -1.9[/B]
X-Spam-Status: No score=-1.9 tagged_above=3.0 required=5.0 tests=[]

Oh, Dokumentationsfehler.
Schreiben Sie bitte vor den Domainnamen in der /etc/postfix/spamassassin noch ein "@", und führen dann "postmap /etc/postfix/spamassassin" aus. Dann klappt's (eben getestet).

[B][COLOR=#b22222]@[/COLOR][/B]example.org 1 2.5 6.0 1 web123 ***Spam-Verdacht***

Wird beim nächsten Update in die man-Page zu "lcsam" mit aufgenommen...

Die Meldung besagt, dass keine korrekte Kommunikation mit dem entsprechenden Service von Let's Encrypt möglich ist. Vielleicht gibt es dort gerade einen Fehler oder Wartungsarbeiten - versuchen Sie es bitte einfach in 1-2 Stunden noch einmal.

http://www.liveconfig.com/de/h…advanced.lcdefaults.xhtml
mail.spam.enabled, mail.spam.warn, mail.spam.reject

Es ist aber geplant, das mittelfristig auch über die GUI verwaltbar zu machen.

Viele Grüße

-Klaus Keppler

Zitat von weltmeister

Problem: wird von LiveConfig überschrieben.
Kann dieser Zusatz nicht Standardmäßig enthalten sein?

Nein, LiveConfig überschreibt die dovecot.local.conf definitiv nicht.
Wir werden aber prüfen inwiefern wir das evtl. als Standard aufnehmen können.

Hallo,

die PHP-Pakete für Debian wurden eben auf die Versionen 5.5.34, 5.6.20 und 7.0.5 aktualisiert.

Viele Grüße

-Klaus Keppler

Update: ab v2.1.2 erzeugt LiveConfig die /etc/vsftpd/users/<Vertrag> nun auch wenn das Passwort aktualisiert wird und diese Datei nicht (mehr) existiert.

Zitat von lebenszeit

Ob LC beim Start oder zumindest bei neuem Passwört die Existenz von /etc/vsftpd/users/subscriptionname sicherstellen könnte?

Lässt sich kurzfristig umsetzen (sind nur ein paar Zeilen in Lua).

Zitat von Aybee

Dito, das ist bei uns nicht anders.... Der Support per E-Mail ist mehr Schlecht als Recht.

Können Sie uns bitte eine Ticketnummer nennen?
Mit der E-Mail-Adresse aus Ihrem Forumsaccount sind hier zwei Tickets registriert, die beide bearbeitet wurden (12/2015 und 01/2016).

Viele Grüße

-Klaus Keppler

Hmm, in OpenSUSE Leap wurde "httpd2" in "httpd" umbenannt... :-/
Bitte bearbeiten Sie die Datei /usr/lib/liveconfig/lua/apache.lua und ändern in Zeile 329 "/usr/sbin/httpd2" in "/usr/sbin/httpd" (also die "2" entfernen).

Danach sollte LiveConfig erfolgreich starten. Wir führen gleich mal einen Testlauf mit einem "frischen" OpenSUSE 42.1 durch.

Viele Grüße

-Klaus Keppler

Im vorliegenden Fall wurden die SSL-Zertifikate gelöscht (aus der SSL-Verwaltung), daher konnte LiveConfig die beim besten Willen nicht verlängern... :cool:

In Ihrem Fall haben Sie eventuell zu viele Zertifikate für die Domain beantragt (siehe Limits). Bitte suchen Sie mal im LiveConfig-Log nach "webmail.<IhreDomain>". Sie müssten dann entsprechende Fehlermeldungen finden ("too many certificates issued..." oder so ähnlich).

Not Before      Not After       Subject Name
2016-03-12     2016-06-10     CN=dev01en.###
2016-03-12     2016-06-10     CN=dev01.###
2016-02-28     2016-05-28     CN=###
2016-02-22     2016-05-22     CN=autodiscover.###
2016-02-22     2016-05-22     CN=pma.###
2016-02-20     2016-05-20     CN=ww1.###
2016-02-20     2016-05-20     CN=ww3.###
2016-02-20     2016-05-20     CN=ww2.###
2016-02-06     2016-05-06     CN=test.###
2015-12-30     2016-03-29     CN=###
2015-12-24     2016-03-23     CN=autodiscover.###
2015-12-23     2016-03-22     CN=webmail.###
2015-12-23     2016-03-22     CN=pma.###
2015-12-10     2016-03-09     CN=webmail.###

Was im ACME-Tab angezeigt wird ist die Gültigkeit der Domain-Authorisierung (also quasi der Prüfung, dass die Domain Ihnen gehört). Diese ist normalerweise etwa 9 Monate lang gültig.

LiveConfig startet 30 Tage vor Ablauf der Zertifikats-Gültigkeit automatisch die Verlängerung. Eine erneute Validierung ist dabei meistens nicht notwendig - im Grunde ruft LiveConfig einfach "nur" ein neues Zertifikat ab und richtet das ein.
Schicken Sie uns bitte mal einen betroffenen Domainnamen an support@liveconfig.com, wir prüfen dann mal ob eventuell zu viele Zertifikate damit bei Let's Encrypt angefordert wurden.
Im LiveConfig-Log (/var/log/liveconfig/liveconfig.log) sollten Sie zudem Fehlermeldungen finden, wenn etwas nicht geklappt hat (suchen Sie dort einfach mal nach dem betroffenen Domainnamen und/oder nach dem Stichwort "ACME").

Viele Grüße

-Klaus Keppler

Die sichtbaren Informationen sind alle abstrakt (man hat keinen Zugriff auf die Apache-Konfiguration etc.). Eine chroot-Umgebung zu pflegen ist eine äußerst aufwendige Angelegenheit - zumindest wenn man dem User die selbe Umgebung "vorkaukeln" möchte wie die, unter welcher auch Apache (und PHP-Scripte etc.) laufen. Wer das machen möchte, dem steht LiveConfig aber nicht im Weg.
Für eine zusätzliche Abhärtung bei Shared-Hosting-Systemen (z.B. gefilterte Prozessliste) sollte man zudem auf entsprechend gehärtete Kernel (z.B. grsec) zurückgreifen.

Dieser Thread ist uralt. Es macht unserer Meinung nach keinen Sinn, ein Ticketsystem in LC zu integrieren (das sind zwei völlig verschiedene Dinge). Thema geschlossen.

Ich habe den Beitrag mal von "Fehler und Problembehebung" in "Installation und Verwendung" verschoben.

Zur Frage: theoretisch wäre das möglich, praktisch aber ein großes Sicherheitsrisiko. Mit "FollowSymLinks" kann man so nämlich auf alle Daten aller anderen Webspaces zugreifen. Auf jedem System mit mehr als einem Kunden wäre das also grob fahrlässig.
Wenn es um gemeinsam genutzte "globale" Verzeichnisse geht, wäre eventuell ein Bind-Mount die elegantere Lösung (z.B. /var/xyxy nach /var/www/webXXX/priv/xyxy mounten).

Ich werde ich darum kümmern, dass die o.g. Anfragen am Montag bearbeitet werden (ab da ist unser Büro wieder voll besetzt).

Die häufigsten Ursachen für Probleme sind:
- Debian 6 wird noch verwendet (dort lassen sich keine individuellen DH-Parameter im Apache konfigurieren, zudem ist Debian 6 inzwischen "veraltet")
- 1024-Bit-Parameter für Mailservices sind so beabsichtigt, da es viele Clients gibt die mit größeren Parametern schlicht nicht zurecht kommen.

Mit freundlichen Grüßen

-Klaus Keppler

Hallo,

um Spam-Filter für Catch-All-Accounts einzurichten, geben Sie bitte wie folgt vor:
- legen Sie im LiveConfig einen CatchAll-Account an (als Weiterleitung auf irgendeine bestehende E-Mail-Adresse)
- bearbeiten Sie die Datei /etc/postfix/spamassassin: fügen Sie dort eine Zeile hinzu, welche die gewünschte SpamAssassin-Konfiguration enthält. Das Format ist:
<Domain> 1 <PunkteFürWarnung> <PunkteFürAblehnung> 1 <Vertragsname> <PräfixFürBetreff>

Beispiel:

example.org 1 2.5 6.0 1 web123 ***Spam-Verdacht***

Danach führen Sie den Befehl "postmap /etc/postfix/spamassassin" aus, um die Datenbank-Datei zu aktualisieren.

Grundsätzlich raten wir dringend davon ab, überhaupt CatchAll-Accounts zu nutzen. Diese stellen einen großen Angriffspunkt für Spam und DoS-Angriffe dar.

Viele Grüße

-Klaus Keppler