Debian 12 Login Grommunio Admin mit Web Interface nach reboot access denied

herbert

Ich habe grommunio auf einer Virual Box mit Debian 12 installiert.

Ich habe folgenden Effekt:
Nach der Insatallation ist ein Admin Login mit dem Web Interface möglich.
Alles funktioniert richtig.
Nach einem reboot von Debian funktioniert der login nicht mehr.
Erster login Versuch:
admin
password

Login access denied

auf der Web Seite.

Fehlerausgabe
journalctl -f

zeigt folgendes

Mar 30 16:59:38 debian-12 uwsgi[1691]: [WARNING] (grommunio Admin API) Database schema version updated detected - reloading ORM
Mar 30 16:59:38 debian-12 uwsgi[1691]: [WARNING] (security) getUser() failed (ArgumentError): reverse_property 'mlist' on relationship MLists.user references relationship Users.mlist, which does not reference mapper mapped class MLists->mlists
Mar 30 16:59:38 debian-12 uwsgi[1691]: [WARNING] (grommunio Admin API) GET /api/v1/domains?domainType=0&sort=domainname,asc from 2a02:778:141:8a01:78df:57e0:1c72:f90b -> 401 '{"message":"Access denied","error":"Failed to get user information from database"}\n'

Zweiter login Versuch
Fehlermeldung auf Webinterface
The server encountered an error while processing the request.

journalctl -f
Zeigt folgendes

Mar 30 17:01:25 debian-12 uwsgi[1691]: [ERROR] (grommunio Admin API) Traceback (most recent call last):
Mar 30 17:01:25 debian-12 uwsgi[1691]: File "/usr/lib/python3/dist-packages/flask/app.py", line 1820, in full_dispatch_request

Mar 30 17:01:25 debian-12 uwsgi[1691]:     rv = self.dispatch_request()
Mar 30 17:01:25 debian-12 uwsgi[1691]:          ^^^^^^^^^^^^^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/lib/python3/dist-packages/flask/app.py", line 1796, in dispatch_request
Mar 30 17:01:25 debian-12 uwsgi[1691]:     return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
Mar 30 17:01:25 debian-12 uwsgi[1691]:            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/share/grommunio-admin-api/api/core.py", line 204, in wrapper
Mar 30 17:01:25 debian-12 uwsgi[1691]:     return call()
Mar 30 17:01:25 debian-12 uwsgi[1691]:            ^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/share/grommunio-admin-api/api/core.py", line 169, in call
Mar 30 17:01:25 debian-12 uwsgi[1691]:     ret = func(*args, **kwargs)
Mar 30 17:01:25 debian-12 uwsgi[1691]:           ^^^^^^^^^^^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/share/grommunio-admin-api/endpoints/misc.py", line 43, in login
Mar 30 17:01:25 debian-12 uwsgi[1691]:     success, val = loginUser(request.form["user"], request.form["pass"])
Mar 30 17:01:25 debian-12 uwsgi[1691]:                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/share/grommunio-admin-api/api/security.py", line 208, in loginUser
Mar 30 17:01:25 debian-12 uwsgi[1691]:     user: Users = Users.query.join(Altnames, isouter=True)\
Mar 30 17:01:25 debian-12 uwsgi[1691]:                   ^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/share/grommunio-admin-api/orm/__init__.py", line 38, in __get__
Mar 30 17:01:25 debian-12 uwsgi[1691]:     mapper = class_mapper(type)
Mar 30 17:01:25 debian-12 uwsgi[1691]:              ^^^^^^^^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/lib/python3/dist-packages/sqlalchemy/orm/base.py", line 448, in class_mapper
Mar 30 17:01:25 debian-12 uwsgi[1691]:     mapper = _inspect_mapped_class(class_, configure=configure)
Mar 30 17:01:25 debian-12 uwsgi[1691]:              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/lib/python3/dist-packages/sqlalchemy/orm/base.py", line 427, in _inspect_mapped_class
Mar 30 17:01:25 debian-12 uwsgi[1691]:     mapper._check_configure()
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/lib/python3/dist-packages/sqlalchemy/orm/mapper.py", line 1941, in _check_configure
Mar 30 17:01:25 debian-12 uwsgi[1691]:     _configure_registries({self.registry}, cascade=True)
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/lib/python3/dist-packages/sqlalchemy/orm/mapper.py", line 3527, in _configure_registries
Mar 30 17:01:25 debian-12 uwsgi[1691]:     _do_configure_registries(registries, cascade)
Mar 30 17:01:25 debian-12 uwsgi[1691]:   File "/usr/lib/python3/dist-packages/sqlalchemy/orm/mapper.py", line 3562, in _do_configure_registries
Mar 30 17:01:25 debian-12 uwsgi[1691]:     raise e
Mar 30 17:01:25 debian-12 uwsgi[1691]: sqlalchemy.exc.InvalidRequestError: One or more mappers failed to initialize - can't proceed with initialization of other mappers. Triggering mapper: 'mapped class MLists->mlists'. Original exception was: reverse_property 'mlist' on relationship MLists.user references relationship Users.mlist, which does not reference mapper mapped class MLists->mlists
Mar 30 17:01:25 debian-12 uwsgi[1691]: [WARNING] (grommunio Admin API) POST /api/v1/login? from 2a02:778:141:8a01:78df:57e0:1c72:f90b -> 500 '{"message":"The server encountered an error while processing the request."}\n'
Mar 30 17:01:36 debian-12 systemd[1]: Starting grommunio-index.service - Fulltext search index regeneration...
Mar 30 17:01:36 debian-12 systemd[1]: grommunio-index.service: Deactivated successfully.

Dann
systemctl stop grommunio-admin-api
Ausgabe:
Warning: Stopping grommunio-admin-api.service, but it can still be activated by:
grommunio-admin-api.socket
Dann
systemctl start grommunio-admin-api
Alles funktionier wieder richtig

Wie lässt sich das erklähren?
Was läuft hier falsch ?

herbert

Das Problem tritt auf, nachdem Grommunio auf Debian 12 mittels folgendem Install Script installiert wurde:
Debian neu installiert.

git clone https://github.com/eryx12o45/grommunio-setup.git /usr/local/share/grommunio-setup
/usr/local/share/grommunio-setup/grommunio-setup
Dann ein reboot.

Das Problem verschwindet, wenn folgendes ausgeführt wird:

systemctl disable grommunio-admin-api

Danach ein Reboot.

Kann das jemand erklären?
Ich vermute einmal das liegt da drann, dass mariadb nach dem gromox sevice gestartet wird (Nur Vermutung)

WalterH

Einfach mit einem Cron Eintrag einige Minuten nach dem Reboot das grommunio-admin-api restarten, als temporäre Lösung.

herbert

Danke für die Antwort
Sollte als Info an das Grommunio Team dienen,
oder an jemand der das gleiche Problem hat.
Die temporäre Lösung ist ja viel einfacher.
Einmal den Befehl
systemctl disable grommunio-admin-api
ausführen
und dann ein Reboot.
danach funktioniert ja alles richtig.
Danach funktioniert es immer richtig.
Auch nach einem reboot.
Ich have mir gedacht , man könnte den Start des Datenbank Servers vor den Start der Grommunio Services
schieben.
Leider habe ich keine Ahnung , wie man in Linux die Startreihenfolge der Services beeinflussen kann.

WalterH

herbert an jemand der das gleiche Problem hat?

Für alle die dieses Problem haben, das systemctl disable grommunio-admin-api wird vor dem Reboot meistens vergessen, eine Automatik, die das Service nach dem Reboot neu startet ist einfacher.

herbert

WalterH wird vor dem Reboot meistens vergessen

Man muss das nicht jedes mal vor dem reboot machen.
Nur ein einziges mal nach der Installation.
Dann tritt das Problem nie wieder auf.
Also Installation (auch Reinstallation), systemctl disable grommunio-admin-api dann reboot.
Fertig!
Danach gibt es keine Probleme mehr.

WalterH

herbert systemctl disable grommunio-admin-api

wenn man ein disable macht, startet das grommunio-admin-api beim nächsten Reboot nicht mehr. Dann muss grommunio-admin-api von einem anderen Dienst gestartet werden. Die Frage ist, welcher Dienst startet dann das grommunio-admin-api?

herbert

WalterH welcher Dienst startet dann das grommunio-admin-api

Wenn ich
systemctl stop grommunio-admin-api
eingebe, bekomme ich folgende Meldung
Warning: Stopping grommunio-admin-api.service, but it can still be activated by:
grommunio-admin-api.socket
Ich denke, dass der Service grommunio-admin-api.socket
den dienst
grommunio-admin-api
startet

WalterH

Was meldet dieser Befehl: systemctl is-enabled grommunio-admin-api.service
Wenn enabled kommt, wird das grommunio-admin-api ganz normal vom OS nach grommunio-admin-api.socket gestartet.

herbert

WalterH Was meldet dieser Befehl: systemctl is-enabled grommunio-admin-api.service

Der Befehl
systemctl is-enabled grommunio-admin-api.service
meldet
disabled
Der Befehl
systemctl status grommunio-admin-api.service
meldet:
Loaded: loaded (/lib/systemd/system/grommunio-admin-api.service; disabled; preset: enabled)
Active: active (running) since Tue 2025-04-01 08:59:22 CEST; 46min ago
TriggeredBy: ● grommunio-admin-api.socket

So wie das aussieht wird er also von grommunio-admin-api.socket
gestartet.