Beiträge von kk

    Problem ist die DS-GVO. Auf einfachen Landingpages oder aber auch z. B. bei Coming-Soon Pages, muss eine Anbieter-Kennzeichnung in Form von Impressum und Datenschutzangaben vorhanden sein.


    Die LiveConfig-Anmeldeseite ist weder eine Landing- noch eine Coming-Soon-Seite.
    Es werden hier keinerlei kennzeichnungspflichtige Inhalte bereitgestellt, daher ist auch keine Anbieterkennzeichnung erforderlich.
    Das Cookie, das für die LiveConfig-Session erzeugt wird, wird zudem in keiner Weise für irgendwelche Trackingzwecke verwendet und spielt daher auch keine Rolle bei der DSGVO.


    Bei "anderen Panels"(tm) sieht das womöglich anders aus, da werden ja teilweise Twitter- und Facebook-Ressourcen sowie Tracking-Cookies im Footer eingeblendet - das ist bei LiveConfig alles ganz bewusst nicht der Fall.


    Zitat

    2 Links, welche unterhalb der Login-Maske angezeigt werden.


    Es kann ein Hilfe-Link eingeblendet werden: siehe LCDefaults, Schlüssel "login.help.url".


    Viele Grüße


    -Klaus Keppler

    Hallo,


    an der Schrift-Darstellung auf der LiveConfig-Website und in der LiveConfig-Oberfläche hat sich in letzter Zeit nichts geändert.
    Öffnen Sie die Seiten mal testweise mit einem anderen Browser und/oder auf einem anderen Computer.


    Die Schrift im Forum ist in der Tat vergleichsweise klein, eine Überarbeitung des Forum-CSS ist bereits eingeplant.


    Viele Grüße


    -Klaus Keppler

    Das geht schonmal mit der Frage los, welche GeoIP-Erweiterung genau (etwa PECL?) und für welche PHP-Version.


    Kurzanleitungen zur Installation von PECL-Erweiterungen:

    • zur gewünschten PHP-Version passendes "-dev"-Paket installieren, also z.B. php-7.3-opt-dev
    • PECL-Erweiterung herunterladen, entpacken und gemäß Dokumentation installieren
      (meist so was wie: "/opt/php-7.3/bin/pecl install geoip")
    • wenn das Modul im PHP-Extension-Verzeichnis installiert ist, dann in die LiveConfig PHP.INI-Verwaltung gehen und dort eine neue php.ini-Option anlegen (Typ: "Erweiterung", Name: "extension", Wert: "geoip.so")


    Viele Grüße


    -Klaus Keppler

    Welche MySQL-Version genau auf welcher Distribution setzen Sie ein?


    Offenbar ist bei Ihnen die MySQL-Option ONLY_FULL_GROUP_BY aktiv. Die betroffene SQL-Abfrage funktioniert damit offenbar nicht (wird mit dem nächsten Update korrigiert). Bis dahin deaktivieren Sie ONLY_FULL_GROUP_BY am besten.
    Hierzu rufen Sie zunächst mal den aktuellen SQL-Modus ab:

    SQL
    SELECT @@GLOBAL.sql_mode;


    Die Ergebnisliste nehmen Sie dann her, entfernen daraus ONLY_FULL_GROUP_BY und tragen dann in die /etc/mysql/my.cnf in [mysqld]-Abschnitt ein, z.B. ungefähr so:


    Code
    sql_mode = "STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"


    Anschließend MySQL neu starten.


    Viele Grüße


    -Klaus Keppler

    Hierfür gibt es aktuell noch keine einfache Möglichkeit.


    Warten Sie einfach bis zum nächsten Update (v2.11), da kann man dann einzelne PHP-Versionen in der PHP-Verwaltung (Server-Verwaltung -> Web) aktivieren/deaktivieren. Und dann auch z.B. so, dass bestehende Domains weiter mit der eingestellten Version arbeiten, diese aber für neue Domains nicht mehr ausgewählt werden kann.

    Was könnte der Grund dafür sein, dass der lclogsplit-Prozess nicht läuft?
    Gibt es eine Möglichkeit, diesen manuell zu starten oder gar neu zu installieren /zu aktivieren?
    Hat dieser Dienst Konfigurationsdateien, die man auf Richtigkeit / vorhandensein prüfen kann?


    Wie in meinem vorherigen Beitrag schon beschrieben, wird dieser Prozess normalerweise automatisch durch Apache gestartet (aufgrund der Pipe-Anweisung in /etc/apache2/conf-enabled/liveconfig.log: "CustomLog "||/usr/lib/liveconfig/lclogsplit -i -w" LiveConfig")


    Wenn lclogsplit also nicht läuft, dann läuft wahrscheinlich der gesamte Apache (zumindest kurzzeitig) nicht.


    Ich kenne Ihre Server nicht, aber dieses Verhalten basiert vermutlich auf einer lokalen "Spezialkonfiguration". Der Aufruf von logrotate (via cron.daily) erfolgt normalerweise um 06:25 (siehe /etc/crontab). Wenn bei Ihnen alles um 00:00 statt findet, dann passiert da vielleicht zu viel gleichzeitig. Letztendlich lässt sich das nur anhand der Logs genauer analysieren.


    Viele Grüße


    -Klaus Keppler

    Das Problem liegt wahrscheinlich ganz woanders, das hier beschriebene Verhalten vom logrotate ist lediglich ein Symptom.


    Zitat
    Code
    Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web4/logs/*.log '
    Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden


    Das zeigt, dass der lclogsplit-Prozess überhaupt nicht lief, als logrotate ausgeführt wurde. Da lclogsplit aber i.d.R. als Child-Prozess vom Apache gestartet wird, scheint da schon irgendwas nicht zu stimmen.
    (Ausnahme: beim Dual-Betrieb von Apache und NGINX läuft lclogsplit als eigenständiger Daemon)
    Hier wird übrigens ein HUP-Signal gesendet, der lclogsplit-Prozess wird dadurch also nicht beendet, sondern lediglich darüber informiert dass diese prüfen soll, dass Log-Dateien eventuell rotiert wurden.


    Wir können die logrotate-Konfiguration dahingehend ändern, dass der Exit-Code des postrotate-Scripts (also der killall-Aufruf) ignoriert wird. Das dürfte das von Ihnen beschriebene Symptom beseitigen, aber nicht die Ursache beheben.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ab sofort steht LiveConfig v2.10.4 zum Download bereit. Dieses Update ist ein reines Bugfix-Release - alle Änderungen finden Sie im Changelog.


    Außerdem steht PHP 8.0.0 RC4 bereit. In knapp zwei Wochen - am 26.11.2020 - ist das Release von PHP 8.0.0 geplant.


    Viele Grüße


    -Klaus Keppler

    Ah ok, das wusste ich nicht, habe es auch nicht in den Changelogs gefunden, das sich die bind.lua bzw dns.lua geändert hat.


    Da hat sich auch nichts geändert. Wie gesagt - der genannte Code-Schnipsel kann in dieser Form noch nie funktioniert haben.


    Zitat

    Naja in den Optionen nicht, ich möchte am ende include "/etc/named/log.conf"; hinzufügen. Wir hatten das Logging selbst aufgeteilt und deswegen stand es bei uns auch so drin, dann wurde aber die Config von der Liveconfig neu geschrieben und ist seit dem weg.


    Ich vermute vielmehr, dass die Änderung direkt in die BIND-Konfiguration eingetragen wurde und zusätzlich noch die Änderung in der custom.lua vorgenommen wurde (die faktisch aber nie funktioniert haben kann).


    Tragen Sie Ihre include-Anweisung doch einfach in die named.conf.local ein, die wird von LiveConfig nicht angefasst.


    Viele Grüße


    -Klaus Keppler

    Seit LiveConfig 2.10 werden im Homeverzeichnis des Benutzers folgende Dateien mit angelegt:


    Code
    /var/www/web111
    -rw-r--r--   1 web111 web111    18 Apr  1  2020 .bash_logout
    -rw-r--r--   1 web111 web111   193 Apr  1  2020 .bash_profile
    -rw-r--r--   1 web111 web111   231 Apr  1  2020 .bashrc


    Der Fehler ist mit LiveConfig v2.10.4 behoben (Update erscheint morgen). Unter CentOS/RHEL wurde beim Aufruf von "adduser" die Option "-M" nicht mehr übergeben, dadurch wurde beim Anlegen von Systembenutzern das System-Skeleton-Verzeichnis verwendet.

    Die Option "auch 'www'-Subdomain erstellen" fehlt hier noch. Wenn man eine Domain per API anlegt, wird die www-Subdomain nicht angelegt. Wenn man per API (HostingSubdomainAdd) die www-Subdomain anlegt, dann wird die Domain und die Subdomain www separat dargestellt, so wie es sonst in der Experten-Ansicht üblich ist, obwohl Standard-Ansicht aktiv ist.


    Guter Hinweis, werden wir mit einem der nächsten Updates anpassen. Auch für die automatisierte SSL-Bestellung macht das Sinn.

    Hallo,


    Seit dem Update geht unsere custom.lua nicht mehr


    Der nachfolgend beschriebene Fehler wird so definitiv auch mit früheren LiveConfig-Versionen aufgetreten sein. Weil...:


    Zitat

    Beim Testen via lclua zeigt er folgendes an

    Code
    Can't run /usr/lib/liveconfig/lua/custom.lua: /usr/lib/liveconfig/lua/custom.lua:3: attempt to index global 'bind' (a nil value)


    Das hat damit zu tun, dass die "custom.lua" automatisch durch das lclua-Programm geladen wird (lclua lädt u.a. die liveconfig.lua, und die wiederum die custom.lua)


    Sie können die custom.lua also nicht direkt via lclua ausführen. Schreiben Sie ein leeres Testscript (leere Datei) und führen diese mit lclua aus - die custom.lua wird da automatisch mit geladen.


    Zitat

    Und in der Liveconfig -> Serververwaltung -> DNS beim neustarten von BIND steht:

    Code
    /usr/lib/liveconfig/lua/custom.lua:9: attempt to index global 'fh' (a nil value)
    stack traceback:
        /usr/lib/liveconfig/lua/custom.lua:9: in function 'configure'
        /usr/lib/liveconfig/lua/dns.lua:228: in function


    Es handelt sich um folgenden Abschnitt:

    Code
    3:  orig_bind_configure = bind.configure
    4:  
    5:  function bind.configure(cfg, opts)
    6:  
    7:          orig_bind_return = orig_bind_configure(cfg, opts)
    8:  
    9:          fh:write("include \"", configpath, "/log.conf\";\n")
    10:         return orig_bind_return
    11:
    12: end


    "fh" ist eine lokale Variable (Filehandle), die in der hier aufgerufenen Funktion gar nicht (mehr) existiert. Das wird so nicht funktionieren.
    Möchten Sie eigene Einstellungen in die BIND-Konfiguration aufnehmen? Wenn es im "options"-Abschnitt sein soll, nutzen Sie die dokumentierte Tabelle. Allgemeine Einstellungen können Sie direkt in die /etc/bind/named.conf.local eintragen.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    ab sofort steht LiveConfig v2.10.2 zum Download bereit.


    Die neue Version enthält hauptsächlich Detailverbesseungen und Fehlerbehebungen - die vollständige Liste der Änderungen finden Sie wie immer im Changelog.


    Viele Grüße


    -Klaus Keppler

    Das Logo steckt in der Ressourcendatei von Let's-Encrypt-Modul, da kommt man nicht sooo einfach ran.
    Um eine weitere CA aufzunehmen, einfach die Spalte SP_LOGO in der Datenbank leer lassen (dann wird da kein Logo angezeigt).

    Die Fehlermeldung ist recht allgemein; kann z.B. auch dann auftreten wenn Kunden ihren Mailclient falsch konfiguriert haben (etwa wenn ein Kunde Port 110 auswählt, statt STARTTLS da aber SSL einstellt).
    Schicken Sie uns bitte mal den Namen Ihres Mailservers an support@liveconfig.com, dann testen wir das mal soweit wie möglich von außen durch.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    seit einigen Wochen stellen wir für Debian & Ubuntu die ersten PHP8-Pakete bereit (Beta bzw. Release Candidate).


    Die PHP8-Pakete wurden nun auf Version 8.0.0-RC2 aktualisiert.
    Allerdings sind einige PHP-Erweiterungen noch nicht für PHP 8 vorbereitet, konkret z.B. ImageMagick oder Redis. Wir werden diese Pakete nachliefern, sobald diese kompatibel sind.


    PHP 8.0 soll am 26. November 2020 freigegeben werden.
    Am 30. November 2020 endet wiederum der Security-Support für PHP 7.2.


    Viele Grüße


    -Klaus Keppler