1.2 Definitions and Terminology
The LANSA Group
The LANSA Group is a valid Linux group id that is used to set group ownership for the whole LANSA installation directory except a few special files and sub-directories. In order to support allowing multiple Linux user ids to use the same LANSA installation at the same time, LANSA for Linux is designed to work relying on user group permissions. Except for a few special operations (see below about Root privileges usage), any program execution, including for example running x_run from the command line and server type processes spawned off from the Listener, from the LANSA installation directory must be running using a valid Linux user id belonging to the LANSA Group. For the normal course of running LANSA applications from the installation directory in a production environment, various files and directories will be created and accessed in the installation directory. When new files or directories are created, they will be usually created such that they are readable and writable by the LANSA Group. Existing files or directories, including those created manually, to be accessed the LANSA applications in use must be readable and/or optionally writable (depending on the LANSA applications in question) by the LANSA Group.
For multiple LANSA installations on the same Linux system, there is no need to use the same LANSA Group across all the installations. Using different Linux group ids as the LANSA Group for the multiple installations can actually reduce potential interference between the multiple installations.
Unless you have very special requirements, you should avoid using any Linux system group id, for example "bin" and especially "root", as the LANSA Group. It is highly recommended to create a specific group id for use as the LANSA Group.
The LANSA Group must be provided to the LANSA for Linux installer upon installation.
The LANSA Owner is a valid Linux user id that is used to set user ownership for the whole LANSA installation directory except a few special files and sub-directories. The LANSA Owner must be a member of the LANSA Group and preferably the LANSA Group is being the primary group of the LANSA Owner. While the LANSA Owner can be used to run LANSA applications from the installation, it is not a requirement to run LANSA applications using the LANSA Owner only. Any Linux user id belongs to the LANSA Group (and preferably as the primary group) would be able to run LANSA applications from the installation. It is perfectly all right that the LANSA Owner is not used to run anything at all. However, some crucial configuration files are modifiable only by the LANSA Owner. You will need to login as the LANSA Owner to make changes to those files.
For multiple LANSA installations on the same Linux system, there is no need to use the same LANSA Owner across all the installations. Using different Linux user ids as the LANSA Owner for the multiple installations can actually reduce potential interference between the multiple installations.
Unless you have very special requirements, you should avoid using any Linux system user id, for example "bin" and especially "root", as the LANSA Owner. It is highly recommended to create a specific user id for use as the LANSA Owner.
The LANSA Owner must be provided to the LANSA for Linux installer upon installation.
The Apache Daemon User is a valid Linux user id for running the Apache HTTP daemon.
The Apache Daemon Group is a valid Linux group id for running the Apache HTTP daemon.
For example in a default Red Hat Enterprise Linux installation, the defaults for both are usually named "apache".
If you install LANSA for the Web (including the Apache Module and standard images and scripts) and/or LANSA Integrator for Linux, a few special files and sub-directories in the installation directory will be explicitly installed to be owned by the Apache Daemon User and Group. The remaining files and sub-directories for these two areas of installation will still be owned by the LANSA Group and Owner but they will be accessed by the Apache HTTP daemon and so the permissions will be checked against the Apache Daemon User and Group instead of the LANSA Group and User. If you make changes to those files and sub-directories and/or adding files and sub-directories, you may need to make sure the files and sub-directories affected are readable and/or optionally writable by the Apache Daemon User and Group depending on your application.
For LANSA for the Web Apache Module, the Apache Daemon User and Group are not normally used or required to run any LANSA applications from the same or any other LANSA installations, including those not on the same system. In other words, the execution of the Apache Module is very much independent of the execution of your LANSA applications and security-wise this is a good thing.
For LANSA Integrator for Linux and if you use JSMDirect, LANSA applications running through the LANSA Integrator (effectively the x_run command for the LANSA installation which the LANSA Integrator uses) will be running under the Apache Daemon User and Group and so, as described above about the LANSA Group, the Apache Daemon User must be a member of the LANSA Group of the LANSA installation which the LANSA Integrator uses. You can either manually add the Apache Daemon User to the LANSA Group for the LANSA installation which you use or there is an option for the LANSA for Linux installer to do that for you upon installation. If you have multiple LANSA installations that JSMDirect would use, the Apache Daemon User may need to made member of more that one LANSA Groups.
For standard Apache Web Server setup, LANSA for Linux installer will attempt to figure out the Apache Daemon User and Group names from standard Apache configuration files. If that fails or you have a non-standard Apache Web Server setup, you will need to provide the Apache Daemon User and Group to the LANSA for Linux installer upon installation.
LANSA table owners (also known as collections) are special ORACLE database user ids (reminded not to confuse with Linux user id) that own LANSA tables. The LANSA table owner LX_DTA exists to own the LANSA repository. Application-specific LANSA table owners exist to own a collection of LANSA tables. They are directly related to the data library associated with a table. For example, the partition data library for the DEM partition shipped with LANSA is DC@DEMOLIB. The associated collection is called XDEMOLIB.
When accessing a table from the database, LANSA automatically prefixes the collection name to the table. For example, SELECT … FROM TABLE LX_DTA.LX_MSG.
For further details on how collections are named, refer to in the
In the following description, LANSAXROOT is usually used to refer to the directory on the Linux system under which the LANSA installation resides. This is also referred to as the LANSA installation root directory or simply installation root. During normal operations using LANSA for Linux, for either an interactive shell or any LANSA system process, an environment variable of the same name is usually required to be set to the installation root.