Beiträge von weltmeister

    nicht "localhost" setzen, sondern "127.0.0.1". Dann geht die Kommunikation über TCP.


    Danke, das wurde testweise geändert. Leider kein Erfolg.


    Die Datei 50-client.cnf sieht so aus:



    Die Fehlermeldung lautet nach wie vor:


    Zitat

    #2002 - Connection refused — Der Server antwortet nicht (evtl. ist der Socket des lokalen MySQL-Servers nicht korrekt konfiguriert).


    Hat jemand eine Idee?

    Wenn die phpmyadmin-Installation auf dem gleichen Server ist (localhost) ist keine Verbindung möglich.


    Herr Keppler hat dazu folgende Info geschickt:


    Zitat

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864662
    Debian 9 ist installiert) in /etc/mysql/mariadb.conf.d/50-client.cnf fehlt folgende Zeile:


    socket = /var/run/mysqld/mysqld.sock


    Ohne diesen Eintrag können einige Anwendungen bei "localhost"-Verbindungen nicht den MySQL-Socket finden.


    Leider schafft dies keine Abhilfe. Von allen "externen" Servern ist der Zugriff jedoch möglich. Hat jemand eine andere Idee?


    Auszug aus der config.inc.php:


    Sendet man eine Mail per PHP-Mail an einen nicht-erreichbaren Empfänger, mit z.B. diesem Script oder einer anderen beliebigen Anwendung, landen diese Mails im Nirvana und der Absender wird nicht über die unzustellbarkeit informiert. Dies kommt sehr häufig vor, wenn z.B. WordPress-Kontaktformulare automatische Antworten versenden.


    PHP
    <?php 
    $from = "info@kundendomain.de";
    $to = "test@htstruzwirsi.de"; // hier wird bewusst eine nicht-erreichbare Mailadresse verwendet.
    $subject = "PHP Mail Test Script";
    $message = "Das ist ein Test";
    $headers = "From:" . $from;
    mail($to,$subject,$message, $headers);
    echo "Test email geschickt";
    ?>


    Als Return-Path ist im Header einer jeden Mail von Hause aus beispielsweise hinterlegt: <web35@s1.serverdomain.de>


    Damit der Kunde eine Info oder den Mailrückläufer erhält, würde ein Eintrag in der Datei /etc/aliases wie folgt aushelfen:


    web35: info@kundendomain.de ---> wobei hier die Adresse des Kunden verwendet werden sollte, die im LiveConfig für den Kunden hinterlegt ist.


    Nun macht es keinen sinn, diese Datei für hunderte Kunden manuell zu pflegen. Hier wäre es sinnvoll, wenn LiveConfig diese Aufgabe künftig übernehmen würde und diese Einträge gleich mit anlegt.


    Ich verweise wiederum auf Plesk, denn dort ist die Sache, genau wie bei Confixx, bereits so eingestellt:


    Zitat

    Default Return-Path for PHP mail script is taken as server administrator mail address.


    Plesk erlaubt es sogar für jeden Kunden, einen individuellen Return-Path festzulegen: https://support.plesk.com/hc/e…-Path-for-PHP-mail-script


    Eine Sache, die ich bei LiveConfig vermisse. Es würde jedoch schon reichen, wenn durch LiveConfig die Datei /etc/aliases gepflegt wird, indem dort für jeden Benutzer die im LiveConfig hinterlegte Mailadresse des Kunden hinterlegt wird. Somit wird der Kunde zumindest informiert, wenn eine Mail per PHP-Mail nicht zugestellt werden konnte, indem er den Rückläufer und den Grund der Nichzustellbarkeit erhält.

    Auch hier muss ich wieder auf Plesk verweisen: viele Kunden, die vorher Plesk genutzt haben, wünschen sich auch für LiveConfig einen solchen Dateibrowser.


    Ich selbst würde diese Funktion auch sehr begrüßen, mit der möglichkeit, Dateien zu verändern, löschen, bearbeiten, verschieben, komprimieren usw.

    Danke, das hat leider nicht funktioniert und in der Dokumentation findet man kein Wort dazu. Das sollte ggf. mal mit ergänzt werden. Besser wäre eine Möglichkeit, dies direkt in der Oberfläche komfortabel festlegen zu können.

    Gibt es die Möglichkeit, PHP 7.2. als Standard für neu angelegte Accounts zu verwenden? Das würde ein paar Klicks zusätzlich einsparen.

    Ich bin auch dafür, dass man das eigene Serverzertifikat wesentlich einfacher anlegen können sollte. Mit den Kundenaccounts klappt das ja recht gut, warum also nicht auch für das eigene Server-Zertifikat?


    Unser Kaufzertifikat läuft im kommenden Jahr ab, ich möchte der SSL-Mafia nur ungern wieder Geld für ein neues Wildcard-Zertifikat hinterherwerfen.

    Habe gestern mehrfach versucht, einen Umzug gemäß der Anleitung auszuführen, jedoch erfolglos.
    (Debian 8-Server ---> Debian 9-Server: Probleme bereits seit Beginn).
    (Debian 7-Server ---> Debian 8-Server: hat in mehreren Fällen funktioniert).


    Ein sog. "Export-Import-Script" oder irgend eine andere möglichkeit, Kunden schnell und problemlos umzuziehen wird wirklich dringend benötigt. Das erspart sehr viel Zeit und "Bastelarbeiten".

    Jetzt wo es das Single Sign-On für phpMyAdmin gibt, stellt sich doch die Frage: geht das nicht mit einer externen Roundcube-Installation auch? D.h. der Kunde klickt ein Postfach an und ist automatisch eingeloggt. (Wenn ich mich nicht irre, gibt es das bei Plesk oder einer ähnlichen Verwaltungsoberfläche bereits)

    Danke, ich habe das einmal wie o.g. umgesetzt. Nun ist folgende Meldung zu sehen:


    Zitat

    #2002 - Connection refused &mdash; Der Server antwortet nicht (evtl. ist der Socket des lokalen MySQL-Servers nicht korrekt konfiguriert).


    Ich habe eben eine Mail fertig gemacht, allerdings mit den config-Dateien, falls es etwas nützt oder sich in diesen gar noch ein Fehler befindet.


    Falls noch etwas benötigt wird, bitte einfach eine kurze Info per Mail.

    Von vielen Kunden gewünscht: eine sog. E-Mail-Whitelist. D.h. die Mail soll unbedingt zugestellt werden, ohne vorherige Spam-Prüfung, Filterung, Abweisung oder prüfung der Absender-IP auf Blacklist-Einträge. Wenn ich richtig informiert bin, gibt es diese Funktion bei Plesk bereits, viele Kunden wünschen sich das auch für LiveConfig, ich selbst würde diese Funktion ebenso sehr begrüßen.

    Wenn ich in den Einstellungen einer Datenbank das Häckchen aktiviere und das bisherige Passwort eintrage erhalte ich die Fehlermeldung "Um Single Sign-On zu aktivieren, müssen Sie das aktuelle Datenbankpasswort eingeben (oder ein neues Passwort festlegen)."


    Den Fehler kann ich so bestätigen.


    kk: die aktuelle "lc-sso.php" wurde verwendet.


    Browser: Firefox in der aktuellen Standard-Installation ohne weitere besondere Einstellungen.

    Am einfachsten ist es wirklich für HSTS den gewünschten Header per .htaccess senden zu lassen.
    Besteht denn Bedarf, das auch über GUI einzurichten?


    Ja, es gab schon mehrfach Nachfragen (Kunden sind nun mal bequem). Andere Hoster bieten das so schon lange per GUI an!

    Von unseren Kunden hagelt es nur Beschwerden wegen der eigentlich mieserablen Backup-Funktion. Mal geht es, mal nicht. (Debian 9, ZIP ist installiert)


    Es wird etwas ganz simples gewünscht, was es bei Confixx schon einmal gab. Sichern und wiederherstellen mit nur jeweils einem Klick. Nicht mehr und nicht weniger. Und wer das ganze auf der eigenen Festplatte speichern will, kann sich das Archiv per FTP herunterladen.


    Fallbeispiel: der Kunde hat eine Seite mit tausenden Dateien, fertigt eine Sicherung an, die auf der lokalen Festplatte nach ewigem Download bereitsteht, wenn es denn mal funktioniert. Geht etwas schief, muss der Kunde das ganze manuell wieder per FTP hochladen. Die Datenbank muss jedesmal manuell exportiert und importiert werden. Bei sehr großen Datenbanken mit mehreren Hundert MB ein Problem. Ein nicht unerheblicher Zeitaufwand. Und ja, es hat eben nicht jeder SSH-Kenntnisse, es sollte hier auch an die normalen Endkunden gedacht werden, die sich eine solche simple Funktion zur sicherung derer Daten und Datenbanken wünschen.


    Hier muss sich also schnellstens etwas ändern!