Andy Die spannende Frage ist wohl, von was das abhängt

Allerdings!

Die spannende Frage von was das wohl abhängt:

Das hört sich nach "FRICKLER-ARBEIT" an!

Um hier weiter zu kommen müssen zuerst folgende Fragen beantwortet werden:
Problem nur in der WEP-App, oder auch auf anderen Clients (Windows Outlook nativ, SmartClients wie iphones, androids etc via EAS) oder nur in der WEB-APP.
Problem unter welchem Browser, ggf unter welchen Betriebssystem
Problem unter welchem Zugriff (also über die FQND oder per nativer IP)
Problem welcher Installationstiefe (also lediglich Core oder mit welchen optionalen Plug-Ins)

und natürlich immer: Das Gromunio ist meldungs-aktuell in der richtigen/aktuellsten und funktionsgecheckten Version (Community / Suported) und es wurde danach auch prinzipiell rebooted.
Wenn diese Infos fließen kann ich ggf. versuchen mittels FRICKELEI Abhängigkeiten zu finden.
Ansonsten wird das Müßig da zwar einige aber nicht alle das Problem haben, 5 Meldungen sind bei meinem ansonsten funktionierenden System ehrlich mal gesagt nicht viele. Vielleicht 5 zuviel aber ansonsten scheinbar kein "großes Problem". ---- Ich beschwere mich auch nicht das dies und das in meiner Appliance primär nicht funktioniert weil ich sie um fail2ban erweitert habe, bei installationen ausserhalb der CoRE-Inhalte (also mit Files, Office oder sonstigem) empfehle ich grundsätzlich eine Supportet Version. Hier kann der Gro-Support besser helfen als diese Forum und er wird ja auch entsprechend finanziert!

F@H

Bei mir zeigt sich das Bild nur bei der WebAPP / DeskAPP.

In Outlook unter Windows und mit der Nine APP auf den Android-Smartphones gibt es keine Probleme mit der Suche, allerdings arbeite ich da jeweils und überall im Full-Cached-Modus. Im Non-Cached-Modus geht das bei Outlook bekanntlich generell nicht und auf meinen Smartdevices habe ich Non-Cached noch nie betrieben.

Im weiteren, in den von mir verwendeten Browsern Firefox, Chrome, Edge ist das Fehlerbild genau gleich und meine Erfahrung ist auch, wenn in der DeskAPP solche Effekte auftreten, macht der verwendete Browser keinen Unterschied. Ebenfalls keinen Unterschied macht die Verwendung der FQND oder IP. Bezüglich der Installation habe ich Core und alle Optionsmodule installiert. Allerdings war jene Installation, mit welcher diese Suche funktionierte, in gleicher Weise ausgestattet. Schliesslich, aktueller Updatestand und Reboots sind bei mir ohnehin schon Gewohnheit.

Ja, bei mir auch nur WebApp und DeskApp. Getestet mit Windows und Linux, Firefox und Chrome, mit IP und FQDN. Installiert ist nur Core ohne weitere Plugins in der Community-Version:
rpm -qi gromox | head -n 3 && echo "" && rpm -qa grom | sort
Name : gromox
Version : 2.21.29.g81a193a
Release : lp155.20.1

irgend etwas ist bei euch anders als bei mir!

Ich war heute mittag auf einen Kaffee bei der betreuten Nachbarschaft. Habe dort eine GRO-Community_Appliance geprüft und mit einem Update versehen. Also auch Suse 15.4 auf 15.5.
In der primären Version funktioniert die Suche. Nach allen Updates funktioniert die Suche in der WebApp nun auch unter der Version Suse 15.5. Die Basis war eine wirklich alte Kiste, niemals wurde auf dieser Kiste ein UPGRADE angestossen. Alle UPDATES erfolgten per ssh befehl oder über die WEB Admin GUI.

Aus dieser Erfahrung kann ich weiter keine grundlegende problematik bei Grommunio finden. Die Frickler Frage bleibt also was macht ihr anders als der Standart?

Ich habe jede Appliance seit Ende 2022 installiert und meine Daten entsprechend transferiert. Dadurch bestätigt sich für mich immer wieder, dass es ein Unterschied ist, ob ich eine Basis-Appliance betreibe, die bereits seit einiger Zeit installiert ist und laufend auf den neusten Stand gebracht wird, oder ich die gerade aktuelle Appliance installiere und mit dieser weiter arbeite. Wenn also in einer fortlaufend aktualisierten Appliance bei deren Installation irgendwelche Fehler oder fehlerhafte Konfigurationen eingeschlichen haben, werden diese nicht in allen Fällen durch Updates beseitigt, wohingegen mit einer neuen Appliance eine bereinigte Installation eingerichtet wird.

Ich konnte diesen Effekt bei Jitsi beobachten, was zwar wegen der Reverse-Proxy-Geschichte noch immer nicht läuft, aber dafür auf andere Weise nicht läuft. Oder nun die Geschichte mit der Suche. Ich kann mich erinnern, dass mit der vorherigen Appliance v2023.11.1, Build 14.2 vom 4.12.23 die Suche bei mir noch funktioniert hat. Hätte ich diese bis heute geupdatet, würde die Suche wohl noch gehen.

Ich kann mir das nur so erklären, dass die Konfliktbereinigung noch nicht richtig funktioniert, denn mit jeder Appliance-Installation bleiben am Ende bei einem Check mit zypper dub irgendwelche Ungereimtheiten mit installierten Paketversionen.

@Mister2
Thank you very much for your How-to. I made a first try But wasnt able to login to my Accounts on the new system. I had some warning when exporting the data from the old to the new system. You also had this? I also use ldap to Import the user accounts, maybe thats a problem.
I will try it again.

    Check the permissions in the directories and subdirectories to which you are transferring data (e.g. /var/lib/gromox/...), as these may no longer be correct after the transfer and it will then no longer be possible to log in.

    • tf91 replied to this.

      tf91 I don't use LDAP for my accounts, however, in point 1 of my process I mentioned that you should NOT creathttps://community.grommunio.com/d/1444-suchfunktion-in-webapp-deskapp-mit-fehlermeldunge the Organisation, Domain or Users, as the database imports to your new server (items 11-13 - only use 12 if you are using Grommunio Files) will do all this as per your existing (old) server.

      Looking back at my post and just to make sure this is not misinterpreted, I should have mentioned that the bold text in the various points, should be considered as a single line, not as 1 or more as it displays. ie in Item 6 you should highlight all the text from 'mysql' right through to (and including) 'done' as this is just one command sequence, it is a long command, hence my suggestion to copy and paste it. Also the 'root@192.168.xxx.xxx' bits in item 7 & 8 should be replaced with the account and IP address of your 'root' user on the new server.

      Hope your second/third test go a little better. The whole above process should be performed while logged in as the default 'root' user (on both servers) otherwise you might come across permissions errors during the export process.

      In item 9 I originally had chown -Rf grommunio:gromox /var/lib/gromox/user, but found that following the 11/23 new appliance ISO's that Grommunnio couldn't find my user directories after I had migrated the data. It seems there had been a slight change to the permissions in the appliance ISO and I had to set the permissions one directory higher. I built a fresh VM to check this, from the same appliance ISO, and using WinSCP found the permissions were different to my previous versions, so modified item 9 to its current form. Once I had made this change I have not had any other issues in the roughly 10 migrations I have done since with the above process.

      Hope the above helps.

      Andy Thank you.
      I did the change like in step 9. On my current grommunio its owned by gromox:gromox. Maybe because its an old appliance. The permissions are same. But it dont work with both owners.

      @Mister2 Yes of course, I did all like you described again 🙂
      I also didnt configured anything before.
      Second test cause the same problem. I will try a bit more.

        tf91 So, as I did when I had a similar problem.

        1. Create a new VM with the same appliance ISO you used to build your new VM (This should be considered as a TEST Machine only)
        2. Run the Setup Wizard as normal, unto the point you can log into the GUI
        3. Create and Test Organisation, and Domain (any thing will do - as its only a test)
        4. Create one new user manually. Grommunio will create the user directory in /var/lib/gromox/user.
        5. Use something like WINSCP on a Windows box (oe a suitable Linux equivalent tool that lets you look at the permissions Grommunio has set on your new users folder (probably /var/lib/gromox/user/0). With the permissions documented rerun the line in item 9 on your not working new server (not the test one) using the permissions you have just recorded, then reboot it.

        I do recall that I did have some issues initially getting the permissions to take on item 9, but as said in my previous post this was caused by me now having sufficient permission to the /var/lib/gromox/user folder, hence I applied the permission one folder higher (/var/lib/gromox) and this deployed the permissions correctly. Obviously once you have set the permission, check they have actually taken as intended, that is how I found that they had not taken at first.

        Mark

        tf91 When you were exporting the data from old to new (step 7) you mentioned you received some warnings. What were these as this is just a straight data copy using rsync. If you are using root on both servers warning s suggest you may have some permissions issues on your 'old' server preventing the files being copied.

        Mark

        @MisterG Thank you again for all youre advices. I Was able to make an Import and to login, after detach a Mail account and "change" password. There have to be a Problem about ldap. I will try a bit more again the next days.

        Though I expereinced still the problem in webapp search. Any news about this at someone here?

        I have found the problem of webapp search ("An unexpected error has occurred"), at least in my installation. The files created by grommunio-index.service in the folder /var/lib/grommunio-web/sqlite-index have the wrong permissions. After creating they are owned by user grommunio and group gromox. If I change the permissions to owner groweb and group groweb the websearch is working again.

          odo125 I have found the problem of webapp search ("An unexpected error has occurred"), at least in my installation. The files created by grommunio-index.service in the folder /var/lib/grommunio-web/sqlite-index have the wrong permissions. After creating they are owned by user grommunio and group gromox. If I change the permissions to owner groweb and group groweb the websearch is working again.

          I can confirm that. However, I had to adjust the rights of the index.sqlite3 file to: -rw-rw---- (0660). In order to show search-results, a re-indexing was necessary: grommunio-index -v -c -A

            Suchfunktion läuft wieder. ...

            Ohne vernünftigen Index gibt es auch keine Suche bei Web. Verbesserte Index-Berechtigungen sind teil eines kommenden Updates (Freitag release)

            Joerg

            I can confirm that you have also to change the rights of the index.sqlite2 file. A re-indexing was not necessary in my case.

            15 days later

            @Mister2
            Thank you again for all youre tips. Finally I got it to work, and it was a problem with LDAP .. and own dumbness.
            Though I still have problems since I can sync with ActiveSync. The log of grommunio_http says (for example)
            E-5320: link /var/lib/gromox/user/2/1/wOF374ChwQLrlsZQ -> /var/lib/gromox/user/2/1/cid/Y-0c/870769629a1bf375e95baac5723cdf: Permission denied
            I set all permissions in /var/lib/gromox/user as you described and also tried like it was set in a new created mailbox in the appliance. I dont know the issue.

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