1. Release Notes for 3.5

Next chapter

Overview

GemStone/S 64 Bitâ„¢ 3.5 is a new version of the GemStone/S 64 Bit object server. Version 3.5 includes support for X509-Secure GemStone, new infrastructure that supports remote OpenSSL-based TLS X.509 secure RPC logins, with many security features. These features operate independently of the classic GemStone architecture, which is not affected by X509-Secured GemStone. This release also includes many other new features, enhancements and bug fixes.

These Release Notes include changes between the previous version of GemStone/S 64 Bit, v3.4.3, and v3.5.

Upgrade is supported from GemStone/S 64 Bit v3.4.x, 3.3.x, and 3.2.x.

For details about installing GemStone/S 64 Bit 3.5 or upgrading from earlier versions of GemStone/S 64 Bit, see the GemStone/S 64 Bit Installation Guide for v3.5 for your platform.

New keyfiles required

The keyfiles for v3.4.x and earlier cannot be used with v3.5. If you are upgrading from v3.4.3 or earlier, new keyfiles are required. To obtain a new keyfile for GemStone/S v3.5, write to keyfiles@gemtalksystems.com. In your request, include your license information, platform and any updates to contact information.

Please contact GemTalk Technical Support if you have issues or questions.

The X509-Secured GemStone feature requires specific keyfile permissions.

Keyfile expiration dates

Keyfile expiration dates previously were printed with the potentially ambiguous date format MM/DD/YYYY. Now, the display is YYYY-MM-DD.

Supported Platforms

Platforms for Version 3.5

GemStone/S 64 Bit version 3.5 is supported on the following platforms:

  • Red Hat Enterprise Linux Server 6.9 and 7.4, and
    Ubuntu 16.04 and 18.04, and SUSE Linux Enterprise 12, on x86
  • Solaris 10 and 11.3 on x86
  • AIX 6.1, 7.1, and 7.2
  • OS X 10.13.2 (High Sierra), with Darwin 17.3.0 kernel, and
    OS X 10.14.3 (Mojave) with Darwin 18.2.0 kernel, on x86
    (Mac is supported for development only)

For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.5 Installation Guide for that platform.

The X509-Secured GemStone feature is fully tested and supported on Linux platforms only.

GemBuilder for Smalltalk (GBS) Versions

GemStone/S 64 Bit version 3.5 requires GBS version 8.4 or later for VisualWorks Smalltalk, or version 5.4.5 or later for VA Smalltalk. GBS versions 8.3/5.4.4 can login, but some signal-related operations may fail.

The following versions of GBS are supported with GemStone/S 64 Bit version 3.5:

GBS version 8.4

VisualWorks
8.3.2

32-bit and 64-bit

VisualWorks
7.10.1

32-bit

VisualWorks
7.10.1

64-bit

  • Windows 10 and Windows 7
  • RedHat ES 6.9 and 7.4; Ubuntu 16.04 and 18.04
  • Windows 10 and Windows 7
  • RedHat ES 6.9 and 7.4; Ubuntu 16.04
  • Windows 10
  • RedHat ES 6.9 and 7.4
GBS version 5.4.5

VA Smalltalk
9.1

VA Smalltalk
8.6.3

  • Windows 10
  • Windows 7
  • Windows 10
  • Windows 8.1
  • Windows 7

GBS/VA does not support logins using X509-Secured GemStone.

For more details on supported GBS and client Smalltalk platforms and requirements, see the GemBuilder for Smalltalk Installation Guide for that version of GBS.

VSD Version

The GemStone/S 64 Bit v3.5 distribution includes VSD version 5.4. This is the same version of VSD that was included in the previous version of GemStone/S, v3.4.3.

The build number has changed: this reflects new definitions added to describe new statistics collected in v3.5.

Upgrade

Upgrade is supported from all 3.3.x and 3.4.x versions without recompile of methods and blocks. Upgrade from 3.2.x does require method and block recompile. To upgrade from earlier versions, upgrade to a 3.3.x or 3.4.x version and then upgrade to 3.5.

Upgrading from GLASS/GsDevKit/Seaside

The upgradeSeasideImage script that can be used during upgrade has been rewritten and expanded to allow customization. Applications using GLASS, GLASS1, the original GsDevKit environment, and tODE can upgrade using the processes described in the Installation Guide.

For more information on these different starting environments and the upgrade process, see the discussion here:

https://github.com/GsDevKit/GsDevKit_upgrade/blob/master/README.md#upgrading-glassgsdevkit-applications-to-gemstone-350

Documentation Changes

All documentation has been revised for this release, with modifications to incorporate new and changed features, as well as corrections and improvements.

In addition to the maintenance changes and addition of new information and features, the following improvements have been made:

  • A new manual has been added, the GemStone/S 64 Bit X509-Secured GemStone System Administration Guide. This contains all configuration, setup, and architectural information related to X509-Secured GemStone.
  • gemnetobject now is documented as a utility in the System Administration Guide, and using arguments to gemnetobject and to a Gem are described in detail.
  • System Administration Guide Appendix F on tranlog analysis has been moved out of that manual and is now a separate document, http://downloads.gemtalksystems.com/docs/Other/SDoc-TranlogAnalysis-3.5/SDoc-TranlogAnalysis-3.5.htm.
  • A new chapter has been added to the Programmer’s Guide, providing some encryption and validation information using OpenSSL.
  • The Topaz Users Guide has reorganized and expanded material on scripting, including the new topaz features.
  • Indexes are no longer included in the .pdf documents; since these documents are no longer printed; search tools provide a more reliable and maintainable way of locating information.

1.1  Library and Distribution changes

Updated library versions

The version of lz4 has been updated to v1.9.1.

The version of OpenSSL has been updated to 1.1.1b.

The version of OpenLDAP has been updated to 2.4.47.

The version of MIT Kerberos has been updated to 1.17.

Updated ZoneInfo (TimeZone database)

The zoneinfo TimeZone database has been updated from version 2017b to 2019a. As part of this update, the files within the timezone directory tree have been reorganized to adhere more closely to standard directory naming conventions.

Raspberry Pi

An initial version of support for GemStone clients running on Raspberry Pi is now supported. The Raspberry Pi runs Linux distribution "Raspian", which is a Debian Linux variant.

Raspberry Pi is a client-only distribution with the name GemStone64BitClient3.5.0-arm.Linux. No specific Installation Guide has been created; the process is similar to a client-only installation on Linux.

32-bit openSSL client now included

A 32-bit openSSL client application is now included, $GEMSTONE/bin32/openssl.

Change in how shared libraries are packed

In v3.4, the three shared libraries previously included in the distribution were replaced by a single library, libfloss.

However, this did not allow sufficient flexibility in specifying the openSSL library, so this change has been backed out. In addition, extra libraries are now used by the NetLDI.

In v3.5, $GEMSTONE/lib now includes:

libkrb5-NN-64.so
libldap-NN-64.so
libldipcmon-3.5.0-64.so
libldipgsvr-3.5.0-64.so
libnetldi-3.5.0-64.so
libssl-NN-64.so

$GEMSTONE/lib32 now includes:

libkrb5-NN-32.so
libssl-NN-32.so

(as well as other files); and the libfloss* libraries are not shipped.

File documenting special selectors

A file, $GEMSTONE/doc/specialSends.txt, has been added. This lists reserved selectors and other special cases in which there is no message send for code execution.

shrpcmonitor shell removed

The shrpcmonitor shell was previously usable for certain commands, such as computing large memory page requirements. This shell has been removed, and startshrpcmon is no longer included in the distribution. Large memory page requirements are now calculated using the added largememorypages script, described here.

Open Source Library versions

The distribution now includes a file containing the versions of open source software included in the product, under $GEMSTONE/licences/ossversions.txt.

In v3.5, the contents of this file are:

Package         Version(s)
=========================================
icu             58.2, 54.1, 51.2
MIT Kerberos    1.17
libicuid        1.4.1
linenoise       none
lz4             1.8.3(server), 1.3.1 (VSD)
oniguruma       5.9.1
openldap        2.4.47
openssl         1.1.1b
rbc             0.1
tcl             8.6.8
tk              8.6.8
tix             8.4.3
zlib            1.2.11
zoneinfo        2019a

Temporary files on Linux now created in /tmp, not /usr/tmp

Recent linux distributions do not define /usr/tmp/, as the standard location for temporary files is now /tmp/. GemStone now creates temporary files in /tmp/.

Banner printing changes

The log files and topaz banners have changes on Linux, Mac, and Windows; memory information is now on a separate line, and processor information is included. Note that both the number of physical cores and the number of CPUs are provided, the CPU count is the number of hyperthreaded cores, usually 2X physical cores.

DbfHistory now includes build as well as version

The Global DbfHistory tracks the upgrade history of the GemStone image. The version that is listed now includes the build number as well. E.g.

upgrade to GemStone 3.5.0 64bit-45899 at 20/02/2019 16:17:25

1.2  Optimizations

Reduced round-trips from Gem to Stone

During login, most Gems made seven round trips to the Stone, which is expensive over slower networks. This has been reduced to four round-trips for most logins.

A remote Gem was making a separate call to the Stone to fetch the lock sets, if any object was locked. Now, the lock sets are returned by the Stone, as part of the serialization request, saving a round trip during a critical region.

SSL-encrypted Network Connections

Now, all network communications may be encrypted using anonymous SSL.

STN_ANONYMOUS_SSL
If true, the network connections between the stone and other processes and between shrpcmonitor and other processes are encrypted with Anonymous SSL. In this case, the settings for GEM_PGSVR_USE_SSL and GEM_RPC_USE_SSL are ignored and the GCI to gem and gem to pgsvr connections will always use SSL. If false, which is the default, the behavior is as in previous releases.

This parameter does not affect any connections established using X509-secured GemStone; those connections always use SSL.

Loading a specific OpenSSL library version

An external OpenSSL library (that is, an OpenSSL library that is not part of a GemStone distribution) can now be loaded instead of the OpenSSL library provided by GemStone. To do this, set the environment variable GS_OPENSSL_LIB to reference the external library.

The external OpenSSL directory (not the file) must also be in the LD_LIBRARY_PATH, to ensure that the dynamic loader can find the libcrypto.so library.

To ensure that failing to configure LD_LIBRARY_PATH is detected, GemStone prints out the value of LD_LIBRARY_PATH when attempting to load a non-GemTalk SSL library.

Only OpenSSL 1.1 and later are supported.

Improved support for additional execution environments

In addition to the default Smalltalk execution environment with envId 0, GemStone allows additional execution environments. The handling of code in envIds greater than 0 is improved in v3.5:

  • topaz commands are all environment aware
  • A number of issues and bugs, such as in Behavior's handing of class and method operations, and ClassOrganizer functions, have been fixed.
  • Behavior fileout methods have been added, with an additional environment variable keyword.

Expansion in file and path names

Smalltalk methods, topaz commands, and other operations use of strings to describe file paths and names, which may include references to shell environment variables. Previously, these were limited to a single leading environment variable, and other instances of embedded dollar signs $ were interpreted literally.

Now, any dollar sign found in a string defining a file name/path is interpreted as a environment variable name to be expanded. Valid characters in environment variable names are a-z, A-Z, 0-9 and underscore. Any other character terminates the environment variable.

If no matching environment variable is defined, an empty string is used.

This includes a change in behavior for ambiguous usages. If $FOO is defined as foo, using $FOObar will now return an empty string, and may produce an error on subsequent use; attempting, for example, to write to a directory. In previous versions, it would have produce a file path or name with a literal $, and a subsequent use for writing would have written, for example, to a file with the name $FOObar.

It is also now supported to include curly braces ${varname} to define environment variables that are substrings. For example, with $FOO is defined as foo, ${FOO}bar would be expanded to foobar. {$FOO}bar expands to {foo}bar.

Automatic Asynchronous Aborts

GemStone/S 64 Bit v3.5 and GBS v8.4 now include support for an automatic asynchronous abort feature. This allows a Gem that is outside of a transaction to automatically process sigAbort from the Stone, using handler blocks to provide detailed instructions for processing. This feature has specific integration requirements, and should be used under the guidance of GemTalk Engineering.

The server function is enabled with the configuration parameter GemAutoServiceSigAbort, which is described here.

The GBS API is documented in the GBS method GbsSession>>asyncAbortStartAction:finishAction:.

Spin locks reduced

The Free frame spinlock and the Free PCE spinlock have been eliminated, and instead managed using bitlists, which are atomically updated. This improves performance.

Array with: now implemented as primitive

A primitive has been added for Array class >> with:.

Cache line size

The cache line size was changed from 128 to 64 bytes on Intel/AMD CPU platforms (Solaris x86, Linux x86, Darwin)

OOB signal

The out-of-band signal from the Stone to Gems is a 6 byte packet in v3.5.

1.3  Support for X509-Secured GemStone

X509-Secured GemStone is a new architecture that supports mutually-authenticated
secure SSL connections between all processes within a distributed GemStone environment. These are designed to allow Gems to run on a remote node that is less secure than the Stone’s node.

The Stone’s node is expected to remain in a secure environment; there are no differences in the way the Stone is configured, started up, or secured.

You must have a keyfile with appropriate permissions in order to use X509-secured logins.

X509-Secured GemStone Configuration, Login, Administration, and other details are described in the new manual, the GemStone/S 64 Bit X509-Secured GemStone System Administration Guide. Changes that only support X509-Secure GemStone, such as additional utility command arguments and utilities that generate certificates, are not included in these Release Notes.

New HostAgent process

The HostAgent process has been added to support X509-Secured logins. The HostAgent provides necessary services to remote X509-secured processes.

The HostAgent runs as a new system user, HostAgentUser, with its own GsObjectSecurityPolicy. The HostAgent is started with the new script starthostagent that is executed on the Stone’s node.

Each remote node running X509-secured Gems has a HostAgent process running on the Stone’s node

New login parameter set

X509-secured logins are performed using new C calls that require a different set of login parameters than ordinary logins. Arguments have been added to topaz and GBS 8.4 to support X509-secured logins.

All connections require certificates

All interprocess connections in X509-secured GemStone require X.509 certificates.

GemStone has added utilities to support generation of Host, User, certification authority, and Certification-Revocation-List PEM files. Certain utilities, such as startnetldi and gslist, have added arguments to allow specification of certificate files.

Remote and mid-level shared page caches

To mediate remote X509-secured logins, NetLDIs must be started in X509-secured mode on both the remote Gem host and the Stone’s node, configured with the appropriate certificates, before an X509-secured remote cache can be started.

The remote shared page cache is started by the remote NetLDI, when requested to do so by the HostAgent on the Stone’s node.

X509-Secured GemStone also supports X509-secured Mid Level Caches.

Object Filtering

Object Filters are applied to all objects on any pages that are requested by a remote X509 cache, determined by GsObjectSecurityPolicy and IP address. Objects that are protected are not transmitted to the remote cache. This avoids the risk that sensitive data may be present at all in a remote cache.

The classes ObjectFilteringPolicy and ObjectFilteringPolicyMap have been added to support this function. The classes IPv4Subnet, Cidr, CidrGrammar and CidrParser have been added to represent IP addresses and allow subnet filtering.

 

Next chapter