Beiträge von Ringelnatz

    Vor einiger Zeit brauchte ich den ZendGuardLoader und habe die entsprechenden php.ini-Zeilen über LiveConfig hinterlegt. Vor einer Weile habe ich den Server auf eine Debian 9 Installation migriert und dabei den ZendGuardLoader nicht mehr mit installiert, seit der Migration gibt es also auch die entsprechende php.ini-Konfiguration nicht mehr. Durch die neue Debian-Version war nun PHP 7 installiert, PHP 5.6 habe ich über das LiveConfig Repo nachinstalliert.


    Seit diesem Update funktioniert auch unter diesen Bedingungen der PHP-Session-Cronjob (/usr/lib/liveconfig/cron.php.sh) wieder und ich erhalte nun alle halbe Stunde die Fehlermeldung, dass der ZendGuardLoader nicht gefunden werden kann. Die Konfiguration dafür wurde zwar entfernt, aber nur in den php.inis in webX/conf/php7 und php56. Das Cron-Script verwendet hingegen die Ordner php7 und php5; letzterer ist eigentlich veraltet und sollte von dem Cron-Script auch gar nicht berücksichtigt werden oder?

    phpMyAdmin Single Sign On ist klasse. Aber lässt sich der neu angelegte Server aus der PMA-Loginseite entfernen? Ich habe dazu keine Konfigurationsmöglichkeit gefunden. Und die Fehlermeldung unten auf der Startseite "Konfigurationsspeicher nicht eingerichtet" lässt sich wohl auch nicht entfernen?

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

    Eigentlich sollte es keine Änderung geben, da im Zweifelsfall das Original-Passwort einfach nochmal neu gehasht wird (was zum identischen Hash führen sollte).


    Hat evntl. ein Passwort-Manager reingespielt?


    Das Original-Passwort wird ja gar nicht übergeben beim Speichern und ist ja auch ungehashed nirgends gespeichert. Eigentlich sollte die passwd-Datei gar nicht angefasst werden.


    Mein Passwort-Manager fügt nichts ohne Tastenkombination ein. Das Feld war sicher nicht ausgefüllt.

    Korrektur: Jetzt kann ich mich mit meinem 40 Zeichen langem Passwort mit Sonderzeichen gar nicht mehr beim Postfach anmelden, selbst wenn ich das Passwort neu setze.


    EDIT: Habe mein ursprüngliches Passwort nun selbst gehashed und in der passwd-Datei aktualisiert. Wie kann es sein, dass ich dieses Passwort ursprünglich über LiveConfig gesetzt habe, dieses aber nun nicht mehr funktioniert?

    Die letzten Male, als ich für meine Mailadresse temporär Greylisting deaktivieren wollte, konnte ich nach Speichern der Änderungen in LC keine Mails für die entsprechende Adresse mehr abrufen. Es ist dann notwendig, das Passwort neu abzuspeichern. Im LiveConfig Log steht dazu "[LUA] Adding/updating user account xxx at dovecot config file: /etc/dovecot/passwd". Das Passwort-Feld wird natürlich freigelassen.


    Vielleicht lässt sich das ja irgendwie reproduzieren, ansonsten gebe ich gerne weitere Infos. Eingesetzt wird die aktuelle LiveConfig-Version auf Debian Stretch.

    Scheinbar ist es nicht möglich, http_canonical_host gleichzeitig mit http_proxy_url zu verwenden? Bei mir zumindest erzeugt das eine Endlosweiterleitung. Gibt es eine andere Möglichkeit, von der Standard-Adresse IP:8443 auf die Proxy-URL weiterzuleiten?

    Das ergibt natürlich sinn, und ja, jetzt wird alles ordentlich angezeigt. Ich habe auch mal eine Domain zu einem Vertrag hinzugefügt und ein paar Einstellungen verändert und die Konfiguration für den entsprechenden vHost wurde ordentlich aktualisiert. Seltsam, dass das Löschen eines Vertrags da vor einigen Tagen nicht funktioniert hat (und ich erinnere mich, dass ich schon vorher bei einer Reaktivierung einer Domain nachhelfen musste) ...

    Die Serververwaltung sieht so aus: http://imgur.com/a/ZNBYj
    Ich verstehe das nicht, die aktivierten Module wurden mal korrekt angezeigt, und PHP über FastCGI funktioniert ja auch.


    EDIT:
    Der entsprechende Auszug aus liveconfig --diag:

    Ich habe derzeit das Problem, dass die Apache-Konfiguration bei Änderungen über LiveConfig nicht verändert wird. Aktuelles Beispiel: Ein Kunde inkl. Vertrag wird gelöscht. Hierbei bleibt aber die webXX.conf aus dem sites-enabled Ordner erhalten:

    Zitat

    Warning: DocumentRoot [/var/www/web28/htdocs/] does not exist
    apache2: bad user name web28


    Das sind die zugehörigen Einträge aus dem LiveConfig-Log:


    System ist Debian 8, LC-Version war zu dem Zeitpunkt 2.4.0-4607. Wieso tritt das Problem auf (ist nicht das erste Mal) und wie kann ich die Apache-Configs nun aktualisieren?

    This was already discussed here and there was a clear statement that because of the lower price there are less resources for development and LE won't be included.


    Because LE is in my opinion a very important feature and not an unique feature of LiveConfig there is no use case for LC Basic for me anymore, but for the LC team it appears to be more profitable this way.