OpenText product name changes coming to the community soon! Learn more.

Related Tips & Info
Wikis - Page

SMG 24.3 Deployment Considerations

Kevin Boyle
 
2 Likes

SMG 24.3 Deployment Considerations

Available information

Secure Messaging Gateway 24.3 released today! (2024-07-24)

OpenText Secure Messaging Gateway 24.3: Recommended Software Update

opentext Product Support Lifecycle (Updated: SMG 23 extended from 2024-12 to 2025-7)

Secure Messaging Gateway 24.3 Administration Guide

Release notes: The half page document can be found in the SLD. There are four references to the 24.3 Administration Guide but it doesn’t even mention the OS platform requirements.

At this time there is a single thread in the discussions forum: SMG 24.3 on a new sles15sp5 server

Choose your OS

While the Release notes and the Administration Guide make no mention of a supported OS, we have been told what they are in a couple of webinars and in Pam’s announcement post. They are:

  • SLES 15 SP5
  • openSUSE LEAP 15.5
  • openSUSE LEAP 15.6

While these may be the supported OSs, nowhere have I seen it stated to what extent they are supported. I suspect support is limited to the SMG application itself when deployed on one of these OSs! If you want a fully supported OS, your only option is to deploy SLES 15 SP5 and purchase maintenance & support from SUSE.

At a bare minimum we need to be able to patch our OS. Patches are readily available for openSUSE LEAP and for SLES (if you have a SLES entitlement such as the one provide with GroupWise).

If you don’t want to purchase maintenance & support from SUSE for SLES and have no SLES entitlement your only option for a supported OS is openSUSE LEAP. Keep in mind that a SLES entitlement may only apply to a single deployment and may not be an option if your deployment requires multiple instances of SMG.

Should you decide to deploy openSUSE LEAP, Community support is available for free from SUSE. If you do encounter a Linux issue you are unable to resolve you have the option to purchase maintenance & support for SLES from SUSE and upgrade openSUSE LEAP to a fully supported SLES 15 SP5.

Configuration Options

The Administration Guide tells us that SMG is quite happy with the default partitioning provided by either SLES or openSUSE LEAP and suggests we just accept it but are free to modify it should we choose to do so. While SMG may be quite happy with the defaults, do they really meet our needs?

When we deployed the SMG appliance, we had little control over the internal configuration. If there were issues, and we had current maintenance, we just opened a case with OpenText. Things are quite different now: We are responsible for maintaining the OS and are responsible for the configuration decisions we make. We want our deployment(s) to be stable, reliable, easily maintained, and provide adequate performance. The configuration options we choose will determine this.

Storage Requirements

When the SMG appliance is deployed, it is configured with 120 GB of storage. This is also the recommended storage when deploying 24.3.

The 24.3 Administration Guide provides this additional information:

Keep in mind, if you are deploying multiple SMG instances, the storage requirement for each instance will depend on the functions it will perform.

Partitioning Requirements

The default partitioning provided by both SLES and openSUSE is a single BTRFS root (/) partition with a SWAP partition at the end of the disk. SMG is quite happy with this configuration but to what extent does it meet our deployment objectives?

Appliance Partitioning

To make intelligent decisions regarding partitioning, we have to understand how and where SMG stores its data but there is limited information available. Let’s look at how the appliance does it.

Things to note:

  • This is my production SMG deployment.It is a single appliance. After four years I am using less than 15 GB of the 120 GB configured storage.
  • /dev/sda1, /dev/sdb1, & /dev/sdc1 all use EXT3 filesystem.
  • /dev/sdb1 is mounted at /vastorage where the majority of the SMG data is stored.

With /dev/sdb1 mounted at /vastorage, the majority of the SMG data resides on /dev/sdb1.

  • This may provide some performance benefits with SMG data on its own device using a dedicated storage adapter.
  • As SMG data increases over time, it is easy to provide additional storage by increasing the size of /dev/sdb1.
  • As SMG data increases over time, the root partition is protected from the SMG data exhausting all available free space which could have a disastrous result.

I don’t know why /var storage is also assigned to a dedicated device but I suspect it is to constrain the amount of storage consumed by log files.

SMG 24.3 Partitioning

I must ask: Shouldn’t we give the same consideration to our SMG 23.4 deployments as was given to the appliance deployments especially considering that we are now responsible for the maintenance and management of the platform we deploy?

I must point out that storage locations have changed from what they were on the appliance. The 24.3 Administration Guide provides this additional information: “(Optional) By default, SMG is installed to /opt/opentext/smg. If you want to install SMG to a different physical storage location, create a mount point for /opt/opentext/smg to the desired location.”

  • On my appliance, my Postgres database(s) reside at /vastorage/postgres/data.
  • On my beta install of SMG 24.3, my Postgres database(s) reside at /var/lib/pgsql/data.

Choosing an Appropriate Filesystem.

The choice of an appropriate filesystem depends on a number of (sometimes conflicting) factors.  By deploying different devices for different content, we are better able configure an appropriate filesystem based on the data stored on each device.

While I’m aware that BTRFS is not used for deployments of eDirectory nor GroupWise, I was wondering if there were any guidelines on the best filesystem to use with Postgres. As I began researching this I discovered this very detailed assessment:
Postgres vs. File Systems: A Performance Comparison

Ultimately, you have to decide what’s best for you!

If you have additional information to help with a deployment, feel free to include it below. If you have questions or want to express your point of view, that is best done in the SMG discussion forum.

I have started a thread for that purpose: SMG 24.3 Deployment Considerations discussion thread.

Labels:

How To-Best Practice
New Release-Feature
Comment List

  • Kevin, the major problem is to configure postgres, this is not completly in the documentation, and not in your description. Many administrators are investigate many times to find this command or find this solution:

    1. Configure postgres
    Let’s see together:
    cgcs-smg:/ # su - postgres
    postgres@cgcs-smg:->
    psql
    psql (15.7)
    Type "help" for help.
    postgres=# CREATE ROLE root WITH SUPERUSER LOGIN;
    CREATE ROLE
    postgres=# CREATE DATABASE root;
    CREATE DATABASE
    postgres=# \q
    postgres@cgcs-smg:~$ exit
    logout
    -------------------------------------------
    Let’s login with root again:
    cgcs-smg:/ # psql
    psql (15.7)
    Type "help" for help.
    root=#
    2. Changing/Configuring postgresql.conf
    In order to fix this issue we need to find postgresql.conf. In different system’s it is located at different place. I usually search for it.
    $ find / -name "postgresql.conf"
    /var/lib/pgsql/data/postgresql.conf
    Open postgresql.conf file and replace line
    listen_addresses = 'localhost' with listen_addresses = '*'
    Now restart postgresql server with systemctl restart postgresql.service
    3. Changing/configuring pg_hba.conf
    $ psql -h 192.168.13.23 -U postgres
    psql: could not connect to server: Connection refused
    the server running on host "your-host-or-ip" and accepting
    TCP/IP connections on port 5432
    In order to fix it, open pg_hba.conf and add following entry at the very end.
    host all all 0.0.0.0/0 md5
    host all all ::/0 md5
    The second entry is for IPv6 network.
    Do not get confused by "md5" option mentioned above. All it means is that a password needs to be provided. If you want client to allow collection without providing any password then change "md5" to "trust" and that will allow connection unconditionally.
    Restart postgresql server with systemctl restart postgresql.service

    $ psql -h your-ip-address -U postgres
    Password for user postgres:
    psql (15.7)
    Type "help" for help.
    postgres=# \l
    You should be able to see list of databases.
    Now we are able to connect to postgresql server remotely.
    Please note that in the real world you should be using extra layer of security by using "iptables".
    After this, we can access the smg software to begin the configuration

    The writer of the documentaiton are not the programmers and since time not adminstrators or integrators!

    OT must be more carefull for this, the best is to give to novice the installation to do and see the result

Related
Recommended

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.