Beiträge von tbc233

Lösen sich die betroffenen Domains DNS-mäßig noch auf die alte Domain auf? Ich hab da was im Kopf, dass das abgefragt wird beim generieren. Ich kann mich aber irren.

Ich hab auch mal versucht, die Host Dienste per ipv6 zugänglich zu machen. Da ich keine andere Möglichkeit kenne, habe ich es wie von Dir angedacht so gelöst, dass ich einen eigenen Container in die template Datei eingefügt habe.

Grundsätzlich hats funktioneirt, allerdings wirft das administrator und das customer Interface dann einen Lizenzfehler wenn man per ipv6 daher kommt. Weil die Lizenz ist ja auf die ipv4 Adresse ausgestellt und das wird an dieser Stelle geprüft.

Mir fällt auf, dass meine /home/mysql/$HOSTNAME.err Logfiles teilweise ganz schön fett geworden sind. Hauptursache sind Zeilen wie diese

2022-10-04T00:30:01.497239Z 55985 [Note] Aborted connection 55985 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-04T23:00:05.914856Z 59778 [Note] Aborted connection 59778 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-05T00:30:02.338012Z 59832 [Note] Aborted connection 59832 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-05T23:00:05.903515Z 61884 [Note] Aborted connection 61884 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)
2022-10-06T00:30:01.427975Z 61939 [Note] Aborted connection 61939 to db: 'vadmin' user: 'vadmin' host: 'localhost' (Got an error reading communication packets)

So eine Meldung entsteht jeden Tag um 23:00 Uhr und um 00:30 Uhr. Mit welchem Cronjob dass zusammenpassen würde, erschließt sich mir allerdings nicht.

Jedenfalls hab ich das auf so gut wie allen pd-admin Servern.

Hat das sonst noch jemand?

Ich hab schon vor längerem aufgegeben, hier selbst herum zu justieren. Ich finde es geht einfach zu viel Zeit drauf um ein zufriedenstellendes Ergebnis zu erzielen (und es auch aufrecht zu erhalten).

Daher hab ich vor ein paar Jahren entschieden, dass Leute machen zu lassen, die das hauptberuflich tun und mach das - je nach individuellem Kundenbedarf - über spamexperts.com

Die machen einen guten Job und die Preise sind fair. Integriert wird das ganze via MX Eintrag je Domain.

Wenn wir mal davon ausgehen, dass es ein vergleichbares Thema wie beim Avast ist, würde mich brennend interessieren (weil ich diesen Test leider verabsäumt habe als ich beim Kunden mit Teamviewer drauf war) ob das Problem auch besteht wenn SMTPs über Port 465 genutzt wird. Weil in die SSL Kommunikation sollte sich der Virenschutz ja eigentlich nicht einmischen können.

Seit Ende letzter Woche schlagen bei mir öfter mal Kunden auf, die keine Mails mehr senden können. Bisher war es ausschließlich Outlook als Client btw.

Es kommt eine Fehlermeldung "451 See http://pobox.com/~djb/docs/smtplf.html" im Client, während es am Server in den Logs verdächtig ruhig bleibt.

Habe mir das also per Teamviewer direkt beim Kunden angesehen. In allen Fällen war es der AVAST Virenscanner. Wenn man den deaktiviert, geht es sofort wieder. Alternativ kann man auch das "Mailschutz" Modul von diesem Avast abdrehen. Dann geht es ebenfalls wieder.

Die genauen technischen Zusammenhänge sind mir hier allerdings nicht klar. Offenbar mischt sich dieser Avast in den SMTP Dialog ein. Leider habe ich aber bisher bei allen Fernwartungen vergessen nachzusehen, ob die Betroffenen SSL/TLS nutzen bei SMTP. Weil da sollte das ja eigentlich nicht so einfach möglich sein für einen Virenscanner sich da in den SMTP Dialog einzuklinken.

Ist hier ein bekanntes CMS oder so im Einsatz, oder etwas selbstgebautes?

Leider gehört es mittlerweile zum Grundrauschen dass ständig versucht wird mit SQL- oder Command Injection bekannte Schwachstellen auszunutzen. Hier versuchts anscheinend jemand über GET entsprechende Befehle zu injizieren.

Was mich in Deinem Fall aber ein bisschen nervös macht ist, dass hier anscheinend explizit ein "SELECT bla bla bla FROM usrdb...." versucht wird. Das sieht mir danach aus als würde der Angreifer den Namen Deiner Datenbank kennen. Das dürfte eigentlich nicht sein, woher sollte er den wissen?

Also ich will jetzt hier noch nicht den Teufel an die Wand malen, aber möglicherweise weiß er Angreifer schon ein bisschen mehr über diese Website als er eigentlich wissen sollte.

Wenn es an veralteten Root Zertis liegt, dass Du hier den Weg über einen anderen Server gehst, kann ich Dir meinen hier zitierten Befehl RE: Neue Domain/neuen Kunden einrichten -> Unzureichende Berechtigung. durchaus empfehlen. Läuft seit Monaten klaglos.

Zitat von Eisenherz

Ich weiß, dass ich mal die Uhrzeit des Cronjobs zur Lizenzabfrage verändert hatte, da war mal irgendwann was zu im Forum glaube ich.

Es gab mal ein Thema das ganz früher (das ist aber wirklich schon viele Jahre her) alle Installationen mit dem gleichen Zeitpunkt zur Abholung der Lizenz ausgeliefert wurden. Das wurde dann etwas zu viel für den Lizenzserver und es wurde dann empfohlen die Zeit des Jobs auf eine andere, eher zufällige Zeit zu stellen.

Das ist aber schon länger vom Tisch, seit vielen Jahren wird dieser Cronjob automatisch mit zufälligen Zeiten ausgeliefert. Hab mir grad zwei, drei Server angesehen, da steht überall eine völlig andere Zeit drin.

Nachtrag:
Sorry, hab erst jetzt gelesen dass Du ja eine Vollversion haben solltest. Dann ist davon auszugehen, dass das abholen der Lizenz nicht funktioniert hat und daher die Lizenz als Free läuft.

Lass mal den Lizenz-Abhol-Cronjob manuell laufen und schau Dir den Output an. Ich hatte hier auf vielen Servern das Problem, dass die das nach dem letzten Letsencrypt Root Zertifikatswechsel nicht holen wollten, da sie das Zerti nicht kannten. Ich musste dazu das ca-certificates Paket meiner Distri aktualisieren.

Bei einem sehr alten Server, wo ich die root Zertifikate nicht mehr so ohne weiteres aktualisieren kann, hab ich mal diesen Thread aufgemacht: licence.conf manuell in Stellung bringen

Die Erkenntnisse aus diesem Thread habe ich dann übrigens später verfeinert auf diesen Befehl:

/usr/local/pd-admin2/bin/curl -k "https://www.pd-admin.de/license/?action=get_licence&name=pd-admin-4&IP_ADDR=IP-ADRESSE-DES-SERVERS" > /opt/pdadmin/etc/license.conf

Zitat von Twilo

ich frage mich gerade, warum die Lizenz nur bis zum 14.03. gültig ist.

Bei der FREE Lizenz wird dieses Datum nicht sonderlich gepflegt bzw. spielt es ohnehin keine Rolle. Unter 10 Domains läuft ohnehin nichts ab.

Zitat von Twilo

Eine aussagekräftige Fehlermeldung wäre hilfreich gewesen

Das hab ich mir damals auch gedacht als es mir passiert ist. Habe aber vergessen das rückzumelden.

Verzeih wenn ich Dich alten Hasen sowas naheliegendes frage , aber kannst Du ausschließen dass das generelle Domainlimit Deiner Lizenz vielleicht am Ende ist?

Ich bin mir nämlich sehr sicher dass ich genau die Meldung das letzte Mal bekommen habe, als die Anzahl meiner Domains auf dem Server zur Neige gegangen ist.

Das kann meiner Beobachtung nach immer wieder mal vorkommen. Da überschneidet sich, vermutlich sehr vereinfacht gesagt, der Neustart vom Apache um ein paar Sekunden (zb. aufgrund des regulären httpd_vhosts Cronjobs) und drum kommts zu der Meldung dass ers ich nicht binden kann an den Port.

Wenn nachher alles läuft, würde ich dem keine Bedeutung zumessen.

Die WAF Integration ist noch relativ jung. Ich setze sie derzeit noch nicht ein.

Twilo wenn es sich nicht bewährt, würde ich das WAF halt vorerst mal abdrehen.

Ja, kann ich bestätigen. Debian setzt das Ding nicht ein. Ubuntu anscheinend auch nicht (zumindest nicht in einer Minimalkonfiguration die ich habe).

Auf centos Systemen hab ich mal unmittelbar nachdem ich von dem Zeug gelesen habe ein "chmod 0755 /usr/bin/pkexec" ausgeführt.

Ich habe keine Mail Verständigungen aktiviert. Find ich sinnlos. Blocken genügt.

An das Melden an die Abuse Departments hab ich schon lange den Glauben verloren. Und das Melden an größere Blocklisten unterstütze ich auch nicht mehr so gern, seit IPs oder IP Blöcke so oft den Besitzer wechseln und man damit vielleicht den falschen bestraft. Mich nervts ja umgekehrt selbst immer wenn ich wo einen völlig frischen Server mit neuer IP aufsetze und dann erst mal bei hundert Blocklisten die IP Reputation in Ordnung bringen muss.

Zitat von WebTeufel

und denn noch, wäre doch interessanter und evtl besser wenn jeder kunde es in seinem eigenem backup haben könnte, oder?

Da würde ich ein Datenschutzproblem sehen. Derjenige der pd-admin bedient ist oft ein externer Webdesigner, manchmal auch nur der Nachbarsjunge mit seinem Wordpress. Ich fänds nicht gut wenn der mal so eben mit einem Klick die gesamte Unternehmenskommunikation runterladen kann.

Darauf könnte man natürlich einwenden, dass jeder mit pd-admin customer Zugang sich ohnehin Zugang zu den Mails verschaffen könnte, durch Passwort neu setzen, allerdings würde das halt viel schneller auffallen.

Zitat von WebTeufel

werden mails / popboxen irgendwo gesichert?

kann man das nicht ins backup mit einbeziehen?

Wenn Du die Standardsicherung von pd-admin benutzt (Backupziel unter /opt/pdadmin/etc/pdadmin.conf sowie cronjob /opt/pdadmin/bin/backup.pl) wird in deinem Backupziel unter "system" ein backup namens home_popuser.tar.gz erstellt, welches das gesamte popboxen Verzeichnis (also alle Mailboxen) enthält.

Zitat von tooliload

Hallo, ist $cron_mem_limit in der Datei /opt/pdadmin/etc/pdadmin.conf noch korrekt? Ich habe den Cronjob nach Änderung in der PD-Admin KOnfiguration editiert, jedoch besteht das Softlimit weiter.

Ich denke nicht dass $cron_mem_limit noch ausgwertet wird, seit das in die Angebotsverwaltung geflossen ist.

Hast Du bei Dir die cronjob Limits in dem zugrunde liegenden Angebot kontrolliert?

Dankeschön! Wie man sieht klappt das jetzt gut.