QM supports the option to install multiple separate copies that each run in an isolated environment on the same server. This concept is referred to as multi-tenanting.
Multi-Tenanting on Linux, FreeBSD, AIX or Solaris
On Linux systems, this mode of install does not necessarily require root access though a non-root installation has weaker security. Non-root mode installations are referred to as "user mode".
A multi-tenant installation is initiated by using the -u command line option with the install script.
Each installation is identified by a numeric value automatically formed from the device and inode values of a hidden empty .qmid file. In the unlikely event of QM failing to start because two user mode installations have the same qmid value, use the Linux/Unix touch command to create a new empty file, delete the existing .qmid file and rename the new file to replace it.
Multi-Tenanting on Windows
Windows installation requires administrator rights to allow the QMSvc service to be installed. A multi-tenanted Windows system is installed by use of a command line option to the installer program
where n is an integer value in the range 1 to 65535 identifying the specific tenant installation.
The name of the QMSvc service is modified to become QMSvc-n. and it is this modified name that will appear in the Windows services administration screen.
Note that the Windows installer offers the location of the most recent installation as its default QMSYS pathname.
The QM Network Server Control tool has a browsable selection for the QMSYS pathname of the instance of QM to be monitored or updated. This defaults to the instance from which the QMNetworkCtrl executable is run.
Licensing and Configuration
Each installation must be covered by a separate licence.
An application can access the qmid tenant number by using the QMBasic SYSTEM() function with key value 1022. Zero indicates a standard install, non-zero is the qmid value referenced above.
There are some important rules to observe when using a multi-tenant installation. Firstly, the configuration parameters must be set such that each installation is listening on different port numbers for incoming network connections (see the PORT, CLIPORT and REPLPORT configuration parameters). The installer will set PORT and CLIPORT to zero for a new installation, effectively disabling network connections until valid port numbers are set. Secondly, it is essential that no files are simultaneously open to more than one installed instance of QM unless this is via QMNet. For directory files, failure to observe this rule may result in data integrity problems. For hashed files, the file will almost certainly become corrupted and unusable.
It is also essential that the qm command is executed from the bin subdirectory of the QMSYS account in the correct instance of QM. Users should take care to ensure that the search path list in the PATH environment variable does not cause the incorrect program to be run. Similarly, if the optional QMSYS environment variable is defined, it is essential that it points to the correct installation.
System administrators should set operating system permissions to ensure that a user cannot see other instances of QM on the same server.
Because a user connecting to a multi-tenant installation directly over a network is routed to different installations based on the port number, it is necessary to ensure that a user can only connect to instances of QM for which they should have access. The easiest way to achieve this is to use QM's user security features to restrict login based on user name. For users entering a Linux system via the shell, operating system permissions should provide adequate enforcement of access restrictions.
When running a Linux system in user mode, user authentication is handled differently depending on whether the qmlnxd daemon that manages network connections is run as the root user or as a non-root user.
•If qmlnxd is running as root, the user name and password entered when starting a QM process must be known the underlying operating system and the QM process will run as this user.
•If qmlnxd is running as a non-root user and QM's user security features are enabled, the user name and password must have been defined using the CREATE.USER or ADMIN.USER commands. The QM process will run as the same user as the qmlnxd process but the @LOGNAME variable will contain the user name entered on connection.
• If qmlnxd is running as a non-root user and QM's user security features are not enabled, no prompt for the user authentication details will appear. The QM process will run as the same user as the qmlnxd process and the @LOGNAME variable will contain the qmlnxd user name. On a QMClient connection, the user name and password supplied in the QMConnect() function will be ignored.
User authentication can be disabled entirely by use of the SECURITY command but this is not recommended.