Beiträge von kk

RPM-Repo ist nun auch aktualisiert.

Es gab eben noch eine Aktualisierung (v1.6.1-r2142) - spielen Sie diese bitte ein und speichern Sie dann noch mal die Postfix-Einstellungen neu ab. Auf unserem CentOS6-Testsystem wurde damit der richtige ClamAV-Socket-Pfad konfiguriert.

Viele Grüße

-Klaus Keppler

@arboldB: wir setzen für Tests ein System auf Basis von Jenkins und Selenium ein - da spielt im Hintergrund nicht nur die SOAP-API mit, sondern auch eine "Fernsteuerung" von Firefox, um auch auf GUI-Ebene alles durchzutesten. Zum Testen der konfigurierten Dienste kommen Perl-Scripte zum Einsatz, die dann z.B. per FTP eine Datei hochladen und prüfen ob die auch über den Webserver erreichbar ist. Um nun SMTP mit SSL zu prüfen, muss auf jedem Testserver das entsprechende Perl-Modul mit SSL-Unterstützung aktiviert sein, und vor allem müssen wir erst noch unser "eigenes" CA-Zertifikat an alle Testserver verteilen, mit dem wir wiederum die SSL-Zertifikate für die Test-Instanzen unterschreiben.
In der Theorie ist das also alles ganz einfach, nur in der Praxis mit eben seeehr viel Handarbeit verbunden...

Keine Ursache - ich bitte um Entschuldigung für die Unannehmlichkeiten.

Das neue Paket steht nun bereit (v1.6.1-r2142).
Außerdem haben wir schon herausgefunden, wie wir das mit SSL durchtesten können.

Zitat von eiclinde

/usr/lib/liveconfig/lua/postfix.lua:450: bad argument #2 to 'write' (string expected, got nil)

Fehler wurde lokalisiert und beseitigt, das Update läuft gerade durch die Build-Server.
Kurz gesagt: im betroffenen Abschnitt der postfix.lua wurde zuletzt noch etwas an der Reihenfolge der Configdatei-Erstellung verändert, damit zum Aufruf der "postmap"-Befehle die "main.cf" bereits erzeugt ist. Leider wurde dabei auch die Erstellung der SSL-Schlüssel-Dateien verschoben - an eine "zu späte" Stelle.
Wir werden prüfen, wie wir auch die SSL-Konfiguration von Postfix künftig automatisiert durchtesten können, um ähnliche Probleme künftig zu verhindern.

Das Update steht in ca. 10min bereit, ich gebe dann gleich noch mal Bescheid.

Hallo Herr Lindner,

ich vermute, dass bei Ihnen in der Postfix-Konfiguration das Häkchen bei "SSL/TLS" gesetzt ist, aber kein Zertifikat ausgewählt ist (oder dass das gewählte Zertifikat noch nicht "vollständig" ist, in diesem Fall wird vermutlich noch kein CRT hinterlegt sein).
Deaktivieren Sie bitte das Häkchen bei SSL/TLS, dann sollte das Speichern klappen.
Wir werden das gleich mal genauer prüfen und ggf. einen Check einbauen, so dass man kein unvollständiges SSL-Zertifikat auswählen kann.

Viele Grüße

-Klaus Keppler

Das LiveConfig-Team freut sich, die Verfügbarkeit von LiveConfig v1.6.1 (stable) bekannt geben zu dürfen.

Mit dieser Version wurden sehr viele Detailverbesserungen vorgenommen und Fehler beseitigt - eine ausführliche Liste der Änderungen finden Sie im Changelog.
Wir empfehlen allen Nutzern von LiveConfig, bei Gelegenheit auf die neue Version zu aktualisieren.

Der Issue-Tracker für die Planung der nächsten Versionen wird heute im Laufe des Abends aktualisiert.

Viele Grüße

-Klaus Keppler

Nein, für den Angriff via ptrace muss man bereits lokaler Benutzer sein. Der Einstieg erfolgt aber scheinbar direkt über den root-Account via SSH.

Gleich vorab: das hat nichts mit LiveConfig zu tun

Derzeit scheint ein SSH-Rootkit im Umlauf zu sein - Details sind noch äußerst unklar. Ein Hinweis auf eine Infektion liegt vor, wenn die Datei /lib64/libkeyutils.so.1.9 existiert (andere Versionen - wie z.B. libkeyutils.so.1.3 sind ok).

Die infizierten Systeme werden derzeit wohl hauptsächlich zum Versand von Spam verwendet. Eine ausführliche Diskussion dieses Themas findet sich auf dem englischen WebHostingTalk-Forum.

Bitte prüfen Sie bei Gelegenheit, ob die o.g. Datei auf Ihren Systemen existiert. Betroffen sind offenbar alle Linux-Distributionen. Ob der Einstieg über einen Fehler im SSH-Daemon oder über per Trojaner abgeschnüffelte Passwörter läuft, ist derzeit noch nicht geklärt.

Viele Grüße

-Klaus Keppler

Zitat von dicker

Can't open any socket for address 0.0.0.0, port 8443

Das deutet darauf hin, dass LiveConfig noch läuft.
Bitte stoppen Sie LiveConfig (/etc/init.d/liveconfig stop), prüfen ob es wirklich nicht mehr läuft (ps aux | grep liveconfig) und starten es dann noch mal neu (/etc/init.d/liveconfig start).

Falls es sich nicht vollständig beenden lässt: "killall -9 liveconfig", danach mit "ipcs" suchen ob es noch Shared-Memory-Segmente von LiveConfig gibt (siehe Handbuch).

Zitat

Dem Reseller stört es, dass da mein Servername steht, weil seine Kunden das ja sehen.

Wenn Server für Reselling genutzt werden, dann tragen diese üblicherweise auch "neutrale" Hostnamen. Auch wenn der Hostname nicht in LiveConfig angezeigt werden würde - er würde dennoch z.B. im SSL-Zertifikat für die LiveConfig-Oberfläche und ggf. im Reverse-DNS-Eintrag der Server-IP stehen.

Viele Grüße

-Klaus Keppler

Äh - so wie das aussieht sollten Sie sich unbedingt mit der Bedeutung von /etc/passwd auseinander setzen. Diese Zahlen darin sind extrem wichtig (User- und Group-IDs) und dürfen unter keinen Umständen geändert werden! (außer man weiß genau was man da macht).
Die "zusätzlichen" (virtuellen) FTP-Benutzer wie z.B. web1p1 werden nicht als Systemaccounts angelegt und sind daher auch nicht in /etc/passwd zu finden, sondern (je nach Software) in /etc/proftpd/passwd oder /etc/vsftpd/passwd.db. Auch da kann bzw. soll nichts manuell eingegriffen werden.

Insgesamt lese ich zwischen den Zeilen heraus, dass Sie LiveConfig auf einem Server aufgesetzt haben, auf dem bereits Confixx läuft? Ich befürchte, daß das nicht gutgehen wird, da sich nun zwei Control-Panels um die Konfigurationsdateien "streiten". Bitte setzen Sie für LiveConfig einen neuen ("leeren") Server auf und migrieren ggf. die Confixx-Accounts (siehe KB#5).

Viele Grüße

-Klaus Keppler

Ist ab v1.6.1-r2107 korrigiert.

Danke für den Hinweis, das ist im Stable-Release (1.6.1) dann auch berücksichtigt; die Bedingung wurde einfach so korrigiert, dass diese immer "positiv" ist:

32    03    * * *     root       [ ! -d /etc/awstats/liveconfig ] || /usr/lib/liveconfig/cron.awstats.sh

Viele Grüße

-Klaus Keppler

Hmm, wenn ich das richtig sehen sollte der Milter-Socket unter CentOS 6 unter /var/run/clamav/clamav-milter.ctl liegen.
Im kommenden Stable-Release (1.6.1) dürfte das dann bereits korrigiert sein - ich lasse das morgen aber dennoch noch mal durchtesten.

Also, ich kenne da viel niedrigere Straßenpreise (eher um die <300 EUR).

Diese sollen natürlich auch exportier-/importierbar sein - in Form einer XML-Datei. Hier ist aber bislang noch nichts implementiert (da stehen noch ein paar wichtigere Dinge an).

Hmm, das sind eher interne Daten, die auch noch nicht konsequent aktualisiert werden. Hiermit soll jedenfalls die Version einer Konfigurationsdatei zurückverfolgt (versioniert) werden. Ich schätze mal, wir werden diese Anzeige vorübergehend eher mal entfernen, bis da verlässliche Daten drin stehen.

Auf unserer ToDo-Liste steht eine "Panic Button"-Funktion, mit der alle (bzw. alle gewünschten) Konfigurationsdateien neu erzeugt werden - damit dürfte das dann möglich sein.

Äh - das ist ein Mißverständnis; hier wird lediglich die Domain ausgewählt, unter welcher die Zugriffsstatistiken erreichbar sind. Berücksichtigt werden aber die Zugriffe auf alle Domains.

Dieser Punkt befindet sich noch in Arbeit - darüber werden künftig php.ini-Einstellungen individuell verwaltet.