Beiträge von TCRserver

In diesem Setup wäre LAC eigentlich nur für den Web Server Relevant.
Ein Ausbruch aus einem Skript bzw. ein Shell Zugriff auf den DB oder Mail-Server macht keinen Sinn, oder?
Und eigentlich war ja der Plan von LC, dass man keinen expliziten C&C Server benötigt, sondern man einen ganz normal genutzten Server dafür nimmt. Somit könnte man den Webserver mit der Business ausstatten und den dann mit LAC.

Oder vielleicht reicht es ja auch aus einen Business Server als C&C zu nutzen und dann wird die Funktion auf die Standard Server vererbt.
So wie beim Let's Encrypt Feature. Das muss aber KK beantworten.

Zitat von kk

Meine persönliche Meinung (als Techniker und Nicht-Jurist) ist, dass E-Mail kein verlässlicher zweiter Faktor ist.

Der Grund ist banal: wenn das Passwort für LC via E-Mail zurückgesetzt werden kann, und Mail auch als 2FA genutzt wird, dann ist das eben nur ein Faktor.

Sehe ich auch so. Aber leider sind die Juristen keine Techniker...

Liest sich aber so, als ob es schon einen groben Plan für das Thema gibt.
Dann mache ich in meiner Checkliste mal einen Haken bei "In Planung".

Logging via Syslog - mit einem LC eigenen Dienst oder sowas wie z.B. GrayLog?

Ich würde hier gerne eine Diskussion zur NIS2 und LC3 eröffnen:

Meiner Meinung nach, müssten alle LC Accounts (die eine DNS Verwaltung ermöglichen) eine erzwungenen 2FA Aktivierung haben.
Derzeit ist in LC3, wenn ich es richtig gesehen habe, die 2FA Anmeldung optional.

Somit müsste eigentlich eine 2FA E-Mail Methode für LC3 nachgerüstet werden und eben einen Option zur Zwangsaktivierung.

Wie ist eure Meinung dazu und was ist Seitens LC3 schon in Planung dazu?

Wie kann man die Site-Pro Funktionen unter LC3 testen?
Aktuell finde ich keinen mod der für LiveConfig3 angeboten wird.

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.

# journalctl -u apache2
Jun 30 07:50:24 s7 systemd[1]: Stopping The Apache HTTP Server...
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203717 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203718 (lclogsplit) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203719 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203720 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203721 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203856 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203920 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1205253 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1205746 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1205753 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1206084 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1206097 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1206413 (php-cgi) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203732 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1203762 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Killing process 1205305 (apache2) with signal SIGKILL.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Succeeded.
Jun 30 07:50:24 s7 systemd[1]: Stopped The Apache HTTP Server.
Jun 30 07:50:24 s7 systemd[1]: apache2.service: Consumed 1min 43.110s CPU time.
Jun 30 07:50:24 s7 systemd[1]: Starting The Apache HTTP Server...
Jun 30 07:50:26 s7 systemd[1]: Started The Apache HTTP Server.
Jun 30 07:50:26 s7 lclogsplit[1210713]: EOF received while reading from STDIN - closing...

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

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?

Funktioniert wieder, Danke!

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.

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.

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.

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.

Von dem Tool scheint es einen Container zu geben. Nimm doch den, dann entfällt das komplizierte Setup mit eigenen Paketen, für die es sicherlich einen Grund gibt warum man die nutzen möchte und nicht die etablierten Standard Pakete.

Ansonsten würde ich die Doku zu eigene PHP Pakete empfehlen.

https://www.liveconfig.com/de/…hp-versionen-registrieren

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

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?

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.

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.

Ich habe mal angefangen den öffentlichen Bugtracker im Github mit einigen Punkten zu füllen. Vielleicht finden sich ja noch mehr Leute die mitmachen.
Generell funktioniert die API Schnittstelle sehr gut und der Fortschritt von LC3 in den letzten Wochen ist deutlich spürbar.

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.

mal probiert die Seriennummer der Domains zu erhöhen?
Damit sollte doch die Zone komplett neu geschrieben werden.

Und was sagen die Logs ist da evtl. noch ein Fehler zu finden?

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

Per default ist bei dir die PHP Version von Debian aktiv.

Und dort wirst du auch keinen ioncube installiert haben.

Tausche mal die PHP Version im LiveConfig auf die andere 8.2.

Dann wird es vermutlich funktionieren.

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

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