Das ist dann äußerst merkwürdig - weil nämlich viele Anwender hinter NAT nun die öffentlichen IPs in IP_NAT hinterlegt haben und damit alles funktioniert...
(unsere CI-Test-Server hängen auch in einem privaten Subnetz, auch da klappt's mit IP_NAT problemlos).
Falls das Problem aktuell noch besteht, könnten wir das anhand konkreter Daten mal prüfen (also Domainname mitsamt den zugehörigen Einträgen in IPS.IP_ADDRESS and IPS.IP_NAT).
Viele Grüße
-Klaus Keppler
Der "X-Spam-Report"-Header wird von lcsam hinzugefügt, wenn dieser mit der Option "-r" gestartet wird.
Wenn möglich leiten Sie uns bitte mal den betroffenen Header einer solchen Mail an support@liveconfig.com weiter, dann schauen wir uns das mal an.
Die Frage wäre, woher die "kaputten" Daten des X-Spam-Report-Headers kommen - ob schon vom SpamAssassin, oder erst nach dem Einbau in die Mail durch lcsam.
Ja, diese Möglichkeit werden wir einbauen - kommt voraussichtlich direkt mit der nächsten Version (2.9.0).
Öh, mir ist nicht bekannt dass LiveConfig + Let's Encrypt + NAT im Moment nicht funktioniert...
In die Tabelle IPS muss in die Spalte IPS.IP_NAT die "öffentliche" IP (zu jeweiligen privaten IP) hinterlegt werden, damit die DNS-Prüfung erkennen kann ob die jeweilige Domain korrekt konfiguriert ist.
Ich gebe zu, dass wir überrascht sind wie viele Server tatsächlich hinter NAT betrieben werden. Daher soll LiveConfig künftig automatisch erkennen, wenn es mit "privaten" IPs läuft; die Konfiguration der NAT-IPs soll künftig direkt über die GUI möglich sein.
Viele Grüße
-Klaus Keppler
Herr Keppler hatte ich auch schon X mal deshalb angeschrieben, eine Reaktion ist leider nie erfolgt und da es sehr dringend ist, möchte ich euch mal fragen.
Zu dieser konkreten Frage hatten Sie das Ticket LC#2019101834000019 geöffnet (am 18.10., also am selben Tag wie diesen Forumsbeitrag). Die Mail habe ich Ihnen vorhin beantwortet.
Die anderen Tickets (ob man auch ohne SSH auf den Server zugreifen kann etc.) haben mit LiveConfig nichts zu tun, trotzdem wurden diese meines Wissens beantwortet.
Zitatschade das Herr Keppler heute auch nicht im Support verfügbar war
Konkrete Fragen bzgl. LiveConfig hätten Ihnen meine Kollegen sicherlich genauso beantworten können - ich sehe hier aber keine weiteren Tickets.
Wir kennen das Problem (insbesondere auf "alten" Distributionen). Wir werden in die nächste LC-Version eine Möglichkeit einbauen, die "Standard-CLI-Version" von PHP auch konfigurierbar zu machen.
Für Userspace-Anwendungen gibt es mit "lcphp" bereits eine Lösung (siehe man-Page zu lcphp).
Viele Grüße
-Klaus Keppler
Nein, diese Möglichkeit gibt es derzeit leider nicht - einzelne Anwendungen können nur global deaktiviert/ausgeblendet werden.
Da wir den AppInstaller aberhin demnächst überarbeiten, nehme ich das gerne mal als Anregung mit auf.
Viele Grüße
-Klaus Keppler
Hallo,
wir möchten auf eine kleine Änderung im AppInstaller hinweisen.
Bislang lief das so, dass zur Installation einer Anwendung das gewünschte Paket direkt vom jeweiligen Downloadserver heruntergeladen wurde. Anschließend wurde eine SHA-Prüfsumme berechnet (um die Integrität sicherzustellen) und dann die Anwendung entpackt/installiert.
Die Betreuer von WordPress haben aber seit Kurzem die unpraktische Angewohnheit, Änderungen am Downloadpaket vorzunehmen, ohne dabei die Versionsnummer zu erhöhen. Zwar werden scheinbar "nur" Änderungen an den Übersetzungen vorgenommen, aber die Prüfsumme passt dann halt nicht mehr.
Wir werden daher bis auf weiteres solche Pakete auf unseren eigenen Downloadservern "cachen" - konkret werden diese dann also nicht mehr von z.B. de.wordpress.org heruntergeladen, sondern von download.liveconfig.com/cache/...
Wir planen umfangreichere Änderungen am AppInstaller, dazu dann aber mehr Anfang kommenden Jahres.
Viele Grüße
-Klaus Keppler
Ein klein wenig off-topic, aber dennoch: seit Juni 2012 hält cPanel Inc. Anteile an der WHMCS Ltd., im Juni 2019 wurde WHMCS dann vollständig an "WebPros" verkauft. WebPros ist die Gesellschaft, unter der u.a. Plesk, cPanel und WHMCS zusammengefasst sind - größter Anteilseigner ist Oakley Capital. Gehört also (vereinfacht gesagt) alles zu selben Familie...
aufgrund der Fehler in php-fpm, vor allem das der Timeout nicht unendlich einstellbar ist, hat mich dazu bewogen mod_apache für meinen Ubuntu 18.04 einzusetzen.
mod_apache? Meinen Sie evtl. Apache mod_php?
Das ist ein latentes Sicherheitsrisiko - bei Servern mit mehreren Benutzern sollte das besser nicht eingesetzt werden.
Lange Scriptlaufzeiten sollten anderweitig "bekämpft" werden, sofern man für den Code verantwortlich ist (Datenbankabfragen strukturell beschleunigen, "langsame" Scripte in CLI/Cron-Aufrufe auslagern, usw.). Jedes lange PHP-Script blockiert zwangsläufig einen Slot in Apache, so fängt man sich ggf. sehr schnell einen DoS ein.
ZitatCode[Mon Sep 30 12:38:07.344059 2019] [php7:error] [pid 1285] [client 44.64.56.xx:36166] script '/usr/share/liveconfig/html/email.compose.php' not found or unable to stat
Das kann z.B. dann auftreten, wenn jemand über eine nicht konfigurierte Domain oder über die IP-Adresse auf "/email.compose.php" zugreift - dann landet das (durch den 000-default_vhost) in /usr/share/liveconfig/html/.
Werfen Sie mal einen Blick auf /var/log/apache2/other_vhosts_access.log - da müsste der jeweilige Domainname mitprotokolliert werden, vielleicht hilft das weiter.
Viele Grüße
-Klaus Keppler
Das ist ein nagelneues Feature in LiveConfig. Automatische Problembehebung (Feenstaub und so...).
Spaß beiseite. Die eigentliche Ursache für die o.g. Fehlermeldung ist, dass bei Let's Encrypt für die selben Domains mehrere Aufträge existiert hatten. Ab der ACMEv2-API fasst LE diese Aufträge automatisch zusammen, was bei LiveConfig bis dahin aber zu einem Problem geführt hatte (LiveConfig ging davon aus, dass es sich um verschiedene Aufträge handelte).
In Ihrem Fall werden die offenen Bestellungen einfach abgelaufen (expired) sein, und somit konnten die Bestellungen "ganz normal" (neu) abgearbeitet werden.
Hallo,
der Fehler ist in v2.8.4-r5653 behoben - aktuell als Preview verfügbar, "Stable Release" voraussichtlich morgen früh.
Viele Grüße
-Klaus Keppler
Danke für den Hinweis.
Der o.g. Fehler tritt auf, wenn eine identische Bestellung für das selbe SSL-Zertifikat vorliegt. Prüfen Sie daher mal die Log-Meldung und die Liste der SSL-Zertifikate, ob es "doppelte" Aufträge gibt.
Wir werden den Fehler der o.g. Meldung kurzfristig beheben.
Viele Grüße
-Klaus Keppler
Hallo,
unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.23 und 7.3.10 aktualisiert.
Viele Grüße
-Klaus Keppler
Danke auch für die Rückmeldung!
In v2.8.4-r5651 (aktuelle Preview) ist's nun auch korrigiert.
Aaargh... Stop. Nachtrag.
Ich habe den betroffenen Code eben analysiert - im lcsam steckte da tatsächlich ein Fehler bei der Umwandlung von IPv6-Adressen. 
Ich habe das eben aktualisiert - ein aktualisiertes LiveConfig-Paket werden wir dann gleich bereitstellen.
Welche Distribution und welche Postfix-Version nutzen Sie denn?
lcsam wird von Postfix aus über die Milter-API angesprochen. Die Funktion lcsam_connect() erhält dabei (zumindest laut API-Spezifikation) die IP-Adresse der SMTP-Gegenseite.
Wenn da nun was anderes (unbrauchbares) drin steht, kann kann das bedeuten, dass eine der beteiligten Komponenten (vermutlich Postfix oder dessen libmilter) kein IPv6 beherrschen.
Um das zu testen, müssten wir aber die genaue Distribution kennen.
Viele Grüße
-Klaus Keppler
Welche Version von SpamAssassin genau kommt zum Einsatz? (SA <3.4 kann IPv6 nur eingeschränkt).
Please edit the reseller subscription (as admin). Click the tab "Domains & Mail". Below the "subdomains" property, you can select the DNS template which may be used by that reseller.
The reseller can then use your own DNS server (using the allowed DNS template).
