1. Installing GemStone/S 64 Bit Version 3.2.6
This chapter describes the procedure for installing GemStone/S 64 Bit version 3.2.6 on a single machine. We recommend that you set up GemStone this way initially to ensure that all the pieces work together. At the end of this chapter, we suggest refinements you might want to make, such as running GemStone in a network configuration.
NOTE
If you are upgrading to this release from a previous version of GemStone/S 64 Bit, follow the instructions in the appropriate later chapter of this Installation Guide.
Adjust the installation to meet your specific needs. The topic What Next? provides references to procedures and related information in the System Administration Guide.
Review the Installation Procedure
The following list summarizes the steps to install GemStone/S 64 Bit.
Check the System Requirements
Before you install GemStone/S 64 Bit, ensure that the following system requirements are satisfied. Systems meeting these requirements are suitable for installing GemStone/S 64 Bit and beginning development, but additional system resources may be necessary to support large applications.
RAM
1 GB is sufficient for only for very small systems. In most cases you will need much more, depending on the size of the cache and the number of Gem sessions.
Swap space
- Total swap space should be at least equal to the amount of RAM. We recommend installing twice as much swap space as RAM.
Due to the way GemStone uses memory, systems with insufficient swap space allocated have a risk of memory errors even if there is available RAM.
Disk space
- Space for the installed distribution files—you need approximately 450 MB for GemStone/S 64 Bit, and additional space for other products.
- Additional disk space as required for your repository.
The repository files should be located on a disk drive that does not contain swap space. Use of multiple disk drives is advisable for servers.
C/C++ Compiler
GemStone requires a C/C++ compiler only if you are developing C or C++ code for user actions or for a C or C++ application. This compiler is required only for development work, not for execution.
Debugger
A C debugger can be useful to allow problem analysis by GemStone consulting or Technical Support. It also may allow you to debug your C user actions. It is not required for GemStone execution.
Configure the Operating System
The kernel must be configured to support shared memory and semaphores. See your operating system documentation for further information. These requirements apply both to server nodes and to client nodes (nodes that will run Gem processes).
The following suggested settings in /etc/system are typical of those used at GemStone, and most are intentionally set high to provide flexibility. These settings may not be suitable for your hardware configuration and system load.
On Solaris 10 and above, Sun recommends configuring shared memory and semaphores at the project level, rather than system wide. This provides greater flexibility, as well as avoiding the need to reboot after editing /etc/system. However, if the parameter settings are present in /etc/system, they are used as the default project settings. If you are not partitioning your system using projects, you can continue to configure these settings using /etc/system.
1. Shared memory maximum
The default for maximum shared memory segment is not adequate to run GemStone/S 64 Bit. We recommend a value larger than your desired Shared Page Cache size, and not more than 75% of your real memory.
For example, if you have 8192 MB of real memory:
8192 MB * .75 = 6144 MB
6144 MB * 220 = 6442450944 bytes
The parameter in Solaris 10 and above is project.max-shm-memory, which controls project total memory use, not segment size. To configure this, use a command similar to the following, which sets the shared memory maximum to 6GB.
prctl -n project.max-shm-memory -v 6gb -r -i project "user.root"
projmod -sK 'process.max-shm-memory=(privileged,6G,deny)' default
In earlier versions of Solaris, shmsys:shminfo_shmmax set the maximum shared memory segment size, rather than limiting total memory use. To set this parameter using legacy-style Solaris configuration, in /etc/system include the following:
set shmsys:shminfo_shmmax=6442450944
2. Semaphores
The maximum number of semaphores per id (per semaphore set) limits the number of GemStone sessions that can log in to a particular Stone and connect to its shared page cache.
On the Stone’s node, this parameter must provide two semaphores for each user who will log in to that Stone from any node plus an overhead of four. In distributed systems, nodes that have only user sessions (Gems), but no Stones, must provide two semaphores for each user session on that node plus an overhead of one.
The number of semaphores actually requested for a particular shared page cache depends on the GemStone configuration file read by the process that starts the cache and is (SHR_PAGE_CACHE_NUM_PROCS * 2 ) + 1.
In Solaris 10 and above, the project parameter is process.max-sem-nsems. The default is 512 which is adequate for smaller-sized systems. For larger systems, use a command similar to the following, which set the value to 2048:
prctl -n project.max-sem-nsems -v 2048 -r -i project "user.root"
projmod -sK 'process.max-sem-nsems=(privileged,2048,deny)' default
In earlier versions of Solaris, this parameter was named semsys:seminfo_semmsl (Note that semmsl ends with a lowercase L, not a digit.). To set this, use a command similar to the following, which sets the value to 500:
set semsys:seminfo_semmsl=500
If you are adjusting settings using /etc/system, save the file, and reboot the system using boot -r.
The maximum number of semaphore identifiers in the system limits the number of GemStone shared page caches on the node; each shared page cache uses one identifier. This parameter must be large enough to allow for one shared page cache for each Stone running on the node, plus one for each cache running on a remote node.
The project parameter in Solaris 10 and above is project.max-sem-ids. The default is 128. This should be adequate for most installations.
In earlier versions of Solaris, the parameter is semsys:seminfo_semmni.
3. PAM
If you are using UNIX authentication for GemStone logins, or if you run NetLDI as root with setuid (i.e. not in guest mode), you must have PAM (Pluggable Authentication Module) configured on the server. You may include a specific GemStone authorization service name, or allow the default “other” authentication definitions to be used.
PAM authentication definitions are in /etc/pam.conf. The specific GemStone service names are gemstone.gem for user authentication, and gemstone.netldi for a NetLDI running with authentication. The libraries that are specified in the stack depend on how you are configuring PAM to perform the authentication. The examples below are for PAM configured to invoke LDAP for authentication.
For example, to allow GemStone UNIX authentication, which uses PAM, to authenticate via LDAP:
gemstone.gem auth requisite pam_authtok_get.so.1
gemstone.gem auth required pam_ldap.so.1
For NetLDI authentication, again using LDAP:
gemstone.netldi auth requisite pam_authtok_get.so.1
gemstone.netldi auth required pam_ldap.so.1
If the following “other” stack is available in /etc/pam.conf, GemStone can use this to authenticate via LDAP:
other auth requisite pam_authtok_get.so.1
other auth required pam_ldap.so.1
Consult your System Administrators for more information on how authentication is handled on your system.
4. Configuring GemStone’ Shared Page Cache
The configuration option SHR_PAGE_CACHE_SIZE_KB defines the size (in KBytes) of extent page space in the shared page cache. The maximum acceptable value for this configuration option is limited by system memory, kernel configurations, cache space allocated by SHR_PAGE_CACHE_NUM_PROCS and space allocated for other GemStone caches.
For more general information about these and other configuration options, see Appendix A of the System Administration Guide.
5. System clock
The system clock must be set to the correct time. When GemStone opens the repository at startup, it compares the current system time with the recorded checkpoint times as part of a consistency check. A system time earlier than the time at which the last checkpoint was written may be taken as an indication of corrupted data and prevent GemStone from starting. The time comparisons use GMT.
6. TCP keepalive option
GemStone processes ordinarily use the TCP keepalive option to determine how long they will wait after communications activity ceases unexpectedly. This setting can be useful for reaping stale RPC Gems, but the operating system default may not be appropriate for this purpose. For further information, refer to your operating system documentation.
Prepare for Installation
Perform the following steps to prepare the machine to receive the GemStone/S 64 Bit software. Although most steps require root login, we recommend that you perform the initial step as the GemStone administrator.
These are the portions of the system that are affected by the installation of GemStone:
/dev/rdsk
Optional raw partitions for repository extents and transaction logs.
/etc/services
Internet services database, for NetLDI name lookup.
/InstallDir/GemStone64Bit3.2.6-sparc.Solaris
/InstallDir/GemStone64Bit3.2.6-i386.Solaris
Location of the object server software.
/opt/gemstone
Default location for server lock files, host name id file, and log files for GemStone network servers (NetLDIs). See the System Administration Guide for more information.
/tmp/gemstone
Pipe file for the Stone repository monitor.
/usr/gemstone
Alternative location for lock and log files, for compatibility with previous products; /opt/gemstone is created unless /usr/gemstone already exists. See the System Administration Guide for more information.
1. As the GemStone administrator, log in to a machine that has adequate resources to run GemStone and that owns the disk on which you are going to install the GemStone files.
NOTE
Do not copy the files as root. The ownerships that were in effect when the distribution media was created are preserved, and this might result in file permission errors for users at your site.
2. Determine that adequate swap space is available.:
% /usr/sbin/swap -s
3. Check the free disk space and determine the disk drive and partition on which you will install the GemStone software.
To list all disk partitions, along with the amount of free space in each partition:
% df
We recommend that you avoid choosing either an NFS-mounted partition or one containing UNIX swap space for the initial installation. Mounted partitions can result in executables running on the wrong machine and in file permission problems. Existence of swap space on the same drive can dramatically slow GemStone disk accesses.
4. Select an installation directory, InstallDir, and make this directory the current working directory.
5. GemStone/S 64 Bit is provided as a zipped archive file with a name similar to GemStone64Bit3.2.6-sparc.Solaris.zip or GemStone64Bit3.2.6-i386.Solaris.zip.
6. Move this distribution file to the directory location in which GemStone will be installed, InstallDir.
7. Unzip the distribution file using unzip. For example:
% unzip GemStone64Bit3.2.6-sparc.Solaris.zip
8. The InstallDir now contains a GemStone directory with a name similar to GemStone64Bit3.2.6-sparc.Solaris or GemStone64Bit3.2.6-i386.Solaris.
In addition to several subdirectories, this directory also contains two text files: PACKING, which lists all of the GemStone files, and version.txt, which identifies this particular product and release of GemStone.
NOTE
Although you can complete the installation as a non-root user, we do not recommend this. During installation, GemStone system security is established through file permissions and process attributes. To ensure that the installation is successful, you must install as root. If you later decide to change the security of your GemStone system, see Chapter 1 of the System Administration Guide, which explains the concept of GemStone server file permissions and how to change them.
Set the Environment
Perform the following steps to properly configure the operating environment.
1. Set the environment variable GEMSTONE.
a. If more than one installation of any GemStone/S product resides on this machine, check for existing GemStone environment variables:
% env | grep GEM
All GemStone environment variables are displayed.
b. If any environment variables exist and are not appropriate for the new installation, you must specifically unset each one. For example, depending on your shell:
% unsetenv GEMSTONE GEMSTONE_SYS_CONF
$ unset GEMSTONE GEMSTONE_SYS_CONF
c. Set the environment variable GEMSTONE to the full pathname (starting with a slash) of your new GemStone installation directory. For example, depending on your shell:
% setenv GEMSTONE InstallDir/GemStone64Bit3.2.6-sparc.Solaris
% setenv GEMSTONE InstallDir/GemStone64Bit3.2.6-i386.Solaris
$ GEMSTONE=InstallDir/GemStone64Bit3.2.6-sparc.Solaris
$ export GEMSTONE
$ GEMSTONE=InstallDir/GemStone64Bit3.2.6-i386.Solaris
$ export GEMSTONE
Create the GemStone Key File
To run GemStone, you must have a key file for this version of GemStone/S 64 Bit and for the appropriate platform. Email keyfiles@gemtalksystems.com, or contact GemTalk Technical Support, if you have questions about your keyfile, or if you need an evaluation keyfile.
Once you receive your keyfile with the name mykeyfile.key:
1. Change the permissions on the directory $GEMSTONE/sys so that you can create the file:
% cd $GEMSTONE/sys
% chmod 755 .
2. Copy the keyfile into this directory, using the name gemstone.key.
cp mykeyfile.key $GEMSTONE/sys/gemstone.key
You may locate and name the file differently, but you will need to specify the path using the KEYFILE parameter in the configuration file used by this repository.
3. Change the file and directory permissions so that they are not writable:
% chmod 555 gemstone.key
% chmod 555 .
Verify TCP/IP
To run GemStone, TCP/IP must be functioning, even if your machine is not connected to a network.
1. Verify that TCP/IP networking software is functioning (1 is the number 1):
% /usr/sbin/ping hostname 1 1
where hostname is the name of your machine. If ping responds with hostname is alive, TCP/IP is functioning.
Define the NetLDI Service
The NetLDI service, by default gs64ldi, should be defined in your system services database. A NetLDI is required for certain kinds of local and remote sessions to log into GemStone, and if it cannot be resolved by name, you must refer to it by port number. For clients on remote machines, the same NetLDI service name and port number must be defined on the remote machines as well as the main host.
If you are upgrading from a previous version, you may need to keep the NetLDI for that version running. In this case, select a distinct name and port for the NetLDI for GemStone/S 64 Bit 3.2.6.
1. Determine whether the gs64ldi service is already defined. How to do this will depend on how your system is set up. The GemStone distribution includes an executable that will allow you to do this:
% $GEMSTONE/install/getservbyname gs64ldis_name=gs64ldi s_port = 50377 s_proto = tcp
If you are using a local copy of the system services database, /etc/services, then check in this file for a definition for gs64ldi.
If you are using NIS or LDAP, consult your UNIX system administrator for assistance.
If gs64ldi is defined, skip the rest of this procedure and continue with the installation at Run the Installation Script.
If it is not defined, continue performing this procedure.
2. Add an entry similar to the following to the system services database:
gs64ldi 50377/tcp #GemStone/S 64 Bit 3.2.6
Choose a port number that is not being used by another service. The port number should be in the range 49152 <= port <= 65535, to confirm to IANA standards (http://www.iana.org/assignments/port-numbers).
3. If several machines will be running GemStone, have the UNIX system administrator update the system services database for each machine. This includes Windows client machines as well as UNIX nodes. Note that the port number must be the same for every machine.
Run the Installation Script
Invoke the installation script from the install subdirectory:
% cd $GEMSTONE/install
% ./installgs
installgs is an interactive script that analyzes your system configuration and makes suggestions to guide you through installing GemStone on your machine.
NOTE
You can usually terminate execution of the installation script with Ctrl-C without risk to your files. When it is not safe to do so, the message Please do not interrupt appears on the screen. If this happens, wait for the message now it is OK to interrupt before you interrupt the script. You can run the script again from the beginning as many times as necessary.
Decisions to Make During Installation
During installation, you are asked several questions. The entire installation dialog is not reproduced here, but the main points are addressed. Some questions may not be asked, depending on answers to previous questions.
Whenever you are asked to answer “yes” or “no,” answer with y or n. When the script offers a default answer in square brackets (such as “[y]”), press Enter to accept the default.
Do you want the installation script to set up directories for server lock files and NetLDI logs?
The default location for server lock files and NetLDI log files is /opt/gemstone, although for compatibility with earlier products /usr/gemstone is used only if it exists. If the environment variable GEMSTONE_GLOBAL_DIR is defined to point to a valid directory, this overrides the default server lock files and log file location; however, all Gemstone processes that will interact on this machine must have this environment variable set to the same directory.
If these directories do not exist, the installation script offers to create /opt/gemstone and the subdirectories locks and log. Then, the script offers to set access (770) to these directories.
If you answer no to creating the directories, you must create them (or provide a symbolic link) before starting the server.
Do you want the installation script to set the owner and group for all the files in the GemStone distribution?
If you answer yes, the script will prompt you for the owner and group you want to use. Refer to Chapter 1 of the System Administration Guide for more information about setting owner and group permissions.
If you answer no, the permissions will remain the same as when the files were extracted from the distribution media.
Do you want the installation script to protect the repository file?
The default, which we recommend, gives only the owner read and write access (600) through ordinary UNIX commands. Other users can read and write the repository through a GemStone session. If you choose not to protect the repository, the setuid bit is cleared from all executables, which causes them to run under ownership of the user who invokes them.
Default: Set the repository permission to 600, and leave the setuid bit applied.
Allow NetLDI to Run as Root?
Do you want the installation script to allow non-root users to start a NetLDI that runs as root?
The NetLDI is a network server that permits remote processes to interact with the repository. There are two ways to set up a NetLDI so that it can provide services to all GemStone users: it can run as root, or it can run in guest mode with a captive account.
- To run NetLDIs as root, accept the default “yes” response. Ownership of the NetLDI executable is changed to root, and the setuid bit is set. Any GemStone user will be able to start a NetLDI process that is accessible to all GemStone users because it will always run as root. For certain services, users will need to authenticate themselves by supplying a password. Alternatively, answer “no” but log in as root before starting the NetLDI.
If the NetLDI uses a port number less than 1024, it must run as root.
- To run NetLDIs in guest mode with a captive account, answer “no” to the prompt, because those modes are not permitted if the NetLDI runs as root. “Guest mode” means that GemStone users do not have to supply a UNIX password to use NetLDI services. The “captive account” is an account that owns all processes the NetLDI starts; typically, it is the GemStone administrative account that owns the files. You must start the NetLDI while logged in as that account.
Default: Change ownership of the netldi executable to root, and set its setuid bit.
Set up an Extent?
Do you want the installation script to set up an extent now?
GemStone is distributed with a read-only copy of the initial repository in
$GEMSTONE/bin/extent0.dbf. Before you can start GemStone, this file must be copied to a suitable location and made writable. The script offers to copy the file to its default location of $GEMSTONE/data.
If you are a new GemStone user, we recommend that you answer y. If you are an existing GemStone user, you might prefer to answer n, then copy the extent to a different location yourself. (If you choose a location other than the default, you must edit your configuration file before starting GemStone. For information, see the System Administration Guide.)
Default: Place a writable copy of extent0.dbf in $GEMSTONE/data.
Start a NetLDI?
Do you want the installation script to start a NetLDI?
If you prefer, you can start these processes manually at any time.
Almost every host needs a NetLDI. You must start a NetLDI when the Stone repository monitor or Gem session processes will run on this machine.
You can start a NetLDI that runs as root by answering yes to this prompt and the confirmation that follows. However, if you want to start the NetLDI in guest mode with a captive account, you must do that after completing the installation. For more information about guest mode with captive account, see Chapter 3 of the System Administration Guide.
Change System Passwords and Add Users
After installing GemStone/S 64 Bit, you must change the passwords for the administrative users: DataCurator, SystemUser, and GcUser. (The initial password for each is swordfish.) The DataCurator account is used to perform system administration tasks. The SystemUser account ordinarily is used only for performing GemStone system upgrades. The GcUser account is used by the garbage collection task, which runs automatically as a separate login. Access to each of these accounts should be restricted.
You must then establish GemStone accounts for each of your system’s users.
The chapter entitled User Accounts and Security in the System Administration Guide tells you how to change the passwords and set up accounts for other GemStone users, and how to create new GemStone user accounts. These functions can also be done using GemBuilder for Smalltalk tools; see the GemBuilder for Smalltalk Users’s Guide for more information.
Users must execute gemsetup
The directory $GEMSTONE/bin contains two files, gemsetup.sh and gemsetup.csh, to help set a user’s environment. These files define the GemStone environment for users by modifying the PATH and MANPATH variables to include $GEMSTONE/bin and $GEMSTONE/doc, respectively.
After GemStone/S 64 Bit 3.2.6 has been installed, you should notify each GemStone user of the installation and explain how to use the gemsetup files.
Each user must perform this procedure before running GemStone.
1. Set the environment variable GEMSTONE to the full pathname (starting with a slash) of the GemStone/S 64 Bit 3.2.6 directory. For example, depending on your shell:
% setenv GEMSTONE InstallDir/GemStone64Bit3.2.6-sparc.Solaris
% setenv GEMSTONE InstallDir/GemStone64Bit3.2.6-i386.Solaris
$ GEMSTONE=InstallDir/GemStone64Bit3.2.6-sparc.Solaris
$ export GEMSTONE
$ GEMSTONE=InstallDir/GemStone64Bit3.2.6-i386.Solaris
$ export GEMSTONE
2. Invoke the script gemsetup. For example, depending on your shell:
% source $GEMSTONE/bin/gemsetup.csh
$ . $GEMSTONE/bin/gemsetup.sh
3. If you will use GemStone frequently, consider adding to your login shell’s initialization file (.cshrc or .profile) the environment variable GEMSTONE and the command gemsetup. This way, the GemStone environment is automatically configured every time you log in or create a login shell.
Install the default TimeZone
GemStone/S 64 Bit is shipped with a default time zone of US Pacific. If you are in another Time Zone, edit the file installtimezone.txt in the GemStone upgrade directory, then file it in as SystemUser.
What Next?
This chapter has guided you through installation of GemStone/S 64 Bit 3.2.6 in an initial configuration that is sufficient to create a basic repository and begin setting up user accounts. The objective has been to get a simple, default configuration up and running.
You might consider performing the following tasks:
- To modify the initial object server configuration to one that is more efficient for your particular needs, refer to Chapter 1 of the System Administration Guide. This chapter describes in detail the many options for configuring your system.
- To modify the configuration of Gem session processes and to ensure that users have the necessary permissions to access the shared page cache and the extents, refer to Chapter 2 of the System Administration Guide.
- If you are going to operate in a network environment, Chapter 3 of the System Administration Guide has additional information about the GemStone network server (NetLDI), how to handle user authentication, how to share software over the network, and how to set up some common configurations.
- To start and stop the GemStone object server, refer to instructions in Chapter 4 of the System Administration Guide.