Beiträge von kk

  • AWStats Leer

    Naja, die erste Frage wäre dann natürlich, ob denn Statistikdateien existieren (/var/www/<Vertrag>/logs/access.log)


    Wenn nicht: existiert die Datei /etc/apache2/conf-enabled/liveconfig.conf? (Symlink auf /etc/apache2/conf-available/liveconfig.conf)

  • PHP aktivieren, aber wie

    - entfernen Sie am besten das Paket "libapache2-mod-php7.0" wieder
    - installieren Sie das Paket "php7.0-cgi"
    - starten Sie LiveConfig neu (damit die geänderte PHP-Installation erkannt wird)
    - wenn Sie Hosting-Angebote angelegt haben, bearbeiten Sie diese und stellen dort PHP auf "FastCGI" um
    - angelegte Verträge müssen ggf. auch bearbeitet und dort PHP auf FastCGI umgestellt werden.

  • PHP aktivieren, aber wie

    Sie machen nichts falsch.
    In dem Screenshot wird gezeigt, welche Apache-Module aktiviert sind. In dem Fall ist eben kein mod_php aktiviert (was soweit auch gut und richtig ist).


    Mit der nächsten LiveConfig-Version (v2.6) wurde diese Anzeige etwas umgestaltet, um Verwirrung zu vermeiden. :)

  • Anwendungen aktualisieren.

    Zitat von bfal

    denn im Grunde sind alle veraltet.


    WordPress, Joomla und RoundCube sind alle auf dem aktuellen Stand (das betrifft also >90% aller Installationen). Für Drupal gibt's voraussichtlich heute ein Update (da gibt es erst seit einigen Tagen eine neue Version).
    Für die ganze "neue Generation" vieler Apps wird oftmals PHP7 benötigt, was auf Distributionen wie Debian 7/8, Ubuntu 14 und CentOS nicht zur Verfügung steht. Wir ändern in dem Zusammenhang derzeit die Verwaltung von PHP-Interpretern, so dass der AppInstaller "weiß" welche zusätzlichen PHP-Versionen bereitstehen und entsprechend inkompatible Anwendungen dann ausblenden kann.

  • ClamAV verhindert Mailversand (4.7.1 Service unavailable)

    "Service unavailable" bedeutet in dem Zusammenhang meistens, dass der Prozess "clamd" (bzw. "clamav-daemon") nicht läuft.
    Warum der nicht mehr läuft (bzw. seinen Dienst eingestellt hat) lässt sich eventuell über die einschlägigen Log-Dateien herausfinden.


    Kürzlich gab es einen kritischen Bug im ClamAV-Daemon, über den man mit einer einzigen (präparierten) E-Mail den ClamAV abstürzen lassen konnte. Inzwischen stehen aktualisierte Debian-/Ubuntu-Pakete dafür bereit, die aber i.d.R. nur über das "updates"-Repository installiert werden (nicht über "security").


    Viele Grüße


    -Klaus Keppler

  • Eu-dsgvo

    Zitat von kroerig

    wie weit ist LC auf die neue DSVGO vorbereitet?


    Bis auf das Löschen von unbenutzten Handles (aktuell in Arbeit) sehen wir derzeit keine Konformitätsprobleme seitens der Software. Wir werden in den nächsten zwei Monaten aber noch eine Herstellererklärung vorbereiten, die genau darlegt, welche Daten wo gespeichert und welche Daten an uns übermittelt werden.
    (vorab schonmal: da LiveConfig absolut keine Daten außer der Lizenznummer an uns sendet, ist das äußerst unproblematisch. Bei anderen Panels ist die Situation nicht ganz so einfach ;-))


    Zitat

    Was mir da so spontan einfällt, wären die Loggingeinstellungen der einzelnen über LC konfigurierten Dienste (Webserver, Mailserver).


    Die Konfigurationsmöglichkeiten werden wir im Handbuch ggf. näher beschreiben.


    Zitat

    Wie kann ich z.B. in LC einstellen dass Postfix, Dovecot und Apache keine vollständigen IP-Adressen/ E-Mail-Adressen mehr loggen? Und das (auch) benutzerbezogen?


    Was Apache betrifft, können Sie das aktuell schon pro Angebot oder Vertrag einstellen (Tab "Log-Dateien", Einstellung "Log-Anonymisierung"). NGINX-Logs werden ab v2.6 auch durch LiveConfig geschrieben (und ggf. mit Apache-Logs zusammengeführt), da gilt dann das selbe.
    Postfix/Dovecot protokolliert ja nur Aktionen "eigener" Kunden, eine Anonymisierung ist da wenig zielführend und widerspricht dann z.T. anderen gesetzlichen Anforderungen (TKG, TKÜV).


    Die größte Herausforderung bei der Umsetzung der DSGVO sind eher die Prozesse im Unternehmen. Viele Fachzeitschriften bringen da aktuell Schwerpunktthemen, welche einen guten Überblick verschaffen.
    Ansonsten empfehlen wir, sich gezielt beraten zu lassen (z.B. bei PSW und/oder einem entsprechenden Fachanwalt).


    Viele Grüße


    -Klaus Keppler

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