Beiträge von kroerig

Vor dem Auskommentieren:

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:

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:

[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:

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:

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

Ich meinte die von Ubuntu mitgelieferte PHP-Version, die will ich im LC nicht haben. Die Opt-Pakete haben jeweils neuere Versionen.

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

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:        16.04
Codename:       xenial
[code]


libpcre3 ist installiert:
[code]
Package: libpcre3
State: installed
Automatically installed: no
Multi-Arch: same
Version: 2:8.41-1.2+ubuntu16.04.1+deb.sury.org+1
Priority: required

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

aptitude purge php7.1-cgi
The following packages will be REMOVED:
  php7.1-cgi{p} php7.1-cli{u} php7.1-json{u} php7.1-opcache{u} php7.1-readline{u}
0 packages upgraded, 0 newly installed, 5 to remove and 10 not upgraded.
Need to get 0 B of archives. After unpacking 14.1 MB will be freed.
The following packages have unmet dependencies:
 liveconfig-meta : Depends: php5-cgi which is a virtual package and is not provided by any available package.
 or
                            php-cgi but it is not going to be installed.
                   Depends: php5-cli which is a virtual package and is not provided by any available package.
 or
                            php-cli but it is not going to be installed.
 php-imagick : Depends: phpapi-20170718 which is a virtual package and is not provided by any available package.
 or
                        phpapi-20160303 which is a virtual package, provided by:
                         - php7.1-cli, but it is not going to be installed.                         - php7.1-cgi, but it is not going to be installed. or
                        phpapi-20151012 which is a virtual package, provided by:
                         - php7.0-phpdbg, but it is not going to be installed.                         - php7.0-fpm, but it is not going to be installed.                         - libphp7.0-embed, but it is not going to be installed.                         - php7.0-cli, but it is not going to be installed.                         - php7.0-cgi, but it is not going to be installed.                         - libapache2-mod-php7.0, but it is not going to be installed.                         - php7.0-phpdbg, but it is not going to be installed.                         - php7.0-fpm, but it is not going to be installed.                         - libphp7.0-embed, but it is not going to be installed.                         - php7.0-cli, but it is not going to be installed.                         - php7.0-cgi, but it is not going to be installed.                         - libapache2-mod-php7.0, but it is not going to be installed. or
                        phpapi-20131226 which is a virtual package and is not provided by any available package.


The following actions will resolve these dependencies:


     Remove the following packages:
1)     liveconfig-meta
2)     php-imagick

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

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

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

Zitat von kk

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.

Zitat von kk

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.

Hallo zusammen,

jemand eine Idee, wie man in LC pro Kunde/Domain oder auch global E-Mailweiterleitungen verbieten kann?

Und CatchAll am besten gleich mit.

Danke & Gruß

Klaus

wie sage ich denn der custum.lua, dass sie genau diese eine Zeile aus der Konfig rauswerfen soll?

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.

Ich hatte auch mal überlegt Z-Push zu installieren, aber Z-Push läuft nur mit mod_php

Zitat von aziegler

wir haben einen wöchentlichen Cronjob, der das bei ProFTPd genutzte Zertifikat für LC übernimmt:

nach dem Motto "sharing is caring", hier:

Auch von mir ein Danke.

Hallo!

Ich habe gerade ein paar Mail verschickt und in Thunderbird die Option "Übermittlungsbestätigung (DSN) aktiviert" und mich gewundert, warum nicht passiert ist. Das kannte ich von meinem alten Confixx-Server so nicht.

Also mal auf die Suche gemacht und folgende Zeile in der main.cf gefunden

smtpd_discard_ehlo_keywords = silent-discard, dsn

Welchen Sinn macht es DSN komplett zu unterdrücken? Das MDNs keine wirkliche Aussagekraft haben OK, hier entscheidet der User ob eine "Empfangsbestätigung" versenden will. Aber mit einer DSN kann ich zumindest mal belegen, dass meine Mail an den nächsten HOP geleitet wurde.

Danke & Gruß

Klaus Rörig