Beiträge von kk

    Ab LiveConfig v2.11.0 wird die logrotate-vhosts-Konfiguration nun so geschrieben, dass die Kompression auch klappt wenn das Quota eines Benutzers ausgeschöpft ist. Die bestehende Logrotate-Konfiguration wird während des Upgrades entsprechend gepatched.


    Die Preview-Version wird heute Nachmittag entsprechend aktualisiert.


    Viele Grüße


    -Klaus Keppler

    Zitat

    Jan 18 00:00:03 s41.de logrotate[14869]: gzip: stdout: Disk quota exceeded
    Jan 18 00:00:03 s41.de logrotate[14869]: error: failed to compress log /var/www/web36/logs/priv/php_errors.log.1


    Wir planen, die Anweisung "su" in der LiveConfig-Logrotate-Konfiguration von "su <Vertrag> <Vertrag>" in "su <Vertrag> root" zu ändern. Somit werden die Logs während der Komprimierung nicht dem Quota des Kunden zugeordnet. Anschließend soll die Gruppe dann (per "postrotate"-Anweisung) wieder der Kunden-Gruppe zugeordnet werden, damit die Logs letztendlich wieder dem Quota zugezählt werden.

    ich möchte eine React Anwendung auf meiner Webspace laufen lassen. Diese Anwendung besitzt jedoch verschiedene routen, welche über einen internen router in der Anwendung zu verschiedenen Seiten in der Anwendung führen.


    Am einfachsten und wartungsfreundlichsten ist es tatsächlich, die paar RewriteRules in eine .htaccess zu packen. Einfach die <Directory>-Anweisung noch entfernen, und das ganze als .htaccess in's Webspace-Verzeichnis (~/htdocs/.htaccess) schreiben:


    Apache Configuration
    RewriteEngine on
        # Don't rewrite files or directories
        RewriteCond %{REQUEST_FILENAME} -f [OR]
        RewriteCond %{REQUEST_FILENAME} -d
        RewriteRule ^ - [L]
        # Rewrite everything else to index.html to allow html5 state links
        RewriteRule ^ index.html [L]


    Viele Grüße


    -Klaus Keppler

    Es gibt die Möglichkeit, die Quell-IPs bei BIND explizit zu konfigurieren.
    Bearbeiten Sie testweise mal die Datei /etc/bind/named.conf.options und fügen dort im options-Abschnitt folgende Einstellungen ein:


    Code
    transfer-source { 169.254.12.34; };
    notify-source { 169.254.12.34; };
    transfer-source-v6 { 2001:db8::1; };
    notify-source-v6 { 2001:db8::1; };


    IPs natürlich entsprechend anpassen. Danach BIND neu starten und beobachten, ob damit alles wie gewünscht funktioniert.
    Wenn ja, dann nehmen wir das gerne in ein kommendes Update mit auf.


    Bis dahin lässt sich das über z.B. /etc/liveconfig/lua.d/bind.lua mit folgendem Inhalt einrichten (siehe Handbuch:(

    Code
    bind.LOCALOPTIONS = {
      ['transfer-source'] = "{ 169.254.12.34; }",
      ['notify-source'] = "{ 169.254.12.34; }",
      ['transfer-source-v6'] = "{ 2001:db8::1; }",
      ['notify-source-v6'] = "{ 2001:db8::1; }"
    }


    Viele Grüße


    -Klaus Keppler

    Leute, wir sind hier i.d.R. auf Shared Webhosting Systemen unterwegs. Das sind die Server, bei denen man für ein zeitgemäßes WordPress auch ein zeitgemäßes PHP braucht. Was nutzt da z.B. ein CentOS 6 (das "erst" seit knapp 4 Wochen EOL ist), wenn das standardmäßig PHP 5.3 mitbringt?


    (E)LTS ist was für abgeschottete Spezialserver, aber nicht für prinzipiell "offene" Multi-User-Systeme.


    Und um mal einen kleinen Rant aus Entwicklersicht los zu werden: so uralte und ewig lang künstlich am Leben erhaltene Distributionsversionen sind eine einzige Katastrophe. Um die Software anständig zu testen betreiben wir z.B. für jede Distri eine eigene VM, die jeweils aktualisiert und gepflegt werden muss (aktuell sind das übrigens über 15 Server nur für Tests). Will man nun moderne Sicherheitsfunktionen (ASLR etc.) nutzen oder einfach "nur" modernere Sprachen (C++ 11/15/17/20) muss man schauen inwiefern auf der jeweiligen Plattform überhaupt passende Compiler verfügbar sind. Spoiler: C++11 auf CentOS 6 kann man knicken.
    Um also nicht sicherheitsmäßig auf dem kleinsten gemeinsamen Nenner arbeiten zu müssen (also auf dem technischen Stand von vor knapp 10 Jahren), muss man einen gewaltigen Aufwand in die Build-/Test-Chain und die Pflege von Servern mit uralten Distributionen stecken. Für uns bedeutet das also z.B. dass wir uns moderne Compiler selber auf Altsystemen einrichten (selber bauen) müssen. Spätestens uralte glibc-Versionen stellen dann aber eine nicht mehr überschreitbare Grenze dar.
    Ich persönlich bin daher froh um jede Distribution, die ihr EOL erreicht hat. ;) Bei Debian finde ich das Release-Intervall persönlich sehr angenehm, und die Upgrades sind meist völlig reibungslos.

    Werden auf dem Server eventuell ausgehende Verbindungen blockiert?


    Auf den ersten Blick klingt diese Fehlermeldung danach, dass der Webserver keine OCSP-Stapling-Tickets von der jeweiligen SSL-CA abrufen kann.

    /var/www/<Vertrag>/conf/fpm.conf funktioniert leider immer noch nicht!


    Haben Sie nach Änderungen in der fpm.conf den Vertrag (bzw. irgendeine Domaineinstellung) auch neu gespeichert?
    Die fpm.conf wird beim Schreiben der (aktualisieren) vHost-Konfiguration jedenfalls berücksichtigt.


    Falls nicht: welche Einstellungen genau haben Sie darin gemacht?


    Zitat

    Gut wäre wenn man die Einstellungen direkt im Interface machen könnte!


    Steht bereits auf der ToDo-Liste - die PHP-Verwaltung soll insgesamt umstrukturiert werden.

    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