I just did an ISO-Installation for tests this morning.
Only thing i had to do was an zypper modifyrepo --disable repo-backports-update and zypper in -y open-vm-tools so far. However i only use core and only test something else if i'm really bored....

I also opened an ticket because the OVA-Image does not align with the configured Repositorys in the ISO. Meaning that the OVA-Image sadly still uses a few 15.3 Repositorys.

For this "2021.05.2" the Package grommunio-release-$NUMBER is responsible to my knowledge.
What are your current Package-Versions?
rpm -qa *grom*

  • tf91 replied to this.

    Is it not possible to choose another way than zypper dup?

    I have experienced that for a first installation it is best to use only the ISO and not the OVA, without any update during their installation. What if the same method is used for an existing installation, installing the v2022.12.1 over the v2022.05.x?

    Or would there be a way to do a fresh install for as major upgrade and then reliably migrate all user data from install to install, it means from v2022.05.x to v2022.12.1?

    What I read here about zypper dup seems not process safe (!)

    • crpb replied to this.

      Andy Or would there be a way to do a fresh install for as major upgrade and then reliably migrate all user data from install to install, it means from v2022.05.x to v2022.12.1?

      The reliable way is your Backup and Recovery strategy 😛.
      It isn't that much what you need to do.

      My and others Notes about it here which i've basically done now a couple times..
      https://community.grommunio.com/d/307-mailbox-backup/5

      zypper dup is the way of doing an System-Upgrade in Suse. No way around it AFAIK..

      OK. On the linked page I have seen the Restore way and what is the process for the Backup?

      My way of backing up is stated directly above.

      Sorry, I can't read anything from it, I'm not enough of an expert, so it's all unsure for me. Something like a summary is missing. It would be good if there was a kind of script of function for "normal users", or even better, a function in the admin "Save" and "Restore".

      Backing up two directories completely and restoring them completely on the new installation is not the issue.

      /etc/gromox/
      /var/lib/gromox/

      Then backup and restore the databases. I can't do anything with the shown restore sequence at "MYSQL-DB zurückspielen". Could I use it 1:1? Etc. and so on. You can see that these operations cause headaches for the not so experienced users.

      • crpb replied to this.

        I still have "Write a decent Backup-And-Restore-Utility in XYZ" on my ToDo but hadn't had the time for it ☹️.

        You should definitely read this to get a Basic understanding and maybe think about how you could integrate an Backup which fits your needs.
        https://docs.grommunio.com/admin/operations.html#backup-disaster-recovery

        A VM-Snapshot can't be considered as an real backup.
        It doesn't matter about which Software we are talking.

        Just think about when you only want to restore Mailbox A but not B-Z...
        Yes there is stuff like Mailstore/Benno/Whateverelse which i also use but this isn't working for e.g. Contacts or the Calendar.
        For those i got an Script from another Community-User here which i haven't even came around to publish or integrate in my Systems. Notes and Tasks aren't covered with these either.

        Andy I can't do anything with the shown restore sequence at "MYSQL-DB zurückspielen".

        Take a look into the File /etc/gromox/mysql_adaptor.cfg

        eval `sed 's/ //g' /etc/gromox/mysql_adaptor.cfg`

        and after the Command you can do something like echo $mysql_username in the Shell.

        But you can do those just manually like the Link states.
        The eval-Command will basically do the same as if you would have done by cat /etc/gromox/mysql_adaptor.cfg and copy/pasted this output in the same console. Note that eval can be considered "BAD" in many cases. But there is enough about that in the Internet.
        Because i know which content it has i do that w/o worrying about it in any way.
        And that's enough for now.

        I run production and test VM's on Synology NAS. For backup & disaster recovery, I have the option there to export the shutdown VM and import it if necessary. For intermediate steps before updates I create snapshots. I use both of these on a regular basis.

        However, when reading the contents of the linked Backup & Disaster Recovery website, I have doubts that such a backup is suitable for simply restoring after a major upgrade. What I read there rather leaves the impression to create a backup, which can be easily restored in a version clean installation, so I could do that with the above mentioned exports and snapshots. But our topic is something different because of major version jumps.

        For example, if I have a directory in an installation that contains the complete setting and user data and only that, it is very easy to bridge a major version jump, because I copy the directory into the new installation and it runs as before. If the MariaDB would be the database that controls and maps everything, it would be a further simplification, because then the content could be transferred easily via a transfer script.

        Now then, these are thought experiments for a simple handling of such upgrades. From the current point of view, I would not consider any of the given ways as applicable and safe. Maybe the easiest way could be to transfer user data between two running installations via a command sequence.

        crpb
        My current package versions:
        grommunio:~ # rpm -qa *grom*
        system-user-gromox-2-lp153.13.1.noarch
        grommunio-setup-1.0.68.bb1014d-lp153.7.1.noarch
        gromox-debuginfo-2.1.3.cb51757-lp153.54.1.x86_64
        grommunio-antispam-3.4-lp153.2.1.x86_64
        grommunio-admin-api-1.9.26.d9367fd-lp153.45.1.noarch
        grommunio-common-10.e94d08a-lp153.7.1.x86_64
        grommunio-release-2022.05.2-lp153.2.1.x86_64
        grommunio-cui-1.0.239.ad62461-lp153.44.1.noarch
        grommunio-chat-6.2.2-lp153.2.1.x86_64
        grommunio-index-0.1.16.e01e06c-lp153.23.1.x86_64
        grommunio-web-3.1.182.52d9180-lp153.139.1.noarch
        grommunio-jicofo-2.0.5390-lp153.12.4.noarch
        grommunio-imapsync-2.200-lp153.4.1.noarch
        systemd-presets-branding-grommunio-2022.12-lp153.1.1.noarch
        system-user-grommunio-2-lp153.11.1.noarch
        grommunio-keycloak-20.0.2-lp153.18.1.noarch
        grommunio-auth-21.c8473e9-lp153.12.1.noarch
        gromox-2.1.3.cb51757-lp153.54.1.x86_64
        grommunio-sync-1.1.55-lp153.61.1.noarch
        grommunio-files-10.9.1-lp153.17.1.noarch
        grommunio-error-pages-1.0.6.9c50afb-lp153.7.1.noarch
        grommunio-admin-web-2.6.0.33.45689ef-lp153.31.1.noarch
        grommunio-dav-1.1.33.a126414-lp153.1.1.noarch
        plymouth-theme-grommunio-1-lp153.11.4.noarch
        gromox-debugsource-2.1.3.cb51757-lp153.54.1.x86_64
        grub2-theme-grommunio-1-lp153.11.4.noarch
        grommunio-videobridge-2.1.508-lp153.16.4.noarch
        grommunio-admin-common-6.cb985db-lp153.14.1.noarch

        I tried to "upgrade" (= zypper dup) my GRO. Which was a bad idea. It totally messed up my GRO. System had problems each and every day. I'd to do a fresh install. Now I only use the "zypper ref && zypper up" command. Still kind of curious whether someone already upgraded the GRO successfully?

        Is there any other command, skript or readme on how to upgrade a GRO properly? I will need to upgrade my GRO when the new Q1/2023 release with full ews support for macos is out.

        Will I have to do a full, manual (new) installtion and then restore the email accounts and data (I saved them via outlook as pst-files and later restored them)?

        Or ist there a way to "just" do a full new installation in a 2nd VM and then use a skript to transfer settings (i.e. main.cf, master.cf, sasl_password, etc.) email accounts and data via a skript?

          In a fresh installation there is the same dependency problem. This lines come from a fresh appliance installation with core, meet and files (grommunio-setup.log).

          Paketabhängigkeiten werden aufgelöst...
          
          Problem: das zu installierende grommunio-files-10.9.1-lp154.1.1.noarch erfordert 'php7-smbclient', aber diese Anforderung kann nicht bereitgestellt werden
            Nicht installierbare Anbieter: php7-smbclient-1.0.0-bp154.1.67.x86_64[base]
           Lösung 1: Folgende Aktionen werden ausgeführt:
            Deinstallation von php8-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-zlib-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-zip-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-xmlwriter-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-xmlreader-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-sysvshm-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-sqlite-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-sodium-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-soap-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-posix-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-pdo-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-pcntl-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-openssl-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-opcache-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-mysql-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-mbstring-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-iconv-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-gettext-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-gd-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-fpm-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-dom-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-curl-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-ctype-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-cli-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-bcmath-8.0.27-150400.4.23.1.x86_64
            Deinstallation von php8-redis-5.3.7-lp154.1.1.x86_64
            Deinstallation von grommunio-sync-1.1.62-lp154.75.1.noarch
            Deinstallation von grommunio-web-3.1.197.c7957cc-lp154.157.1.noarch
            Deinstallation von grommunio-dav-1.1.37.d5b6463-lp154.10.1.noarch
            Deinstallation von gromox-2.2.140.7f3e6a0-lp154.112.1.x86_64
            Deinstallation von patterns-grommunio-1-lp154.8.1.x86_64
           Lösung 2: grommunio-files-10.9.1-lp154.1.1.noarch nicht installieren
           Lösung 3: grommunio-files-10.9.1-lp154.1.1.noarch durch Ignorieren einiger Abhängigkeiten brechen
          
          Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/3/a/d/?] (a): a
          2023-02-03 11:18:06 ::  Dialog: mysql installation type
          2023-02-03 11:18:12 ::  Selected MySQL installation type: 1

          Perhaps on weekend I have the time to test a restore.

          4 days later

          In the meantime I learned that the files-plugin is still based on php7. So I will wait until all modules are converted to php8 before updating.

          • Andy replied to this.
            7 days later

            Just did an upgrade at our internal System.
            Everything seems to be in order expect a few errors in nginx-web-error.log about fastcgi but i couldn't find anything not working so i will wait for the Support what that might be..

            DAV works again!++++

            vdirsyncer works

              BusinessTux all modules

              I have no idea where are the modules to configure. Is there a special modules folder?

              crpb
              Did you uprade your 15.3 appliance to 15.4?
              If so, what were your steps to upgrade. I'm still waiting since weeks for the promised instructions here in the forum, but there are no news around this. So I am still on 2205.02.

              Work in Pro.. Upgrade

              You might want to look at Update form Open SuSE 15.3 to 15.4

              Update the Repositories

              sed -i 's/15.3/15.4/g' /etc/zypp/repos.d/*
              zypper --verbose refresh

              Then it got icky because of the PHP-Change and packages which made a fuzz'.
              First Update just gromox which will take care of Package-Problems.
              The question from zypper should be answered as "Uninstall all PHP7 Packages"

              Take care of PHP..

              zypper update gromox

              The actual Distupgrade

              zypper dup

              I basically got through all "Warnings" by always choosing the option to remove the PHP7-Package..
              Be aware that the Number changes!

              I guess i should just have uninstalled the problematic packages before the zypper dup but about 10-15 Questions later i was already upgrading :-).

              Enable PHP-FPM

              mv /etc/php8/fpm/php-fpm.conf.default /etc/php8/fpm/php-fpm.conf
              systemctl enable php-fpm.service
              reboot

              I did that mv much later after trying to determine what's wrong... but now i know that, i just should have done so from the start.. "Lucky you!"

              Eventually reinstall missing Packages...

              If the Package grommunio-index didn't make it. (This might happen because of the PKG grommunio [1])

              zypper install -y grommunio-index
              rm -Rf /var/lib/grommunio-web/sqlite-index/*
              systemctl start grommunio-index.service

              I think this was all...

              Here is my /var/log/zypp/history so you might see what will happen.

              And FWIW: I'm using the Supported REPO!!!

              EDIT: Added systemctl-call.
              EDIT: index
              EDIT: zypper update gromox after Release-Code-Change

              Successfully upgraded: 3

              [1] zypper info --requires grommunio

              Thank you!
              I'll give it a try with a clone of my community version and post the results.

              @crpb

              I works for me, with your last post.
              after the reboot php-fpm seems to be disabled and not running. There was a 502 Gateway message in the user-web-gui. Admin-web-gui works. In that i enabled php-fpm. At last everything is working now.

              I've seen it in the history but wasn't sure if i was just doing nonsense at that moment :-).
              That is an SuSe/Redhat-Behavior(not automatically enabling the Services)
              In Debian the service is automatically enabled (which i might not want always but that's what it is..)

              You can see that with systemctl list-unit-files --target enabled, it will look quite different depending on the OS

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