Beiträge von kk

    Jein. LiveConfig läuft prinzipiell mit CloudLinux 7, die speziellen Features wie CageFS sind aber derzeit nicht über die GUI steuerbar. Das hat schlicht damit zu tun, dass hierzulande CL noch relativ wenig verbreitet ist.
    Die meisten Vorteile von CL kann man dennoch problemlos nutzen (also inbes. die Sicherheitsvorteile, Kernel Patching usw.)


    Wir haben eine CloudLinux7-Testumgebung am Laufen, mit der wir testen & entwickeln, und haben auch einen recht guten Draht zu den CL-Entwicklern, bei Problemen können wir also i.d.R. weiterhelfen.
    CloudLinux8 steht bereits auf unserer Agenda - aber erst gegen Q2/2021, wenn wir auf eine neue Testumgebung migrieren. CentOS 8 bzw. deren Nachfolger/Derivate werden wir nach Möglichkeit weiter unterstützen. Eine "offizielle" Stellungnahme zur Zukunft mit CentOS 8 ist für die nächsten Wochen geplant (wenn sich der Staub um die CentOS8-Entwicklung etwas gelegt hat).


    Viele Grüße & frohe Weihnachten


    -Klaus Keppler

    Weiß hier jemand ob man den Spamfilter für alle E-Mail Adressen eines Kunden aktiveren kann, ohne dabei die Einstellung in jeder E-
    Mail Adresse manuell durchführen zu müssen?


    Das geht nur über einen Eingriff in die LiveConfig-Datenbank:


    SQL
    UPDATE MAILBOXES SET MB_SA_ENABLED=1, MB_SA_WARN=300, MB_SA_REJECT=500, MB_STATUS=9
      WHERE MB_SA_ENABLED=0 AND MB_STATUS=1;


    Anschließend LiveConfig neu starten - damit sollten die Postfächer serverseitig aktualisiert werden (ggf. Blick in liveconfig.log werfen).


    Zitat

    Und kann man irgendwo den Default so setzen dass bei jeder neuen E-Mail der Spamfilter aktiviert wird?


    Das geht über die LCDefaults:


    SQL
    INSERT INTO LCDEFAULTS VALUES ('mail.spam.enabled', '1');


    Auch hier LiveConfig anschließend neu starten, da diese Einstellungen nur beim Start gelesen werden.


    Viele Grüße


    -Klaus Keppler

    Anhand der aufgerufenen Domain könnte das passende Set an Ressourcen gewählt werden.


    Das würde erfordern, dass man entweder ein Multi-Domain-Zertifikat mit allen möglichen Reseller-Domains einrichtet, oder für jede Reseller-Domain ein separates SSL-Zertifikat.
    Da ist es wesentlich einfacher, die Anmeldeseite neutral zu halten und eben keine Informationen anzuzeigen.

    Die Sprache des Benutzers wird ja automatisch erkannt, wenn jemand seinen Browser also auf Deutsch oder Englisch eingestellt hat wird die Anmeldeseite daher nicht auf Französisch angezeigt. Ich verstehe also den Sinn nicht, die nicht benötigten Sprachen auszublenden, wenn diese ohnehin explizit ausgewählt werden müssten...

    Ja, wenn eine bestehende Domain mit einer "alten" PHP-Version bearbeitet wird, dann kann man diese auch weiterhin nutzen (sonst könnte man ja keine Domaineinstellung ändern ohne PHP umstellen zu müssen, was praxisfremd ist...)


    Zur PHP-Standardversion nur für neue Domains: steht auf der ToDo-Liste; ob' noch in die 2.11.0 mit reinpasst kann ich aber noch nicht versprechen.


    Viele Grüße


    -Klaus Keppler

    Danke für die Rückmeldung.
    Das zuständige CSS bevorzugt lokale Schriftarten in der Lade-Reihenfolge, das das Verhalten somit erklärt.


    Viele Grüße


    -Klaus Keppler

    Die Werte in LOCALOPTIONS sehen soweit ganz gut aus.
    Wurden diese dann auch in die /etc/bind/named.conf.options geschrieben? LiveConfig muss hierfür neu gestartet und die DNS-Konfiguration neu erstellt werden (siehe Handbuch).

    Lässt sich daher so nicht lösen.


    Geht nicht gibt's nicht. ;)
    Man kann Sockets für ausgehende Verbindungen an bestimmte Adressen binden. Soweit ich weiß geht das in BIND durchaus (ich kann mich da dunkel an diverse Firewall-Thematiken erinnern).


    Die Frage ist daher, für welche Requests genau BIND an welche Adresse gebunden werden soll.

    Mein Problem ist jetzt wenn ich PowerDNS mit bind Backend betreibe werden auf dem Ext. Slave die zonen nicht geupdatet.
    Intern nutzt er ja die Bind Backend und bekommt somit alle änderungen ohne AFXR durch dierekt zugriff auf die Zone-Files.


    Die Änderungen landen aber nicht direkt in den Zonenfiles.
    LiveConfig aktualisiert die Zonen mittels DNS-Updates (RFC2136 etc.). BIND schreibt die Änderungen nicht direkt in die Zonendateien, sondern führt Journalfiles (.jnl). Ich weiß nicht, ob PowerDNS die mit berücksichtigt.


    Ich kann mir vorstellen, dass ein Hidden-Primary-Setup hier mehr Sinn macht. Primary DNS ist ein von LiveConfig verwalteter BIND, und die öffentlichen Secondaries laufen z.B. mit PowerDNS und erhalten die Zonenänderungen via AXFR/IXFR.


    Zitat

    Bekomme jetzt aber immer die folgenden Meldungen,
    "Received NOTIFY for domain.tld from IP1 but remote is not permitted by TSIG or allow-notify-from"
    "Received NOTIFY for domain.tld from IP1which is not a master"


    Da stimmt dann wohl was mit der Auth-Konfiguration nicht (falsche IPs und/oder falscher TSIG-Key).


    Zitat

    Leider kein Erfolg Bind nutzt immernoch die Anderen IPs für anfrage und notify


    Was genau haben Sie in bind.LOCALOPTIONS eingetragen, und was genau meinen Sie mit "die anderen IPs"? Mir ist das eigentliche Problem noch nicht so ganz klar.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    bislang bauen wir unsere PHP-Pakete für Debian/Ubuntu immer "vanilla", also möglichst ohne spezielle Patches - abgesehen von zwingend notwendigen Anpassungen (z.B. OpenSSL bei PHP 5.6).


    Die besonders alten Versionen 5.6, 7.0 und 7.1 bauen wir aber ab sofort mit den Security-Backports. Dieses Repository wird von Microsoft bereitgestellt und zu einem Großteil von Remi Collet gepflegt (ein PHP-Entwickler, der u.a. auch das Remi-Repo unter CentOS/RHEL bereitstellt).


    Unser Test-Repository ist bereits umgestellt, folgende Paketversionen enthalten die Security-Backports:

    • 5.6.40-4
    • 7.0.33-3
    • 7.1.33-3


    Sofern keine Probleme bekannt werden, planen wir diese Pakete am kommenden Freitag, 11.12.2020 in das "stable"-Repo aufzunehmen.


    Viele Grüße


    -Klaus Keppler

    Knackpunkt ist die Tatsache, dass auf der Anmeldeseite weder persönliche Daten erfasst noch inhaltlich relevante Daten angezeigt werden. Wir hatten das seinerzeit sogar von einem Fachanwalt prüfen lassen.
    Kunden, welche die Anmeldeseite nutzen können, stehen ja bereits in einem Vertragsverhältnis mit Ihnen, in dessen Rahmen sie auch ihre Zugangsdaten erhalten haben.
    Ein IMAP-Server meldet im Prompt auch keinen Impressums-Link, obwohl dieser genauso Zugangsdaten erhält.


    Sofern Sie belastbare Quellen haben, die dem gegensprechen, bitte immer her damit.


    Viele Grüße


    -Klaus Keppler

    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