Beiträge von loswebos.de

    Hallo,


    was könnte den folgende Status Meldung in den Logfiles bedeuten?


    Code
    [2019/10/11 17:15:17.528823] [23967|25225] ACME2: error while finalizing for SSL_ID=1220 (**DOMAIN**) (AO_ID=979): Order's status ("invalid") is not acceptable for finalization

    Die haben übrigens nur geänderte Languagefiles in der aktualisierten 5.2.2 :confused:


    Hallo,


    der Wordpress Installer funktioniert aktuell nicht.


    Laut Log:


    Code
    [2019/08/22 22:14:56.589688] [17652|17653] wai-wordpress-5.2.2-2.php: ERROR in download sha1 check failed!


    Laut /var/cache/liveconfig/installer/wai-wordpress-5.2.2-2.php müsste der Vergleichswert "f39f23925e97ecbf776171ddec45ffbb1272bee1" entsprechen.

    Code
    $LCWAI_DOWNLOADS['de'] = array( // Downloads for 'de' (german) language
      'PACKAGE' => array('NAME' => 'wordpress-5.2.2-de_DE.tar.gz',
                         'SHA1' => 'f39f23925e97ecbf776171ddec45ffbb1272bee1',
                         'URL'  => 'https://de.wordpress.org/wordpress-5.2.2-de_DE.tar.gz'),
    );


    Der tatsächliche Download hat allerdings 98e2b328db96cce2b58c763054384cfdfd2236aa"


    Code
    wget https://de.wordpress.org/wordpress-5.2.2-de_DE.tar.gz
    sha1sum wordpress-5.2.2-de_DE.tar.gz
    98e2b328db96cce2b58c763054384cfdfd2236aa  wordpress-5.2.2-de_DE.tar.gz


    Ich hab den SHA1 Wert im File mal manuell auf "98e2b328db96cce2b58c763054384cfdfd2236aa" geändert, damit läuft die Installation durch. Sollte ggf. in der wai-wordpress-5.2.2-2.php angepasst werden.

    Richtig, Centos. Allerdings hats bei allen anderen CentOs basierten Systemen auch geklappt ;)


    Protokoll unter der URL

    Code
    /liveconfig/admin/liveconfig/log


    Auf dem Server sind keine "Kunden" eingerichtet, wird alles via "Mein Hosting" verwaltet. War früher mal eine Basic und wurde geupgraded zu Standard Lizenz.

    Hallo,


    nach / ggf auch vor dem Upgrade (auf 2.8) haben wir auf einem Kundenserver folgendes Problem.
    Beispielsweise wenn als admin auf das Protokoll zugegriffen werden soll.


    Code
    [2019/08/22 15:26:19.400051] [28156|28161] ERROR: Releasing db connection, but still have open statements
    [2019/08/22 15:26:19.400074] [28156|28161]        aborting SQL: 'SELECT CUST_ID FROM CUSTOMERS WHERE ( ( CUST_OWNER = ?1 ) AND ( CUST_ID = ?2 ) )'
    [2019/08/22 15:26:19.400090] [28156|28161] Database Exception: Database Error: Unexpected SQL parameter (2 parameters expected) (SQL: SELECT CUST_ID FROM CUSTOMERS WHERE ( ( CUST_OWNER = ?1 ) AND ( CUST_ID = ?2 ) ))


    DB Upgrade wurde wohl durchgeführt



    Allerdings wurde wohl auch beim Upgrade kein db.bak File angelegt. Upgrade wurde gestern durchgeführt.


    Code
    -rw-------   1 liveconfig liveconfig 4609024 Aug 22 15:34 liveconfig.db
    -rw-------   1 root       root       4414464 Mar  8 16:11 liveconfig.db.bak


    Irgendeine Idee?

    Für Multi Server Installation müsstest du die Korrekte PHPVERSIONID (auf dem Zielserver) raussuchen und dann dann das Update selektiv (je Webserver) ausführen.


    SQL
    UPDATE SUBDOMAINS SET SD_PHPVERSIONID = ##ID## WHERE SD_PHPVERSIONID IS NULL AND SD_WEBSERVERID = ##WSID##;
    SQL
    UPDATE
    SUBDOMAINS SET SD_PHPVERSIONID = (SELECT DISTINCT WR_ID FROM WEBRUNTIMES WHERE WR_CODE = 'php_56x') WHERE SD_PHPVERSIONID IS NULL;


    Würde eine explizite PHP Version für alle Domains setzen, welche die Standard-PHP Version (NULL) nutzen.
    (In Beispiel auf den ID Tag php_56x).


    Dann kann via

    Code
    LC.web.PHPDEFAULT="php_71x"

    die neue Standardversion gesetzt werden.


    Backup der /var/lib/liveconfig/liveconfig.db nicht vergessen. Vorher ;)

    Hallo Herr Keppler,


    unter CentOS müssen wir den Nginx als User 'apache' laufen lassen, da die Verzeichnisberechtigungen für die User von LiveConfig auf apache:apache gesetzt werden (CentOS Typisch halt).


    Funktioniert sauber, bis auf das PHP Problem, sofern man FPM nutzen möchte, dort wird ja www-data:www-data in die Pools geschrieben, was dann nicht funktioniert. Hier hatte ich auch bereits eine Thread eröffnet.


    Haben Sie hier auch eine Lösung parat?

    Wir setzen rspamd schon eine Weile ein, allerdings nicht auf den LiveConfig basierten Hosts.


    Zitat

    Dabei werden zunächst E-Mails von Rspamd geprüft. Allerdings beeinflusst das noch nicht das Ergebnis der Liveconfig Prüfung.


    Rspamd eingebunden als Milter rejected doch selbst, da werden keine Werte an Spamassassin gegeben.


    Den Rspamd Milter Eintrag würde ich auch an erste Stelle schreiben.
    Wenn rspamd schon zu dem Schluss kommt, die Mail zu rejecten erspart das alle anderen Checks.