Beiträge von suppenuser

Zitat von weltmeister

Ich danke dir für den Tipp. Ich habe stichprobenartig den Server durchsucht nach Dateien mit falschen Dateirechten im Verzeichnis /var/lib/mysql/... konnte dort aber nichts finden. Auch im Backup des heute gelöschten Kunden konnte keine falschen Dateirechte finden.

Die Datenbank war sehr groß (über 800 MB), ich vermute eher dass dies das Problem war?

Hmmm. dürfte nicht sein. Zumal 800 MB jetzt nicht wirklich groß ist (IMHO wartet LC da nur auf die Rückmeldung des MySQL-Daemon, der für das Löschen zuständig ist ). Im Liveconfig-Log des betroffenen Servers steht der Grund, warum Liveconfig den Kunden nicht entsorgen kann drin.

Bei uns war das immer der MySQL-Daemon, der nicht die Rechte zum löschen des Verzeichnisses /var/lib/mysql/<userdb> hatte. In der Dev-Mailing-Liste von Digital-Ocean war damals auch der Hinweis, dass es einen Fehler mit den Rechten der Dateien gegeben hatte woraufhin wir überall die Owner und Rechte korrigiert hatten.

Zitat von weltmeister

Heute gleiches Problem wieder gehabt.

Liest das hier eigentlich jemand, bzw. passiert noch etwas?

Wann gibt es eine dauerhafte Lösung, ohne Bastelarbeiten?

Wird das Problem in der Version 3 behoben?

Du meinst, das einmalige korrigieren der Dateirechte, die von MySQL verhunzt wurden stellt keine dauerhafte Lösung ohne Bastelarbeit dar?

Nachdem wir das irgendwann vor 2019 bei uns auf allen Servern gemacht hatten ist das Problem nicht mehr aufgetreten. Und es hat keinen Nebeneffekt, wenn die Dateien -wie es sich gehört- mysql mysql gehören. Das da Dateien in den Userverzeichnissen (meist die db.opt) dem root gehören ist falsch und war ein Bug bei irgendeiner älteren MySQL-Version oder dessen Installer.

Hi.

Ja, kannst Du. Mailstore kann sich die Mails aus den Sicherungspostfächer ziehen…

Gruß

Zitat von taenzerme

Ich möchte mich hier mal einklinken, da wir von dem "Bug" auch betroffen sind und noch keine zufriedenstellende Lösung bisher haben.

Aber: Die hier genannten kleinen Provider als Referenz bzw. Entscheidungsgrundlage zu nennen erscheint mir dann doch etwas kurzsichtig. Host-On existiert nichtmal ein Jahr. Plesk kostet für die Plesk Web Host Edition for VPS nach meinem letzten Stand ca das 2,5fache pro Server, ungeachtet davon, dass wir einen Haufen Kunden hatten, die bei Plesk in keinster Weise durchgeblickt haben und genauso unzufrieden waren.

Korrekt.

Übrigens ist der "Bug" eigentlich kein Bug von Liveconfig.

Man kann das Problem recht schnell vermeiden, indem man einmal schaut ob in den Datenbankverzeichnissen der Kunden unter /var/lib/mysql/<datenbank-des-kunden>* Dateien, die nicht von mysql gelöscht werden dürfen rumliegen.... IMHO entstand dies durch Updates von MySQL/Debian/Ubuntu oder FreeBSD.

Zitat von weltmeister

Kann man so machen, aber es behebt die Ursache leider nicht.

die Ursache wirst Du mit LiveConfig 2.x nicht behoben bekommen.

Zitat von weltmeister

Gleiches Problem heute wieder gehabt. Wann wird es eine Lösung geben?

Handeln wir bei uns mit dem Nagiosplugin von Klaus in Verbindung mit einem kill und start ab...

Zitat von weltmeister

Alles gut, bei uns ist das wiederum ganz anders. Die ständigen Anfragen nach Funktionen die es nicht gibt, nerven einfach nur noch, weil man sich über die Jahre immer wieder rechtfertigen muss. Dann müssen wir uns noch anhören, ich zitiere aus einer der Mails: "dass dies bei jedem Billig-Hoster mit Plesk möglich sei, warum jedoch bei Ihnen nicht?"

Klar könnten wir noch mehr Spam-Blacklisten einbinden oder die Filter allgemein verschärfen. Das Problem ist, dass Absender wie office oder web.de, t-online.... usw. ständig auf Blacklisten gelistet sind. Von unseren Kunden gibt es dann auch wiederum "Ärger" wenn diese Mails nicht durchkommen. Und extra whitelisten für diese Spamschleudern aktivieren, ich weiß ja nicht... der Kunde versteht einfach nicht, dass das Problem in dem Falle gar nicht auf unserer Seite besteht, sondern auf der des Absenders oder besser dessen Provider.

Ich denke, dass Du das ein bisschen falsch siehst (nur meine Meinung!)

Bei uns kann der Kunde den sekundären Spamfilter ausschalten. Wenn er das nicht tut, werden Mails automatisch in den Spamfolder verschoben.

Den primären Spamfilter (rspamd) kann er nur indirekt beeinflussen indem er Mails in einen speziellen Ordner verschiebt aus dem das System lernt. Da wenig Falschmeldungen kommen ist der Kunde zufrieden und fragt nicht (ihm fehlt ja nichts)

Web.de/t-online etc. sind übrigens nicht mehr so heftig in den Blacklists. Die haben auch gelernt.

Gruss Ralf

Zitat von weltmeister

Die wöchentlichen Anfragen lassen nicht nach:

Sinnvoll ist eine Option, wo der Kunde selbst entscheiden kann, was mit Spam passieren soll:
1.) ablehnen
2.) in einen Ordner sortieren oder
3.) normal im Posteingang zustellen.

Mittlerweile gibt es diese Optionen bei fast allen Massenhostern wie Strato oder Ionos. Wir müssen also mitziehen und am Ball bleiben. Auch die Nutzer, die vorher Plesk bei anderen Providern hatten, sind verwundert über die fehlende Einstellungsmöglichkeit.

Ist hier etwas diesbezüglich in der neuen Version geplant?

Alles anzeigen

Kannst Du mit Deinem Dovecot automatisch anlegen lassen:

/etc/dovecot/conf.d/15-mailboxes.conf:

namespace inbox {  
    mailbox spam {    
        special_use = \spam    
        auto = subscribe  
        }
    mailbox junk {    
        special_use = \junk    
        auto = subscribe  
        }
    mailbox Trash {    
        special_use = \Trash    
        auto = subscribe  
        }

    }

Gruß Ralf

Zitat von Mogwais

Klingt interessant. Wie macht ihr das? Chatgpt mit Daten füttern und durchreichen oder gibt es schon spezialisierte Anbieter für den Anwendungsfall?

Exakt. Ein Kollege hat ein Plugin für Zammad gebaut. Basis sind die bisherigen Antworten und zusätzliches Futter aus FAQs.

Das Ganze funktioniert aber auch mit MS-Copilot (da stammt auch die Idee her). In der Developer-Network MSDN gibt es ein Sample-Source zum einfachen Anpassen und loslegen. Soweit ich mich erinnere ist ein Beispiel auch auf CodeProject verfügbar…

Ist also wirklich kein Hexenwerk und nimmt wirklich massiv Arbeit ab. 😊

Zitat von weltmeister

Herr Kayser, der Suppenkasper hat wieder lange weile.

Nö.

Aber, nachdem Du mit Supportanfragen zu kämpfen hast, hab ich einen Tipp für Dich. Setz einfach auf KI.

Du kannst schlicht und ergreifend nicht alles mit LiveConfig abdecken. Das ging schon nicht mit Confixx und Foxlor und geht nicht mit cPanel, DirektAdmin, LiveConfig oder Plesk/Onyx.

Im Moment handeln die Provider, für die wir die Server warten (und wir) sicher mehr als 95% der Supporttickets vollautomatisch mit der KI ab. Spart Arbeit und Nerven. Hebt die Supportqualität.

<sarkassmus>

Herzlichen Glückwunsch zu Ihrem neuen Server. Bitte versuchen Sie Ihren Hamster nicht im Server zu trocknen. Die Temperaturen der Prozessoren sind der Gesundheit nicht immer zuträglich</sarkassmus>

Wenn er die Daten in der Mail nicht liest, liest er auch die Hinweise im Web nicht.

Und bei uns sind es nur eine Handvoll (einstellig) Kunden, die mit dieser Mail nicht zurande kommen.

Zitat von weltmeister

Immer wieder kommt es vor, dass Kunden die "Füllstandsanzeige" z.B. der Postfächer falsch interpretieren. Ständig kommen Mails wie: "ich habe mein Postfach geleert, warum wird in LiveConfig angezeigt, dass es noch voll sei? Das kann doch nicht sein!"
Dass sich die Anzeige halbstündlich(?) aktualisiert, weiß leider niemand und ahnt sicher auch keiner. Vielleicht wäre ein Hinweis an der Stelle angebracht, dass der Füllstand der Postfächer und des Webspace nicht in Echtzeit ausgelesen wird und dass sich der Wert halbstündlich aktualisiert. Ebenfalls wäre eine Uhrzeit der letzten aktualisierung sinnvoll. Das erspart in Zukunft viele solcher Anfragen.

Was spricht dagegen, selbst den Text in /etc/liveconfig/mailquota.txt anzupassen? Dann bekommt der Kunde bei 80/90/95/100% einen sinnigen Text und verschont den Support?

Zitat von weltmeister

Das geht sicher mit einem Reseller ganz gut, aber bei mehreren? Ich denke eine Lösung über die Oberffläche ist lange überfällig. Ein Reseller hat keinen root-Zugriff, d.h. dieser könnte diesen Eintrag / Zusatz erst gar nicht erst setzen.

Das ist natürlich richtig. Aber, der Reseller kann auch keine PHP-Versionen installieren. IMHO ist es zentrale Aufgabe eines Admins, die veralteten Versionen zu ersetzen und die jeweils verwendbare aktuelle Version zur Standard-Version zu machen. Zumindest sehe ich das so....

Zitat von weltmeister

Schon mehrfach kamen diese Anfragen so oder so ähnlich... ich kann das ganze absolut nachvollziehen, auch mir würde es keinen Spaß machen, sämtliche PHP-Versionen für hunderte Kunden manuell ändern zu müssen. Klar geht es manuell über die Datenbank über den Support, aber eine Dauerlösung ist das nicht, ebenso ist das ganze nicht ganz ungefährlich, wenn mehrere Reseller auf einem Server sind. Der Support soll zudem entlastet und nicht belastet werden, indem der Kunde solche Kleinigkeiten selbst regeln kann.

Code

Ist es möglich, die PHP-Version für alle Kunden und alle Domains einheitlich
über die Verwaltung zu aktualisieren, so dass ich in den Kunden bzw. Domains
lediglich als PHP-Version "Standard" hinterlege und dann in den Allgemeinen
Einstellungen oder anderweitig diese Version mit einem Klick für sämtliche
Kunden und Domains auf die jeweils angepasst wird, ohne dass ich sämtliche
Kundenprofile und Domains für eine neue PHP-Version manuell aktualisieren
muss? Ich habe leider keine Einstellung gefunden, die PHP-Einstellungen und
PHP-Version global zu aktualisieren.

*Ohne Garantie*

Soweit ich gesehen habe, werden die Standard-Versionen mit dem Eintrag in der /etc/liveconfig/lua.d/php-default.lua umgesetzt:

LC.web.PHPDEFAULT = 'php83' setzt bei Kunden, die bisher den Standard (z.b. PHP 7.4) hatten einfach die PHP 8.3.x ein.

Nach der Änderung der Datei lcclient oder liveconfig restart hat bei uns den gewünschten Effekt gehabt.

Zitat von thopoh

Leider nein, immer noch das gleiche kein Login möglich! Liegt es an Debian 12? Ich weiß es nicht, bin echt Ratlos! Auf Debian 9 lief alles unproblematisch, aber weil ich drei Shopsysteme bei Kunden drauf habe und die Updaten sollte, ging das Theater los Debian 9 hatte php 7.3 drauf und die neue Shopsoftware wollte unbedingt min. PHP 8.0 oder höher. Da ich für Debian 9 keine Repositorys mehr bekommen habe und demzufolge auch keine Updates mehr, habe ich mich entschlossen auf das neuste Debian hochzustufen (Debian 12). Und seit dem habe ich jetzt Murks und keinen, der mir helfen kann!

Wenn Du möchtest, kann ich morgen früh auf Deine Kiste schauen. Gib einfach Bescheid…

Zitat von thopoh

Ja habe ich, ich vergleiche alles immer noch mit dem alten Server, dort ist nichts verändert, alles so wie es dort vorher lief!

Und die passwd ist identisch mit dem alten Server, aber da liegen nur die zusätzlichen FTP-Accounts drin, die ein Kunde angelegt hat! Also

in meinem Fall nur 4 Stück und nicht alle anderen die zum Account des Kunden mal erstellt worden sind. Ich kann auch in Liveconfig

reingehen und das Standard Passwort ändern, aber auch hier tut sich nichts es kommt auch keine Fehlermeldung, man kann sich nicht einloggen

in den FTP auch nicht mit dem geänderten Passwort.

beende einmal den proftpd auf beiden Kisten, sichere die Passwort-Datei und kopiere nochmals die (und nur diese) die Password-Datei vom alten Server drüber. Danach den Proftpd neu starten und nochmal testen…

Zitat von thopoh

Hallo Leute,

ich habe einen Server Umzug gemacht und alles wie beschrieben in Liveconfig vollzogen! Nun so wie es aussieht, geht inzwischen das meiste bis auf einige FTP Zugänge nicht mehr! Einige gehen und andere nicht " Kritischer Fehler bei der Verbindung etc." Unbekannter Benutzer -> abgewiesen!

Was mach ich falsch oder besser wie kommen die entsprechenden User wieder auf Ihren Webspace per FTP? Kann ich das irgendwo nachvollziehen wo die Usernamen und Passwörter abgelegt werden?

Sind bei Kopieren mit rsyc Daten verloren gegangen? Wo setze ich an? Kann Liveconfig das regeln und neu einlesen oder zurücksetzten?

Mfg. Thomas

Alles anzeigen

Du hast die Config neu schreiben lassen und verifiziert, dass die Passwort-Datei in /etc/proftpd/ liegt?

Zitat von antondollmaier

Sollte kein Problem sein: ISPConfig schafft's auch. Sieht dann so aus:

Code

require ["fileinto", "mailbox", "regex", "date", "relational", "vacation", "imap4flags", "envelope", "subaddress", "copy", "reject"];

Genau.

Wir haben das bisher über das extra Kundemenü gelöst. Wär toll, wenn wir das nicht mehr extra bräuchten

Zitat von weltmeister

Mehrfacher Kundenwunsch:

Wäre es möglich bei der Autoantwort nicht nur die automatische Deaktivierung zu einem bestimmten Datum zu aktivieren, sondern auch die Aktivierung automatisch mit einem bestimmten Datum zu automatisieren, also wie folgt:

automatische Antwort einschalten am ... ---> nicht vorhanden, neuer Funktionsvorschlag

automatische Antwort abschalten am ... ---> vorhanden

Gute Idee. Aber beides bitte mit Datum und Uhrzeit, dann hätte das richtig Stil .... (Einschalten am 23.2.2024 12:00, Ausschalten am 26.2.2024 8:00 Uhr)