Beiträge von suppenuser

    Hast du nicht? Naja, unter https://www.liveconfig.com/de/ befindet sich der Link zum Forum im Menüpunkt "Support", wenn ich mich nicht irre. Was darf ich dann hier erwarten? Dass hier nicht nur User versuchen Usern zu helfen, sondern sich die Herrschaften der LiveConfig GmbH vielleicht auch mal regelmäßig zu Wort melden und mit regelmäßig meine ich nicht alle paar Monate in der Kategorie "Ankündigungen und neue Versionen".


    Und was den Support per E-Mail angeht: Ticket LC#2022090234000027 vom 02.09.2022 (ja, wir lesen richtig) ist seit 2 JAHREN trotz Nachfrage absolut unbeantwortet. Bei aller Liebe: wenn ich so mit meinen Kunden umgehen würde, dann könnte ich den Laden zumachen. Ich kann absolut NICHT verstehen, dass man soviel Energie in eine Veriosn 3.x legt, obwohl in der aktuellen Stable hier seit vielen Jahren unbearbeitete Baustellen sind. Das alles wirft kein gutes Licht mehr auf Herrn Keppler und sein Team. Eigentlich warte ich nur noch darauf, dass es irgendwann eine Pressemitteilung gibt: "LiveConfig verkauft" oder "LiveConfig wird eingestellt, bitte wechseln Sie zu XY", denn das wäre wirklich extrem schade.


    Man verstehe micht bitte nicht falsch: ich bin ein großer Fan von LiveConfig, aber auch ein inzwischen sehr frustrierter Fan.

    In der Tat. Wenn ich dort auf Support klicke, komme ich auf https://www.liveconfig.com/de/support/ und NICHT auf https://forum.liveconfig.com


    Aus meiner Sicht ist das Ding hier neben den Ankündigungen rein "User helfen User"- basiert (was auch zur Wesensart von Klaus passen würde).


    Nervig (und da gebe ich Dir recht) ist in der Tat, das manche Tickets untergehen. Bei sowas frage ich dann in Gottes Namen einfach telefonisch nach und hab meinen Selenfrieden.

    Die Tatsache, dass die 3er noch nicht raus ist ist auch nervig. Auf unserem Testserver läuft die letzte veröffentlichte sehr stabil, aus meiner Sicht wär es da durchaus Zeit für einen größeren Beta-Test.

    Seit über einem Jahr leider unbeantwortet. Gibt es hier noch Support oder sind alle schon in den Weihnachtsferien? ;)

    soweit ich weiß ist der Support über support@liveconfig.com erreichbar? Oder per Telefon...? (Zumindest bei uns klappt das tadellos) Ein Hinweis, das dies ein Support-Forum ist hab ich noch nicht wirklich gesehen....


    Und um beim Thema zu bleiben, die Quota automatisiert einzurichten ist nicht trivial. Alleine bei unseren Serverkunden hat es da (laut puppy) mehr als 15 verschiedene Konfigurationen (abgesehen von 9 zusätzlich möglichen Formatmöglichkeiten).

    Da kann ich verstehen, dass Klaus mehr Energie in die 3.x legt.

    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.

    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.

    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?