The primary role of the Eloquence eloqsd server is to interact with eloqcore
processes executing programs written in the Eloquence programming language.
This interaction includes services such as counting active users and validating
available user licenses as well as, on HP-UX and Linux, coordinating the TASKID
values of active programs. An optional HTTP interface is available to query
server status information with a web browser.
In addition, the eloqsd may be used to start background programs, using various
clients such as Eloquence JDLG, Eloquence WebDLG, the Eloquence IDE or the
eqstart utility.
Also, the Eloquence IDE may use the eloqsd file sharing functionality which may help
to overcome network file system limitations such as wide-area network incapability.
Starting with Eloquence B.08.20, the eloqsd server provides a new server-side
application configuration, improves access control for applications and shares,
allows to store user passwords in encrypted form and adds PAM authentication
on HP-UX and Linux.
User configuration
The eloqsd.user configuration supports the new config items PassKey,
GroupList and UsePAM (HP-UX and Linux).
The PassKey item is explained below in the section titled
"Store user passwords in encrypted form".
The UsePAM item (HP-UX and Linux) is explained below in
the section titled "PAM authentication on HP-UX and Linux".
GroupList config item
The GroupList item allows to associate a user with a list
of arbitrary group names, for example to arrange the configured users in
different categories.
These group names, or categories, may then be used in the
Application and Share configuration
files to restrict access to specific users.
GroupList accepts a comma-separated list of group names.
Multiple GroupList entries are recognized and combined.
The example below defines a user named "joe" in the eloqsd.user file
that belongs to the groups "users", "admins" and "local_users":
[joe]
GroupList = users, admins
GroupList = local_users
...
eloqsd.user file
The location of the eloqsd.user configuration file depends on the operating
system:
- HP-UX, Linux:
- /etc/opt/eloquence/8.2/eloqsd.user
template file: /opt/eloquence/8.2/newconfig/config/eloqsd.user
- Windows:
- C:\Program Files\Eloquence\8.2\etc\eloqsd.user
template file: C:\Program Files\Eloquence\8.2\etc\eloqsd.user.sam
(the location of the Eloquence base directory may be installation dependent)
Below is the default eloqsd.user file content, as found in the template file:
# eloqsd.user
# @(#) $Revision: 27.5 $
#
# The purpose of this file is to define all users which are known to
# Eloquence.
#
# HP-UX and Linux: /etc/opt/eloquence/8.2/eloqsd.user
# Windows: C:\Program Files\Eloquence\8.2\etc\eloqsd.user
#
# This file is read at the startup time of the eloqsd process.
# Changes are automatically detected and honored.
#
# This makes it possible to define Eloquence users without the
# need to have a system account for each individual user.
#
# Note on HP-UX and Linux:
# If clear text passwords are configured in this file we consider
# it good practice to make this file unreadable for regular users.
# You should chown it to the administrator (usually root) and
# chmod it to 400.
#
# Format:
#
# The section names are not case sensitive. String values can be
# enclosed in double quotes to protect leading or trailing spaces.
# Everything after a hash (#) character is considered a comment.
#
# Each user definition is a different section.
#
# The following configuration items are recognized for each section:
#
# [user_id]
#
# Name The full user name (currently unused)
#
# Password The user password (clear text)
#
# PassKey Refers to a password key defined in the eloqsd.pswd file.
# This is an alternative to using the Password item above.
# The eloqsd.pswd file stores passwords in encrypted form
# and is maintained by the eqpasswd utility.
#
# UID System account to execute client processes
#
# GID System group to execute client processes
#
# GroupList Comma-separated list of group names to specify the user
# group membership. Defined group names may be used in the
# GroupList item of the eloqsd.app and eloqsd.share files.
# Multiple GroupList entries are recognized and combined.
#
# UsePAM If nonzero, PAM (Pluggable Authentication Modules) is
# used to verify the password (Password/PassKey items
# are not used). Also, PAM is used to set UID/GID/GroupList
# unless UID/GID/GroupList are explicitly configured.
#
# Profile Template user entry. User defaults will be taken from
# this section.
#
# There are two predefined sections:
#
# [public] is used if a client does not provide a user id. This can
# only happen if an eloqcore process has been started locally and
# requests a remote operation. (currently unused)
#
# [default] is used as the default user profile.
[public]
Name = Anonymous
[default]
Name = Default user profile
#[demo]
#Name = Demo User
#Password = secret
Application configuration
Starting with Eloquence B.08.20, the eloqsd server provides a new server-side
application configuration, using the new eloqsd.app config file.
Previously, a client, for example Eloquence JDLG, was required to specify the
command line as well as the necessary environment variables to start an
application on the server. This behavior is still supported if the
[default] section is configured in the eloqsd.app
file (see below).
Beyond that, the new eloqsd application configuration allows for a server-side
definition of applications a specific user or client is permitted to start,
including the command line and environment variables and specifying which
environment variables are allowed to pass from the client.
A
JDLG application
configuration like below was typically used to start a program through
the specified eloqsd server. The example below configures the "ADMIN,APP"
program, using the eloqcore -log and -t command line options and defining
the HOME and EQPATH environment variables:
[ADMIN_TRACE]
name = ADMIN program with trace file
server = 192.168.1.11
protocol = rdlg
command = -log /tmp/eq-trace.log -t ADMIN,APP
environment = HOME=/home/$login
environment = EQPATH=/data/app/admin/prog:/data/app/common/prog
Please note that in the example above the eloqcore -log command line option
as well as the HOME and EQPATH environment variable definitions refer to
directories located on the server. Consequently, these definitions should
take place on the server side, not on the client.
To configure this application on the server side, the following section
could be added to the eloqsd.app configuration file:
[ADMIN,APP]
Env = HOME=/home/$user_name
Env = EQPATH=/data/app/admin/prog:/data/app/common/prog
EnvPass =
#Command = -log /tmp/eq-trace.log -t
Command = ADMIN,APP
Please note:
- The [ADMIN,APP] section name is matched against the last component
of the command line passed from the client, which is typically the
Eloquence program name. The section name is not case sensitive.
- The Env items define the environment
variables (see below). The $user_name
token is replaced with the name of the
connecting user when the application is started.
- An empty EnvPass item is configured
so that all environment variables the client might pass are dropped.
- The Command items define the command line. If configured,
the client command line is no longer used. In this example, the -log and -t
options are put into a separate Command item which may
then be enabled as needed.
Having this [ADMIN,APP] section configured in the eloqsd.app file, the
corresponding
JDLG application
configuration could be reduced to:
[ADMIN]
name = ADMIN program
server = 192.168.1.11
protocol = rdlg
command = ADMIN,APP
Here, the client configuration is reduced to the necessary options to address
the eloqsd server and to specify the program name, while the server-side details,
including whether or not to create a trace file, are configured on the server.
Defining environment variables
The Env item specifies an environment variable to be passed
to the application. Token resolving is applied (see
below). Multiple Env entries are
recognized and combined.
The example below defines the HOME and EQPATH environment variables for an
application named "ADMIN,APP" in the eloqsd.app file. The HOME variable uses
the $user_name token:
[ADMIN,APP]
Env = HOME=/home/$user_name
Env = EQPATH=/data/app/admin/prog:/data/app/common/prog
...
Passing client environment variables
The EnvPass item restricts which environment variables are
allowed to be passed from the client.
If EnvPass is configured, any variable a client passes must
be listed, otherwise it is not passed to the application.
If EnvPass is configured but empty, all variables a client
might pass are dropped.
EnvPass accepts a comma-separated list of environment variable
names. Multiple EnvPass entries are recognized and combined.
Please note: Variables passed from the client take precedence over variables
having the same name that are specified with the
Env item. This allows to configure a
fallback for variables a client might or might not pass.
For example, if a JDLG client is configured to use a nonstandard DLG port, it
might be required to pass the $host:$port connection argument to the program
if the
RDLG
protocol cannot be used. In this case, the
JDLG application
configuration typically specifies a command line using the -dlg $host:$port
option.
However, the eloqsd.app Command item overrides
the client command line, so that specifying the -dlg $host:$port command line option
on the client would have no effect. Instead, the $host:$port connection argument
should be assigned to an environment variable on the JDLG client, as shown in the
JDLG application
configuration example below:
[ADMIN]
name = ADMIN program
server = 192.168.1.11
command = ADMIN,APP
environment = DLG=$host:$port
The corresponding eloqsd.app configuration would then allow the DLG variable to
be passed from the client, so that it can be used in the command line, for example:
[ADMIN,APP]
Env = DLG=$peer_addr
EnvPass = DLG
Command = -dlg $(DLG) ADMIN,APP
...
In the example above, the eloqsd.app configuration includes a fallback definition
for the DLG variable in case it is not passed by the client, where it would be set
to the address of the PC running the JDLG client ($peer_addr), assuming the
standard DLG port.
StartDir config item
The StartDir item may be used to set the current directory
where an application is started. This overrides the start directory a client
may have passed. Token resolving is applied (see
below).
Please note: If the Command item is
configured, the start directory a client may have passed is never used,
because it is assumed that if an application defines a server-side command
line it would be inappropriate to accept a client-side start directory.
TTY config item (HP-UX and Linux)
On HP-UX and Linux, the TTY item supports character mode
application debugging by redirecting an application's stdin, stdout and
stderr streams to the specified TTY device. This overrides the TTY setting
a client may have passed. Token resolving is
applied (see below).
Token resolving
The Command,
Env,
StartDir and
TTY items may use the tokens listed below
which are resolved when the application is started:
- $peer_addr
- client IP address
- $peer_name
- client host name
- $user_name
- user name
- $(VARIABLENAME)
- value of an environment variable, including any variable
passed from the client (depending on the
EnvPass
configuration) or specified with the
Env item.
The example below defines an application named "ADMIN,APP" in the eloqsd.app
file that uses the $(DLG) token in the command line and the $peer_addr
and $user_name tokens in the specified environment variables:
[ADMIN,APP]
Env = DLG=$peer_addr
Env = HOME=/home/$user_name
Command = -dlg $(DLG) ADMIN,APP
...
UserList config item
The UserList item restricts which users are allowed to start
an application.
If UserList is configured, the connecting user must be listed,
otherwise the user is not allowed to start an application. The user names refer
to the configured users in the eloqsd.user file or, if
PAM authentication is used on HP-UX or Linux, to (selected)
operating system users.
UserList accepts a comma-separated list of user names.
Multiple UserList entries are recognized and combined.
The example below defines an application named "ADMIN,APP" in the eloqsd.app
file that restricts access to the users "bob", "joe" and "teresa":
[ADMIN,APP]
UserList = bob
UserList = joe, teresa
...
GroupList config item
The GroupList item restricts which groups are allowed to start
an application.
If GroupList is configured, the connecting user must be a member
of a group that is listed, otherwise the user is not allowed to start an application.
The group names refer to GroupList entries of the
configured users in the eloqsd.user file or, if
PAM authentication is used on HP-UX or Linux, to operating
system groups associated with the connecting user.
GroupList accepts a comma-separated list of group names.
Multiple GroupList entries are recognized and combined.
The example below defines an application named "ADMIN,APP" in the eloqsd.app file
that restricts access to those users that belong to the groups "admins", "operators",
"local_admins", or "local_operators":
[ADMIN,APP]
GroupList = admins, operators
GroupList = local_admins,local_operators
...
Restricting access by IP address
The AllowFrom and DenyFrom items restrict access
to an application based on the client IP address or an IP address range.
Multiple AllowFrom and/or DenyFrom entries are
recognized, using the syntax below:
AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
DenyFrom = {All | ip-address [/ {netmask | addrbits}]}
- ip-address
- IP v4 address, such as 127.0.0.1
- netmask
- IP v4 network mask, such as 255.255.255.0
- addrbits
- number of significant leading IP v4 address bits
If neither netmask nor addrbits is specified, an entry defaults
to a host address.
If neither AllowFrom nor DenyFrom are
configured, access to an application is enabled from all IP addresses
(implied AllowFrom=All).
If AllowFrom and/or DenyFrom are
configured, access to an application is denied unless specifically allowed
(implied DenyFrom=All).
The example below defines an application named "ADMIN,APP" in the eloqsd.app
file that restricts access to the local system (127.0.0.1) as well as to the
local network (192.168.1.1 to 192.168.1.254) except the 192.168.1.22 and
192.168.1.44 addresses:
[ADMIN,APP]
AllowFrom = 127.0.0.1
AllowFrom = 192.168.1.0/255.255.255.0
DenyFrom = 192.168.1.22
DenyFrom = 192.168.1.44
...
Using the addrbits notation, the AllowFrom rules in the example above could
also be specified like:
AllowFrom = 127.0.0.0/8
AllowFrom = 192.168.1.0/24
(The 255.255.255.0 netmask is equivalent to the leading 24 bits in an IP v4
address. Also, the local system might use any address ranging from 127.0.0.1
to 127.255.255.254, hence the 127.0.0.0/8 entry.)
Specifying the executable
By default, the eloqsd server starts an application using the eloqcore
executable located in the Eloquence bin directory.
The Execute item, if configured, allows to specify a
different executable. This could be used, for example, to start the
Eloquence dbutil program or to invoke a shell script that wraps the
eloqcore executable.
The eloqsd.app configuration below could be used to start the Eloquence
dbutil program from a JDLG client located on the local system (127.0.0.1
to 127.255.255.254) or in the local network (192.168.1.1 to 192.168.1.254):
[dbutil]
Execute = /opt/eloquence/8.2/bin/dbutil
Env = DLG=$peer_addr
EnvPass = DLG
Command = -D $(DLG)
AllowFrom = 127.0.0.0/8
AllowFrom = 192.168.1.0/24
The corresponding
JDLG application
configuration could be like:
[dbutil]
name = Eloquence dbutil
server = 192.168.1.11
command = dbutil
environment = DLG=$host:$port
Note that the DLG environment variable is allowed
to pass from the client. The JDLG client configuration above sets it
to $host:$port. If the client does not pass the DLG variable, the server
sets it to the address of the system running the JDLG client ($peer_addr),
assuming the standard DLG port. The DLG variable is then used with the
dbutil -D command line option.
Backward compatibility
The predefined [default] section is used as a fallback whenever an
application is not explicitly configured.
The eloqsd.app configuration template file defines an empty [default]
section to provide full backward compatibility for existing applications:
[default]
#UserList =
#GroupList =
#AllowFrom =
#DenyFrom =
Because no Command or EnvPass items
are defined, the client command line and environment variables are passed
to the application.
As shown above, the [default] section contains UserList,
GroupList, AllowFrom and
DenyFrom items which are commented out but may be
enabled as needed to restrict backward compatibility to specific users
or groups or client IP addresses.
For security reasons, it is recommended to add a specific configuration for
each application and then to remove or comment out the [default] section.
eloqsd.app file
The location of the eloqsd.app configuration file depends on the operating
system:
- HP-UX, Linux:
- /etc/opt/eloquence/8.2/eloqsd.app
template file: /opt/eloquence/8.2/newconfig/config/eloqsd.app
- Windows:
- C:\Program Files\Eloquence\8.2\etc\eloqsd.app
template file: C:\Program Files\Eloquence\8.2\etc\eloqsd.app.sam
(the location of the Eloquence base directory may be installation dependent)
Below is the default eloqsd.app file content, as found in the template file:
# eloqsd.app
# @(#) $Revision: 27.4 $
#
# The purpose of this file is to configure the applications
# a client is permitted to start through the eloqsd server.
#
# HP-UX and Linux: /etc/opt/eloquence/8.2/eloqsd.app
# Windows: C:\Program Files\Eloquence\8.2\etc\eloqsd.app
#
# This file is read at the startup time of the eloqsd process.
# Changes are automatically detected and honored.
#
# Format:
#
# The section names are not case sensitive. String values can be
# enclosed in double quotes to protect leading or trailing spaces.
# Everything after a hash (#) character is considered a comment.
#
# Each application definition is a different section.
#
# The app_id matches the last component of the command line that
# a client submits. Typically, this is an Eloquence program name.
#
# The following configuration items are recognized for each section:
#
# [app_id]
#
# Command Specifies the command line to start the application.
# If configured, it replaces the command line that a
# client submits.
#
# Command line arguments are separated with spaces. If an
# argument contains space characters it should be enclosed
# in single or double quotes.
#
# Token resolving:
#
# $peer_addr - client IP address
# $peer_name - client host name
# $user_name - user name
#
# $(VARIABLENAME) - value of an environment variable,
# including any variable passed from the client (depending
# on the EnvPass configuration, see below) or specified
# with the Env configuration (see below).
#
# Multiple Command entries are recognized. The command
# line is formed by concatenating the Command entries
# in the specified order.
#
# Env Specifies an environment variable to be passed to the
# application. Token resolving is applied as explained
# in the Command section above.
# Note: Variables passed from the client take precedence,
# as explained in the EnvPass section below.
# Multiple Env entries are recognized and combined.
#
# EnvPass Comma-separated list of environment variable names.
# The corresponding variables are allowed to be passed
# from the client. If configured, any variable a client
# passes must be listed, otherwise it is not passed to
# the application. If configured but empty, no variables
# are allowed to pass from the client.
#
# Note: Variables passed from the client take precedence
# over variables having the same name that are specified
# with the Env configuration (see above). This allows to
# configure a fallback for variables a client might pass.
#
# Multiple EnvPass entries are recognized and combined.
#
# StartDir Used to set the current directory where an application
# is started. Overrides the startdir a client may have
# passed. Token resolving is applied as explained in the
# Command section above.
# Note: If Command is configured, the startdir a client
# may have passed is never used.
#
# TTY Supports character mode application debugging, redirects
# an application's stdin, stdout and stderr to the specified
# TTY device. Overrides the TTY setting a client may have
# passed. Token resolving is applied as explained in the
# Command section above.
#
# UserList Comma-separated list of user names. If configured, the
# connecting user must be listed, otherwise the user is
# not allowed to start an application.
# Multiple UserList entries are recognized and combined.
#
# GroupList Comma-separated list of group names. If configured, the
# connecting user must be member of a group that is listed,
# otherwise the user is not allowed to start an application.
# Multiple GroupList entries are recognized and combined.
#
# AllowFrom Used to enable or reject access to an application based
# DenyFrom on the client IP address.
#
# AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
# DenyFrom = {All | ip-address [/ {netmask | addrbits}]}
# Multiple AllowFrom/DenyFrom entries are recognized and
# combined.
#
# ip-address: IP v4 address, such as 127.0.0.1
# netmask: IP v4 network mask, such as 255.255.255.0
# addrbits: number of significant leading IP v4 address bits
# If neither netmask nor addrbits is specified, an entry
# defaults to a host address.
#
# If neither AllowFrom nor DenyFrom are configured, access
# to an application is enabled from all IP addresses
# (implied AllowFrom=All).
# If AllowFrom and/or DenyFrom are configured, access to an
# application is denied unless specifically allowed
# (implied DenyFrom=All).
#
# Execute If configured, specifies the executable to start the
# application. By default, this is the eloqcore executable
# located in the Eloquence bin directory.
#
# The predefined [default] section, if configured, is used whenever
# an application is not explicitly configured.
#
# The [default] section below is configured for backward compatibility
# to retain the previous eloqsd behavior, where any client may start
# any application. The UserList/GroupList/AllowFrom/DenyFrom items may
# be configured to restrict this to specific users or groups or client
# IP addresses.
#
# For security reasons, it is recommended to add a specific configuration
# for each application and then to remove or comment out the [default]
# section below.
[default]
#UserList =
#GroupList =
#AllowFrom =
#DenyFrom =
# The example configuration below matches a program named EXAMPLE
# located in the APP volume (client command line: EXAMPLE,APP)
#
# It allows the DLG environment variable to be passed from the client.
# On a JDLG client, DLG would typically be set to $host:$port. If DLG
# is not set by the client, an Env configuration makes sure it is set
# to the peer address. The DLG variable is then used with the -dlg
# command line option when starting the EXAMPLE,APP program.
#[EXAMPLE,APP]
#Env = DLG=$peer_addr
#Env = HOME=/home/$user_name
#EnvPass = DLG
#Command = -dlg $(DLG) EXAMPLE,APP
# The [dbutil] configuration below could be used to start the Eloquence
# dbutil program from a JDLG client located on the local machine or in
# the local network (assuming 192.168.1.0/24).
#
# Corresponding JDLG application configuration:
# [dbutil]
# name = Eloquence dbutil
# server = 192.168.1.11
# command = dbutil
# environment = DLG=$host:$port
#[dbutil]
#Execute = /opt/eloquence/8.2/bin/dbutil
#Env = DLG=$peer_addr
#EnvPass = DLG
#Command = -D $(DLG)
#AllowFrom = 127.0.0.0/8
#AllowFrom = 192.168.1.0/24
Share configuration
The eloqsd.share configuration supports the new config items UserList,
GroupList, AllowFrom and DenyFrom.
UserList config item
The UserList item restricts which users have access to a share.
If UserList is configured, the connecting user must be listed,
otherwise access to a share is denied. The user names refer to the configured
users in the eloqsd.user file or, if PAM
authentication is used on HP-UX or Linux, to (selected) operating system
users.
UserList accepts a comma-separated list of user names.
Multiple UserList entries are recognized.
The example below defines a share named "projects" in the eloqsd.share file
that restricts access to the users "adam", "joe" and "mary":
[projects]
UserList = adam
UserList = joe, mary
...
GroupList config item
The GroupList item restricts which groups have access to a share.
If GroupList is configured, the connecting user must be a member
of a group that is listed, otherwise access to a share is denied. The group names
refer to GroupList entries of the configured users
in the eloqsd.user file or, if PAM authentication
is used on HP-UX or Linux, to operating system groups associated with the
connecting user.
GroupList accepts a comma-separated list of group names.
Multiple GroupList entries are recognized.
The example below defines a share named "projects" in the eloqsd.share file
that restricts access to those users that belong to the groups "users", "local_users"
or "local_admins":
[projects]
GroupList = users, local_users
GroupList = local_admins
...
Restricting access by IP address
The AllowFrom and DenyFrom items restrict
access to a share based on the client IP address or an IP address range.
Multiple AllowFrom and/or DenyFrom entries are
recognized, using the syntax below:
AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
DenyFrom = {All | ip-address [/ {netmask | addrbits}]}
- ip-address
- IP v4 address, such as 127.0.0.1
- netmask
- IP v4 network mask, such as 255.255.255.0
- addrbits
- number of significant leading IP v4 address bits
If neither netmask nor addrbits is specified, an entry defaults
to a host address.
If neither AllowFrom nor DenyFrom are
configured, access to a share is enabled from all IP addresses (implied
AllowFrom=All).
If AllowFrom and/or DenyFrom are
configured, access to a share is denied unless specifically allowed
(implied DenyFrom=All).
The example below defines a share named "projects" in the eloqsd.share file
that restricts access to the local system (127.0.0.1) as well as to the local
network (192.168.1.1 to 192.168.1.254) except the 192.168.1.22 and 192.168.1.44
addresses:
[projects]
AllowFrom = 127.0.0.1
AllowFrom = 192.168.1.0/255.255.255.0
DenyFrom = 192.168.1.22
DenyFrom = 192.168.1.44
...
Using the addrbits notation, the AllowFrom rules in the example above could
also be specified like:
AllowFrom = 127.0.0.0/8
AllowFrom = 192.168.1.0/24
(The 255.255.255.0 netmask is equivalent to the leading 24 bits in an IP v4
address. Also, the local system might use any address ranging from 127.0.0.1
to 127.255.255.254, hence the 127.0.0.0/8 entry.)
eloqsd.share file
The location of the eloqsd.share configuration file depends on the operating
system:
- HP-UX, Linux:
- /etc/opt/eloquence/8.2/eloqsd.share
template file: /opt/eloquence/8.2/newconfig/config/eloqsd.share
- Windows:
- C:\Program Files\Eloquence\8.2\etc\eloqsd.share
template file: C:\Program Files\Eloquence\8.2\etc\eloqsd.share.sam
(the location of the Eloquence base directory may be installation dependent)
Below is the default eloqsd.share file content, as found in the template file:
# eloqsd.share
# @(#) $Revision: 27.4 $
#
# The purpose of this file is to define all disk resources which are
# known to Eloquence.
#
# HP-UX and Linux: /etc/opt/eloquence/8.2/eloqsd.share
# Windows: C:\Program Files\Eloquence\8.2\etc\eloqsd.share
#
# This file is read at the startup time of the eloqsd process.
# Changes are automatically detected and honored.
#
# Eloquence provides its own file sharing capabilities.
# This will make you independent of the availability of specific
# network file systems (NFS/SMB) and overcomes possible file system
# limitations.
#
# Format:
#
# The section names are not case sensitive. String values can be
# enclosed in double quotes to protect leading or trailing spaces.
# Everything after a hash (#) character is considered a comment.
#
# Each share definition is a different section.
#
# The following configuration items are recognized for each section:
#
# [share_id]
#
# Path Absolute path
#
# Comment Share description. This is displayed by the client.
#
# UserList Comma-separated list of user names. If configured, the
# connecting user must be listed, otherwise access to a
# share is denied.
# Multiple UserList entries are recognized and combined.
#
# GroupList Comma-separated list of group names. If configured, the
# connecting user must be member of a group that is listed,
# otherwise access to a share is denied.
# Multiple GroupList entries are recognized and combined.
#
# AllowFrom Used to enable or reject access to a share based on the
# DenyFrom client IP address.
#
# AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
# DenyFrom = {All | ip-address [/ {netmask | addrbits}]}
# Multiple AllowFrom/DenyFrom entries are recognized and
# combined.
#
# ip-address: IP v4 address, such as 127.0.0.1
# netmask: IP v4 network mask, such as 255.255.255.0
# addrbits: number of significant leading IP v4 address bits
# If neither netmask nor addrbits is specified, an entry
# defaults to a host address.
#
# If neither AllowFrom nor DenyFrom are configured, access
# to a share is enabled from all IP addresses
# (implied AllowFrom=All).
# If AllowFrom and/or DenyFrom are configured, access to a
# share is denied unless specifically allowed
# (implied DenyFrom=All).
#[example]
#Path = /opt/eloquence/8.2/share
#Comment = Eloquence shared files
Store user passwords in encrypted form
The new eloqsd.pswd configuration supports storing eloqsd user passwords
in encrypted form.
Encrypted passwords are maintained with the eqpasswd utility and kept in the
eloqsd.pswd configuration file.
The PassKey user configuration item is
used to refer to encrypted passwords stored in the eloqsd.pswd file.
Please note: While passwords in the eloqsd.pswd file are encrypted with the
256-bit AES encryption algorithm so they are protected against accidential
disclosure, a fixed internal encryption key is currently used which cannot
be changed by the user.
The eqpasswd utility
usage: /opt/eloquence/8.2/bin/eqpasswd [options] passkey
options:
-help - show usage (this list)
-a - add new passkey entry
-d - delete passkey entry
-f pswdfile - encrypted passwords file name
(default is configured in eloqsd.cfg file)
The -a option is used to add a new passkey/password combination.
The passkey is specified on the command line. The eqpasswd
utility then prompts for the associated password.
The -d option is used to delete a passkey.
When neither the -a nor the -d option is present, the password
for the specified passkey is updated. The eqpasswd utility
then prompts for the associated password.
Encrypted passwords are maintained in a file specified in the
eloqsd.cfg config file (by default eloqsd.pswd). To add a passkey,
change a password or delete a passkey, write access to the
password file is required. At runtime, the password file is
also read by the eloqsd process.
The -f option instructs eqpasswd to use the specified password
file instead of the default eloqsd.pswd file.
For example:
$ /opt/eloquence/8.2/bin/eqpasswd -a joe
Adding new password entry for 'joe'.
New password:
Reenter new password:
Password entry added.
This adds the encrypted password to the password file, associated
with the specified passkey "joe".
$ /opt/eloquence/8.2/bin/eqpasswd joe
Changing password entry for 'joe'.
New password:
Reenter new password:
Password entry changed.
This changes the password associated with the passkey "joe".
PassKey config item
The PassKey item may be specified as an alternative to
the Password item in the eloqsd.user
configuration. The PassKey item, if present, takes
precedence over the Password item.
The PassKey item specifies an entry in the password file
so that the associated password is used to authorize a user.
The example below defines a user named "joe" in the eloqsd.user
file that uses a PassKey to define the user password.
[joe]
PassKey = joe
...
PAM authentication on HP-UX and Linux
Starting with Eloquence B.08.20, the eloqsd server supports PAM
(Pluggable Authentication Modules) user authentication on the HP-UX
and Linux platforms. This allows to configure the eloqsd server to
use the operating system users and passwords.
PAM authentication may be globally enabled in the eloqsd.cfg config file so
that the eloqsd.user configuration is no longer used.
The PAM subsystem may be configured to restrict which users are allowed to
logon to the eloqsd, for example only those users belonging to a specific
group (see below).
Alternatively, the UsePAM item in the
eloqsd.user configuration may be used for specific users,
so that these users authenticate against PAM.
Globally enabling PAM authentication
The AuthPolicy item in the eloqsd.cfg config file may be
set to "pam" to globally enable PAM authentication:
AuthPolicy = pam
If PAM authentication is globally enabled, the eloqsd.user
configuration is no longer used. Instead, PAM is used to verify a user's
password and to obtain the user's UID, GID and GroupList properties.
To use this, it is typically required to configure the PAM subsystem for
the eloqsd service and optionally to restrict which users are allowed to
logon to the eloqsd (see below).
User-specific PAM authentication
In case the globally enabled PAM authentication is not applicable, it is
possible to still use the eloqsd.user configuration
while using PAM for password verification.
To use this, the AuthPolicy item in the eloqsd.cfg config
file must be set to "server" (the default) and the UsePAM
item in the eloqsd.user config file must be set to 1
for those users where PAM authentication should be used. Also, it is
typically required to configure the PAM subsystem for the eloqsd service
(see below).
The example below defines a user named "joe" in the
eloqsd.user file that uses PAM authentication:
[joe]
UsePAM = 1
If the user "joe" tries to logon to the eloqsd, the PAM subsystem is
queried for a user named "joe". If this user exists and the user's
account is valid and the password matches, the user is logged on.
Please note: If PAM authentication is used, the Password
and PassKey items are ignored. Furthermore, the
UID, GID and GroupList
items are not required. If present, they are used as specified. If not,
PAM is used to obtain the user's UID, GID and GroupList properties.
PAM configuration on Linux
On Linux, the PAM subsystem is usually configured using service-specific files
in the /etc/pam.d directory. The eloqsd PAM authentication uses the "eloqsd"
service name, which typically requires that the /etc/pam.d/eloqsd PAM configuration
file is created and configured. Without this file, the eloqsd service would
fall into the "other" service category which is usually configured to deny
any request.
A typical content of the /etc/pam.d/eloqsd PAM configuration file could be
like:
#%PAM-1.0
auth required pam_unix.so
account required pam_unix.so
session required pam_limits.so
session required pam_unix.so
This configuration instructs the PAM subsystem to verify that the user exists
and is allowed to logon, e.g., that the account is active and does not violate
any configured limits, and that the user's password is not expired and matches
the password that was submitted to the eloqsd.
Based on that, additional rules may be implemented, preferably using the
pam_succeed_if module (see also: man pam_succeed_if).
For example, the line below, appended to the /etc/pam.d/eloqsd configuration file,
would require that the users belong to the group named "eloqsd_allow":
account required pam_succeed_if.so quiet user ingroup eloqsd_allow
As shown in the example above, it is recommended to use the pam_succeed_if
"quiet" option to avoid that each eloqsd logon attempt is logged to the
Linux syslog.
Please note that on older Linux installations the /etc/pam.d directory might
not exist, in which case the /etc/pam.conf configuration file is used.
The above examples, adapted to the /etc/pam.conf configuration, would look
like:
# Eloquence eloqsd
eloqsd auth required pam_unix.so
eloqsd account required pam_unix.so
eloqsd account required pam_succeed_if.so quiet user ingroup eloqsd_allow
eloqsd session required pam_limits.so
eloqsd session required pam_unix.so
PAM configuration on HP-UX
On HP-UX, the PAM configuration file is /etc/pam.conf.
The eloqsd PAM authentication uses the "eloqsd" service name. By default,
the /etc/pam.conf does not contain a configuration for the eloqsd service,
therefore the eloqsd service falls into the "other" category which by
default is sufficiently configured so that any user allowed to logon to
the system would be as well allowed to logon to the eloqsd.
However, if additional rules are desired, for example to require that the
eloqsd users belong to a specific group, it is necessary to use a specific
eloqsd configuration in the /etc/pam.conf file, like below:
# Eloquence eloqsd
eloqsd auth required libpam_hpsec.so.1
eloqsd auth required libpam_unix.so.1
eloqsd account required libpam_hpsec.so.1
eloqsd account required libpam_authz.so.1
eloqsd account required libpam_unix.so.1
eloqsd session required libpam_hpsec.so.1
eloqsd session required libpam_unix.so.1
This example uses the pam_hpsec and pam_unix modules to instruct the
PAM subsystem to verify that the user exists and is allowed to logon, e.g.,
that the account is active and does not violate any configured limits,
and that the user's password is not expired and matches the password that
was submitted to the eloqsd.
In addition, it configures the pam_authz module for the PAM account management
group, which allows to implement additional rules in the
/etc/opt/ldapux/pam_authz.policy file (see also: man pam_authz).
Example /etc/opt/ldapux/pam_authz.policy file:
# /etc/opt/ldapux/pam_authz.policy
# Eloquence eloqsd logon restrictions
# Note: Use the pam_authz module for the eloqsd service only!
allow:unix_group:eloqsd_allow
deny:unix_group:eloqsd_deny
This specifies two groups, "eloqsd_allow" and "eloqsd_deny". Users belonging
to the eloqsd_allow group are allowed to logon to the eloqsd. To explicitly
deny eloqsd logon for specific users, those users could be added to the
eloqsd_deny group.
Please note: It is not possible to configure the pam_authz module so that
it uses a configuration specific to a particular PAM service. Therefore,
if the /etc/opt/ldapux/pam_authz.policy file is configured for the eloqsd
service, usually the pam_authz module should not be used for any service
other than eloqsd in the /etc/pam.conf file.
|