bringha Ah verstehe. Tatsächlich ist das hier das Image meines Hosters. Keine Ahnung was der verwendet. Aber in der Tat ohne das wirds wohl nicht gehen. :-(

Gehen wir also das nächste Debian Thema an: grommunio-archive und das nette Programm 'indexer' (s.o.)

Hat jemand noch eine Idee oder Information, wie man zu dem Tool 'indexer' kommt, welches da in diversen scripts so locker verwendet wird?

... Beantworte ich mal selbst: grommunio-archive braucht das zusätzliche Paket 'sphinxsearch', da ist der drin ...

BR br

Ich glaube archive, files, meet und chat haben wir bisher nicht aufgenommen. wenn du für archive ne lösung hast wärs cool wenn du die hier zur Verfügung stellst oder bei grosser Lust als Pull Request gegen das Repo stellst :-)

wenn Ichs hinkriege natürlich gerne - aber das scheint kein Selbstläufer zu sein - ich bin mir nicht sicher wieviele grommunio-archive zB ausserhalb der appliance am laufen haben - gibt doch einige Beiträge im Forum dazu, die Schwierigkeiten beschreiben. Im Moment hänge ich an der Frage, dass ich gar kein Archive GUI hochbekomme (error 404). Auch habe ich fpm pools für archive, die nicht starten wollen...

Fragen über Fragen .....

Na ich werd die Tage auch mal schauen. Ich hab eher noch das Problem dass der indexer läuft und auch sagt er stellt den index neu her für mein Postfach aber finden tu ich nix in der WebApp. Aber ich denk ich bin nur zu doof 😅

Zur not einfach mal rm -rf /var/lib/grommunio-web/sqlite-index/* ; grommunio-index-run.sh

Das mag der manchmal ganz gerne. Vor allem nach Updates zu empfehlen da ja immer wieder was dran gemacht wird.

Danke! Probier ich morgen mal aus :-)

Ich bin jetzt genau auch an dem Punkt, dass ich eigentlich den Archiver auf Debian am laufen habe (piler, sphinx, piler-smtp in postfix, piler ui, vor allem aber die permissions schlacht mit 1001 workarounds bis zum nä update gewonnen habe) und er aber nix findet.

Irgendwie bekomme ich das Zusammenspiel zwischen sphinx.conf und config-site.php und dem installierten Datenbankschema noch nicht hin. In der mail.log ist, wenn man sich ins piler ui einlogged dann zB.

piler-webui[132298]: index dailydelta1,delta1,main1: query error: no field 'from' found in schema
piler-webui[132298]: sphinx query: 'SELECT id FROM main1,dailydelta1,delta1 WHERE MATCH(' ( (@from user1XmydomainXxx) | (@to user1XmydomainXxx) ) ') ORDER BYsentDESC LIMIT 0,20 OPTION max_matches=1000' in 0.00 s, 0 hits, 0 total found

Weiterhin: Obwohl piler-smtp behauptet, dass er mails sauber ins Archive schreibt und auch /var/lib/grommunio-archive/store ... sich füllt und auch die Indexe sich ändern (piler cron-jobs mit indexer) behauptet die Abfrage zB '0 total found'. Welche Version von Sphinx verwendet denn die Appliance? kann es sein dass das Schema zu einer anderen Version von Sphinx passt und nicht zu der relativ alten 2.12, die Debian installiert (sphinx hat mittlerweile 3.X)?

Any idea?
Br br

PS: irgendwie geht bei mir der Codeblock mit ```immer noch nicht: Wie genau ist denn die Syntax dazu? (:nerv)

Du machst die drei "```" in eine Zeile, in der nächsten fängt dein Codeblock an und nach dem Codeblock in einer neuen Zeile machst du dann wieder die Markierung ^_^

Soooo .... ich habe das Thema archiver im Moment mal zurückgestellt, da ich da nicht so wirklich weiter gekommen bin: der Archive store füllt sich, die Indexer laufen zwar aber irgendwie finden die nix und daher findet auch search nix ....

Stattdessen hab ich mich noch mal dem grommunio-antispam angenommen und aus den Susepaketen eine vollständig lauffähige Lösung gebastelt. Die wenigstens filtert jetzt auf Debian 11 zuverlässig SPAM und das GUI ist vollständig in das Grommunio admin GUI integriert und wird da auch angezeigt.

Die Änderungen sind allerdings beträchtlich und um da jetzt wieder ein lauffähigen Debian Paket draus zu bauen wäre etwas Hilfe nett, da ich kein Debian Paket Experte bin und ein paar zusätzliche Skripte integriert werden müssten.

Die wichtigsten Änderungen vorab:

  • Das Suse Paket enthält die binares von rspamd, die laufen so nicht auf Debian, habe ich ersetzt durch eine Standard rspamd Installation auf Debian; der rspamd-redirector ist da allerdings nicht dabei
  • Dann die /usr/share/grommunio-antispam, /etc/grommunio-antispam und /usr/lib/systemd/.../grommunio-antispam und /var/lib/grommunio-antispam Files kopiert und die Berechtigungen und user angelegt/adaptiert.
  • Dann müssen einige grommunio-admin-common files, Directories, Berechtigungen, rspamd config files etc angepasst werden, damit der Standard rspamd sauber integriert ist.
  • (...)
    Ich bin ja gerade erst dazugestoßen und habe ehrlich gesagt noch nicht den Mechanismus verstanden wie denn der Debian Pfad von grommunio maintained wird. Ist das vollständig hier in der Community? Macht grommunio das zentral (auf git? (wenn ja wo)?) Wie läuft die Interaktion dann? Gabs da schon mal wo anders einen Thread zu?

Br br

PS: Mein Lieblings"```" beschäftigt mich leider noch immer: Irgendwie geht das vom Mac aus noch nicht: Gebe ich 3 "```" auf einer Zeile ein und will dann auf der neuen Zeile den Code eingeben, bleiben in der Vorschau nur 2 `` (der dritte wird wieder gelöscht) stehen und der Code wird in Header Text Größe angezeigt - kein code block :-(

  • crpb replied to this.

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

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