Eloquence version B.08.30 is currently in beta test stage.
A production release is expected to be available in Q3/2018.
Unfortunately, only a preliminary documentation is currently available.
Welcome to the B.08.30 test release.
The Eloquence B.08.30 release extends on the successful B.08.20 release
and delivers improved efficiency and scalability as well as updated
technologies.
Major changes include:
-
Database server performance improvements.
The Eloquence database was further enhanced to improve performance and
efficiency on contemporary hardware.
The Eloquence B.08.30 database is expected to deliver noticeably improved
throughput with a lower CPU utilization for a variety of workloads.
The database adds speculative read-ahead to improve disk I/O rates
and concurrency. The database server may read-ahead data content
that is likely to be used, depending on application access patterns.
This speculative disk I/O is performed asynchronously in parallel
or while the application is processing the previous data.
The replication slave server uses parallel disk I/O to improve
replication performance.
-
Improved FTS scalability and new FTS dictionary pools.
-
Support for compressed forward log files.
-
IPv6 support.
-
On the HP-UX and Linux platform support for local sockets was
introduced as an alternative to local TCP sockets to connect
the database server. Local sockets are more efficient then regular
TCP sockets and do not require system configuration.
-
Database security improvements.
Most visibly, a new hashing scheme is used to secure database passwords.
-
A new DLG protocol was designed to improve JDLG
usability in cloud environments or using high latency networks (such as
the internet).
Both the number of messages between JDLG and the application
backend is reduced as well as the amount of traffic.
The new protocol supports compressed bulk transfer, allows for
server side caching to reduce the number of round trips and
supports encrypted transport.
Information on the DLGv2 behaviour in eloqcore is
described in the DLGv2 document.
-
The Java based GUI (JDLG) comes in a new major version, and
delivers noticeably improved performance and efficiency.
JDLG improves performance with existing environments and is
noticeably faster when used with B.08.30 using the new
DLG protocol version.
JDLG 2.0 is
available for download.
-
The terminal handling was enhanced to
support a Unicode environment on all platforms.
On Linux and Unix, the terminal subsystem supports UTF-8
environments transparently.
The new eloqcore
CRT configuration allows to configure terminal properties such as the
linedraw character mapping and, on Windows, the console font and colors.
-
The eqpcl utility was enhanced to support a subset of unicode characters.
-
Thread safe database client libraries.
-
The Eloquence image3k (and ftc) libraries support an additional
"Big Endian" byte order on "Little Endian" platforms. This will
simplify migration of Cobol based IMAGE applications to Linux.
-
Fixed a number of issues with more than 2 billion records in a table.
A number of database utilities had minor issues with database
tables with more than 2 billion records. query3k simply failed
and the database server could abort when exceeding 4 billion
records per table.
-
Systemd support on Linux.
-
The eloqsd server was enhanced to support
TLS-encrypted network connections.
The Internet Protocol version 6 (IPv6) is an improved version of
the Internet Protocol (IP) that is used for almost all network
communication.
IPv6 was developed by the Internet Engineering Task Force (IETF) to
address, among others, the anticipated problem of IPv4 address exhaustion.
IPv6 became a Draft Standard in December 1998, and became an
Internet Standard on 14 July 2017.
The most visible difference to IPv4 is that internet addresses are
using 128 bits (rather than 32 bits with IPv4) and use a different
notation. IPv4 addresses use a "dottet decimal notation", for example
"172.16.254.1". IPv6 uses a hex notation where colons separate
each 16 bit groups and any zero sequences may be omitted, for example
"2001:0dbb:ac10:fe01::".
As the colon separator in the IPv6 notation could be ambigous
Eloquence requires any IPv6 IP address to be enclosed in square
brackets. For example, the local address becomes [::1].
Another change introduced is that host names may support more than
one IP address which could be either IPv4 or IPv6. Eloquence tries
them in order (as configured by the OS), silently ignoring any
connection failures until a connection completes.
IPv6 may coexist with IPv4. Any Eloquence server process, such as eloqdb,
may be configured to use a single IPv6 socket supporting IPv4 and
IPv6 connections or separate the two IP protocols.
Any IPv4 access limits specified in Eloquence also apply to mapped
IPv4 connections using an IPv6 listening socket.
By default Eloquence uses separate sockets for both IPv4 and IPv6
connections.
See also:
http://en.wikipedia.org/wiki/IPv6
In previous versions, Eloquence used a secure hash to encode any
database passwords. As of B.08.30 the standard PBKDF2 algorithm
is used to hash passwords with salting.
This is intended to provide additional protection against reverse
lookup of passwords if the hashed password hash value might have
been exposed. Eloqdb password hashes are only visible to the dba user.
As a related change the database protocol was enhanced to handle
password salting and additional hashing schemes and to improve the
encryption of passwords in transit.
The database library was changed to support the new password encoding
and protocol. As a consequence Eloquence versions before B.08.30 are
no longer able to authenticate passwords with B.08.30 and beyond
if the new password encoding is used. Compatibility is not affected
if a database account does not use a password or uses the old password
encoding scheme.
As Eloquence on HP-UX (and Linux) makes use of the openssl library
for crypto functionality, installation of openssl on HP-UX is now
required to use the new password hashing.
Password authentication will fail if the crypto functionality is not
available.
See also:
http://en.wikipedia.org/wiki/PBKDF2
Dynamic libraries
Eloquence internally does no longer use static linking. Instead it
links the Eloquence database and support libraries dynamically.
This allows for minimizing updates if a problem in a library was
corrected that might also affect database utilities.
As a consequence, Eloquence utilities depend on accessing the
correct database libraries. An improperly set LD_LIBRARY_PATH
(or SHLIB_PATH on HP-UX) may impact the correct function.
Due to the new password hashing scheme, any application or utility
connecting to the database depends on the database client library
using the openssl crypto library.
While previously openssl was optional and only used with database
encryption it is now mandatory to use the new database password
handling.
The Eloquence database client libraries (eqdb, image3k and ftc)
are now thread safe by default. The default thread model used by
Eloquence separates each thread, similar to processes.
Each thread is required to open databases separately, accessing
a database from another thread is not possible.
With the IMAGE database calls it is not sufficient to simply
protect against concurrent calls by multiple threads. Typically
database calls depend on a context that needs to be protected against
concurrent modification. Examples include the current record, current path,
chain, FTS results or database transactions or locks.
Enabling shared access among threads would require potentially complex
application locking to protect the database context and is unlikely
to achieve better performance. A welcome benefit of the thread separation
is avoiding any locking overhead for typical database accesses.
To support more complex approaches (eg. thread pools) Eloquence also
supports changing the association between threads and database
contexts. The database context may be released by a thread and is
then available to be requested by another thread. This allows switching
the ownership of database contexts for the duration of a transaction
rather than dealing with individual calls.
The terminal handling was enhanced to support a Unicode environment on
all platforms.
On HP-UX and Linux, the terminal subsystem supports UTF-8 environments
transparently.
Eloquence on Windows uses Unicode for the console output.
Eloquence terminal handling was enhanced to support terminals using the
UTF-8 character set encoding, in addition to HP-ROMAN8 and ISO-8859-1
and ISO-8859-15 character sets.
For some "known" terminal types the character set is fixed, for example
the HP-ROMAN8 character set is always used with 70092 terminals.
Otherwise, the character set of the locale (LANG or LC_CTYPE) is used
to define the character set encoding. This allows to use different
encodings with the same terminal type. For example, the xterm terminal
type may be used with various character sets.
If the character set encoding supports the EURO symbol (utf-8 and
iso-8859-15) the "currency symbol" character is mapped to the EURO symbol.
Eloquence applications are now able to output unicode characters to
the screen or a dialog. It depends on the terminal capabilities to
what extent this is visible.
The new eloqcore
CRT configuration allows to configure terminal properties such as the
linedraw character mapping and, on Windows, the console font and colors.
The eloqdb database server performance and scalability was
further improved.
For a variety of work loads the Eloquence B.08.30 database
server can noticeably improve throughput using less CPU cycles.
An optimization of the internal locking strategy results in reduced
overhead, improved performance and concurrency. Most work loads are
expected to see a noticeable improvement in throughput with lower CPU
utilization.
The internal buffer cache management was changed to perform efficiently
with large buffer cache configurations. As a result, the size of the
buffer cache should only have a negligible effect on the management
overhead and allows to configure larger buffer cache sizes.
More efficient handling of deleted records. Skipping a large number
of deleted records could impact performance with previous eloqdb
versions. While skipping over a large number of deleted records may
still result in additional disk I/O it should be of little consequence
otherwise.
Speculative read-ahead and asynchronous I/O
The database adds speculative read-ahead to improve disk I/O rates
and concurrency. The database server may read-ahead data content
that is likely to be used, depending on application access patterns.
This speculative disk I/O is performed asynchronously in parallel
or while the application is processing the previous data.
For example, reading a record in chained order may trigger disk I/O
on subsequent records.
The replication slave disk read is now executed in parallel to
improve replication performance bounded by disk I/O.
The AIOThreads configuration must be set to enable use of the
asynchronous disk reads. On HP-UX IA64 the Kernel AIO functionality
is used to handle disk read-ahead with little overhead, requiring only
few internal I/O threads. On other platforms, internal I/O threads are
used to perform disk read-ahead asynchronously and the number of
I/O threads defines the number of concurrent async disk read operations.
A number of FTS indexing scalability and performance enhancements
were developed for B.08.30, specifically improving performance for
large environments.
Scanning the dictionary index for a keyword range or wildcard
uses a more efficient approach to iterate the index. Instead of
obtaining keyword entries separately, an entire index page is
fetched and processed internally at once.
This reduces the overhead and locking contention.
In addition the searching process was optimized to avoid
internal locking on keywords that have no reference in the
searched context.
Caching some FTS internal results makes access to FTS references
substantially more efficient and reduces contention of the
buffer cache.
Handling of FTS keywords with a large number of references was
improved to be more I/O efficient. When creating new FTS indexes
(or re-creating existing ones) an additional storage pool is
created to maintain keywords with a lage number of references.
Please be aware that feature this is not backwards compatible to
previous Eloquence releases and requires rebuilding FTS indexes.
FTS was enhanced to support multiple keyword pools. Before B.08.30
a single dictionary index was used to maintain any keyword for
the entire database. This could result in a large dictionary
and could affect performance in some range searches where a
large number of keywords exist that are not relevant in the
current search context. Using a separate dictionary index makes
those searches instantaneous and allows to maintain similar
keywords (for example, date ranges) in a separate dictionary.
When enabled in the eloqdb configuration forward log files are
compressed. This will noticeably reduce the size of forward log
files in exchange for additional CPU utilization to compress the
data. It depends on the system CPU resources and the disk bandwidth
if this is beneficial to performance.
The forward log files may also be compressed afterwards with gzip
(for example, when changing forward log files).
The Eloquence utilities (as well as the fwutil library) handle
compressed forward log files transparently.
On the Linux platform, Eloquence preferably uses systemd to manage
services where available. The systemd services provide similar
functionality as the Eloquence SystemV start/stop scripts.
The following systemd unit files are available:
-
eloquence83.target
-
The Eloquence target encloses any enabled or running Eloquence
B.08.30 services. The target may be used to start or shut down
all Eloquence B.08.30 services.
-
eloqdb83.service
-
The default Eloquence database instance.
-
eloqdb83@.service
-
Additional Eloquence database instances. The instance name is
specified after the @ sign and implies the database server
configuration file name.
For example, a eloqdb83@test.service would use the eloqdb-test.cfg
configuration file.
-
eloqsd83.service
-
The Eloquence eloqsd service
-
dbrepl83.service
-
The default Eloquence database replication instance
-
dbrepl83@.service
-
Additional Eloquence database replication instances. The
instance name is specified after the @ sign and implies
the dbrepl configuration file.
For example, a dbrepl83@test.service would use the configuration
file repl-test.cfg.
The unit file names are versioned to allow coexistence with other
Eloquence releases. Once enabled and started a service name without
a version number may be used as an alias.
The Eloquence services are not enabled by default. Please use
"systemctl enable ..." to enable the necessary services for autostart.
As system wide systemd services requires root access sudo may be used
to allow non-root users starting and stopping Eloquence services.
The config items below are new or were changed in the eloqdb.cfg
database configuration file.
The [Server] section has the following
configuration changes:
-
[Server] Service
-
This configuration item specifies the service name (as defined in
/etc/services) or the port number where the server should listen
for requests. The default value is eloqdb.
A suffix /4, /6, or /46 may be used to establish IPv4 only,
IPv6 (with implied IPv4 support), or separate IPv4 and IPv6
listening sockets. By default, separate IPv4 and IPv6 sockets are
used.
For example, "eloqdb/46" would specify to use the port number
associated with the service name eloqdb and to use separate
IPv4 and IPV6 sockets.
-
[Server] ServiceHttp
-
The service name (as defined in /etc/services) or the port number
where the server should listen for HTTP requests. If this is not
specified the HTTP status is disabled.
A suffix /4, /6, or /46 may be used to establish IPv4 only,
IPv6 (with implied IPv4 support), or separate IPv4 and IPv6
listening sockets. By default, separate IPv4 and IPv6 sockets are
used.
For example, 8103/6 would specify to use the port number 8103
and to use a single socket for IPv4 and IPv6 connections.
-
[Server] ServiceLocal
-
This configuration item specifies the name or path of an AF_Unix
socket to be used as an additional method to connect the database
server. If not specified the local socket connection is disabled.
An absolute file name may be specified with a leading slash.
Otherwise the file name is relative to the default directory
/var/opt/eloquence/socket. Please note that a matching
definition must be used on the client library to use local sockets.
For example, ServiceLocal=eloqdb creates the socket file
/var/opt/eloquence/socket/ eloqdb.
A prefix of /local:eloqdb would then access the database
using the local socket (EQ_DBSERVER=/local:eloqdb).
-
[Server] UseKeepAlive
-
A numeric flag to specify that the tcp keep alive socket option is used.
Valid values are 1 and 0, the default is 1.
If set the operating system may verify whether the client is still
connected after a system defined time of inactivity.
The sections [db-access] and [http-access]
that are used to specify access to the Eloquence database server
now support IPv6 addresses and host names.
The following syntax is supported:
{allow|deny} = { All
hostname
ip-address [/{addrbits|netmask}] }
-
hostname is the name of a host or network that is resolved into
one or more ip addresses.
-
ip-address is either an IPv4 or IPv6 address.
-
An IPv6 address, enclosed in square brackets, such as [::1].
The addrbits option may be used to specify the number of relevant
bits in the IP address.
-
An IPv4 address, such as 127.0.0.1. The addrbits option may be
used to specify the number of relevant bits in the IP address.
The netmask option allows to specify an IPv4 network mask,
such as 255.255.255.0.
Multiple Allow/Deny entries are recognized and combined.
The following defaults are used:
If the section [db-access] is not present, access is restricted
to localhost (127.0.0.1 and [::1]).
If the section [http-access] is not present, access to
the database http status is not restricted.
For example:
allow = localhost
allow = 192.68.71.0/24
allow = [2001:4860:4802:38:]/64
A local socket is considered local access and always allowed,
subject to file system permissions.
As of B.08.30 the access lists may also be configured using
the dbctl access command.
The follwing entries were added to the [config]
section:
-
[Config] AIOThreads
-
The AIOThreads configuration item specifies the number of internal
I/O threads used by eloqdb.
On HP-UX IA64 the kernel Posix AIO functionality is used by default
and only two threads are required. Otherwise the specified number of
internal I/O threads defines the number of concurrent async disk read
operations. A zero value (default) disables async I/O.
It is recommended to set AIOThreads to two on HP-UX IA64 based systems
and to at least 4 on other platforms.
On slave replication servers AIOThreads should be set to benefit from
parallel disk reads applying replicated transactions.
-
[Config] SessionFtsLimit
-
The SessionFtsLimit config item may be used to limit the memory allocated
for a session to hold FTS search results or intermediate results.
The numeric value specifies the number of internal results supported
(which could be different from the search results). An additional k or m
multiplies this value
by 1000 or 1 million. A zero value disables the limit. For example,
SessionFtsLimit = 100m
The [devices] section is used to define dbstore/dbrestore
targets.
The backup path does no longer support specifying a command with a
leading pipe (for example, using gzip to compress the dbstore archive).
As an alternative, the dbstore utility and the dbctl dbstore
commands support compression and dbctl dbrestore transparently handles
compressed archive files. As an additional enhancement
dbctl dbstore/dbrestore allow absolute paths and do no longer
depend solely on configuring dbstore/dbrestore targets.
The [ForwardLog] section has the following
configuration changes:
-
[ForwardLog] FwLog
-
Configures the forward log file. The %N token in the
file name (now mandatory) is replaced by the forward log file
generation and sequence.
By default, forward-logging is inactive.
For compressed forward log files the .gz extension (FwCompressExt)
is automatically added to the file name.
For example, FwLog = /data/fwlog/fw-%N.log
Previous versions also allowed to specify a command to handle the
forward log file, for example to compress the forward log file.
This is no longer supported.
The FwCompress option may be used to write a compressed forward log
file.
-
[ForwardLog] FwArchive
-
FwArchive may be used to specify a list of directories, separated by a
colon (or semicolon on Windows) to hold forward log files in addition
to the directory specified in the FwLog config item.
By default, FwArchive is not set. This configuration may be used to
locate archived forward log files.
This configuration item is used by database utilities, such as dbrepl
or dbrecover that access the forward log.
For example, FwArchive = /data/archive1:/data/archive2
-
[ForwardLog] FwCompress
-
A numeric flag to specify whether the forward log files are compressed.
By default compression is not active.
Compression will noticeably reduce the size of forward log files in
exchange for additional CPU utilization to compress the data.
It depends on the system CPU resources and the disk bandwidth if
this is beneficial to performance.
The forward log files may also be compressed afterwards with gzip (for
example, when changing forward log files). The Eloquence utilities
(as well as the fwutil library) handle compressed forward log files
transparently.
-
[ForwardLog] FwCompressExt
-
FwCompressExt specifies the extra file extension to indicate a
compressed file. The default is gz.
The following config items are obsolete and result in a warning.
[Config]IOThreads
[Config]IOQueueSize
[ForwardLog]FwRecovery
IOThreads/IOQueueSize was used before Eloquence B.08.00 to scale the
disk I/O concurrency. FwRecovery is no longer supported as of B.08.30.
It was used to specify a command to uncompress a forward log file.
The new dbctl access command may be used to manage the [db-access]
or [http-access] filter.
The following syntax is supported:
dbctl access show [db|http]
dbctl access add [db|http] {allow|deny} address
dbctl access reset [db|http] [{allow|deny} address]
The first argument specifies the operation, the second the access-filter
to operate on (db or http).
The show operation lists the current access rules for the specified
section. For example:
dbctl -u dba access show db
# show Access
-- ------------------------------------
1 Allow localhost
2 Allow 10.64.71.0/255.255.255.0
The add operation adds a new access rule. The reset operation is used
to reset all access rules and optionally allows to add a new access rule
at the same time, for example, to keep remote access functional when
the reset operation is used remotely.
Please refer to the eloqdb [db-access] documentation for more
information about the access and address argument.
For example:
dbctl -u dba access add db allow 10.64.71.0/24
dbctl -u dba access reset db allow 10.64.71.0/24
dba or operator capabilities are required.
The dbctl dbstore command transfers a single database to the target
archive.
dbctl dbstore [/z] database target
In order to store a database, database admin (dadmin) or server admin
(dba) or operator capabilities are required.
The target archive may start with a leading slash to specify an
absolute file name. The file must not exist and is created by
dbstore.
Otherwise the target specifies either the name of a configured
server device or the name of a server device and a filename
separated by a slash.
If the dbstore target is a disk file, it will be created with
permissions that restrict access to the UID used for running
the database server.
The /z option may be specified to enable compression of the
store archive. It is recommended to use a .gz extension with
a compressed dbstore archive file to indicate compressed
archives. However, this is not required and a dbctl dbrestore
will handle this transparently.
For example:
$ dbctl -u dba dbstore /z payrol backup/payrol.bkup.gz
Database "payrol" has been stored to "/data/backup/payrol.bkup.gz".
$ dbctl -u dba dbstore sample /tmp/sample.bkup
Database "sample" has been stored to "/tmp/sample.bkup".
B.08.30 introduced support for compressed archive files and
specifying an absolute archive file.
The dbctl dbrestore command restores a single database from a
source archive. The database must not already exist.
Server admin (dba) or operator capabilities are required in order
to restore a database. The /nouser option is restricted to dba users.
dbrestore [/info] source
dbrestore [/all] [/nouser] [/force] [/nice] source [new_database_name]
The source archive may start with a leading slash to specify an
absolute file name.
Otherwise the source specifies either the name of a configured
server device or the name of a server device and a filename
separated by a slash.
A compressed archive file is handled transparently.
If the /info argument is present, information on the archive is
obtained and the archive is not restored. The header of the
specified archive is displayed.
If the /all argument is present, the association between
database permission groups and server users ("sysmember") is retained.
Usage of the /all argument is safe if the database environment where
the database is restored is the same or has identical server users as
the environment where the database was stored. Specifying the /nouser
option has the same effect as omitting the /all option.
If the /force option is present, the database may even be
restored while the server is in online backup mode. By default,
dbrestore requests are rejected during online backup mode because of
the possible negative impact on performance and log volume size.
If the /nice option is specified, the server attempts to
mitigate the performance impact on concurrent client sessions and the
operating system buffer cache at the cost of slowing down the dbrestore
progress.
If a new_database_name is specified, its length must not exceed 255
characters, it must not begin with a slash ('/') and must not contain
any space characters.
For example:
$ dbctl -u dba dbrestore /all backup/payrol.bkup.gz
Database "PAYROL" has been restored from "/data/backup/payrol.bkup.gz".
B.08.30 introduced support for compressed archive files and specifying
an absolute archive file.
The dbctl bimport command allows the import of binary export files
for a data set.
bimport [/v] [/a] [/n] [/f] database set bexp_file
A binary import retains any chain information and detail set record
numbers. The affected data set is erased before the import file is
processed. A compressed bexp_file is handled transparently.
If the optional /v argument is specified, additional information is
displayed. Specifying /v twice (/v /v) displays progress information.
If the optional /f argument (force) is present, the database set
is forced to allow import while the server is in online backup mode.
By default, bimport requests are rejected during online backup mode
because of the possibly negative impact on performance and log volume size.
For example:
$ dbctl bimport /v /v sample 1 $PWD/SAMPLE.001.exb
P0: server: /data/tmp/SAMPLE.001.exb: 1355 records expected
P0: server: /data/tmp/SAMPLE.001.exb: completed, 1355 records processed
B.08.30 changed the record counter to 10 digits to support tables with
more than 2 billion records. A compressed bimport source file is handled
transparently.
The following database utilities were changed:
dbinfo
-
Changed capacity and entries columns to 10 digits to handle
tables with more than 2 billion records.
dbimport
-
Changed record counter column width to 10 digits to handle
tables with more than 2 billion records.
-
New -Z option to support compressed export files.
dbexport
-
Change entries and record counter columns to 10 digits to
handle tables with more than 2 billion records.
-
New -Z option to support compressed export files.
-
Changed record counter update interval to 1000 records.
dbpasswd
-
Support for new password hashing scheme if supported by server.
Otherwise fall back to previous scheme.
-
The option -X (experimental) may be used to enforce a fallback to
the old password hashing.
dbrepl
-
New -Z option to enable compressed slave communication.
-
Transparent support for compressed forward log files.
-
Support fwlog archive path list.
The -Z option will reduce the replication bandwidth but will
use additional CPU resources. It depends on the network
speed if this benefits replication performance.
According to some preliminary testing compression may improve
performance if the available bandwidth to the replication slave
is less than 100 MBit. Compression is unlikely to improve
performance on the local network.
prschema
-
Fixed capacity to account for tables with more than 2 billion records.
dbutil
prdbutil
-
Support for FTS indx option.
-
Added section "db" to emit database name.
-
New option -T to output TurboIMAGE item types (dbutil -T).
dbbexp
-
Changed record counter column width to 10 digits to handle
tables with more than 2 billion records.
-
New -Z option to support compressed export files.
dbdump
-
Transparent support for compressed export files.
dbcfix
-
Changed record counter column width to 10 digits to handle
tables with more than 2 billion records.
dbrecover
-
Transparent support for compressed forward log files.
-
Support fwlog archive path list.
dbrepack
-
Added support for FTS index pools.
dbstore
-
New -Z option to support compressed store archive.
fwaudit
-
New -Z option to support compressed output file.
-
Transparent support for compressed forward log and audit files.
query3k utility
- Fixed query3k limitations accessing tables with a size of more
than 2 billion records.
-
Fixed a problem evaluating boolean operators when searching on a
keyword index (FTS).
-
Remove limitation of 2GB output file.
-
The QUERY3K version number was changed to B.08.30.00 (20171107).
The [Config] section of the eloqsd.cfg configuration file
has the following configuration changes:
-
[Server] Service
-
This configuration item specifies the service name (as defined in
/etc/services) or the port number where the server should listen
for requests. The default value is eloqsd.
A suffix /4, /6, or /46 may be used to establish IPv4 only,
IPv6 (with implied IPv4 support), or separate IPv4 and IPv6
listening sockets. By default, separate IPv4 and IPv6 sockets are
used.
For example, "eloqsd/46" would specify to use the port number
associated with the service name eloqsd and to use separate
IPv4 and IPV6 sockets.
-
[Server] ServiceHttp
-
The service name (as defined in /etc/services) or the port number
where the server should listen for HTTP requests. If this is not
specified the HTTP status is disabled.
A suffix /4, /6, or /46 may be used to establish IPv4 only,
IPv6 (with implied IPv4 support), or separate IPv4 and IPv6
listening sockets. By default, separate IPv4 and IPv6 sockets are
used.
For example, 8101/6 would specify to use the port number 8101
and to use a single socket for IPv4 and IPv6 connections.
The [TLS] section was added to the eloqsd.cfg
configuration file.
The eloqsd server may be configured to accept TLS-encrypted network
connections. Supported clients such as Eloquence JDLG version 2.0
or newer can use this to securely communicate over insecure network
(wide area Internet) connections.
To use TLS communication, a server certificate is needed for the
eloqsd host name. JDLG requires a certificate which is issued by
a known authority. In particular, the associated root certificate
must be contained in the Java truststore.
Using TLS requires that OpenSSL version 0.9.8 or newer is installed.
-
[TLS] Enabled
-
If nonzero, TLS communication is enabled and the other configuration
items in the [TLS] section are read.
The default value is 0 (TLS communication disabled).
-
[TLS] CertChainFile
-
Absolute path to a file in PEM format containing the server certificate
and optionally any additional intermediate certificates which represent
the verification chain up to the root certificate.
The certificates in this file must be sorted in the verification order,
starting with the server certificate.
The file may in addition contain the private key associated with the
server certificate.
-
[TLS] CertKeyFile
-
Absolute path to a file in PEM format containing the private key
associated with the server certificate. This may refer to the same
file as configured with CertChainFile if this file contains both
the certificate(s) and the private key.
-
[TLS] RequiredFrom and OptionalFrom
-
RequiredFrom is used to configure client network addresses which
are required to use secure TLS communication.
If RequiredFrom is configured, OptionalFrom may be used to configure
exceptions for client addresses within the RequiredFrom address range(s)
which are not required to use secure TLS communication.
For example:
RequiredFrom = All
OptionalFrom = [::1]
OptionalFrom = 127.0.0.1
OptionalFrom = 192.168.1.0/24
RequiredFrom/OptionalFrom argument syntax:
{ All | hostname | ip-address [/{addrbits|netmask}] }
-
Multiple RequiredFrom/OptionalFrom entries are recognized and combined.
-
hostname is the name of a host or network that is resolved into one
or more ip addresses.
-
ip-address is either an IPv4 or IPv6 address.
-
An IPv6 address, enclosed in square brackets, such as [::1].
The addrbits option may be used to specify the number of relevant bits
in the IP address.
-
An IPv4 address, such as 127.0.0.1. The addrbits option may be used
to specify the number of relevant bits in the IP address.
The netmask option allows to specify an IPv4 network mask, such as
255.255.255.0.
The AllowFrom and DenyFrom configuration items are
used in the eloqsd.share and eloqsd.app configuration files to
specify share and application access rules.
They now support IPv6 addresses and host names.
-
AllowFrom and DenyFrom
-
Used to enable or reject access to a share or application
based on the client network address.
AllowFrom/DenyFrom argument syntax:
{ All | hostname | ip-address [/{addrbits|netmask}] }
-
Multiple AllowFrom/DenyFrom entries are recognized and combined.
-
hostname is the name of a host or network that is resolved into one
or more ip addresses.
-
ip-address is either an IPv4 or IPv6 address.
-
An IPv6 address, enclosed in square brackets, such as [::1].
The addrbits option may be used to specify the number of relevant bits
in the IP address.
-
An IPv4 address, such as 127.0.0.1. The addrbits option may be used
to specify the number of relevant bits in the IP address.
The netmask option allows to specify an IPv4 network mask, such as
255.255.255.0.
If neither AllowFrom nor DenyFrom are configured, access to a share
or application is enabled from all network addresses (implied
AllowFrom=All).
If AllowFrom and/or DenyFrom are configured, access to a share or
application is denied unless specifically allowed (implied DenyFrom=All).
|