Beiträge von kk

  • SSL-Fehler bei ACME-Verlängerung

    Zitat von Ultrashadow

    Auch das ist getestet und hier sind die Ergebnisse

    Code
    [user@host ~]# sudo su -s /bin/bash liveconfig
bash-4.2$ pwd
/var/lib/liveconfig
bash-4.2$ openssl s_client -connect acme-v01.api.letsencrypt.org:443
Verify return code: 0 (ok)


    Bei dem o.g. SSL-Befehl muss es erheblich mehr Output geben als nur "Verify return code: 0". Bitte schicken Sie uns mal die gesamte Ausgabe dazu, dazu noch die Ausgabe von "openssl version".


    Zitat

    Tatsächlich hat LiveConfig in einigen Ordnern keine Execution-Rechte, im Home unter /var/lib/liveconfig sowie unter /srv/www/liveconfig aber schon. Für mich lässt sich hieraus kein Problem erschließen.


    Was meinen Sie mit "in einigen Ordnern"? Haben Sie einige Berechtigungen eingeschränkt?
    Es kann z.B. durchaus ein Problem sein, wenn LiveConfig keinen Zugriff auf die CA-Zertifikate des Systems hat.


    Zitat

    Könnte das Problem etwas mit PHP zutun haben? Neben Updates gab es unter anderem ein Versionsprung von 5.4 auf 7.1 (5.4 komplett entfernt)


    Was für ein Update war das denn? CentOS 7 bringt nur PHP 5.4 mit.
    LiveConfig (und insbes. der integrierte ACME-Client) laufen unabhängig von PHP.

  • SSL-Fehler bei ACME-Verlängerung

    Wir haben hier auf CentOS7 (und auch auf allen anderen Distributionen) nicht das geringste Problem mit Let's Encrypt.
    Die Meldung "SSL Handshake Failed" deutet darauf hin, dass zwar die TCP-Verbindung selbst zum Let's-Encrypt-Server aufgebaut werden kann, danach aber ein Fehler beim SSL-Handshake auftritt.


    Führen Sie den o.g. "openssl"-Befehl bitte noch mal als Benutzer "liveconfig" aus (also erst mit "su -s /bin/bash liveconfig" den Benutzer wechseln).

  • cron.php.sh verwendet alte php.ini

    Wie wäre es, wenn LiveConfig ein Umschalten der CLI-PHP-Version per GUI ermöglicht?
    Dazu würden wir dann /usr/bin/php durch ein (äußerst schlankes) Wrapper-Programm ersetzen, welches dann an den für den jeweiligen Vertrag/Benutzer ausgewählten Interpreter übergibt. :D


    Eine andere (sauberere) Lösung sehe ich gerade nicht.

  • Nginx mit Wordpress und Typo3

    Ja, das ist recht einfach.
    Legen Sie eine Datei namens /var/www/<Vertrag>/conf/nginx.conf an und tragen Sie da die gewünschten NGINX-Anweisungen ein.
    Anschließend speichern Sie im LiveConfig irgendeine Vertrags- oder Domaineinstellung neu ab (dadurch schreibt LiveConfig die /etc/nginx/sites-enabled/<Vertrag>.conf-Datei neu und holt per include die o.g. nginx.conf mit hinein).


    Viele Grüße


    -Klaus Keppler

  • SSL-Fehler bei ACME-Verlängerung

    Ich vermute, dass es (aus welchem Grund auch immer) Verbindungprobleme zum CA-Server von Let's Encrypt gibt.
    Wenn Sie "openssl" auf dem Server installiert haben, führen Sie bitte mal testweise folgenden Befehl aus:


    Code
    openssl s_client -connect acme-v01.api.letsencrypt.org:443


    Kann damit eine TLS-Verbindung aufgebaut werden, oder gibt es eine Fehlermeldung?

  • cron.php.sh verwendet alte php.ini

    Es geht hier ja letztendlich nur um das Session-Cleanup-Script /usr/lib/liveconfig/cron.php.sh
    Wir gehen dabei davon aus, dass auf dem Server das Paket "php-cli" installiert ist, welches die Datei /usr/bin/php bereitstellt.
    Ab Ubuntu 16 und Debian 9 ist "php-cli" ein virtuelles Paket, das auf "php7.0-cli" verweist.
    Das cron.php.sh ist eigentlich darauf ausgelegt, mit dem jeweiligen "System"-PHP-CLI ausgeführt zu werden. Wenn das System-Paket (php7.0-cli) nicht installiert ist, dann erzeugt LiveConfig auch keinen "/conf/php7"-Pfad, was dann zu Fehlern mangels richtiger php.ini führt.


    Wer also manuell die /usr/bin/php umbiegt, wird zwangsläufig auch das cron.php.sh-Script anpassen oder ersetzen müssen.


    "Unsere" PHP-Pakete werden übrigens demnächst überarbeitet, so dass diese sich "alleine" bei LiveConfig registrieren (ohne addPHP()-Aufruf in der custom.lua). Da werden dann auch die CLI-Binaries registriert, und die können dann auch vom cron.php.sh-Script verwendet werden.

  • Slave DNS?

    Zitat von bash

    Dazu müsste ich dann per URL den Benutzernamen und Passwort mit angeben können was aber eben leider noch nicht funktioniert.. ;)


    Beim Dynamic-DNS Update-Aufruf an LiveConfig?
    Da wird Benutzername und Passwort (wie bei DynDNS "üblich") per HTTP Basic Auth übermittelt.
    Optional können wir gerne alternativ einen URL-Parameter dafür einrichten.

  • Slave DNS?

    Zitat von bash

    für mich ist eher der Dienst mit Dyndns noch nicht gescheit gelöst.


    Was genau?
    IPv4 und IPv6 Updates funktionieren über die dokumentierte Update-Methode (soweit wir das beurteilen können) einwandfrei. Vielen Kunden nutzen das, und auch wir selber - und zwar ohne Probleme.
    DynDNS mit IPv6 ist insgesamt etwas "tricky", das liegt aber weniger am DynDNS als viel mehr an den Eigenschaften von IPv6 (dass sich also alle Geräteadressen im LAN ändern wenn sich der IPv6-Präfix z.B. nach DSL-Zwangstrennung ändert).

  • DRINGEND: Von exclusiv zurück nach gemeinsame IP Addresse?

    So lange eine IP-Gruppe "exklusiv" in Verwendung ist, kann diese nicht auf "gemeinsam" zurück geändert werden.
    Unter "Serververwaltung" -> "Web" gibt es in der Box mit den IP-Gruppen eine Spalte "Domains". Dort sieht man, wie viele Domains diese IP-Gruppe derzeit noch nutzen.


    In Einzelfällen kann man das über einen Eingriff in die LiveConfig-Datenbank erzwingen.
    (Sie bekommen gleich noch eine separate Antwort auf Ihr Ticket bei uns)

  • Upgrade von Debian 8 (jessy) auf Debian 9 (stretch), Problem access.log

    Sorry, ich hatte den letzten Absatz von Ihnen nicht gelesen...


    Ich kann mir nicht erklären, warum die liveconfig[.conf] plötzlich fehlen könnte - LiveConfig löscht diese schließlich nicht. Wurde Apache vielleicht mal "gepurged"?


    Ansonsten legen Sie die conf-available/liveconfig.conf manuell an:


    ... und aktivieren diese dann mit "a2enconf liveconfig".