Beiträge von kk

  • LiveConfig v2.8.0

    Die sauberste Lösung wäre der jeweils eigene Ordner pro Postfach.
    Wir können das relativ einfach ins LiveConfig mit aufnehmen, so dass das Verzeichnis beim Erstellen/Bearbeiten eines Postfachs automatisch erzeugt und beim Löschen entsprechend entfernt wird.
    Ich nehme das gleich als Change Request auf, dürfte im nächsten Preview-Update enthalten sein (steht dann im Changelog).


    Viele Grüße


    -Klaus Keppler


    PS: nach wie vor bin ich der Überzeugung, dass Bayes-Filter wesentlich überbewertet sind - Mails die erst mal so weit gekommen sind, können nur relativ unscharf klassifiziert werden.

  • Webspace Quota (LOG & TMP Ordner)

    Zitat von BMK-Media

    Das kann so ja nicht stimmen, denn die Verträge, bzw. Kunden sind doch nicht separate Partitionen. (/var/www/web1, /var/www/web2 ....)
    Denn dann müsste die Liveconfig ja bei jedem neuen Kunden die Systempartition anfassen um zu verkleinern. Und solche eingriffe wären zu gefährlich, daher glaube ich nicht das es so gelöst ist.


    Es hat doch niemand behauptet, dass jeder Vertrag eine eigene Partition hat.
    Das Quota wird pro Partition verwaltet. Je nach Partitionierung des Systems ist das also z.B. global, oder nur für /var/ oder /var/www/ usw...
    Führen Sie einfach mal den Befehl "repquota -ag" aus. Sie erhalten dann eine Liste aller Partitionen mit den dort jeweils gesetzten Quotas.


    Zitat

    Ja aber die wenigsten interessieren sich für die LOG, aber beschwären sich dann wenn die Seite wegen Error 500 (OPCACHE) nicht mehr erreichbar ist.


    Der Opcache ist eine Sache, die im User-Space läuft. Wenn dieser Dateien erzeugt, dann sind die logischerweise auch dem Kunden zuzurechnen.
    Wenn der Platz ein Problem ist, muss der Kunde eben entweder mehr Platz buchen, oder das Caching abschalten (oder die Caching-Dauer verringern).


    Zitat

    Außerdem bin ich der Meinung, sollten die Logs nicht den Speicherplatz verbrauchen die der Kunde gebucht hat.


    Die vom System erzeugten Logs (access.log, error.log) gehören dem root-Benutzer und werden dem Kunden somit auch nicht zugerechnet.
    Wenn der Kunde darüber hinaus weitere Logs erzeugt (entweder von seiner eigenen Anwendung, oder z.B. das php_error.log), dann sind das auch wieder Sachen die der Kunde zu verantworten hat und die somit legitim seinem Speicherplatz zugeordnet werden müssen.


    Viele Grüße


    -Klaus Keppler

  • Pfad zur PHP Version im App Installer

    Ab LiveConfig 2.9.0 kann man nun über eine Lua-Variable LC.web.PHPCLI den PHP-Interpreter ändern, den der AppInstaller verwendet.
    Bei Bedarf also eine Datei wie z.B. "/etc/liveconfig/lua.d/phpcli.lua" anlegen, und dort folgende Zeile eintragen:

    Code
    LC.web.PHPCLI = '/opt/php-7.3/bin/php'


    Die entsprechende v2.9.0-Preview wird Anfang kommender Woche bereitgestellt.


    Viele Grüße


    -Klaus Keppler

  • Lets Encrypt mit IPv6 oder AWS EC2

    Zitat von antondollmaier

    Kann der Post so ins Handbuch? ;)


    Hmm, guter Hinweis - ich gebe das gleich weiter.


    Zitat

    Und: danke für die Preview - auch wenn ich den Versions-Sprung auf 2.9 (im Vergleich zu den gravierenden Änderungen 2.7->2.8) nicht so ganz nachvollziehen kann.


    Mit v2.9 gab es auf unserer Seite gravierende Änderungen, u.a. haben wir die komplette Codeverwaltung von SVN auf Git umgestellt - an den Build-Prozessen hat sich also viel geändert. Details dazu plane ich nächste Woche (mit dem nächsten Preview-Update) ausführlicher zu beschreiben.
    Und 'n paar weitere nette Features stecken auch gerade in der Release-Pipeline für v2.9. ;)


    Viele Grüße


    -Klaus Keppler

  • Lets Encrypt mit IPv6 oder AWS EC2

    Zitat von lchel

    <ADDRESS> ist eine IPv6 Adresse. Der Server hat eine IPv4 und eine IPv6 Adresse. Wenn ich die IPv6-Adresse auf dem DNS lösche, funktioniert die automatische Verlängerung. Aber das ist nicht der wahre Jakob. Schließlich soll auch IPv6 funktionieren und hat auch bis vor ca. einem Monat funktioniert.


    Da wird es höchstwahrscheinlich eine Inkonsistenz gegeben haben.
    Am einfachsten Fall können Sie das prüfen, indem Sie im LiveConfig (als "Kunde") auf "Hosting" -> "Domains" gehen und dort die betroffene (Sub)Domain anklicken.
    Es öffnet sich das Popup mit den (Sub)Domain-Einstellungen. Dort wird angezeigt, mit welchen IP-Adressen die Domain im LiveConfig konfiguriert ist (über die entsprechenden IP-Gruppen). Eventuell war die IPv6-Adresse nicht in der gewählten IP-Gruppe enthalten.


    Zitat von lchel

    <ADDRESS> ist eine IPv4 Adresse und der Server ist eine AWS EC2 Instanz. <ADDRESS> ist die externe IP-Adresse des Servers, die aber naturgemäß nicht der lokalen IP des Servers entspricht.


    Das lässt sich über die LiveConfig-Datenbank (Tabelle IPS, Spalte IP_NAT) lösen. Wir werden das Verhalten mit LiveConfig v2.9 aber so ändern, dass bei erkanntermaßen "privaten" IPv4-Adressen kein DNS-Check mehr ausgeführt wird, sofern keine NAT-IP konfiguriert ist.


    Falls Sie aktuell noch Probleme haben, schicken Sie uns bitte mal einen betroffenen Domainnamen samt exakter Fehlermeldung an support@liveconfig.com, dann werfen wir da auch mal ein Auge drauf.


    Viele Grüße


    -Klaus Keppler

  • Lets Encrypt mit IPv6 oder AWS EC2

    Zitat von TCRserver

    Aber gegen welche IP Adresse validiert LC es, also welche http-Server Adresse?


    Wenn LiveConfig ein automatisiertes SSL-Zertifikat für "example.org" einrichten soll, passiert Folgendes:


    • LiveConfig prüft, ob die Domain "example.org" überhaupt angelegt ist (also irgendein Vertrag mit dieser Domain existiert).
    • Wenn ja, dann wird geprüft, ob der zugehörige Kunde/Vertrag/Webspace auch aktiviert ist.
    • Wenn ja, dann sucht LiveConfig die IP-Adressen dieses Webspaces heraus (also die Adressen, mit denen effektiv die vHost-Konfiguration erzeugt wird).
    • dann macht LiveConfig eine "externe" DNS-Abfrage (sprich: nutzt den eingebauten Resolver oder - falls nicht möglich - den Resolver des Servers) um herauszufinden, mit welchen IPs denn der verantwortliche DNS-Server tatsächlich antwortet.
    • Zum Schluß wird abgeglichen, ob die Liste der tatsächlichen IPs mit der Liste der konfigurierten IPs (bzw. der NAT-IPs) übereinstimmt. Wenn nicht, dann gibt es eine entsprechende Fehlermeldung.


    Der durch LiveConfig durchgeführte DNS-Check hat mehrere Vorteile, u.a.:

    • sollte eine Domain falsch konfiguriert sein (die Klassiker: falsche IP-Adresse hinterlegt, Domain inzwischen umgezogen, Tippfehler im Domainnamen, ...) dann hat man gleich eine brauchbare Fehlermeldung
    • die Anzahl der ungültigen Domainvalidierungen bleibt somit gering, die Gefahr in Probleme seitens Let's Encrypt zu rauschen wird somit verringert.


    Viele Grüße


    -Klaus Keppler

  • Lets Encrypt mit IPv6 oder AWS EC2

    Zitat von TCRserver

    Meine Vermutung war, dass der LC DNS-Resolver bei Servern mit NAT gegen die interne IP-Adresse geprüft hat und nicht gegen die öffentliche Adresse.
    Ich habe es aber nicht weiter verfolgt, da wir eh umstellen wollten.


    LC führt ein ungecachtes Resolving (also ohne "externe" DNS-Resolver) durch, um die öffentlich hinterlegte IP einer Domain herauszufinden.
    Wenn LC keine eigenen DNS-Anfragen ausführen kann (z.B. weil Port 53 outbound blockiert), dann nutzt es den im System konfigurierten DNS-Resolver.


    Eine mögliche Erklärung wäre natürlich, dass der DNS-Resolver andere Daten zurückliefert als erwartet - in diesem Fall also z.B. die private statt der öffentlichen IP-Adresse. Das müsste man mal im konkreten Einzelfall prüfen.

  • Lets Encrypt mit IPv6 oder AWS EC2

    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

  • Spamassassin funktioniert nicht (postfix/master.cfg)

    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.

  • Lets Encrypt mit IPv6 oder AWS EC2

    Ö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

  • Server im abgelaufenen Demo Modus,SSL ebenfalls abgelaufen, was ist ohne SSH möglich?

    Zitat von isphttp.de

    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.


    Zitat

    schade 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.

  • Pfad zur PHP Version im App Installer

    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

  • Web-Apps Kundenspezifisch de-/aktivieren

    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

  • AppInstaller

    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

  • WHMCS oder Alternative

    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...

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    Zitat von Nobbi

    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.


    Zitat
    Code
    [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