Grommunio for Synology (G4S)

[Andy+]

mindestens 1x am Tag aus einen Snapshot wiederherstellen

Was passiert davor oder was führt dazu? Den MAPI-Fehler, hast Du den laufend? Du kannst auch mal im G-Forum nachschauen, was sich da findet. Weshalb hast Du diese Schreibfehler beim Updaten?

Und wenn Du einen Snapshot rücksicherst, wie läuft das System dann?

Wenn Du einen zeitnahen Export der VM hast, der auch gut funktioniert hat, könntest Du ja auch die Elementedifferenz bis dahin jetzt sichern, die VM löschen und einen Import durchführen und die Elementedifferenz zurücksichern.

Oder Du machst ein komplettes Backup

https://docs.grommunio.com/admin/operations.html#backup-disaster-recovery

und setzt neu auf, wenn sich das nicht mehr klarsteuern lässt.

 

[491810]

Also im Moment gibt es die folgenden Probleme ich stetigen Wechsel:

1.) GPG key error:
Dabei ist es egal, ob ich "nur" einen 'zypper ref && zypper up' gemacht habe oder einen 'zypper dup'
Das ausführen von "rpm -qi GPG-PUPKEY-VERSION" auf der Konsole bringt 0,0. Ab dem Zeitpunkt
Ist kein Update mehr möglich. Egal ob "zypper ref", "zypper up" oder auch "zypper dup" o.a.
Nachtrag: Wenn man "Select software repositories" neu auswählt und mit OK bestätigt ist er weg.

2.) database error:
Bekommt er gerne mal nachdem der GPG error aufgetreten ist und ich ihn neu gestartet habe.

3.) MAPI Error:
Der ist neu hinzugekommen. Die admin gui läuft. Aber er gibt dem Mapi Error aus.
Anmelden am Web-Mail läuft auf einen Fehler. Anmeldung nicht möglich.

4.) "grommunio Console user interface" ist irre langsam bzw hängt komplett

5.) Der Fehler "Service 'redis@default' is currently not available":
Der ist neu. Neustart des Dienstes "redis@grommunio" bringt leider 0,0

Ich habe die VM exportiert. Habe sie inzwichen von der d620slim (max.: 2xCPUs) auf die ds918plus (max.: 4x CPUs) portiert.
Könnte ich also wieder löschen und neu importieren. Damit habe ich dann aber immer den aktuellen Email-Stand verloren.

Was hat es denn mit diesem "ElementDifferenz" auf sich? Höre ich offen gestanden zum ersten mal. Was ist das und wie geh es?
Habe die GRO inzwischen auch schon wiederholt auf der ds918p als auch ds620s neu aufgesetzt. Da geht dann immer was nicht.
Meist geht der nginx nach der Neuinstallation nicht. Aufgrund der database error wollte ich die db schon mal auf der Maria10 nutzen.
Aber irgendwie klappt es vorne und hinten mit einer Neuinstallation nicht. Aber Ich nehme mir heute abend mal mehr Zeit dafür.

Das witzige ist: Läuft eine Umgebung ohne Clients läuft sie stabil. Da kann ich dann soviel "zypper up", "zypper ref" und "zypper dup"
machen wie ich lustig bin und rebooten. Mache ich das aber auf dem produktiven System habe ich alle Nase lang irgendwelche Fehler.

Kaum 2h gelaufen bekomme ich wieder den redis@default-Fehler. Neustart des Dienstes bringt 0,0. Die Festplatten der NAS sind wie
wild am rattern. Keine Ahnung, was der treibt. "zypper ref" bringt direkt wieder den GPG-Key-error. Echt. Zum Kosten mit der GRO.

 

[Andy+]

Dieser Begriff "Elementedifferenz" ist von mir und damit meine ich alle Elemente, also Emails, Kalendereinträge, Aufgaben usw. die sich in einem Zeitraum ansammeln. Hast Du zB. vor 2 Tagen einen Export durchgeführt, arbeitest Du ja weiter und bekommst zB. Emails, schreibst welche usw. und dadurch entsteht bis heute diese Elementedifferenz.

Zu Punkt 1, 3-5 kann ich nichts sagen, vlt. mal im Forum gucken. Zu Punkt 2, mitunter der Database Error hatte mich dazu veranlasst, seither alle Neuinstallationen ohne jedes Update durchzuführen, bis alles rundläuft, einschliesslich des kompletten Settings. Dann Export, Snapshot und erst dann das System updaten. Seither läuft das sehr stabil.

Bezüglich nginx, wenn da so eine Meldung steht



ignoriere ich die bereits seit längerem, denn die habe ich irgendwann immer. Und wenn Web-GUI und Admin-GUI erreichbar sind, läuft das trotzdem.

Dann, "zypper dup" bringt nichts oder führt nur zu Fehlern. Du hast ja mit 2022.12.1 bereits die neuste Installation und ggf. handelst Du Dir damit Fehler ein. Solange Du kein Major Upgrade machst, verwende höchstens "zypper up" und "zypper ref", kein "zypper dup".

Machst Du mal wieder eine Neuinstallation, gehe in der CUI von oben nach unten durch ohne das Setup, führe einen Reboot durch und sperre für die VM den Internetzugang. Erst dann führe den Setup Wizard aus und installiere das System nur mit dem Inhalt der ISO nicht (!) mit der OVA.

Ich kann nicht beurteilen, ob der Wechsel zwischen den DS´n etwas ausmacht. Ich kann mir aber vorstellen, dass Deine DS918+ deutlich besser geht gegenüber der DS620slim und entsprechend die Einstellungen für die VM bez. CPU und RAM ungleich sind. Ich würde die DS918+ nochmal neu und sauber aufbauen nach neusten Erkenntnissen.

 

[491810]

Super. Via Select software repositories" das GPG-Probem gelöst.
Nach dem Neustart habe ich jetzt den "database eror". Ohne Update.
Und bei erneute "zypper ref" habe ich schon wieder den GPG-keyerror.
Ich drehe mich hier gefühlt im Kreis. Ich kan die GRO jetzt neu aufsetzen.
Aber irgendwie fühle ich mich so, als ob der Fehler dennoch wieder kommt.

 

[Andy+]

ohne Clients läuft sie stabil

Das hat aber von der Sache her keinerlei Einfluss. Ich hänge mit 3 Win-Rechnern dran mit Outlook über MAPI, Thunderbird über IMAP und TbSync mit Exchange ActiveSync und 2 Smartphones mit Nine. Alles zusammen genommen, ist und läuft das sogar besser, wie mit K4S und das heisst schon viel.

Diesen "GPG key error" und "redis@default" Fehler würde ich aber an Deiner Stelle analysieren, mit was das zusammenhängt, vielleicht musst Du noch was an Deiner Umgebung korrigieren. Solche Fehler habe ich nie gesehen.

 

[491810]

Ja. Auch ich nutze GRO über einen Windows 11 PC via Outlook (MAPI), ein Macbook via Mail (IMAPs), ein iPad (Exchange) und iPhone (Exchange) und es läuft. Wenn es läuft. Wenn ich jetzt noch wüßte, WIE ich diese zwei Fehler analysiere dann wäre mir sehr geholfen.

Mit was machst Du denn die Sicherungen wenn nicht mit dem integrierten Snapshot Tool in der VMM @Andy+?

 

[Andy+]

Über den Export wird ja eine OVA angelegt und diese wird regulär gesichert.

 

[491810]

Ja. Die Anlage eines OVA via Export kenne ich schon. Dauert nur eine halbe Ewigkeit. So habe ich ja von Syno zu Syno migriert.

 

[491810]

Ich sag es ja nicht gerne ... aber nachdem ich die GRO neu aufgesetzt habe läuft sie jetzt mal endlich stabil.

 

[Andy+]

Seit Anfang Februar muss man vorsichtig mit den Grommunio Updates umgehen, irgendwie ist so leicht der Wurm drin gerade, der erst wieder verschwinden muss, das scheint insbesondere die v2022.05.x zu betreffen.

Bis dahin ist immer gut, am besten einen Export zu haben, den man uU. als OVA wieder importieren kann, denn die vom VMM erstellten Snapshots scheinen nicht die Qualität herstellen zu können, wie dies ein Import einer OVA kann, der natürlich die Reinform wieder herstellt. So zumindest mein Eindruck, der jetzt nicht umfänglich zutreffend sein muss.

Die Testinstallation als "Vorhut" fängt das ab ....

 

[491810]

Ich habe gerade Problem mit dem SMTP Server. Die Einträge sind in der Datei main.cf und sasl_passwd korrekt hinterlegt.
Den 1&1 STMP Server kann ich problemlos pingen. Hängt das jetzt an 1&1 oder einem GRO Update? Hat das noch wer?

Fehler Mail queue Admin GUI:

(local data error while talking to smtp.ionos.de[213.165.67.113])

main.cf (Zeile 341):

relayhost = smtp.ionos.de:587

main.cf (Zeile 741-746):

############################################################
# SASL stuff
############################################################
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtpd_sasl_auth_enable = yes
# cyrus : smtpd_sasl_type = cyrus
# smtpd_sasl_path = smtpd
# dovecot : smtpd_sasl_type = dovecot
# smtpd_sasl_path = private/auth
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
############################################################
# TLS stuff
############################################################
#tls_append_default_CA = no
relay_clientcerts =
#tls_random_source = dev:/dev/urandom

smtp_use_tls = yes
#smtp_tls_loglevel = 0
smtp_enforce_tls = no
smtp_tls_CAfile =
smtp_tls_CApath =
smtpd_tls_cert_file = /etc/grommunio-common/ssl/server-bundle.pem
smtpd_tls_key_file = /etc/grommunio-common/ssl/server.key
#smtp_tls_policy_maps = lmdb:/etc/postfix/tls_policy
#smtp_tls_session_cache_timeout = 3600s
smtp_tls_session_cache_database =

smtpd_use_tls = yes
#smtpd_tls_loglevel = 0
smtpd_tls_CAfile =
smtpd_tls_CApath =
smtpd_tls_cert_file = /etc/grommunio-common/ssl/server-bundle.pem
smtpd_tls_key_file = /etc/grommunio-common/ssl/server.key
smtpd_tls_ask_ccert = no
smtpd_tls_exclude_ciphers = RC4
smtpd_tls_received_header = yes

sasl_passwd

smtp.ionos.de:587 name@domain.ltd : password

(da sind keine Lehrzeichen zwischen "ltd" dem ":" und dem "password". Der baut hier aber sonst einen Smiley ein)

Habe auch schon smtp.ionos.de:465 und auch schon beide in main.cf und sasl_password probiert. Keine Änderung.

Mit "journalctl -r" bekomme ich u.a. folgende Meldung:

Feb 10 14:39:17 localhost sshd[29480]: error: kex_exchange_identification: Connection closed by remote host

Nervt gerade wie Sau ...

(delivery temporarily suspended: lost connection with smtp.ionos.de [213.165.67.97] while receiving the initial server greeting)
(lost connection with smtp.ionos.de[213.165.67.113] while receiving the initial server greeting)
(lost connection with smtp.ionos.de[213.165.67.97] while receiving the initial server greeting)

 

[Andy+]

Ich habe zwar "smtp_use_tls = yes" auskommentiert, das wird jetzt wohl aber nicht der Effekt sein. Ich habe nach wie vor Updatestand Ende Januar/Anfang Februar, welchen Stand hast Du?

Bei mir läuft alles einwandfrei.

 

[491810]

Nach einer 1/2 Stunde Fummelei smtp.ionos.de:464, smtp.ionos.de:587, smtp.1und1.de:465, smtp.1und1.de:587 vor und zurück in der main.cf, sasl_passwd und (damit es schneller geht) sasl_passwd.lmdb und jedes mal systemctl restart postfix geht es jetzt auf einmal wieder mit der alten (anfänglichen) Einstellung smtp.ionos.de:587 in allen drei Dateien. Denke mal 1und1/Ionos hatte "einfach" nur ein SMTP Problem gehabt.

 

[491810]

Interessante Meldung nach dem Update eben (zypper up && zypper ref). Nach den Neustart meint er "nginx läuft nicht". Aber Admin GUI als auch Web-Interface sind online. Stoppt man "nginx" als Dienst in der Admin-GUI geht danach natürlich nach der Aktion weder noch mehr. Logisch. Also Neustart (was mir klar war). Auch nach dem Neustart sagt der Lügebaron das gleiche: "Nginx läuft nicht". Was ein eine Irreführung. Soviel zum Thema "Updaten". Was ein Glück läuft ja noch alles.

 

[Andy+]

Nginx läuft nicht

Ich hatte auch nicht gleich bemerkt, dass diese Meldung gar nichts besagt, solange die GUI´s Admin und Web einwandfrei erreichbar sind und laufen. In aller Regel ist nach Updates und einem Neustart diese Meldung nicht sichtbar und alles ist normal. Dann jedoch, nach einer gewissen Zeit erscheint diese dann doch wieder. Ich habe ohnehin den Verdacht, dass die internen Abstimmungen zu Timeouts noch nicht ganz perfekt sind, nur so kann ich eine derartige Meldung deuten, wenn sie offenbar keine Auswirkungen hat.

 

[491810]

Muss mich korrigieren. Musste den Snap von Mitternacht zurücksichern. Bei mir kamen eben keine Emails mehr an. Jetzt nach dem Restore geht nginx wieder und es kommen auch wieder Emails an. Fragt mich jetzt aber nicht wie das miteinander zusammenhängt. Und "Ja", ich weiß, dass "nginx" nicht der smtpd ist. Also "Nginx läuft nicht" assoziiere ich - trotz laufendem Admin-Gui und Webmailer - dann seit heute mit "es kommt keine Email mehr an". Nicht ganz sooo witzig. Merke ich mir.

 

[Andy+]

Ich habe diese Meldung



eigentlich immer und trotzdem läuft alles normal, jedenfalls bemerke ich nichts an Einschränkungen.

Was sich da zZ aber abspielt mit den Updates, ist haarsträubend und das scheint nicht mal immer die aktuelle v2022.12.1 zu betreffen, sondern fast eher noch die 2022.05.x. Es ist ein Rätsel, wie das gehen kann, man sollte meinen, das Stammpersonal hat gerade Urlaub und wird vertreten und für die Qualitätskontrolle wurde niemand gefunden, oder sowas. Ich bin froh, die Exporte zu haben, auch den Snapshots traue ich noch nicht recht über den Weg.

 

[491810]

Mmmmhh ... also bei mir war das. Admin- und Web-GUI gingen trotzdem. Als ich dann aber auf den Snap davor zurückgesichert hatte war auch die Anzeige wieder weg. "Normal" ist die also eigentlich nicht. Zumal der nginx ja läuft. Sonst wäre ja keine Admin- und Web-GUI erreichbar. Aber solange es keine weiteren Folgen für Dich hat ist es ja okay. Wirst bei der nächsten Migration beim Q1/23 Release ja eh - wie ich - nochmal neu aufsetzen und Postfächer migrieren dürfen. Dann wird das bei der Neuinstallation bei Dir sicherlich auch verschwunden sein. Woher es kommt wissen nur die Götter.

 

[491810]

Also ich finde Grommunio persönlich sehr unausgereift muss ich sagen. Ich habe bei jedem Update irgendein Problem. Zwar nicht mehr so viele wie nach dem "zypper dup". Aber auch von gestern auf heute läuft auf einmal einfach der redis@grommunio nicht mehr. D.h. mobile Endgeräte (iPhone, iPad & Co) können sich nicht mehr syncen. Restart des Dienstes bzw. der GRO brachte nichts. Im Terminal hatte ich dann auch den GPG-key-error wieder. Und die GRO lief gestern den ganzen Tag nach dem letzten Update und Reboot ohne Probleme. Neuer Tag. Neue Probleme. Ergo: Snapshot wiederherstellen. Nachdem ich den Snapshot wiederhergestellt habe und ein "zypper up" gemacht hatte lief auch noch alles. Nach dem Reboot "nginx läuft nicht" - obwohl er läuft. Wie bei @Andy+ . Also. Wieder gestoppt. Wieder Snapshot wiederhergestellt. Wieder gestartet. Nginx läuft wieder. Wieder "zypper up". Nginx via Terminal mit "systemctl restart nginx" neu gestartet. Alles läuft. Kein Problem. Ein Reboot später meckert die AdminGUI wieder "nginx läuft nicht" obwohl er doch läuft. Welche Pfuscher sitzen denn da bei Grommunio in der Programmierung? Oder hat man besser die fehlerhafte Anzeige bei Grommunio da dann das OS wenigstens - wie bei @Andy+ - läuft? Bekomme ich für den roten "nginx läuft nicht"-Fehlertext wenigstens keine GPG-key-Error oder redis@grommunio Fehlermeldungen mehr? #ohneWorte

Nachtrag: ich kann egal welchen Snapshot zurücksetzen. Sobald ich ein "zypper up" mache bekomme ich nach dem Reboot jedes mal die Fehlermeldung "nginx läuft nicht" (obwohl er läuft). D.h. die haben ein buggy Update raus gebracht.

 

[Andy+]

"nginx läuft nicht"-Fehlertext

Da ich nun weiss, wie es um die Bedeutung steht, finde ich das nun nicht weiter schlimm. Bis man auf solche Dinge kommt, ist eher die Sache und bis dahin macht man ggf. unnötige Aktionen oder Neuinstallationen oder sonst etwas. Inzwischen habe ich auch an den Snapshots so meine Zweifel und lege ohnehin schon immer komplette Exporte an. Wenn etwas nicht läuft, lösche ich die VM und sichere die letzte funktionierende OVA zurück.

Ich habe momentan einen gut laufenden Stand

localhost:~ # rpm -qa 'grom*'
grommunio-cui-1.0.241.dbe4906-lp154.45.1.noarch
grommunio-index-0.1.25.3e826c9-lp154.31.1.x86_64
gromox-debugsource-2.2.140.7f3e6a0-lp154.112.1.x86_64
grommunio-admin-api-1.9.28.774374b-lp154.46.1.noarch
grommunio-sync-1.1.62-lp154.75.1.noarch
grommunio-web-3.1.197.c7957cc-lp154.157.1.noarch
grommunio-dbconf-1.1.1.da20a46-lp154.4.2.x86_64
grommunio-common-10.e94d08a-lp154.7.1.x86_64
grommunio-setup-1.0.68.bb1014d-lp154.7.1.noarch
grommunio-release-2022.12.1-lp154.3.1.x86_64
gromox-2.2.140.7f3e6a0-lp154.112.1.x86_64
grommunio-imapsync-2.178-lp154.1.1.noarch
grommunio-admin-common-6.cb985db-lp154.3.1.noarch
grommunio-antispam-3.4-lp154.2.1.x86_64
grommunio-admin-web-2.6.0.43.2feaeef-lp154.35.1.noarch
grommunio-dav-1.1.37.d5b6463-lp154.9.1.noarch
gromox-debuginfo-2.2.140.7f3e6a0-lp154.112.1.x86_64
grommunio-error-pages-1.0.6.9c50afb-lp154.3.1.noarch
localhost:~ #

der nicht der aktuellste ist, was ja per se auch nicht sein muss. Zudem habe ich parallel eine Testinstallation laufen, mit der ich bis zum aktuellen Stand update. Die läuft auch, Update per heute morgen, jedoch vermute ich in der Perfomance einen Unterschied, daher mache ich da erst noch diverse Tests, zudem habe ich abgesehen von der HTTP 500-Geschichte eigentlich keinen akuten Updatebedarf.

Vielleicht solltest Du auch mal versuchen, nicht die Snapshots zu verwenden, sondern komplette OVA´s verwenden, vielleicht ergibt sich da ein Unterschied im Ergebnis.