IBM Integrated Analytics System 1.0.25.0 release notes (April 2021)

Version 1.0.25.0 introduces a number of enhancements, such as a tool to change the root password, Pod Manager (Podman) support, and more.

Important:
  1. If you are on IAS 1.0.19.2 or lower, you must upgrade to IAS 1.0.19.7 before you can upgrade to IAS 1.0.2x.x.
  2. The upgrade to IAS 1.0.25.0 cannot be a partial one. You must do a complete upgrade of the whole system.
  3. To get information about upgrade times for upgrading to version 1.0.25.0 from versions 1.0.19.7, 1.0.21.3, 1.0.22.1, 1.0.23.2, and 1.0.24.0 and different system types, see 1.0.25.0 upgrade times.
  4. If you want to preserve SSL certificate files during upgrade, you must specify the old certificates by using SSL environment variables in the dashdb.env file. For more information, see Preserving old certificate files during upgrade.

What's new

RHEL
Upgraded RHEL to 7.9.
FSN
Updated the FSN firmware to ISKLM 3.0.
root password
Added a utility to change the root user password on all connected IAS nodes. For more information, see aprootpwd utility.
Pod Manager (Podman)
  1. Replaced Docker with Podman. On IAS, all the docker commands work without any changes.
  2. Right now, all output messages that are Podman-related still use the word docker.

  3. In Podman-based containers, data cannot be copied from the host system into the container's /tmp partition. Use other partitions to copy any data from the host into the containers. Although the copy command (docker cp) does not throw any errors when copying the data into /tmp from the host system, no data is actually copied.

DSX
With the upgrade to Podman, DSX is no longer supported on IAS. DSX is supported only through an external connection.
Archive logs
Moved archive logs from scratch to local.
Guardium S-TAP
Updated Guardium S-TAP to 11.3.
STIG compliance
Added options to enable and disable audit rules. For more information, see Security hardening with the security_compliance_manager tool.
LDAP certificates
Added support for generating internal LDAP certificates. For more information, see Generating and updating internal LDAP certificates.
Archive log pruning
  • During the upgrade procedure, logarchmeth1 in db cfg is updated from /scratch/db2archive/archive_log/ to /local/db2archive/archive_log/.
  • The apupgrade command moves the older archive logs from /scratch to /local and the new archive logs are generated under /local.
  • Revised the archive log pruning mechanism to retain twice as many logs that are set for LOGPRIMARY and LOGSECOND in db cfg.
Security patch
Introduced a monthly security patch infrastructure.
Backup and restore
Added an integrity verification option for schema-level backups. You can use -image-check rowcount to ensure schema-level backup files can be processed by Db2 without errors during backup or before restore. When used during backup, -image-check hash size causes restore to be blocked if the backup image was modified. -image-check rowcount is not applicable to tables with large binary objects under some circumstances.
For more information, see Backing up data using the db_backup command, Restoring data using the db_restore command, and Incremental schema backup and restore.

Components

Db2 Warehouse 11.5.5.1
See What's New in Db2 Warehouse.
Db2 Engine 11.5.5.1
Introduced defect fixes. To learn more about the changes that are introduced in Db2 11.5.4.0, read What's new in the Db2 IBM Knowledge Center.
IBM Data Replication for Availability
Console and API support for Db2 SSL certificate
In the web console, when you add a replication target you can now click Trust Target to configure the source database to trust the target Db2 SSL security certificate. After this step, you can use the console to create replication sets, add tables, and start replication. You can also use the replication REST API to update the Db2 SSL certificate in the Bludr-REST truststore.
Ability to monitor performance of target table loading
You can better track the performance of the target table loading process by using four new columns that are added to the replication control table that stores monitoring statistics. The TABLES_LOADED, ROWS_LOADED, TABLES_LOADED_PHYSICAL_SIZE, and TABLES_LOADED_LOGICAL_SIZE columns now store these statistics for each monitoring interval in the IBMQREP_APPLYMON table.
Customer LDAP admin username
When you are configuring external LDAP to manage access to the replicated databases, you can now use a custom bluadmin username such as bluadmin.iias to improve management of users and groups.
After you upgrade from IAS 1.0.23.2 to 1.0.25, the replication web console does not open on the upgraded source or target system because of a problem with the Db2 SSL certificate exchange.
For more information and a workaround, see the Known issues in the IBM Data Replication for Availability documentation.

Known issues

FIPS and SELinux settings must be disabled before upgrading to 1.0.25.0
If FIPS is enabled on your system or SELinux is set to enforcing, you must disable FIPS and set SELinux to permissive before you can upgrade to 1.0.25.0. Upgrade does not preserve this configuration and fails if not disabled. The apupgrade command verifies this before the upgrade procedure is started. The settings must be reenabled after the upgrade.
Backing up with IBM Spectrum Protect (TSM)
Backing up with IBM Spectrum Protect (TSM) is not supported from the web console. You can use the db_backup command instead.
Node booting and rebooting taking more than 45 minutes
If a node is booted and rebooted, and it takes more than 45 minutes for the node to come up, Platform Manager marks the node as Disabled. The node is marked Disabled even if the node comes up after 45 minutes. If this happens, you must enable the node manually. Follow the steps described in the workaround.
WORKAROUND:
  1. Enable the disabled node:
    ap node enable <node_name>
    Example
    ap node enable hadomain1.node3
  2. Rebalance the system:
    ap node rebalance

If the node does not come online after 45 minutes, contact IBM Support.

rsyslog fails to restart
When you issue apstop --service, Platform Managers stops its services and restarts the rsyslog service. Sometimes, rsyslog fails to restart and the following message is displayed:
[root@node0101 ~]# systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: failed (Result: start-limit) since pon 2021-02-08 11:31:55 UTC; 2min 39s ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
  Process: 128335 ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS (code=exited, status=219/CGROUP)
 Main PID: 128335 (code=exited, status=219/CGROUP)
    Tasks: 0
   CGroup: /system.slice/rsyslog.service

lut 08 11:31:55 node0101 systemd[1]: rsyslog.service: main process exited, code=exited, status=219/CGROUP
lut 08 11:31:55 node0101 systemd[1]: Failed to start System Logging Service.
lut 08 11:31:55 node0101 systemd[1]: Unit rsyslog.service entered failed state.
lut 08 11:31:55 node0101 systemd[1]: rsyslog.service failed.
lut 08 11:31:55 node0101 systemd[1]: rsyslog.service holdoff time over, scheduling restart.
lut 08 11:31:55 node0101 systemd[1]: Stopped System Logging Service.
lut 08 11:31:55 node0101 systemd[1]: start request repeated too quickly for rsyslog.service
lut 08 11:31:55 node0101 systemd[1]: Failed to start System Logging Service.
lut 08 11:31:55 node0101 systemd[1]: Unit rsyslog.service entered failed state.
lut 08 11:31:55 node0101 systemd[1]: rsyslog.service failed.
WORKAROUND:
  1. Uninstall the ryslog service from the node that is affected:
    yum remove rsyslog
  2. Unpack /install/rhel7.4/ppc64le/updates_7.4-update-4.tgz in /tmp/rpm_list.If the rpm_list directory does not exist, create it.
  3. Install ryslog:
    rpm -ivh /tmp/rpm_list/rsyslog-8.24.0-57.el7_9.ppc64le.rpm
  4. Reinstall the following rpms:
    yum reinstall ibm-ca-aplogger
    yum reinstall ibm-ca-os-security-profiler
  5. If rsyslog failed to restart on the head node:
    1. Install xcat rpm:
      yum reinstall  ibm-ca-xcat-postscripts
    2. Compare the /etc/rsyslog.d/ files on the affected node with files on a different head node.

      If anything is missing from /etc/rsyslog.d/ on the affected node, copy the necessary file or files.

  6. Run the command:
    /install/postscripts/nz/scripts/postboot_rsyslog_fix.sh
  7. Restart the ryslog service:
    systemctl start rsyslog
Error No such file or directory for the ibm-ca-os-custom-service in the upgrade log but the rpm is installed on the system
In the upgrade log, the following message is displayed for node0105, node0104, u'node0107, u'node0106, and node0103.
error: open of /install/rhel7.4/ppc64le/netezza/packages/ibm-ca-os-custom-service-1.0.25.0.noarch.rpm failed: No such file or directory
The ibm-ca-os-custom-service rpm is copied only on node0101 and node0102, but the rpm is installed on the system.
You can ignore this error message.
After node reboot, the system is stuck
The system is stuck in the following state:
2021-04-11 19:29:42    --> bundle appears to already be extracted -- skipping
2021-04-11 19:29:42 Running preliminary check
2021-04-11 19:29:42 Verifying bundle integrity and authenticity
2021-04-11 19:31:43 Bundle integrity and authenticity verification succeeded.
2021-04-11 19:31:43 INFO: Retrieving installed version from aphistory.
2021-04-11 19:31:43 INFO: Retrieving latest successful upgrade log message from aphistory
2021-04-11 19:31:46 INFO: Latest successful upgrade log message retrieved 'Completed upgrade from 1.0.19.7-20200522105916b7 to 1.0.25.0-20210409.205743-435-release'
2021-04-11 19:31:46 INFO: Building the installed version based on the last successful upgrade log message from aphistory
2021-04-11 19:31:46 INFO: Checking upgrade version.
2021-04-11 19:31:46 INFO: Checking upgrade version.
2021-04-11 19:31:46 A direct upgrade from the current software version 0.1.0.0 to the target software version 1.0.25.0-20210409131801b20285 is not allowed.
This system must first be upgraded to 1.0.15 before continuing.
(END)

WORKAROUND:

Restart the upgrade process.

Error invalid arithmetic operator for the OTHER METADATA/CACHE/CONFIG FILES row if the size of bludb or schema is in floating value
The error occurs when the size BLUDB or SUM(SCHEMA) is in decimal values.
[root@node0101-fab - Db2wh /]# db_size
  Object   |               Name                |        Bytes         |        KB        |      MB      |     GB     |   TB
-----------+-----------------------------------+----------------------+------------------+--------------+------------+------------
Database   |BLUDB                              |      203,558,158,336 |      198,787,264 |      194,128 |    189.578 |       .185
MQTable    |DB2GSE.GSE_SRS_REPLICATED_AST      |            6,815,744 |            6,656 |            7 |       .006 |       .000
Table      |ASN.IBMQREP_RESTAPI_JOBS           |              262,144 |              256 |            0 |       .000 |       .000
Table      |AUDIT.AUDIT                        |          556,924,928 |          543,872 |          531 |       .519 |       .001
Table      |AUDIT.CHECKING                     |       31,802,130,432 |       31,056,768 |       30,329 |     29.618 |       .029
...
-----------------------------------------
**/opt/ibm/migration_tools/db_toolkit/db_size: line 441: let: diff=194128.1875-187335.75: syntax error: invalid arithmetic operator (error token is ".1875-187335.75")**
BLUDB   = 194128.1875 MB
SUM(SCHEMA) = 187335.75 MB
OTHER METADATA/CACHE/CONFIG FILES =  MB
-----------------------------------------
Restoring to a new schema by using the db_restore command with the -target-schema
Restoring to a new schema by using the db_restore command with the -target-schema option is not supported for the following DDL statements:
  • CREATE INDEX
  • ALTER TABLE - ADD CONSTRAINT
Schema backup images taken on IAS 1.0.24 or DB2 Warehouse may contain inaccurate data for tables that contain the BINARY or VARBINARY data type
A backup operation that is taken on IAS 1.0.24 captures data for tables that contain the BINARY or VARBINARY data type as of timestamp when an individual table is processed by the backup operation. All other tables are captured as of timestamp when the db_backup command is issued.
If no concurrent workload was running while db_backup was in progress, the backup image is consistent.
If there was a concurrent write access activity into a table of that type during backup, the backup image might not be consistent. The backup image might contain rows that were inserted or updated after the db_backup command was issued if such rows were committed before that table was processed by backup. The backup image does not contain rows that were deleted or truncated after the db_backup command was issued if the rows were committed before that table was processed by backup.
All schema backup types: -type ONL, -type INC, -type DEL are affected.
Only tables that contain the BINARYand or VARBINARY column types are affected. All other tables are backed up normally, even if they are a part of the same backup image.
To find out if any tables have BINARY or VARBINARY columns, run:
select TABSCHEMA, TABNAME from syscat.columns C, syscat.schemata S where
     S.ROWMODIFICATIONTRACKING='Y' and
     C.TABSCHEMA = S.SCHEMANAME    and
    (C.TYPENAME='BINARY' or C.TYPENAME='VARBINARY')
group by (C.TABSCHEMA, C.TABNAME)
If any table is affected, run the db_backup command again and obtain a backup image by using IAS 1.0.25.
Podman
  1. Right now, all output messages that are Podman-related still use the word docker.

  2. In Podman-based containers, data cannot be copied from the host system into the container's /tmp partition. Use other partitions to copy any data from the host into the containers. Although the copy command (docker cp) does not throw any errors when copying the data into /tmp from the host system, no data is actually copied.

Getting Error: unknown shorthand flag: 'f' for /usr/bin/docker image prune -a -f
When you issue /usr/bin/docker image prune -a -f, in the upgrade log you can see Error: unknown shorthand flag: 'f'.
The upgrade does not fail due to this error. You can ignore this error message if you see it.
An error during copying files from bundle to dashDB container causes upgrade failure
WORKAROUND:

Restart docker service on node0101.

After you upgrade from IAS 1.0.23.2 to 1.0.25, the replication web console does not open on the upgraded source or target system because of a problem with the Db2 SSL certificate exchange.
For more information and a workaround, see the Known issues in the IBM Data Replication for Availability documentation.