logo
Powered by QM on a Rpi server
Home
About OpenQM
Sales and Downloads
Help and Support
About
Login

KnowledgeBase 00025: Installing Multiple QM Environments on a Single Server

Last updated: 22 Jul 2016
Applies to: Release 2.12-0 onwards, not Windows or PDA
Search  
Top level index       Full Index Search Tips
Previous article     Next article

Introduction

When setting up a shared server it may be important that users of one QM application are totally isolated from users of any other QM applications that are running on the same server. Although use of separate accounts and thorough enforcement of access permissions may help, it is not a total solution. For example, the shared memory lock tables are common to all accounts and hence it is not possible to ensure that use of task locks would not cause unwanted interactions between the accounts.

QM's user mode installation allows multiple separate instances of QM to run simultaneously on the same server. The installation mode gets its name from the fact that an installation of this type does not require root access. This feature is not available on Windows.


Installation

Each instance of QM in a user mode installation is totally isolated and separately licensed. The separate instances are identified by a numeric value that is formed from manipulation of the device and inode numbers of a hidden zero length file named .qmid in the QMSYS account directory. In the unlikely event that two instances have the same qmid value, starting the second instance will report an error. The .qmid file should be deleted and recreated.

Installation of a user mode system is performed exactly as for a standard installation except that the -u option should be given to the install script. It is essential that the PATH environment variable does not include a reference to the location of some other QM instance.


Network Access

The installation process will set the PORT and CLIPORT configuration parameters to zero, effectively disabling network connection to QM. If network connection is required, rather than only supporting entry to QM from the operating system shell, these parameters should be set to the appropriate port numbers assigned by the system administrator. Once set, the qmlnxd daemon must be restarted by use of the qm -restart command.


Security

Because the qmlnxd daemon in a user mode installation runs as a standard user, not root, any QM processes started by it (telnet connections, QMClient sessions, qmrpl replication dameons, startup processes) will run as the user that started QM. Users entering QM from the operating system shell will run as the same user as their operating system login.

If direct network connections are allowed, user authentication for network users is performed using QM's own register of user names, maintained using the CREATE.USER and ADMIN.USER commands.


Caveats

Although the different instances of QM running simultaneously are totally separate, it would be possible for users to set up VOC file pointers that reference the same file and then go on to open this file in two instances.

In the case of a directory file, the locking mechanisms will not be able to coordinate updates from the two isolated instances of QM and hence data integrity problems may occur.

In the case of a dynamic hashed file, the internal management of the file structure will be uncoordinated across the two instances and this will almost certainly lead to file corruption.


Related Articles

00016: Installing QM



Please tell us if this article was helpful
Very     Slightly     Not at all
Comments
Email (optional)