Beiträge von kroerig

    das ist dann noch eine Leiche.
    dann werde ich die wohl mal verschwinden lassen müssen.


    Ich hatte mal eine 7.1 von dort installiert, bevor ich die OPT-Pakete kannte.


    Jetzt muss ich nur mal schauen, wie ich noch weitere Leichen finde...

    Code
    root@liveconfig01 ~ # ldd /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so
            linux-vdso.so.1 =>  (0x00007fffd2deb000)
            libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ea8970000)
            /lib64/ld-linux-x86-64.so.2 (0x00007f7ea8fae000)
    root@liveconfig01 ~ # ldd /opt/php-7.2/bin/php | grep pcre
            libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fcf61409000)
    root@liveconfig01 ~ # dpkg -l | grep pcre
    ii  libpcre3:amd64                      2:8.41-1.2+ubuntu16.04.1+deb.sury.org+1 amd64        Perl 5 Compatible Regular Expression Library - runtime files

    Vor dem Auskommentieren:

    Code
    PHP 7.2.11 (cli) (built: Oct 15 2018 08:02:30) ( NTS )
    Copyright (c) 1997-2018 The PHP Group
    Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
        with Zend OPcache v7.2.11, Copyright (c) 1999-2018, by Zend Technologies


    Nach dem Auskommentieren:


    Code
    PHP 7.2.11 (cli) (built: Oct 15 2018 08:02:30) ( NTS )
    Copyright (c) 1997-2018 The PHP Group
    Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies


    Und ohne läuft auch der Contao-Manager wieder.


    Das Problem habe ich bei allen 3 über die Opt-Pakete installierten PHP-Versionen.


    Distri ist: Ubuntu 16.04.5 LTS

    Hallo Keppler,


    ja, dann erhalte ich folgende Meldung im Log:


    Code
    [25-Oct-2018 17:39:43 Europe/Berlin] PHP Fatal error: Phar::webPhar(): Failed opening required 'phar:///var/www/web0/html/www.bergischer24stundenlauf.de/contao4/web/contao-manager.phar.php/web/api.php' (include_path='.:/opt/php-7.2/lib/php') in /var/www/web0/html/www.bergischer24stundenlauf.de/contao4/web/contao-manager.phar.php on line 99


    Auslöser war diese Meldung:

    Code
    ERROR 500 The Contao version could not be determined
    The console returned unexpected content when asked for the Contao version. Please check the output for more information: PHP Warning: Failed loading Zend extension 'opcache.so' (tried: /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so: undefined symbol: pcre_free), /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0 4.4.17


    Daraufhin habe ich 'apt upgrade' gemacht, das hat mir die neuen PHP-Paket gebracht und danach lief dann nichts mehr.

    Hallo zusammen,


    seit dem letzten Update der Opt-PHP-Pakete lässt sich der Contao-Manager nicht mehr starten. Egal welche PHP-Version ich auch auswähle, die Phar-Datei bleibt hängen.


    Es gibt leider auch keine Fehlermeldung.


    Wie komme ich an die letzte Version der deb-Pakete?


    Klaus Rörig

    Hallo,


    apt meldet mir neuerdings:


    Code
    N: Skipping acquire of configured file 'php/binary-i386/Packages' as repository 'http://repo.liveconfig.com/debian xenial InRelease' doesn't support architecture 'i386'


    Ich wüste nicht, das ich eine x86-Version von PHP installiert hätte.


    Stimmt was im Repository nicht?


    Klaus Rörig

    Update:


    PHP 7.1 bin ich jetzt losgeworden, indem ich wieder die virtuellen PHP-Packete (php7.0) hinzugefügt habe.


    Aber eigentlich will ich die auch nicht haben...


    Wenn ich z.B. versuche PHP7.1-CGI zu deinstallieren:



    PHP 7.1 habe ich wohl mal installiert, als ich die Opt-Pakete noch nicht kannte. Aber jetzt werde ich die Distri-eigenen Pakete nicht wieder los.


    Eigentlich möchte nämlich nur mit den Opt-Pakten arbeiten.

    Hallo,


    ich kämpfe hier gerade etwas mit den PHP-Versionen:


    liveconfig --diag meldet


    Code
    Running Lua diagnostics...
    PHP Warning:  Failed loading Zend extension 'opcache.so' (tried: /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so: undefined symbol: pcre_free), /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
    PHP Warning:  Failed loading Zend extension 'opcache.so' (tried: /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so: undefined symbol: pcre_free), /opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so (/opt/php-7.2/lib/extensions/no-debug-non-zts-20170718/opcache.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0


    Das ist das PHP-Paket von http://repo.liveconfig.com


    Erkannt werden

    Code
    - PHP 7.0.31 (code='php70', bin='/opt/php-7.0/bin/php-cgi', SAPI=CGI/FastCGI)
       default php.ini: '/opt/php-7.0/etc/php.ini'
     - PHP 7.1.20 (code='php71', bin='/opt/php-7.1/bin/php-cgi', SAPI=CGI/FastCGI)
       default php.ini: '/opt/php-7.1/etc/php.ini'
     - PHP 7.2.8 (code='php72', bin='/opt/php-7.2/bin/php-cgi', SAPI=CGI/FastCGI)
       default php.ini: '/opt/php-7.2/etc/php.ini'
     - PHP 7.1.13 [DEFAULT] (code='php7', bin='/usr/bin/php-cgi', SAPI=CGI/FastCGI)
       default php.ini: '/etc/php/7.1/cgi/php.ini'


    Die 7.1.13 kommt von Ubuntu, kann ich die irgendwie loswerden? Apt meldet Abhängigkeiten von Liveconfig-meta für PHP 7.0 und PHP 7.1


    Danke.

    Hatte ich so nicht verstanden.


    So groß sehe ich die Anpassungen gar nicht. Wenn externe Weiterleitungen für den Kunden/ Vertrag/ gobal verboten sind, dann sieht der Kunde statt eines Textfeldes ein Dropdown mit seinen Domains und kann nur den Localpart eintragen.

    Also, folgendes hat funktioniert:


    Im Vertrag den Status auf "Deaktiviert" setzen und nur E-Mail auswählen. Ergebnis: Homepage kann noch aufgerufen werden, aber E-Mail ist blockiert.


    Welches Druckmittel soll denn die Sperre des LC-Zugangs für den Kunden sein? Solange er noch alles andere nutzen kann, hat er doch keinen Nachteil.


    Meine Kunden gucken i.d.R. genau einmal in LC-Panel, nämlich dann, wenn sie die E-Mailkonten erstmalig anlegen.

    Catchall könnten wir über eine LCDEFAULTS-Einstellung global abschaltbar machen (ist ein überschaubarer Aufwand).


    Schöner wäre natürlich auf Vertragsebene. Für manche Anwendungen braucht man es leider doch hin und wieder.



    Was die externen Weiterleitungen betrifft: hier ist tatsächlich eine Blacklist geplant, um insbesondere Ziele bei gmail.com, t-online.de etc. zu blockieren, da Weiterleitungen dorthin häufig sehr problematisch sind.


    Wie soll man Kunden das denn dann erklären: Zu irgendeinewaldunwiesen.domäne kann er Weiterleiten, aber zu den am häufigsten genutzen Anbietern nicht. Das gibt Ärger. Dann lieber gar keine Weiterleitungen für Domains, die nicht dem Kunden gehören.


    Weiterleitungen nach Gmail, Outlook.com & Co. sind ja prinzipiell nicht schlimm, wenn ich aber eine verbrannte Adresse dorthin leite, und den Spamfilter in LC nicht aktiviere, dann landet der Server ganz schnell auf der Sperrliste (aber egal bei welchem Anbieter).

    Das würde dann aber interne Weiterleitungen verhindern, also z.B. den Fall info@ soll an zwei Einfänger innerhalb der Domain gehen.
    Es gibt ja in LC keine Möglichkeit (wie das in Confixx möglich war) eine Adresse auf mehrere Postfächer verteilen zu lassen.


    Ich meinte Weiterleitungen nach extern.

    Auf Kundenebene verstehe ich den Zustand "gesperrt" auch nicht. Laut Tool-Tipp darf er sich dann nicht mehr in LC einloggen, aber alle Dienst laufen weiter. Den Anwendungsfall habe ich noch nicht begriffen.


    Anders herum wird für mich ein Schuh draus: Die Dienste (Web/Mail) sind gesperrt, aber der Kunde kann sich noch einloggen um z.B. Fehler zu korrigieren. Das würde man brauchen, wenn z.B. die Webseite gekapert wurde oder Mail missbraucht.


    Ich habe gerade einen Fall, wo ich die E-Mailfunktion abschalten musste, aber dennoch können die User sich in ihre Postfächer einloggen und Mails werden angenommen.

    Ich habe gerade die aktuelle LC Version installiert, und da ich LC verboten habe die Postfix-Config anzupassen, muss ich Änderungen und Updates immer manuell nachziehen.


    Könnte sich bitte mal ein Produktmanager äußern welchen Sinn es hat DSN komplett zu ignorieren?


    Ich nutzte diese Funktion immer mal wieder und auch meine Kunden kennen diese Option im Thunderbird.