Posts by suppenuser

    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.

    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

    Kannst Du mit Deinem Dovecot automatisch anlegen lassen:


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

    Gruß Ralf

    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. 😊

    Herr Kayser, der Suppenkasper hat wieder lange weile. :P

    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.

    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?

    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....

    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.

    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…

    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…

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

    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)

    Den "Fehler" (*) kannst Du durch installieren von "mariadb-client-compat" fixen.


    (*)

    Wir hatten den Fehler, der eigentlich keiner ist auch. Klaus hat mich dazu auch sehr deutlich darauf hingewiesen, dass er immer "nur" die Pakete der jeweiligen Distributionen testet (was ja auch Sinn macht). Die externen Sourcen wie das von Dir und uns genutzte Repo von MariaDB ändern sich so schnell, dass es wenig Sinn macht, diese mitzutesten.