Beiträge von suppenuser

    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.

    Kann der Endkunde damit sichern? Webspace, Datenbanken? Gibt es eine Wiederherstellungsmöglichkeit? Oder habe ich was übersehen?

    Ja. Du gibst dem Anwender (in Verträgen) die Möglichkeit, seine Daten zu sichern und auch wiederherzustellen. Du kannst festlegen, ob nur automatisch oder auch manuell.



    *ALLERDINGS* es klappt nicht zuverlässig, dass der Kunde tatsächlich nur z.B. 4 Backups machen darf. Da ist noch der Wurm drin. Und es ist ein buntes Mischmasch aus Deutsch und englisch.


    Und ganz wichtig für Server mit Spielekinder. Mindestwartezeit sollte immer länger sein als die Kiste braucht, um das Backup zu machen. Ansonsten hast Du eine Que mit Backupjobs ohne Ende :(







    Leider gehört zu einer guten Software auch ein guter Support, welche leider nicht mehr gegeben ist, es werde Updates angekündigt, Termine nicht mehr eingehalten, und der Endnutzer (Webhoster) steht da, und muss sich rechtfertigen wenn was nicht geht oder Funktionen fehlen die der Kunde vorher hatte.

    Den Frust verstehe ich. Ja. Sinnvoll wäre an dieser Stelle tatsächlich, wenn man die gegebenen Termine bei Nichterreichen auch anpasst.

    Das Informationskonzept von Klaus ist diskussionswürdig. Ich weiß, dass derzeit ein Fehler die Veröffentlichung einer neuen Beta verhindert. Nervig ist, dass das nicht offen kommuniziert wird.


    Allerdings weißt Du genauso wie ich das wir nur zum Telefon greifen müssen, um eine Lösung unserer Probleme zu bekommen. Insoweit ist der Support durchaus gegeben...


    Ich persönlich hoffe ja stark auf die 3er-Version. Da ist mit der API deutlich mehr umzusetzen UND bei Klaus sind dann hoffentlich auch wieder Kapazitäten frei. Die Neuentwicklung bindet ja doch zusätzlich zu den 2.x-Problemen...

    Die Backup Lösung für Single Server funktioniert, aber nicht für Multi-Server Installationen!

    Wir haben die meines Wissens nach (mit Ausnahme des letzten Fixes, durch den es ein Datenbank-Problem gibt) nur in der Multiserver-Umgebung laufen und zumindest die Server in Montreal sichern unter /var/backups/liveconfig/.

    -rw------- 1 u***** root 2.0G Oct 5 2023 ************************.zip

    -rw------- 1 u***** root 2.4G Oct 6 2023 ************************.zip

    -rw------- 1 u***** root 2.4G Oct 7 2023 ************************.zip

    -rw------- 1 u***** root 2.4G Oct 8 2023 ************************.zip

    -rw------- 1 u***** root 2.4G Oct 9 2023 ************************.zip

    -rw------- 1 u***** root 2.4G Oct 10 2023 ************************.zip


    Wir sind nicht wirklich glücklich damit weil es die Anzahl der Backups nicht überprüft und etwas Speicherhungrig ist, ja, aber es tut anscheinend soweit.

    Ich schaue hier alle paar Monate mal wieder rein und sehe immer dasselbe. Von der LiveConfig GmbH kommt einfach - nichts. Vor einigen Monaten hat man hier lieblos ein neues Forum hin geklatscht, mehr ist nicht passiert.

    <sarkasmus>

    Sehr sinnvoller Beitrag.

    Wenn Du schon glücklich zu Plesk gewechselt bist, welches unstillbare Mitteilungsbedürfnis drängt Dich dazu, Dein Warmluftgebläse hier anzuwerfen?

    </sarkasmus>

    Seit nun fast 10 Jahren warten wir z.B. auf eine funktionierende Backup-Lösung - die es damals im alten Confixx schon gab. Seit 10 Jahren vertrösten wir unsere Kunden, die immer und immer wieder jährlich nach solchen u.ä. Funktionen anfragen. Man schlägt hier Funktionen im Forum vor, aber kaum etwas wird umgesetzt, was in anderen Panels schon lange möglich ist. LiveConfig ist gut - aber noch lange nicht vollständig im Funktionsumfang.

    Welche religiösen Gründe hindern Dich an der Verwendung von


    /usr/lib/liveconfig/lcbackup




    hmmm. Wie hast Du denn MariaDB installiert? Bei uns taucht der Fehler wie bei Dir nicht auf?


    ---------------------------------------------------------------------------------------------------------------------------------------

    liveconfig --diag


    Running OS diagnostics... (LiveConfig 2.16.1-dev20230711.1)

    FILE SYSTEMS:


    .....

    IPMI:

    ERROR: IPMI not supported in this build

    QUOTA for group 'root' at path /var/www: ERROR - No such process

    Running Lua diagnostics...

    Segmentation fault

    -----

    Checking for database server software:

    - Found 'mysql' database server

    Version: '10.11.3'

    Package version: '1:10.11.3-1'

    ---------------------------------------------------------------------------------------------------------------------------------------


    mariadb --version

    mariadb Ver 15.1 Distrib 10.11.3-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper



    Gruß Ralf