SMG 24.3 on a new sles15sp5 server

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

i had instal a new sles15sp5 with the documented applications, then do the changes for postgres database, install smg and then configure it.

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

Refreshing service 'Basesystem_Module_15_SP5_x86_64'.
Refreshing service 'Python_3_Module_15_SP5_x86_64'.
Refreshing service 'SUSE_Linux_Enterprise_Server_15_SP5_x86_64'.
Refreshing service 'SUSE_Package_Hub_15_SP5_x86_64'.
Refreshing service 'Server_Applications_Module_15_SP5_x86_64'.
Refreshing service 'nu_novell_com'.
Loading repository data...
Reading installed packages...

The following 28 package updates will NOT be installed:
joe perl-CPAN-Changes perl-Cpanel-JSON-XS perl-File-Listing perl-HTML-Parser
perl-HTML-Tagset perl-HTTP-Cookies perl-HTTP-Daemon perl-HTTP-Date
perl-HTTP-Message perl-IO-HTML perl-IO-Socket-SSL perl-LWP-MediaTypes
perl-LWP-Protocol-https perl-Net-DBus perl-Net-HTTP perl-Net-SSLeay
perl-Term-ReadKey perl-Test-Pod perl-TimeDate perl-Try-Tiny perl-URI
perl-XML-Dumper perl-XML-Parser perl-libwww-perl vim vim-data vim-data-common
Nothing to do.

How can i solved the message "The followin 28 package updates will NOT be installed"

Bug or feature?

Thanks for sharing your experience!

cg

  • Suggested Answer

    0  
    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)?

    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.

    __________
    Kevin Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada

  • 0 in reply to   

    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?

  • 0   in reply to 
    do you have a uninstall.sh

    Uninstall SMG: zypper rm smg.

    Uninstall PHP: zypper rm php.

    there are many informations that not in the documentation

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

    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 Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada

  • 0 in reply to   

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

  • 0   in reply to 
    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." Rolling eyes

    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!

    __________
    Kevin Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada

  • 0 in reply to   

    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.

  • 0   in reply to 

    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)


    Use "Verified Answers" if your problem/issue has been solved!

  • 0   in reply to 
    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' ". Worried

    __________
    Kevin Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada

  • 0   in reply to   

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

  • 0   in reply to   

    Thank you, Pam!

    __________
    Kevin Boyle, 
    Knowledge Partner

    Calgary, Alberta, Canada