Grommunio for Synology (G4S)

[Andy+]

Dauert eine halbe Ewigkeit. Anfangs war die GRO bei keinen 10GB

In dem Fall ist mir da IMAP lieber. Ich habe eins mit 12 GB, das dauerte fast einen Tag, wobei das da noch nicht auf SSD lief.

 

[491810]

Also bei mir sind es 1x12GB, 1x 1GB, 1x0,4GB und 2x 1,2GB. Laptop ist seit Freitagnachmittag durchgehend am Pumpen
und zeigt noch immer "userA@domain.ltd UND userB@domain.ltd werden aktualisiert". Nimmt kein Ende. Aber ist so.

 

[491810]

Nur als Frage zum Verständnis:

Du meldest dich in Outlook an der GRO an und hast dann nach einer Neuinstalltion quasi ein neues und leeres Postfach für diesen Benutzer.
Nun hängst du in Outlook entsprechende ARCHIV-PST Dateien ein. Abschließend kopierst du die Inhalte aus der Archiv PST in die gleichen Ordner des neuen Postfach?

Genau so. Zu Deiner Antwort bzgkl. der Kaperung des Mailservers. Das bzgl. des SMTP Ports ist mir klar. Auch meine Sophos filtert die eingehenden Mails und verwirft Angriffe. Advanced Threat Protection, Intrusion Protection System (IPS), SMTP-Proxy/Filter mit Real-Time-Blacklists (RBL), usw. ist natürlich alles aktiv. Ich fragte mich jetzt aber mehr, welche Sicherheitseinstellungen ich innerhalb der GRO (z.B. in der main.cf) sinnvollerweise vornehmen kann damit niemand ohne Authorisierung Emails über meinen Server verschickt. Eigentlich müsste das im default ja nur mit Benutzername und Passwort funktionieren (?). Andererseits habe ich aber auch einige Einstellungen gefunden, wo ich in der main.cf Einschränkungen vornehmen kann. Da wollte ich mal wissen, ob und - falls "ja" - hier schon mal jemand Anpassungen/Einschränkungen zur besseren Absicherung vorgenommen hat.

 

[491810]

Eben ein zypper up" gemacht der mir die WebGUI gegrillt hat. Habt ihr das auch?

Fatal error: Unknown: mapi: opcache is incompatible due to breakage of is_resource($x) in Unknown on line 0

 

[Vogi]

siehe hier:

The php-opcache extension should be deinstalled

 

[Andy+]

Gibt es im GroForum schon einen Thread?

 

[Vogi]

Gibt es im GroForum schon einen Thread?

Ja, hier:
https://community.grommunio.com/d/780-upgrade-von-mapi-header-php-auf-debian-bullseye-blockiert/14

Speziell im letzten Beitrag wird beschrieben, dass der Check jetzt in die mapi.so verschoben wurde, weil ein generelles blockieren über die Paketverwaltung anderweitge Probleme verursacht hat (Rest des Threads).

Viele Grüße
Vogi

 

[491810]

Wenn ich das so lese dann warte ich besser mit einem Update bis die eine solide Lösung für das Problem haben.

 

[Andy+]

weil ein generelles blockieren über die Paketverwaltung anderweitge Probleme verursacht hat (Rest des Threads).

Das steht so aber nicht dort.

Heute ist zudem verkündet worden, dass bei den Optionsmodulen mit den aktuellen Updates ein Switch von OC zu NC vollzogen wurde. Zumindest Files wird also auf Basis von NC funktionieren.

 

[Vogi]

Das steht so aber nicht dort.

sondern?

 

[Andy+]

Da steht doch nur

opcache-Check vom Packaging nach mapi.so verschoben. gromox-2.4-101-ged7be7dbf

 

[491810]

Schon ausprobiert? So wie ihr alle schreibt wohl keiner von euch (?)

 

[Andy+]

Erst mal in der Testinstallation, dann mal sehen. Da schwirrt schon wieder so ein "Error 502 - Bad Gateway on Frontend" umher.

 

[491810]

Und da läuft der Update ohne Fehler? Oder hast Du da nach dem Update den beschrieben "502"?

 

[Andy+]

Ich habe soeben ein Update durchgeführt auf Testumgebung. AdminGUI geht, beim Aufruf der WebGUI erscheint

"Fatal error: Unknown: mapi: opcache is incompatible due to breakage of is_resource($x) in Unknown on line 0"

localhost:~ # rpm -qi gromox | head -n 3
Name : gromox
Version : 2.5.11.7e2fe81
Release : lp154.8.1
localhost:~ #

localhost:~ # rpm -qa 'grom*'
grommunio-dbconf-1.1.1.da20a46-lp154.4.4.x86_64
grommunio-index-0.1.34.aef1495-lp154.37.1.x86_64
grommunio-setup-1.0.81.88c7129-lp154.14.1.noarch
grommunio-common-13.02127be-lp154.17.1.x86_64
grommunio-cui-1.0.246.9c43fb8-lp154.48.1.noarch
grommunio-admin-api-1.9.34.04f8611-lp154.51.1.noarch
grommunio-admin-web-2.6.0.54.c3a5ade-lp154.37.1.noarch
grommunio-imapsync-2.178-lp154.1.2.noarch
grommunio-admin-common-6.cb985db-lp154.3.1.noarch
grommunio-error-pages-1.0.6.9c50afb-lp154.3.2.noarch
gromox-debugsource-2.5.11.7e2fe81-lp154.8.1.x86_64
grommunio-antispam-3.4-lp154.4.1.x86_64
grommunio-dav-1.2.0.9976bca-lp154.2.1.noarch
grommunio-web-3.2.17.e2cdd09-lp154.193.1.noarch
grommunio-release-2022.12.1-lp154.3.2.x86_64
gromox-debuginfo-2.5.11.7e2fe81-lp154.8.1.x86_64
gromox-2.5.11.7e2fe81-lp154.8.1.x86_64
grommunio-sync-1.2.2-lp154.100.1.noarch
localhost:~ #

 

[Andy+]

Meine zZ. ziemlich gut laufende Installation hat dagegen die Versionen

localhost:~ # rpm -qi gromox | head -n 3
Name : gromox
Version : 2.3.122.14afd7d
Release : lp154.64.1
localhost:~ #

localhost:~ # rpm -qa 'grom*'
grommunio-setup-1.0.71.ee675d8-lp154.9.2.noarch
grommunio-common-12.1029661-lp154.16.2.x86_64
grommunio-admin-api-1.9.34.04f8611-lp154.51.1.noarch
grommunio-sync-1.2.2-lp154.99.1.noarch
grommunio-imapsync-2.178-lp154.1.2.noarch
grommunio-dav-1.2.0.9976bca-lp154.1.1.noarch
grommunio-antispam-3.4-lp154.4.1.x86_64
gromox-debuginfo-2.4.94.567cd4e-lp154.42.1.x86_64
grommunio-admin-common-6.cb985db-lp154.3.1.noarch
gromox-2.3.122.14afd7d-lp154.64.1.x86_64
grommunio-admin-web-2.6.0.53.7822c1e-lp154.36.2.noarch
grommunio-dbconf-1.1.1.da20a46-lp154.4.4.x86_64
grommunio-release-2022.12.1-lp154.3.2.x86_64
grommunio-index-0.1.32.a1df240-lp154.35.1.x86_64
grommunio-web-3.2.1.8530eaa-lp154.186.1.noarch
grommunio-error-pages-1.0.6.9c50afb-lp154.3.2.noarch
grommunio-cui-1.0.246.9c43fb8-lp154.48.1.noarch
gromox-debugsource-2.4.94.567cd4e-lp154.42.1.x86_64
localhost:~ #

 

[Vogi]

Da steht doch nur

opcache-Check vom Packaging nach mapi.so verschoben. gromox-2.4-101-ged7be7dbf

Nein, da steht genau das:
Kurzeitig wurde die Installation von gromomx über den Paketmanager unterbunden, wenn php-opcache installiert ist.
Jetzt checkt die mapi.so, ob php-opcache genutzt wird und gibt dann den Fehler aus.

Wenn Du php-opcache trotz Inkompatibiltät mit dem PHP JIT nicht deinstallieren willst, musst Du bei Deiner gut laufenden Version bleiben. Es wird durch die letzte Änderung eben nur genau auf das Problem hingewiesen... Probleme können aber auch vorher auftreten.

 

[Andy+]

OK. Als Laie lese ich nur verschoben.

Ich werde auch bis auf weiteres bei der genannten Version bleiben. Bislang fehlt ein Script bei den Updates, was die Löschung durchführt, sonst bleibt jeder daran hängen.

 

[Vogi]

Ich bin kein Hellseher, was seitens grommunio dazu kommen wird.
Aber gerade weil ja nicht jeder Anwender die Appliance nutzt und/oder noch zusätzliche Anwendungen laufen lässt, wird es wohl eher keine automatische Deinstallation geben.

Kurzzeitig gab es ja schon die Lösung über den Paketmamanger... so dass php-opcache groomox geblockt hatte. Der Konflikt wäre über Deinstallation von php-opcache aufzulösen gewesen. Da man aber auch mehrere php VErsionen parallel betrieben kann, tut das aber denen weh, die php-opcache anderweitig benötigen. Daher die jetzighe Umsetzung, nicht die Installation, sondern die Nutzung zu unterbinden.

Wenn Du nicht selber das Paket deinstallieren möchstest, wirst Du evtl. eine neue Applaince aufsetzen müssen, bei der von Anfang an das Paket nicht an Bord ist... oder auf Deiner jetzigen Version bleiben müssen - aber wie schon geschrieben: Das unter https://docs.grommunio.com/kb/php.html#opcache beschriebene Fehlervhalten hast Du dann trotzdem.

Allein das würde mich mehr beunruhigen, als der manuelle Deinstallationsschritt:
"The opcache extension is incompatible with the PHP JIT in at least php 8.0.25 and causes a vital function to mis-execute."

Deine Entscheidung ;-)

 

[Andy+]

wirst Du evtl. eine neue Applaince aufsetzen müssen

Ich könnte da nun keinen Zusammenhang herstellen, wo ich was aktivieren/deaktivieren muss, dass das Setup danach korrekt ist.

Und dass nun in der jetzigen Sitaution ggf. keine Eingriffe durch die Updateroutinen erfolgen könnten, könnte ich zudem nicht verstehen. Für mich wäre es kein Thema, über die Konsole nun für das lp154.x.x die Befehle rpm -e php8-opcache und systemctl restart php-fpm abzusetzen, wenn das die Lösung bringt. Aber das einfach so laufen zu lassen, wäre trotzdem schon dreist, finde ich. Nicht jeder kann mit Terminal oder Konsole gut umgehen, das ist der eine Punkt, dass aber zudem jeder, der updated, unweigerlich in diesen Fehler rennt und die Lösung nicht implementiert werden sollte, trägt nicht gerade zu einem guten Aussenbild bei, sondern pflegt das Image, was Grommunio in diversen Foren hat.