Beiträge von weltmeister

Kann ich nicht bestätigen. Prüfe einmal den Eintrag "expose_php" unter dem Punkt "PHP-Einstellungen".

Bin auch dafür. (In Plesk gibt es diese Funktionen schon lange!)

... und genau diese Einstellungen kann doch jeder Kunde in seiner htaccess-Datei mauell setzen / überschreiben, d.h. er überschreibt die global-gesetzten Einstellungen durch seine eigenen. (Bei uns funktioniert das zumindest so ohne Probleme)

Allerdings wäre eine solche Funktion angebracht, bei Plesk kann man diese Header komfortabel über die Weboberfläche eintragen / ändern. Eine Sache, die es früher bei Confixx in ähnlicher Form schon gab.

Zitat von antondollmaier

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:

#
# This group is read by the client library
# Use it for options that affect all clients, but not the server
#


[client]
# Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4
# Example of client certificate usage
# ssl-cert=/etc/mysql/client-cert.pem
# ssl-key=/etc/mysql/client-key.pem
#
# Allow only TLS encrypted connections
# ssl-verify-server-cert=on
socket = /var/run/mysqld/mysqld.sock


# This group is *never* read by mysql client library, though this
# /etc/mysql/mariadb.cnf.d/client.cnf file is not read by Oracle MySQL
# client anyway.
# If you use the same .cnf file for MySQL and MariaDB,
# use it for MariaDB-only client options
[client-mariadb]

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:

$i++; //Login funktioniert nicht
$cfg['Servers'][$i]['verbose'] = 'server1.meinedomain.de';
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['hide_db'] = '(information_schema|mysql|performance_schema)';


$i++; //Login funktioniert
$cfg['Servers'][$i]['verbose'] = 'server2.meinedomain.de';
$cfg['Servers'][$i]['host'] = 'server2.meinedomain.de';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['extension'] = 'mysqli';
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['hide_db'] = '(information_schema|mysql|performance_schema)';


// LiveConfig Single Sign-On
$i++;
$cfg['Servers'][$i]['auth_type'] = 'signon';
$cfg['Servers'][$i]['host'] = '';
$cfg['Servers'][$i]['SignonSession'] = 'SignonSession';
$cfg['Servers'][$i]['SignonURL'] = 'lc-sso.php';

Viele Endbenutzer wünschen sich das, eine simple Backup- und Restorefunktion.

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

Zitat von antondollmaier

Übergangsweise:

https://pydio.com/

Eine Lösung wie bei Plesk, ohne zusätzlichen Login wäre komfortabler.

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

Zitat von kk

Haben Sie die neueste Version von "lc-sso.php" installiert? (6067b89 vom 18.10.)
Die o.g. Fehlermeldung tritt auf, wenn ein Ajax-Request vom Browser an LiveConfig nicht ausgeführt werden kann - in der aktuellsten Version sollte die Fehlermeldung eigentlich etwas aussagekräftiger sein.
Zudem: welchen Browser nutzen Sie? Läuft der Browser im "privaten Modus"?

Ansonsten schicken Sie uns bitte mal Test-Zugangsdaten (LiveConfig) an support@liveconfig.com, dann schauen wir uns das mal an.

Unter https://demo.liveconfig.com (admin/admin) haben wir eine Demo eingerichtet.

Viele Grüße

-Klaus Keppler

Alles anzeigen

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.

Zitat von Ringelnatz

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.

Hat es schon jemand hinbekommen? Bin genau nach dieser Anleitung vorgegangen und bin der Meinung nichts dabei vergessen zu haben: https://github.com/LiveConfig/…/blob/master/README.de.md
Alle Dienste wurden zudem neu gestartet, PMA_SIGNON_INDEX wurde angepasst.

Der Login scheitert mit der Meldung " The Ajax request to verify the token failed. (error)"

Hat jemand einen Tipp?

Zitat von kk

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!