Beiträge von loswebos.de

    App Installer läuft, das Wordpress (in dem Beispiel) wird nahezu korrekt installiert.


    Allerdings wird das gewählte Datenbankpasswort nicht korrekt in die wp-config.php geschrieben.
    Dort steht nur


    Code
    define('DB_PASSWORD', '88▒^?▒^?');


    Trage ich dann dort, das korrekte Datenbankpasswort ein, funktioniert die Wordpress Installation einwandfrei.

    Selbes Problem hier. Laut Logfile:


    >[2017/10/29 14:33:00.543503] [1681|1683] Created database 'hst1060dwp' (user 'hst1060dwp')
    >[2017/10/29 14:33:00.545118] [1680|1688] Database exception: syntax error, unexpected TKPARAMETER >(SQL: UPDATE DBS SET DB_PASSWORD=NULL WHERE DB_ID:1)


    AppInstaller ist aktuell somit nicht nutzbar. Die Datenbank an sich wurde aber auf dem MySQL Server angelegt. geht halt nur nicht weiter.


    Ergänzung: Nach dem gestrigen Update der LiveConfig Version.

    Irgendwelche Infos bezüglich der App Updates (phpmyadmin lässt sich beispielsweise nicht installieren, ohne jegliche Fehlermeldung, die bei der Recherche der Ursache helfen könnte).


    Wie könnte man einzelnen nicht mehr funktionale Apps deaktivieren, sodass sie ein Kunde nicht mehr auswählen kann?

    Hallo,


    laut apache.lua sind die SSLProtocole hardgecodet.


    fh:write(" SSLProtocol ALL -SSLv2 -SSLv3\n")


    und landen somit in der 00_default_vhost.conf.


    Könnte man das konfigurierbar gestalten (custom.lua). Einige Kunden auf Managed Servern benötigen PCI 3.1 und darin sind die beiden TLS v1.0 und v1.1 nicht mehr erlaubt (oder nicht gern gesehen).

    Ist überall tatsächlich der gleiche Vertragsname. Ist auch nur Auszugsweise, Jede Domain hat in diesem File tatsächlich mehrere Einträge.


    Mit

    Code
    awk '{print $1}' /etc/httpd/accesslog.map | sort | uniq -c

    gibt ne Menge an Dubletten.
    http://www.loswebos.de ist dort 14 mal angegeben. Output oder das File selbst kann ich bei Bedarf gern zusenden.

    Ich muss mich mal dranhängen, da es scheinbar doch Probleme mit dem lclogsplit gibt.


    Aus reinen Debug Zwecken hatte ich ein Logfiles eines eigenen Entwickler-Accounts offen und habe dort Hits gesehen, welche dort definitiv _NICHT_ reingehören.


    /var/www/vertragX/logs/access.log


    Code
    192.162.85.58 - - [24/May/2017:10:49:51 +0200] "GET / HTTP/1.1" 301 297 "-" "Mozilla/5.0 (compatible; PRTG Network Monitor (www.paessler.com); Windows)" 223 486


    Da das unser Monitoring ist, welches auf die URL http://www.loswebos.de prüft, welche in einem anderen Vertrag liegt, hat das dort nicht zu suchen.


    Nach einem Restart des Apachen (und somit wohl auch lclogsplit) landen die Hits wieder im richten Logfile.


    Zumal mich auch wundert warum in der '/etc/httpd/accesslog.map' für jede Domains mehrere Einträge existieren.



    Zur Umgebung.


    CentOs 7 auf einem Slave (also nur mit lcclient in Version 2.3.1-r4556).


    Zitat

    Haben Sie irgendwelche .httpd.conf-Dateien (mit eigenen Apache-Einstellungen) angelegt, oder die zentralen CustomLog- oder LogFile-Kommandos modifiziert?


    Keine Veränderungen vorgenommen. Dh. die Vhosts werden ausschliesslich direkt aus LiveConfig konfiguriert.

    Http/2 unter CentOs7 geht übrigens auch relativ einfach mit entweder selbst kompiliertem Apache oder einem externem Repo, (z.B. codeit.guru). Ist eher weniger die Aufgabe eines Panels, von notwendigen Config Direktiven mal abgesehen. Beim Apachen kann es auch global via "Protocols h2 h2c http/1.1" aktiviert werden. Dh. komplett abseits vom LiveConfig.

    Teste einfach mal Statt PCI-Konform -> Kompatibel. Ich glaub die Labels sind entweder in der GUI vertausch oder die Cipherllediglich vertauscht.


    ssllabs


    Mit Kompatibel -> A+
    Mit Auswahl PCI Konform C

    Hallo,


    Zitat

    wird nginx nur "mehr oder minder" von Liveconfig unterstützt


    Aktuell eher minder. In der Nginx Konfiguration werden keine AccessLogs für den Kunden geschrieben. Somit können auch keine Awstats erzeugt werden. An welcher Stelle das auf der LiveConfig Todo Liste steht, kann ich natürlich nicht einschätzen.


    Wenn man damit leben kann, läuft es ansonsten aber problemlos. PHP Versionswahl unter Nginx funktioniert. Kunden Spezifische Nginx Directiven (Rewrites etc) kann man unter conf/nginx.conf im Kundenverzeichnis ablegen. Das File wird, falls vorhanden, in den Nginx Vhost included.