Greiner Claude said:

The new version/Build of SMG must be installed on a sles15sp5 server or opensuse 15 sp5/sp6, there is no more a appliance.

You are correct. This is stated in the documentation but only openSUSE LEAP is supported.

What the documentation doesn't state specifically is that the Customer is now responsible for providing and maintaining the platform on which the SMG application is installed and runs. If you are using the SLES entitlement that is provided with GroupWise, it does not include support and the only support available with openSUSE is Community support.

So, what do we do when we encounter an issue like yours where SMG and Linux don't cooperate? Is it an SMG issue (Support can help) or a Linux issue (It's our problem)?

Greiner Claude said:

After installation and by the command "zypper up" i see the following message:

We have been told when patching a system we should use zypper patch, not zypper up which can install upgraded versions. SMG is supported on SLES 15 SP5. The documentation does not say it is supported on subsequence upgrades.

Hopefully, you took a snapshot before doing your zypper up. Can you revert to the snapshot and see if you encounter the same issue if you do zypper patch?

I installed SMG on openSUSE 15.5 then tried to upgrade to openSUSE 15.6 and encountered dependency issues. I learned that SMG has some hard coded dependencies in the application and to complete the upgrade I had to uninstall SMG, do the upgrade, then reinstall SMG.

The other thing I learned is that uninstalling SMG does not delete your configuration. After reinstalling SMG, the basic configuration I had remained intact.

do you have a uninstall.sh (script as for gms) or advice what is to do to uninstall smg and all other programs as postgres?

i don't find anythink for zypper patch in the documentation!

i found the documentation better then older docs, but there are many informations that not in the documentation for configuration of postgres

And why use opensuse and not sles15? Where are the advantage?

Greiner Claude said:

do you have a uninstall.sh

Uninstall SMG: zypper rm smg.

Uninstall PHP: zypper rm php.

Greiner Claude said:

there are many informations that not in the documentation

Yes, the documentation is better but it still needs lots of work.

Greiner Claude said:

And why use opensuse and not sles15?

My preference would be to use SLES if I had an entitlement (which I do). If I encounter issues which I cannot resolve, I can purchase support from SUSE.

Without an entitlement, I would have to purchase a license with maintenance/support from SUSE just to get the SLES patches.

There is no up front cost to deploying openSUSE LEAP, which is what is needed to run SMG. If I encounter issues which I cannot resolve either on my own or with help from the SUSE Community, I can purchase a SLES license with maintenance/support from SUSE and upgrade openSUSE LEAP to SLES with full support.

Kevin, the most problem will be the postgres databse with standard or own password. There is also many *.conf or *.cfg changed, many symlinks, etc

Yes, it will be good to do a snapshot or backup before installing smg, to be able to begin a new clean installation.

we as customer must reclaim that OT give us a full uninstall.sh file, as we found this in gms. The OT-Teams works differently and this may be not optimal for us.

we are on the front between OT and our customer and can only ask for our wishes and transmit our experience!

here directories/files found after smg24.3, but this will not be complete listing!!!

1. /etc/sudoers.d/smg
2. /opt/opentext/smg
3. /usr/bin/smg
4. /usr/liib/posgresql15
5. /usr/bin/postgres
6. /etc/alternatives/postgres
7. /etc/alternatives/psql
8. /usr/bin/psql
9. /usr/share/postgresql15
10. /usr/share/man/man1/psql.1pg15.gz
11. /usr/share/postgresql15/psqlrc.sample
12. /usr/lib/postgresql15/bin/psql
13. /usr/share/bash-completion/completions/psql
14. /usr/share/locale??/LC_MESSAGES/psql-15.mo

any files are changed from install.sh, other must be done manually as pg_hba.conf or postgresql.conf

have a nice day...

Greiner Claude said:

we as customer must reclaim that OT give us a full uninstall.sh file, as we found this in gms. The OT-Teams works differently and this may be not optimal for us.

Claude, you have to remember that for quite some time there has been no central support for the appliances so there will be differences how each product is implemented and supported. Unfortunately, for us, there is little or no public documentation on the internal workings. Now that SMG is being provided as an application, independant from the appliance, how other products behave and are supported on their appliances is completely irrelevant.

SMG enables the installation and removal of the application without impacting the SMG configuration or data. I like this approach! 

SMG also provides the ability to migrate an implementation to another platform, backup/restore the databases, and export/import policies & scan configurations. I suspect we will all become much more familiar with these capabilities than we did when SMG was distributed as an appliance.

We are now responsible for providing and maintaining the platform on which SMG runs, yes, but that means we are also responsible for the SMG installation too and all that implies. This raises the question, "Who is responsible for what?".

Here's how we were notified about the latest SMG release: OpenText Secure Messaging Gateway Administrator's Guide. It says (in part), "SMG v24.3 has been released and is in the downloads area of the SLD. This is our first non-appliance version. It is supported on SLES15SP5, openSUSE Leap 15.5 and openSUSE Leap 15.6."

Here is the Secure Messaging Gateway 24.3 Administration Guide. It is interesting to note that the Guide makes no mention of specific supported platforms. All I can find is this: "SMG is installed on a SLES 15 or openSUSE 15 server." 

Without further clarification, it would appear that when SMG is installed on a supported platform support may be limited to the application itself. There will definitely be a learning curve for all of us. I'm grateful that we have this forum where we can all share our experiences!

Are they really dropping the appliance-approach?

And what, if I absolutely do not want to bother with SLES-details again?

I want to get a working tool, not like a hammer, more like a chainsaw., to solve a complex problem.

This new approach feels like getting the tool in pieces, which have to be assembled to be usefull. This adds too much additional potential problems getting the required tool to work.

Looking at my learning-curve with SMG, which had to be solved by lots of trial and error, and looking into the future I start regretting that I took this tool.

The idea in the background is that appliances are a little bit slower to get the latest security patches. Some people have to test if security patches fit into the appliance environment. In recent days there were complaints that security patches have been too late ...

However I understand your point of view. Appliances are easier to handle and to run. (I think it was not an easy decision by development)

Karl67 said:

And what, if I absolutely do not want to bother with SLES-details again?

The appliance is still supported, for now. I don't believe an EOL date has yet been announced but, as Bob Dylan said, "The Times They Are A-Changin' ". 

Per the product lifecycle page at https://www.microfocus.com/productlifecycle/ - the appliance version of SMG has an EOL date of December 31, 2024

Thank you, Pam!