Debian 11 clean install script

bringha Gebe ich 3 "```" auf einer Zeile ein und will dann auf der neuen Zeile den Code eingeben, bleiben in der Vorschau nur 2 ``

Die Vorschau funktioniert nicht mehr sobald man drei ``` benutzt :p.

Ich empfehle > crpb Editors/Plugins
oder noch ghostwriter

@mwilliams vielleicht gibt's da ja ein update fürs board? Ich hab den namen schon wieder vergessen.... F*irgendwas* (nein kein gefluche).

Zumindest bei mir war es unter Debian bisher nicht möglich, die Services im Dashboard direkt zu starten / stoppen / neustarten.
Debian 11 nutzt wohl immer noch eine völlig veraltete polkit Version (nicht PolicyKit), die mit den "modernen" JavaScript Rules nichts anfangen kann.
Lösen kann man das ganze durch folgende PKLA Datei:
/etc/polkit-1/localauthority/50-local.d/manage-units.pkla

[Allow users to manage services]
Identity=unix-user:grommunio
Action=org.freedesktop.systemd1.manage-units
ResultAny=yes

polkit.service danach restarten.
In vielen Beispielen findet sich hier ein ResultActive=yes. Das reicht aber nicht, weil der User grommunio aus dem Web Admin Interface nicht lokal am System angemeldet ist. Deshalb geht es nur mit ResultAny=yes.
Ein Nachteil sei nicht verschwiegen: Der User grommunio darf damit alle Services starten und stoppen. Eine Beschränkung auf bestimmte Services wäre erst mit der moderneren PolicyKit Version möglich, die Debian aber nicht anbietet.

@mwilliams Bitte validert das für euch nochmal, dann könntet ihr das in der Doku hier https://docs.grommunio.com/admin/manual_core.html#known-issues überarbeiten. Da steht aktuell noch, dass es nicht möglich ist ;-)

weini Ein Nachteil sei nicht verschwiegen: Der User grommunio darf damit alle Services starten und stoppen. Eine Beschränkung auf bestimmte Services wäre erst mit der moderneren PolicyKit Version möglich, die Debian aber nicht anbietet.

Hast du dazu meinen Pull-Request gesehen? Das war bis vor kurzem in den RPM-Paketen auch noch so. Keine Ahnung obs jemals ging.

weini Debian 11 nutzt wohl immer noch eine völlig veraltete polkit Version (nicht PolicyKit), die mit den "modernen" JavaScript Rules nichts anfangen kann.

Ja, leider! Freeze ist gerade angelaufen. Wir hoffen mal das so im Sommer dann Bookworm als "Stable" gilt.

@crpb Danke dir, den Pull Request hatte ich noch nicht gesehen. Der scheit aber umgesetzt zu sein, weil in meinem Appliance Docker Container genau diese Einschränkungen auf die Grommunio Services schon enthalten sind. Wenn du das Sicherheitsrisiko für vertretbar hältst, dann kannst du die pkla Datei ja in das Debian Install Skript mit aufnehmen.

Vielleicht sollte man erstmal hiermit arbeiten

root@grom-deb:~# cat /etc/sudoers.d/grommunio-sudo
# Allow grommunio user to execute specific commands as root
grommunio       ALL = NOPASSWD: /usr/sbin/postconf, /usr/sbin/postsuper

# Allow Systemctl-Calls
Cmnd_Alias      SVC_POSTFIX = /usr/bin/systemctl stop postfix.service, /usr/bin/systemctl start postfix.service, /usr/bin/systemctl restart postfix.service
grommunio       ALL = NOPASSWD:SVC_POSTFIX

und dementsprechend die dbconf mit sudo erweitern....

grommunio-admin dbconf set grommunio-dbconf postfix commit_service "$(grommunio-admin dbconf get grommunio-dbconf postfix commit_service |sed 's/.*=systemctl/sudo systemctl/')"

Das ist nun ungetestet weil ich eh noch nie wirklich was via Webgui/API an postfix geändert habe.

Das kann man natürlich erweitern wie man möchte..

Und wie ich das so schreibe fällt mir ja auf das dies nur für Postfix-Krempel gilt und ich glaube nirgends den Befehl den die grommunio-admin-api auslöst um Dienste neu zu starten/stoppen/wasauchimmer via Konfiguration anpassen kann und hier wieder in den gelieferten Dateien rumschreiben müsste was einfach nicht viel bringt da es eh wieder überschrieben wird beim nächsten Update...

Das ganze läuft über services/systemd.py und wie man sieht ist hier der Aufruf fest geschrieben. Wenn man jetzt ganz gewieft wäre könnten wir uns ein Skript in bspw. /usr/local/bin ablegen mit dem namen systemctl in dem einfach nur drin steht sudo systemctl und dann sollte er das theoretisch auch machen... Benutzer root wird sich nicht großartig dafür interessieren und da wir eigtl. keine anderen Benutzer haben die womöglich systemctl --user ausführen wollen kann es uns also schnurz sein.
Das ist jetzt nur Theorie da ich es nicht ausprobiert habe ob der $PATH auch genauso im Dienst ankommt wie in der Konsole. Andernfalls hieße es nun systemctl edit grommunio-admin-api.service und man passe die temp. Datei im $EDITOR beispielhaft so an...

### Editing /etc/systemd/system/grommunio-admin-api.service.d/override.conf
### Anything between here and the comment below will become the new contents of the file

[Service]
Environment="PATH=/usr/local/bin:/usr/bin:/bin"

### Lines below this comment will be discarded
......

Du siehst, ich würde eher den Umweg wählen als das die Freischein-Policy "Standard" zu implementieren

Also oben die /etc/sudoers.de/grommunio erweitern um alle geforderten "Befehle" dann einen sudo-systemctl-wrapper hineinfuddeln und evtl. die .service mittels override den Suchpfad erweitern.

Und nun nachdem ich noch mal ne Stunde was anderes gemacht habe fällt mir nun ein das die Idee mit dem "Wrapper" so Blödsinn ist da wir damit das selbe erreichen wie mit der Policy.
Also müsste man hier ein Skript schreiben welches alle systemctl-aufrufe schon deklariert hat und diese mittels getopts oder halt if $1.. $2 .. $3 prüfen ob das was man da machen will auch definitiv erlaubt ist...

Ich sage jetzt einfach mal ich lass es erstmal so stehen. Vielleicht erweitern wir einfach die README mit der möglichen Lösung wenn es für jemanden annehmbar ist soll diese Person es selbst so konfigurieren mittels deinem Vorschlag:

weini /etc/polkit-1/localauthority/50-local.d/manage-units.pkla

Und das schicke ich nun so ab damit man auch den kompletten Gedankenfurz versteht warum wieso weshalb..

Im Prinzip sollte man das natürlich auch via sudoers abfackeln können.
Bist du sicher, dass es dafür übehaupt einen Wrapper braucht? Normalerweise sollte es doch damit getan sein, die systemctl-Aurufe in der identischen Syntax in die /etc/sudoers aufzunehmen, wie sie vom Admin-UI abgesetzt werden.

weini Da gibt es vermutlich eine einfacher Lösung, 2 Dateien anlegen:
/etc/grommunio-admin-api/conf.d/01-services.yamlmit Inhalt

options:
  dashboard:
    services: 0

und
/etc/grommunio-admin-api/conf.d/02-services.yamlmit Inhalt

options:
  dashboard:
    services:
      - unit: gromox-antispam.service
      - unit: gromox-delivery.service
      - unit: gromox-event.service
      - unit: gromox-http.service
      - unit: gromox-imap.service
      - unit: gromox-midb.service
      - unit: gromox-pop3.service
      - unit: gromox-delivery-queue.service
      - unit: gromox-timer.service
      - unit: gromox-zcore.service
      - unit: nginx.service
      - unit: php7.4-fpm.service
      - unit: postfix.service
      - unit: redis-server.service

Dann grommunio-admin-api restarten:
systemctl restart grommunio-admin-api und Browser reloaden, sollte das Problem beheben.
Die Einrückungen sind wichtig, das sind yaml Dateien.
User und Gruppe root:root.

Bitte testen und bitte um Rückmeldung ob das hilft?

Habe es getested.
Ich habe deine beiden Dateien in /etc/grommunio-admin-api/conf.d erstellt und grommunio-admin-api.service neu gestartet.

Sobald ich die /etc/polkit-1/localauthority/50-local.d/manage-units.pkla wieder rausnehme oder umbenenne und polkit.service restarte, kann ich die Services nicht mehr über das Admin Web UI starten/stoppen etc. Das finde ich auch logisch, weil durch die yaml Dateien ja nur konfiguriert wird, welche Dienste im Admin UI erscheinen, aber nichts an den Berechtigungen konfiguriert wird.

Ich hatte auch schon mit den yaml Dateien herumgespielt und damit weitere Services aufgenommen. Der Trick mit der 01... yaml zum Deaktivieren der "eingebauten" Services hat mir aber noch gefehlt, 1000 Dank!

Jetzt versuche ich noch, das Logging zu konfigurieren. Müssen die Logs immer in Dateien vorliegen oder kann man das auch auf journald "verbiegen"?
Weisst du, wie man in der oberen Icon-Leiste im Admin UI den Link für rspamd aktivert bekommt?

Also den Link auf rspam in der Admin UI kann man durch folgenden Eintrag in /etc/grommunio-admin-common/config.json setzen, das habe ich jetzt im Source nachvollzogen:
"rspamdWebAddress": "https://server-name:8443/antispam"

@mwilliams: Das fehlt noch in der Doku. Sämtliche anderen Links sind beschrieben, nur der Rspam fehlt (Manual Installation)

Hier sind die üblichen Verdächtigen aus der config.json:
https://github.com/grommunio/admin-web/blob/master/src/components/TopBar.js#L148

Hi everybody,
it is some time when I saw debian installatin script at last time. There are many changes. Good work guys.
I would like to install newer test server today so I refresh script and try to use it, but it does not work I spent some time with debuging. Installation menus are nice thing, but I do not like it because not seen what is happen below "motorhaube". At this time it was first trouble. Menus hide this message:

and installation necessary packages crashed. Script goes forward, but ....
Second problem I discovered is missing package wget at necessary package list. When is not installed in system setup_repo cannot download keyring and installation crash at second time at repository check.
When I repared that next message appears (again hidden by nice menu layout):

Package system-user-groweb is a virtual package provided by:
system-user-grommunio 3-1
grommunio-web 3.1.184. ...
You should explicitly select one to install.

E: Package system-user-groweb has no installation candidate

• Operation completed

I checked repo, system-user-groweb really not in. Both other packages are in repo, but when I remove system-user-groweb from packages list, apt has problem with dependences. So installation crash again.

Can someone tell me which packages are correct for installation? Rest of the script I did not test. I stucked here
Thank you very much for any help information.

P.S.
I do not realy say the menu layout is bad idea, I just would like to show when something unpredictable happen, it is not seen and for someone who cannot debug script could be confusing. Installation is finished, no errors was seen, but many packages are not installed and configured. And log in /var/log/ I discovered during script debuging too. May be better place will be in installation directory. But it is only my opinion.

ladas
Hello everyone,

the same behavior of the grommunio-web with me here. Last week I could still use the script.

Danke für die Arbeit der letzten Monate. :

the package system-user-groweb is obsolete and was removed. grommunio-web should contain the groweb user.

WalterH
Just tried to remove my system-user-groweb, but this would implicitly remove also grommunio-web.
I checked and there is no newer grommunio-web available, then the one I have installed.

weini I opened a ticket for this issue.

Thanks for the Reports. Maybe i get to look at it later.

ladas but I do not like it because not seen what is happen below "motorhaube".

I know exactly what you mean .
I was thinking of doing some work to be able to supply all necessary Options via getopts or smth alike but haven't gotten around to it .

ladas missing package wget at necessary package

I guess this was because most users are installing the "standard-utils".
Even my preseed-file has that in the "d-i pkgsel/include string" list so i haven't had the issue with my "minimal" setups

crpb
There are more possibilities, how to do it I liked the version with varibles at the beggining of the script. It was clear and easy.
But other good way could be read all necessary variables by dialog windows at the beginning and after that run installation in visible mode.

About wget: I use for my servers debian minimal install (cca 0.8 GB). There is not even man in it All I need I install for actual purpose. It is not so much work and system is light and clear.

I forgot report other mistake in the script. After installation is missing directory /etc/grommunio-common/nginx/. After certificate generation at line 444 there is created file ssl_certificate.conf in this directory. As directory is missing, file is not created and at the end nginx not start. When I added line: mkdir -p /etc/grommunio-common/nginx/ before configuration file creation it start to work.