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.
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.
GemStone/S 64 Bit version 3.5 is supported on the following platforms:
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.
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:
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 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.
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
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:
The version of lz4 has been updated to v1.9.1.
The version of OpenSSL has been updated to 1.1.1b.
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.
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.
A 32-bit openSSL client application is now included, $GEMSTONE/bin32/openssl.
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
libkrb5-NN-32.so
libssl-NN-32.so
(as well as other files); and the libfloss* libraries are not shipped.
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.
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.
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
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/.
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.
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.
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.
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.
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:
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.
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:.
The Free frame spinlock and the Free PCE spinlock have been eliminated, and instead managed using bitlists, which are atomically updated. This improves performance.
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.
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
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 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.
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 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.