Beiträge von loswebos.de

    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.

    Hallo,


    die von LiveConfig generieret Poolkonfiguration ist unter CentOS nicht lauffähig,
    da als "listen.owner" & "listen.group" jeweils "www-data" angegeben ist.


    Bei CentOS / Redhat müsste es 'apache' lauten.
    In der web.lua sind beide Angaben auch hardgecodet.


    fh:write("listen.owner = www-data\n")
    fh:write("listen.group = www-data\n")



    Und nebenbei, wird es zukünftig auch die Möglichkeit geben "pm.max_children = 8" als Configvariable oder idealerweise in den Angeboten zu definieren.


    VG,
    Torsten

    Selbes Problem hier, Backup ist nach dem Anstossen eines Backups abgeschmiert.
    Da der Kunde den Zeitpunkt des Backupstarts relativ exakt benennen konnte, einzige Fehlermeldung laut Logfile. Danach war LiveConfig nicht mehr erreichbar.


    [2018/10/27 12:20:17.546545] [4918|4918] SSL write error (OS): Bad address
    [2018/10/27 12:20:27.382389] [4918|4918] SSL write error (OS): Bad address


    Die Backupfunktion ist schlichtweg unbrauchbar. In einem Multiserversetup steht sie ja auch nur auf dem Master zur Verfügung. Wann könnte man den hier überhaupt mit einer Lösung rechnen?


    Ich zitiere mal [kk] vom 28.09.2017 (aus Thread https://www.liveconfig.com/de/…hl/page2?highlight=backup)


    Zitat

    Wir sind bereits mitten in der Umsetzung. Backups können künftig wahlweise auf dem Server verbleiben (mit Begrenzung der Anzahl der Backups) oder heruntergeladen werden.
    Wir geben die Funktion schrittweise nach Fertigstellung frei (zuerst Webspace, dann Datenbanken, zuletzt E-Mails).


    Im Changelog (https://www.liveconfig.com/de/changelog) findet sich bisher noch nichts.

    Kann über custom.lua erledigt werden.
    Funktion LC.web.addAccount und dann mittels


    Code
    LC.fs.mkdir(home .. "/.ssh")
    LC.fs.setperm(home .. "/.ssh/", 700, name, name)
    LC.fs.mkdir(home .. "/.composer")
    LC.fs.setperm(home .. "/.composer/", 700, name, name)


    usw. Gilt dann halt nur für neu angelegte Accounts.