Beiträge von TCRserver

  • Apache startet immer mal wieder neu

    Gute Idee, aber der ist es nicht. Der macht brav um 0:00 seine Rotation und der Apache hat dann um 07:50:24 einen Neustart gemacht.

    Dem Log nach ist es ein ganz normaler Restart, ausgelöst durch systemd.


    Ein CronJob ist es nicht und auch systemctl list-timers zeigt nichts passendes.
    Irgendwann werde ich noch drauf kommen.

  • Apache startet immer mal wieder neu

    Hallo Klaus,


    bei allen LC Servern meldet das Monitoring immer mal wieder einen Neustart vom Apache.
    Meistens im Abstand von ca. 24 h und oftmals auf allen Servern innerhalb von einer Stunde.

    Tut nicht weh und macht nichts kaputt, aber ich verstehe es nicht. Das ganze tritt seit vermutlich 2 Monaten auf.

    In den Logs oder den Metriken sehe ich keinen echten Grund dafür.
    Hat hier LiveConfig evtl. seine Finger mit im Spiel?

  • License Request failed

    Hallo Klaus,


    bei immer mehr Clients und auch Server fällt auf, dass ein Restart von LiveConfig fehl schlägt.

    Ursache ist, dass eine Abfrage der Lizenz fehl schlägt.
    Wenn ich die Lizenz entferne und neu lade, dann funktioniert es wieder.


    Code
    Jun 29 11:26:24 s17 lcclient[4667]:  - /usr/sbin/lcclient: Trying to renew license (serial# xxxxxxxx). Please wait a moment...
Jun 29 11:26:24 s17 lcclient[4667]:  ok.
Jun 29 11:26:24 s17 lcclient[4667]: Sending license request... ok.
Jun 29 11:26:24 s17 lcclient[4667]:  - /usr/sbin/lcclient: renewal failed: License request failed: Missing renewal token
Jun 29 11:26:24 s17 lcclient[4667]:  - /usr/sbin/lcclient: LiveConfig Client 2.18.0-dev20250526.1 starting...
Jun 29 11:26:24 s17 systemd[1]: Started lcclient.service - LiveConfig Client.

  • LiteSpeed Unterstützung?

    Zitat von kk

    Zudem testen wir bei einem Projekt einen serverweiten Brute-Force-Schutz für Wordpress (das ist ein immer häufigerer Grund für lang dauernde und teils extrem hohe Serverlasten).

    Ohja! Das Thema wäre extrem wichtig.
    Die "nutzlosen Anfragen" an WordPress werden immer mehr.
    Und die Plugins in den WordPress Installationen auch immer mehr. Dadurch gibt es extrem viel Blindleistung die einiges an Performance kostet.
    Durch kontinuierliches manuelles überwachen der Logs (zusätzlich zu div. Fail2Ban Filter) und ausfiltern von solchen nutzlosen Anfragen, bekommen wir die Load durchaus um 1-2 Punkte reduziert. Was sich Positiv in der Stromrechnung und der Performance bemerkbar macht.

    Beim LiteSpeed ist das aktuell größte Problem, dass Konfigurations-Änderungen in den .htaccess Dateien durch einen Neustart geladen werden.
    Das macht bei Docker Instanzen nichts aus. Wenn man aber auf einem Shared Host System permanent den http neu startet, dann sorgt das unter Umständen für reichlich Probleme.

  • LiteSpeed Unterstützung?

    Aus meiner Sicht wäre nur die kommerzielle Variante von LiteSpeed spannend.
    Aber die Nachfrage dafür ist in der Tat äußert gering.
    Und mit etwas Leidenschaft, kann man sicherlich den Apache oder auch den NGINX zur gleichen Performance bringen.
    Bottleneck dürfte auch eher PHP sein als der eigentliche http-Server.

  • Ausblick auf das nächste große Release

    Dann schreibe ich doch gleich noch ein paar Issues fürs lange Wochenende :D


    Kann ich eigentlich die aktuelle LC2 Datenbank auf dem LC3 Server nutzen, ohne dass die ganzen Clients angebunden sind?

    Also nur die DB kopieren und dann mit realistischeren Daten meine API Anbindung testen?

  • Bruteforce Angriff hebelt LiveConfig aus, fiktive E-Mail Adresse sendet SPAM - Was könnte man tun?

    Brute Force ist jetzt nicht unbedingt eine Lücke...

    Wenn man die Zugangsdaten hat, dann hat man "legitimen" Zugriff auf das Mail System.

    Hier hilft dann sowas wie fail2ban oder sshguard gegen zu häufige Anmeldeversuche.


    Anhand des Log Auszugs kann ich nichts erkennen.

    Im Prinzip müsste man die Queue prüfen wo die Mails her kommen, also von welchem Kunden oder ob die von z.B. PHP versendet werden.


    Code
    cd  /var/spool/postfix
find active bounce deferred incoming maildrop -type f | wc -l

    Wenn hier irgendwas größer 10 raus kommt, dann würde ich anfangen die Queue zu prüfen.

    Um danach zumindest mal den permanenten Versand zu beenden, könnte man temporär die Mailserver stoppen.

    Dann fängt die Suche nach dem Versender innerhalb des Systems an.

  • Massenänderung PHP-Version

    Ganz ehrlich, es nervt inzwischen etwas. Lass doch das gemaule bitte. So schlecht ist LiveConfig nicht und ich bin SysAdmin weil ich nicht für alles eine GUI benötige. Ja es gibt teilweise echt Handlungsbedarf, aber manche Sachen kann ich auch händisch machen. Oder in Zukunft über die LC3 API.

  • Nameserver Zonen neu generieren

    Ich habe die Zonen vor einigen Jahren mal neu geschrieben, als bei OVH das RZ abgebrannt ist und einer meiner Secondary dort stand.

    Aber das war ein Umzug von Debian nach Debian und es gab eigentlich nur ein Problem, dass irgendein Sync nicht funktioniert hat und sich die IP-Adressen geändert haben. Ich erinnere mich nicht mehr ganz genau daran.


    Ich meine, dass LiveConfig die Zonen auch komplett neu erstellt und kein Backup vom Secondary dafür benötigt.

    Wie wenn man einen weiteren Nameserver hinzufügt, der wird ja auch komplett neu beschrieben.


    Folgende Infos habe ich noch von damals:


    >> Vorab schonmal: den Ersatz-Server installierst Du bitte einfach "ganz normal"
    >> (also frisch aufsetzen). Da dann den lcclient installieren und mit der Host-ID des
    >> "alten" lcclient ins LiveConfig einbinden (also nicht als neuen Server, sondern
    >> als Ersatz für den alten).



    >1.) wenn BIND und lcclient auf dem "neuen" Secondary laufen, auf
    > Serververwaltung -> (Server wählen) -> DNS gehen, und dort die
    > Konfiguration (IP-Adressen) anpassen und abspeichern
    > (damit werden die relevanten Konfigurationsdateien neu geschrieben)
    >
    >2.) danach folgenden SQL-Befehl in der LiveConfig-Datenbank ausführen:
    >
    > update NAMESERVERS set NS_UPDATEKEYS=1;
    >
    > Anschließend LiveConfig (auf dem Master-Server) neu starten.
    > Kurz danach sollten die TSIG-Schlüssel neu geschrieben werden
    > (/etc/bind/keys.liveconfig - sowohl auf dem Primary DNS als auch auf dem
    > Secondary)
    > Wichtig ist, dass beim Master in keys.liveconfig nun die neue IP des
    > Secondaries drin steht.

    >3.) Wenn soweit alles geklappt hat, den LiveConfig-Server auf v2.11.3 aktualisieren (aktuelle Preview, die Clients können auf 2.11.2 bleiben)
    >
    >4.) Danach das DNS-Template bearbeiten und den betroffenen Secondary aus dem
    > Template *entfernen*.
    >
    >5.) einen Moment warten, bis die Jobs abgearbeitet sind.
    >
    >6.) Danach das DNS-Template erneut bearbeiten, und den Secondary wieder aufnehmen.
    >
    > Die Zonen sollten dann in /etc/bind/zones.liveconfig auftauchen.

    >In /var/log/liveconfig/liveconfig.log (Master) bitte prüfen, ob es Fehlermeldungen bei einzelnen Domains gibt.
    >In Einzelfällen hilft es, die jeweilige Domain mal kurz auf "externen DNS-Server" zu schalten und danach wieder zurück (damit wird die komplett neu im DNS konfiguriert). Sollte es mehrere Probleme geben, melde Dich bitte.
    >


    Gefühlt sollte es noch immer so funktionieren.

    Nur eben den Punkt 3 überspringen, der sollte nicht mehr ganz aktuell sein :)

  • Seltsame Fehlermeldung nach dem hochladen von WHMCS

    Also nicht falsch verstehen... aber WHMCS benutzen und damit faktisch irgendwas mit Domains, Hosting, Server machen zu wollen und dann ein einfaches PHP Programm nicht zum laufen bekommen. Bitte überdenkt nochmal den Plan.


    Zum Problem:

    Sicher, dass die richtige PHP Version ausgewählt ist im LiveConfig?
    Wurde auch LiveConfig nach dem installieren einmal neu gestartet?
    Ansonsten wird ioncube nicht geladen.

    Was auch hilft wäre eine Ausgabe von liveconfig --diag

  • DNSBL ix.dnsbl.manitu.net ist nicht mehr

    Ich kenne leider keine entsprechende Übersicht.
    Wäre mal ein Vorschlag für die Heise Redaktion, dass sie daraus einen Artikel machen.


    Bei den meisten Anbietern die (meiner Meinung nach) eine richtig hohe Qualität anbieten, ist das Problem, dass Sie nach Postfächern oder Domains abrechnen. Und dann auch noch irgendwelche kruden Vertragsbedingungen mit rein verknüpfen, dass es bei allen Postfächern auf dem Server identisch sein muss. Was dann bei Shared Hosting eher keinen Sinn macht, wenn ich für jedes Postfach ~ 0,50€ für den SPAM Filter zahlen muss.

    Was ich aus dem Kopf raus an Listen kenne:
    Barracuda Anti-Spam
    Securepoint
    SPAMHAUS
    Abusix
    mcgrail / KAM
    Heinlein
    Schaal-IT
    Spamcop
    SORBS