@Andrew
you should not modify the service file itself.
Instead please create this folder:

/etc/systemd/system/gromox-http.service.d/

and then create a file (e.g.)

sqlite.conf

with the content:

[Service]
Environment=LD_LIBRARY_PATH=/opt/grommunio/lib64

(or where you placed it in the first place)

    GeneralProbe systemctl edit doesn't change the original service file. It creates an override file that takes precedence over the contents of the service file. In this case it would create /etc/systemd/system/gromox-http.service.d/override.conf. It's essentially the same thing as your suggestion, but a more official/supported method of creating the file.

      @mwilliams I've applied the update but I'm still experiencing problems:

      Dec 10 18:33:02 midb[1145473]: sqlite3_exec(/var/lib/gromox/user/0/1/exmdb/midb.sqlite3) "UPDATE folders SET name=CONCAT('t',ROWID)": no such function: CONCAT (1) at [<libgromox_common.so.0(_ZN6gromox11gx_sql_execEP7sqlite3PKcj+0xa4) [0x7fc454a63258]><midb(+0x14e53) [0x5604e51cce53]><midb(+0x1604a) [0x5604e51ce04a]><midb(+0x16358) [0x5604e51ce358]><midb(+0xc97e) [0x5604e51c497e]><midb(+0xc9d7) [0x5604e51c49d7]><midb(+0xd058) [0x5604e51c5058]><libc.so.6(+0x89d22) [0x7fc454089d22]><libc.so.6(+0x10ed40) [0x7fc45410ed40]>]
      Maybe the imap error has something to do with german umlauts or ampersand in folder names. I have duplicate folders in the subscription list and greyed out folders in the current folder pane. All folders have umlauts or ampersand in its name.

      @mwilliams Sorrry, just noticed I've applied gromox-2.38.4 to my box - .5 seems not to be available in the repo. I'll update here after updating.

      @mwilliams gromox-2.38.5.g9866cfd-6 has been applied and the sqlite error doesn't get logged anymore. But I still have issues with IMAP folder containing umlauts and ampersand. Maybe a separate problem... What logs would help to analyze that issue if I file a bug on Github?

      5 days later

      Big thanks to the team at Grommunio for resolving the majority of these issues.
      The only one outstanding I believe now is the rogue load_module lines getting added to NGINX. I updated again last night and they got added back in, breaking NGINX once more. Deleting these lines (they're trying to load the modules from the original /usr/share/nginx/modules location but Grommunio moved them to /usr/lib64/nginx/modules) fixes it temporarily, but every time an update gets installs it re-adds the offending lines and breaks NGINX again.

      load_module modules/ngx_http_brotli_static_module.so;
load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_vhost_traffic_status_module.so;
      • crpb replied to this.
        7 days later

        FYI the NGINX config issue is still happening. I updated again last night and it re-added the bad config lines.

          Grommunio seems to ship an updated version of sqlite that breaks dnf.
          Anyone else affected?

          bye
          Daniel

            daniel just checked, and yes - DNF is broken on my machine after installing a version of SQLite from Grommunio. The offending package appears to be sqlite-libs. If I append --exclude=sqlite-libs then DNF commands succeed and I can install updates.

              @Andrew Yeah, I downgraded, too and it seems to work.
              I was afraid that the sqlite error above (missing CONCAT function) will be reintroduced again, but gromox still seems to use the old statements.

              Yesterday I created an issue on Github, if you'd like to follow:
              https://github.com/grommunio/gromox/issues/118

              5 days later

              Looks like the SQLite packages have been pulled from the Grommunio repo, but the current version of grommunio-index is dependent on them so dnf upgrade fails unless that package is excluded. I reverted back to the RHEL SQLite packages but started getting CONCAT errors and a crashing index, so I've went back to my workaround of compiling my own version of SQLite libraries, and applied the override to both the gromox-http and grommunio-index services.

              11 days later

              Installed latest updates. Seems like it's still breaking NGINX, and grommunio-index won't update because of a broken dependency on the deleted sqlite-libs package.

              Looks like the grommunio-index dependency is now fixed. I removed my custom SQLite override on the gromox-http and grommunio-index services yesterday and haven't had any issues so far.

              11 days later

              SQLite issues seem to be resolved, but the NGINX config is still getting mangled by updates

                Andrew but the NGINX config is still getting mangled by updates

                Please explain (with examples) what you mean with: but the NGINX config is still getting mangled by updates ?

                    • crpb

                    • Post #34

                    Andrew
                    The only one outstanding I believe now is the rogue load_module lines getting added to NGINX. I updated again last night and they got added back in, breaking NGINX once more. Deleting these lines (they're trying to load the modules from the original /usr/share/nginx/modules location but Grommunio moved them to /usr/lib64/nginx/modules) fixes it temporarily, but every time an update gets installs it re-adds the offending lines and breaks NGINX again.

                    > load_module modules/ngx_http_brotli_static_module.so;
> load_module modules/ngx_http_brotli_filter_module.so;
> load_module modules/ngx_http_vhost_traffic_status_module.so;

                    i believe they mean those which of course get reset by the packages config files.
                    can't you set some hook in DNF? to run like a sed over a file if it's beein updated by a package?

                      Are this modules installed on your system? I guess not and nginx refuses to load about missing modules.

                      If the grommunio developers wants theses modules, the system needs the modules. Try to install these modules and see what's happen?

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