Und noch ein soooo ... der archiver läuft jetzt auch vollständig .... allerdings noch auf Sphinx 2.2.11 - Frage wäre, ob es nicht von Interesse ist, das ganze auf Sphinx 3.1.4 lauffähig zu bekommen ... Es gab jetzt dann wohl vorgestern nochmal ein kleines Update der Archiver package für Debian, das muss ich dann nochmal updaten ..

Nach dem fixen des üblichen Berechtigungs- und User Themas hat im wesentlichen den Durchbruch eine Ergänzung der config-site.php gebracht:

Über $config['LOG_LEVEL'] = DEBUG;

erzeugt man im /var/log/mail.log nette Ausgaben über die vom archiver-webui an searchd gestellten queries

Darauf wurde dann sichtbar, dass einer der Queries auf einen Fehler gelaufen ist:

Nov 13 11:31:49 localhost piler-webui[132299]: index dailydelta1,delta1,main1: query error: no field 'from' found in schema
Nov 13 11:31:49 localhost piler-webui[132299]: sphinx query: 'SELECT id FROM main1,dailydelta1,delta1 WHERE MATCH(' ( (@from user1XmydomainXxx ) | (@to user1XmydomainXxx ) ) ') ORDER BY `sent` DESC LIMIT 0,20 OPTION max_matches=1000' in 0.00 s, 0 hits, 0 total found

Ich hatte zwar in einem anderen Thread gelesen, dass
$config['SPHINX_STRICT_SCHEMA'] = 0;
zu setzen sei, allerdings kann ich den Archiver nur zum laufen bekommen, wenn das auf 1 steht.

Nu funzt der Archiver jedenfalls auch auf Debian 11

Ich denke das problem ist, dass Piler (wozu ja auch Sphinx gehört) glaube ich sehr in Richtung paid version umgeschwungen ist. Die Community Seite scheint mir recht ungepflegt zu sein. Ggf, gibts da lizenztechnisch Problem warum das noch auf der alten Version läuft. Wäre aber nur ne Vermutung. Danke dass du das schon mal durchprobiert hast. Macht ja zumindest Hoffnung dass man das zeitnah auch "automatisiert" lauffähig bekommt.

    eryx
    Ich bin gerne bereit die Erfahrungen aus grommunio-antispam, grommunio-index und grommunio-archiver für Debian zu teilen, aber wie ist das hier organisiert? Gibts für so was ein zentrales git repo?

    Im Moment ist das Debian Thema mit viel manueller Frickelei verbunden. Welches Ziel ist denn am Ende für grommunio Debian dahinter? Was soll entstehen? Debian Appliance, gepflegtes Repo von Debian packages? Lose Scriptsammlung? Satz von Howtos?

    Im Fall vom Archiver und Piler: die letzte runterladbare (Community) Version ist 3.4.1 aber die ist auch schon von 2021. Ist das dann die richtige Basis für den Archiver einer neuen Kollaboration Appliance?

    Br br

    Gute Frage, kann ich dir ehrlich nichts sagen. Bin auch nur Anwender ;-)

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

    2 months later

    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)

            weini Wo im Source hast Du das gefunden, kannst Du den Link posten?

            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.

                  © 2020-2024 grommunio GmbH. All rights reserved. | https://grommunio.com | Data Protection | Legal notice