GWME-7.2.1-00 Rollup Patch Installer

Overview

The Rollup Patch installer is a cumulative patch, and is a step closer to the "continuous deployment" method of updating. The patch installer is intended to be used independent of Technical bulletins, though some Technical Bulletins may depend upon the Rollup Patch already having been applied, and some of the code we supplied in Technical bulletins originally may be superseded in a given version of the Rollup Patch. Generally, we recommend applying the rollup patch first, then looking at the Technical bulletins and applying them as needed. The rollup only includes code, not data or configuration, and does no scripted updates, so for some things you will still need the Technical Bulletins, as they can apply scripted updates and make configuration changes.

The rollup patch installer does make database schema updates, so you will need to have a valid postgres user password for the database (see Prerequisites, below). It is not necessary to run the patch installer on a database-server-only installation of GroundWork.

Since it is a cumulative patch, you need only install the latest version - there is no need to install each version of it sequentially. The Rollup Patch Installer is also reversible - it makes a backup of everything it changes, and you can use a simple process to reverse the updates it makes.

If you install two or more sequential rollups and need to roll them back, simply apply the rollback scripts in the reverse order of the rollup patches.

If you installed patch 4111, there is an extra step. See below.
Prerequisites
Considerations

If you have several GroundWork servers in a parent-child configuration, you may run the rollup on any server in any order. Note that it will interrupt monitoring briefly when you apply or roll back.

Installation Steps
Name Size Creator Creation Date Comment  
File groundwork-7.2.2-gw4118-patch-insta... 255.17 MB Thomas Stocking Sep 20, 2019 15:17 MD5: 1cb6448b01ae333d780e0c2fa96e0d01  
You MUST have the postgres user password available before running this patch!
  1. Transfer the Rollup Patch installer to your GroundWork server, and place it in an empty directory.
  2. Log in to the command line on the GroundWork server and become root in that directory
  3. Type:
    chmod +x groundwork-7.2.2-gw4118-patch-install.run
    ./groundwork-7.2.2-gw4118-patch-install.run
    

    The installer will stop GroundWork services, ask for the db user password, then patch and restart the groundwork services.

Rollback Steps

Hopefully you will not need to roll the changes back. If you have any issue after the patch, please let GroundWork Support know as soon as you can. We do extensively test each change, and we do integration and system tests on each Rollup, but we recognize you may need to get back to where you were.

Note that no configuration files will be altered or rolled back, that is up to you to control. Also, when you install a patch, the previous patch state is saved in a directory under /usr/local/groundwork/backup-gwNNNN, where NNNN is the prior patch level. That's the directory you will use to roll back with this procedure.

  1. Log in to the command line on the GroundWork server and become root.
  2. Change to the backup directory, named for the prior patch level, e.g.:
    cd /usr/local/groundwork/backup-gw4114
    
  3. Execute the rollback script:
    ./restore-backup.sh
    

    You will once again need to provide the postgres user password.

Important Directives

Because this rollup patch does affect configuration files, in some cases you must make additions or edits in order to benefit from the new features and fixes in the patch. The following is a list of such edits you may want to make, depending upon how you use GroundWork, and whether you make use of a particular feature.

NOCBoard
  1. GWMON-13406 Window for NocBoard Query speed up
    File to edit:
    /usr/local/groundwork/config/foundation.properties
    

    These parameters denote the acceptable size of the search window in time, and affect how much data is cached.
    If you select a bigger period in NocBoard than you have set here, performance will suffer. Make sure the window size is right for your installation.

    ############################################################################
    # LogMessage Window Service Configuration
    ############################################################################
    logmessage.window.enabled=true
    logmessage.window.size.hours=24
    logmessage.window.update.interval.seconds=5
    

Changes to this file are effective after you restart GroundWork Services.

/etc/init.d/groundwork restart gwservices
LDAP Users
  1. GWMON-13447 Map LDAP groups to GW Roles (fixes for LDAP mapping issues)
    File to edit:
    /usr/local/groundwork/config/foundation.properties
    

Adding the ldap mapping enable parameter and the "|" or function on the roles container search term extends the places that GroundWork will look for users and role mappings. This can add significant redundancy to your authentication/authorization setup with LDAP or AD.

# Whether LDAP Mapper should be enabled
core.security.ldap.mapping_enabled = true
...
core.security.ldap.config.windows2012.roles_ctx_dn = ou=GWRoles,dc=company,dc=com|cn=other,dc=company,dc=com

File to edit:

/usr/local/groundwork/config/ldap-mapping-directives.properties

You can add the mapping of LDAP only groups to GW portal only groups, for example: "aga", "another aga", "ago", "agu", below.
Notice that a space in an LDAP group name requires the replacement of that space with the string "\u0020"

#Portal admin group mapping
GWRoot=gw-portal-administrator

#groundwork admin group mapping
GWAdmin=gw-monitoring-administrator

#Portal operator group mapping
GWOperator=gw-monitoring-operator

#Portal user group mapping
GWUser=gw-portal-user

agr=GWRoot
another\u0020aga=GWAdmin
ago=GWOperator
agu=GWUser

Changes to these files are effective after you restart GroundWork Services.

/etc/init.d/groundwork restart gwservices
  1. GWMON-13501 LDAP Group to Role equivalent recursive tour de mort fix.

You may use a notation for ldap mapping that sets GROUPNAME=GROUPNAME (where the ldap group and the GW role are identically spelled).

If You Installed Patch 4111

If you have installed patch 4111, which was briefly available, it contains a flaw that must be addressed with a command to correct table ownership. This is only necessary if you installed patch 4111. You can do this step at any time including before or after applying 4114 or 4118.
The symptom this is necessary comes to you as failure to do backups and a similar error when you try to do a build instance:

Backup error(s): Problem(s) backing up files and/or database to: 
/usr/local/groundwork/core/monarch/backup/2019-04-30_22-16-38/ 
Error: Got exit status 1 from backup command. 
pg_dump.bin: [archiver (db)] query failed: ERROR: permission denied for relation patch_4109_service_instance 
pg_dump.bin: [archiver (db)] query was: LOCK TABLE public.patch_4109_service_instance IN ACCESS SHARE MODE 

So to fix in place, as root, and with the knowledge of the postgres user password at hand, type these two lines

source /usr/local/groundwork/scripts/setenv.sh 
echo "ALTER TABLE public.patch_4109_service_instance OWNER TO monarch;" | psql monarch 

You will be prompted for the postgres user password.

What is fixed in this version?

The details of what issues and features are changed in this version of the rollup patch are detailed https://kb.groundworkopensource.com/display/DOC721/GWME-7.2.1-00+Rollup+Patch+Details