Client Communication

DEAD_CLIENT_INTERVAL

DEAD_CLIENT_INTERVAL idle_time_seconds

DEAD_CLIENT_INTERVAL controls the timeout interval, the number of seconds of client idle time after which the server checks the connection for that client. The default value is 1800 (30 minutes). Specify 0 to use the system default (typically about 2 hours), which was the V12.0 default behavior.

For the equivalent detection on the client side, see the ctCOMMOPT_TCP_KEEPALIVE_INTERVAL option of the ctSetCommProtocolOption function.

This affects TCP based connections using SQL and ISAM ports.

COMPATIBILITY TCPIP_CHECK_DEAD_CLIENTS enables an older method to carry out this check, which has a minimum setting of 120 seconds (2 minutes).

Note The timeout interval only controls how often the FairCom Server sends a message to test the connection. Different operating systems use different timeout values on TCP/IP messages, so the actual delay before a dead client is dropped depends on when the operating system notifies the FairCom Server that the message failed.

Default: 1800 (30 minutes)

 

MAX_CONCURRENT_USER_ACCOUNTS

MAX_CONCURRENT_USER_ACCOUNTS <max_accounts>

Sets the maximum number of user accounts that can connect at one time to FairCom DB. The maximum number of ISAM and SQL connections can be set separately using MAX_ISAM_CONNECTIONS and MAX_SQL_CONNECTIONS respectively.

Note If limits are set in the license file, the configuration option can only be used to further reduce the connection limits (they cannot be increased above the license file limits).

The error code ALMT_ERR (984) is returned when logon is denied because the number of distinct user accounts that are allowed to be connected at one time has been reached.

See Also

 

MAX_CONNECTIONS_PER_USER_ACCOUNT

MAX_CONNECTIONS_PER_USER_ACCOUNT <max_connections>

Sets the maximum number of connections for each user account. The maximum number of ISAM and SQL connections can be set separately using MAX_ISAM_CONNECTIONS and MAX_SQL_CONNECTIONS respectively.

If a user is in a group, the connections are counted at the group level. If the user is not part of a group, connections are counted for the individual user.

Note If limits are set in the license file, the configuration option can only be used to further reduce the connection limits (they cannot be increased above the license file limits).

The error code ALMT_ERR (984) is returned when logon is denied because the number of distinct user accounts that are allowed to be connected at one time has been reached.

See Also

 

MAX_ISAM_CONNECTIONS

MAX_ISAM_CONNECTIONS <max_number>

Sets the maximum number of ISAM connections. The maximum number of ISAM and SQL connections can be set separately using MAX_ISAM_CONNECTIONS and MAX_SQL_CONNECTIONS respectively.

Note If limits are set in the license file, the configuration option can only be used to further reduce the connection limits (they cannot be increased above the license file limits).

The error code ALMT_ERR (984) is returned when logon is denied because the number of distinct user accounts that are allowed to be connected at one time has been reached.

See Also

 

MAX_SQL_CONNECTIONS

MAX_SQL_CONNECTIONS <max_number>

Sets the maximum number of SQL connections. The maximum number of ISAM and SQL connections can be set separately using MAX_ISAM_CONNECTIONS and MAX_SQL_CONNECTIONS respectively.

Note If limits are set in the license file, the configuration option can only be used to further reduce the connection limits (they cannot be increased above the license file limits).

The error code ALMT_ERR (984) is returned when logon is denied because the number of distinct user accounts that are allowed to be connected at one time has been reached.

See Also

 

TCP/IP

See also COMM_PROTOCOL

 

BROADCAST_DATA

BROADCAST_DATA <Token>

BROADCAST_DATA specifies a token to be broadcast following the Server Name. The token must not contain spaces. There is no default token. For example, add a department name or further identifying information for the FairCom Server.

This configuration option can include an environment variable name that will be substituted with its value when the configuration file is read.

Default: No data sent

See Also

BROADCAST_INTERVAL

BROADCAST_PORT

 

BROADCAST_INTERVAL

BROADCAST_INTERVAL <Seconds>

The number of seconds between broadcasts. The default is 10 seconds, otherwise the token should be a number. The maximum value allowed is set to 86,400 seconds, which is once per day.

If the number is negative, each broadcast is also sent to the FairCom Server standard output.

Default: 10

See Also

BROADCAST_DATA

BROADCAST_PORT

 

BROADCAST_PORT

BROADCAST_PORT <DEFAULT | Port>

Specifies the TCP/IP port used for the broadcast.

The default value is 0, which means the broadcast is off.

If DEFAULT is specified, this means that the broadcast is on and the default port is used, which is 5595.

Any valid four-byte integer greater than 5000 that is not in use by another process may be specified. This should NOT be the port for the FairCom Server, which is displayed at startup and is based on the Server Name.

Default: 0

See Also

BROADCAST_DATA

BROADCAST_INTERVAL

 

SESSION_TIMEOUT

SESSION_TIMEOUT <seconds>

The SESSION_TIMEOUT option forces TCP/IP connections to be removed after the specified number of seconds has elapsed without activity. This option has been verified on Windows, Linux, and Mac OS X.

History

In V11 and later:

For 64-bit FairCom DB servers, a timeout allows each thread to detect and perform its own disconnection in case of a timeout.

  • If SESSION_TIMEOUT is negative, it is ignored.
  • If SESSION_TIMEOUT is less than 5, it is set to 5 so that the minimum SESSION_TIMEOUT value is 5 seconds.

 

In V11.6.1 and later, SESSION_TIMEOUT also applies to SQL connections.

Default: No timeout

 

Shared Memory

See also:

  • COMM_PROTOCOL
  • Shared Memory Resources Considerations

 

SEMAPHORE_BLK

SEMAPHORE_BLK <number>

Note SEMAPHORE_BLK is a legacy keyword that is no longer used.

For Unix based systems only. This is the number of semaphores obtained at one time. These semaphores are used in the shared memory communication subsystem.

Default: 10

See Also:

 

SHMEM_DIRECTORY

SHMEM_DIRECTORY <directory_name>

On Unix systems, the FairCom DB shared memory communication protocol creates a file that clients use to find the shared memory identifier for its shared memory logon region, and it creates named pipes for initial communication between client and server.

This option sets the directory in which FairCom DB stores files used for connecting using the Unix shared memory protocol.

This configuration option can include an environment variable name that will be substituted with its value when the configuration file is read.

Note If SHMEM_DIRECTORY is set, clients must be able to find this non-default directory.
Client processes will check the environment variable CTREE_SHMEM_DIRECTORY (see "Client Configuration" in Shared Memory Client-Server Communication for Unix/Linux). A client looking in the wrong location for shared memory information may take extra time to connect waiting for the shared memory protocol to timeout before falling back to TCP.

See Also

 

SHMEM_GROUP

SHMEM_GROUP  <group>

By default, a client application must belong to the server owner’s primary group to use shared memory. This is configurable with the SHMEM_GROUP keyword. This option causes FairCom Server to assign group membership to the specified group. This option applies to the resources for both the ISAM and the SQL shared memory protocol.

Possible errors indicating problems:

FSHAREMM: Could not get group ID for group <group> for shared memory
FSHAREMM: Failed to set group for LQMSG shared memory region: X

See Also

 

SHMEM_MAX_SPIN

SHMEM_MAX_SPIN <number>

Sets the maximum number of spin operations that a shared memory connection uses for a receive operation when the shared memory spin feature is enabled.

Default:

On Windows systems, the default is 400.

On Unix systems that support atomic operations, the default is 100000.

On Unix systems that do not support atomic operations, the default is 10000.

See Also:

 

SHMEM_MAX_SPINNERS

SHMEM_MAX_SPINNERS <number>

Sets the maximum number of connections that are allowed to use the spin feature at a time. Can be changed at runtime. 

Specifying a <number> that is less than or equal to 1 means that only one connection will be allowed to spin at a time. 

Default: 4

See Also:

 

SHMEM_PERMISSIONS

SHMEM_PERMISSIONS <permissions>

On Unix systems, the FairCom DB shared memory communication protocol creates a file that clients use to find the shared memory identifier for its shared memory logon region, and it creates named pipes for initial communication between client and server.

SHMEM_PERMISSIONS <permissions> sets the permissions for the shared memory resources. The default is 660. 666 will allow access to FairCom DB by any user account. Your the system umask setting for the account can alter this default. Explicitly setting SHMEM_PERMISSIONS avoids issues with umask affecting the default.

Note: Use caution when increasing the access permissions to the shared memory resources. For example, shared memory permission of 666 allows any user to attach to a shared memory segment and read or write to it. This means that any process could make a request to FairCom Server or could read the request data of another process through such a shared memory region.

See Also

 

LDAP

When LDAP is enabled, FairCom DB Server authenticates a supplied username / password (from InitISAMXtd) against the LDAP server itself. By default, FairCom DB doesn't query the server for any other information to be returned, it's simply pass/fail. Note: If the LDAP server becomes unavailable for any reason, users can't be authenticated.

The one exception is when LDAP_ALLOWED_GROUP options are specified. In those cases, FairCom DB additionally authenticates to LDAP with a specific LDAP account provided by the LDAP_APPLICATION_ID option (and passwords specified with LDAP_KEY_STORE) and query and validate group membership for that user. If a user is not allowed in the group, the connection is denied. The optional LDAP_GROUP_CHECK can be used to return and update group membership in FAIRCOM.FCS.

Once a user is authenticated and all group checks are complete, FairCom DB discards all authentication information and disconnects from the LDAP server and there is no further interaction.

Example

FairCom Server provides a set of keywords for configuring the LDAP subsystem:

SUBSYSTEM USER_AUTH LDAP
{
LDAP_SERVER localhost
LDAP_TIMEOUT 10
LDAP_PREFIX cn=
LDAP_BASE ou=people,dc=faircom,dc=com
LDAP_APPLICATION_ID cn=ctreesql,ou=applications,dc=faircom,dc=com
LDAP_ISAM_ALLOWED_GROUP cn=ctreeisamusers,ou=groups,dc=faircom,dc=com
LDAP_SQL_ALLOWED_GROUP cn=ctreesqlusers,ou=groups,dc=faircom,dc=com
LDAP_GROUP_CHECK

{attr:member} {base:ou=groups,dc=faircom,dc=com} {filter:(objectclass=groupOfNames)}
LDAP_PORT 389
LDAP_SSL NO
LDAP_KEY_STORE ldap.fkf
}

Security

LDAP client authentication requires passing an actual client LDAP password to the FairCom DB server. This requires additional encryption to protect the password in transit. Unique public/private key pairs are generated at runtime and are only used for this one particular connection request.

The encryption algorithm that the client library uses to securely pass the user password to the server when using LDAP authentication was updated in V13 to use an AES-GCM encryption with a random initialization vector (iv).

If a client library that uses AES-GCM for LDAP authentication connects to a server that does not support it, the connection attempt now fails with error code 1179, CLIENT_LOGON_REQUIRES_AES_GCM at the ISAM level, or error -18179 at the SQL level.

If a client library that does not use AES-GCM for LDAP authentication connects to a server that use AES-GCM authentication at the ISAM level, the connection attempt now fails with error code 941 or 1180 (SERVER_LOGON_REQUIRES_AES_GCM), or error code -17941 or -18180 at the SQL level.

Limitations

  • The ADO.NET driver uses AES-CBC with a random iv, since AES-GCM is not supported by the .NET Framework (only .NET Core supports AES-GCM).
  • While the JDBC driver can be compiled with Java 1.7 for backward compatibility, it requires Java 1.8 or later in order to use AES-GCM.

LDAP Keywords

Only LDAP keywords are allowed to be specified inside the SUBSYSTEM USER_AUTH LDAP block of the configuration file. Logic prevents non-LAP keywords from being specified in this block.

The following keywords can be used in the SUBSYSTEM USER_AUTH LDAP block:

General LDAP configuration

LDAP_SERVER

LDAP_PORT

LDAP_TIMEOUT

LDAP_SSL

Site-specific directives

LDAP_PREFIX

LDAP_BASE

Required for group management checks

LDAP_APPLICATION_ID

LDAP_KEY_STORE

LDAP_ISAM_ALLOWED_GROUP

LDAP_SQL_ALLOWED_GROUP

LDAP_GROUP_CHECK

 

ADMIN_USER_GROUP

ADMIN_USER_GROUP <admin_user_name>:<admin_group_name>

Specifies the name of the super administrator user (default ADMIN) and administrator group (default ADMIN). Only members of the specified administrator group can perform some operations with FairCom DB such as shutting down FairCom DB or connecting using the ctadmn utility.

Example

ADMIN_USER_GROUP Administrator:Administrators

See Also

 

GUEST_USER_GROUP

GUEST_USER_GROUP <user:group>

Specifies the name of the guest user (default GUEST) and guest group (default GUEST).

Example

GUEST_USER_GROUP Guest:Guests

See Also

 

LDAP_APPLICATION_ID

When the LDAP_APPLICATION_ID option is used, FairCom DB checks the ISAM and SQL group membership (if those configurations enabled) after authenticating the application ID and before authenticating the user ID. This is done because the user ID might not have been assigned the permissions needed to check group membership. LDAP_GROUP_CHECK is performed in the context of the LDAP application ID. This is consistent with what is done for the LDAP_ISAM_ALLOWED_GROUP and LDAP_SQL_ALLOWED_GROUP options.

When LDAP_APPLICATION_ID is not specified the current user ID is used for lookup.

See also:

LDAP_GROUP_CHECK

 

LDAP_BASE

LDAP_BASE <base>

<base> is appended to the user name when authenticating the user using LDAP. and specifies the base name to use for the group membership search (LDAP_ISAM_ALLOWED_GROUP and LDAP_SQL_ALLOWED_GROUP configurations).

Example

LDAP_BASE DC=MyDomain,DC=local

With LDAP_BASE dc=mycompany,dc=com and LDAP_PREFIX cn= in ctsrvr.cfg, then FairCom DB authenticates the user name MYUSERNAME as: cn=MYUSERNAME;dc=mycompany,dc=com

See Also

LDAP_SERVER

LDAP_TIMEOUT

ADMIN_USER_GROUP

GUEST_USER_GROUP

LOGIN_ALLOWED_GROUP

 

LDAP_GROUP_CHECK

LDAP_GROUP_CHECK {attr:<ATTRIBUTE>}{base:<BASE>}{filter:<FILTER>}

Where:

  • <ATTRIBUTE> is the group attribute to be checked (for example attr:member)
  • <BASE> is the LDAP base for the group membership search
  • <FILTER> is the LDAP filter for the group membership search

FairCom Server V11.5 and later are able to update the c-tree group membership records in FAIRCOM.FCS at logon. Because SQL permissions use the current group membership for a user account as stored in FAIRCOM.FCS, this ability makes it possible for SQL permissions to act on the current LDAP group membership for a user account that is authenticated using LDAP.

To use this feature, add this option in the SUBSYSTEM USER_AUTH LDAP block in ctsrvr.cfg.

Any errors encountered are logged to CTSTATUS.FCS.

Example 1:

The file faircom.ldif contains these domain, user, and group definitions:


# Domain

dn: dc=faircom,dc=com
objectClass: domain
objectClass: top
dc: faircom

# People

dn: ou=people,dc=faircom,dc=com
objectclass: top
objectclass: organizationalUnit
ou: people
description: Container for user entries

dn: cn=user1,ou=people,dc=faircom,dc=com
cn: user1
objectClass: person
sn: user1

dn: cn=user2,ou=people,dc=faircom,dc=com
cn: user2
objectClass: person
sn: user2

dn: cn=user3,ou=people,dc=faircom,dc=com
cn: user3
objectClass: person
sn: user3

dn: cn=user4,ou=people,dc=faircom,dc=com
cn: user4
objectClass: person
sn: user4

dn: cn=user5,ou=people,dc=faircom,dc=com
cn: user5
objectClass: person
sn: user5

# Groups

dn: ou=groups,dc=faircom,dc=com
objectClass: organizationalUnit
ou: groups
description: Container for group entries

dn: cn=dev,ou=groups,dc=faircom,dc=com
objectClass: groupOfNames
cn: dev
description: Research and Development group
member: cn=user2,ou=people,dc=faircom,dc=com
member: cn=user3,ou=people,dc=faircom,dc=com

dn: cn=support,ou=groups,dc=faircom,dc=com
objectClass: groupOfNames
cn: support
description: Technical Support group
member: cn=user1,ou=people,dc=faircom,dc=com
member: cn=user2,ou=people,dc=faircom,dc=com
member: cn=user3,ou=people,dc=faircom,dc=com

dn: cn=qa,ou=groups,dc=faircom,dc=com
objectClass: groupOfNames
cn: qa
description: Product Testing group
member: cn=user1,ou=people,dc=faircom,dc=com
member: cn=user2,ou=people,dc=faircom,dc=com
member: cn=user3,ou=people,dc=faircom,dc=com

dn: cn=it,ou=groups,dc=faircom,dc=com
objectClass: groupOfNames
cn: it
description: Information Technology group
member: cn=user4,ou=people,dc=faircom,dc=com
member: cn=user5,ou=people,dc=faircom,dc=com

dn: cn=ctreeisamusers,ou=groups,dc=faircom,dc=com
objectClass: groupOfNames
cn: ctreeisamusers
description: c-tree ISAM Users
member: cn=user1,ou=people,dc=faircom,dc=com
member: cn=user2,ou=people,dc=faircom,dc=com
member: cn=user3,ou=people,dc=faircom,dc=com
member: cn=user4,ou=people,dc=faircom,dc=com
member: cn=user5,ou=people,dc=faircom,dc=com

dn: cn=ctreesqlusers,ou=groups,dc=faircom,dc=com
objectClass: groupOfNames
cn: ctreesqlusers
description: c-tree SQL Users
member: cn=user1,ou=people,dc=faircom,dc=com
member: cn=user2,ou=people,dc=faircom,dc=com
member: cn=user3,ou=people,dc=faircom,dc=com
member: cn=user4,ou=people,dc=faircom,dc=com
member: cn=user5,ou=people,dc=faircom,dc=com

# Applications

dn: ou=applications,dc=faircom,dc=com
objectclass: top
objectclass: organizationalUnit
ou: applications
description: Container for application entries

dn: cn=ctreesql,ou=applications,dc=faircom,dc=com
cn: ctreesql
objectClass: person
sn: ctreesql

Example 2:

The following LDAP configuration options in ctsrvr.cfg require LDAP authentication using an application ID of ctreesql, allow ISAM logons only from members of the ctreeisamusers group, allow SQL logons only from members of the ctreesqlusers group, and update the c-tree group definitions for a particular user ID at logon time based on that user ID's current LDAP group membership:


SUBSYSTEM USER_AUTH LDAP
{
 LDAP_SERVER   localhost
 LDAP_TIMEOUT   10
 LDAP_PREFIX   cn=
 LDAP_BASE   ou=people,dc=faircom,dc=com
 LDAP_APPLICATION_ID  cn=ctreesql,ou=applications,dc=faircom,dc=com
 LDAP_ISAM_ALLOWED_GROUP cn=ctreeisamusers,ou=groups,dc=faircom,dc=com
 LDAP_SQL_ALLOWED_GROUP cn=ctreesqlusers,ou=groups,dc=faircom,dc=com
 LDAP_GROUP_CHECK  {attr:member}{base:ou=groups,dc=faircom,dc=com}{filter:(objectclass=groupOfNames)}
 LDAP_PORT   389
 LDAP_SSL   NO
 LDAP_KEY_STORE  ldap.fkf
}

When user3 successfully connects to c-tree Server, the user3 user account and groups to which user3 belongs are added to FAIRCOM.FCS:

     User Id  User Description (Groups)
------------  ------------------------------------
       ADMIN  ( ADMIN )
       USER3  ( CTREEISAMUSERS CTREESQLUSERS DEV QA SUPPORT )

 

Now it is possible to create a SQL table and grant permission to user3 through a group to which user3 belongs. For example:

As ADMIN:

create table t(ch char(5));
insert into t values ('abc');
commit;

As user3:

select * from t;
error(-20228): Access denied(Authorisation failed)

As ADMIN:

grant select on admin.t to dev;
commit;

As user3:

select * from t;
CH
--
abc
1 record selected

Perform LDAP_GROUP_CHECK in Context of LDAP Application ID

The check for group membership, configured by the LDAP_GROUP_CHECK option, was done in the context of the user account that was logging on. However, the user account might not have permission to query its LDAP groups.

The logic has been enhanced so that, if an LDAP application is specified (by specifying the LDAP_APPLICATION_ID option in the SUBSYSTEM USER_AUTH LDAP block in ctsrvr.cfg), it now performs the LDAP_GROUP_CHECK in the context of the LDAP application ID. This is consistent with what is done for the LDAP_ISAM_ALLOWED_GROUP and LDAP_SQL_ALLOWED_GROUP options.

When LDAP_APPLICATION_ID is specified, you MUST also use LDAP_KEY_STORE to specify an application password, otherwise the application authentication will fail.

Note When LDAP_APPLICATION_ID is not specified the logic behaves as before, using the current user ID for lookup.

See also:

LDAP_APPLICATION_ID

 

LDAP_ISAM_ALLOWED_GROUP & LDAP_SQL_ALLOWED_GROUP

In V11 and later, FairCom Server's ability to check LDAP group membership has been improved. Previously, part of the filter was hard-coded. Now, the entire filter can be specified in the configuration file. Additionally, the attribute is no longer hard-coded; now it can be specified in the configuration file.

To use the new functionality, specify the following syntax for the LDAP_ISAM_ALLOWED_GROUP and/or LDAP_SQL_ALLOWED_GROUP options:


LDAP_ISAM_ALLOWED_GROUP {attr:ATTRIBUTE_VALUE}{base:BASE_VALUE}{filter:FILTER_VALUE}

For example:


LDAP_ISAM_ALLOWED_GROUP {attr:member}{base:dc=mycompany,dc=com}{filter:(&(objectClass=groupOfNames)(cn=myusergroup))}

 

LDAP_KEY_STORE

LDAP_KEY_STORE <key_store_file>

This option is used in conjunction with the LDAP_APPLICATION_ID keyword. <key_store_file> is the name of an encrypted store file created using the ctcpvf utility. The encrypted store file contains the application ID password (that is, the password that c-tree Server will use when authenticating the user name <application_id> with LDAP).

See Also:

 

LDAP_LOCAL_PREFIX

LDAP_LOCAL_PREFIX <prefix>

When LDAP_SERVER is enabled, all non-admin users authenticate using LDAP. The LDAP_LOCAL_PREFIX <prefix> keyword allows filtering certain users to use local c-tree authentication if their user name begins with <prefix>. This prefix comparison is case-insensitive.

Note If the user account existed prior to this V12 change, local authentication may fail with LDRQ_ERR (985) or SQL error (-17985): CT - Logon is denied because this user account requires LDAP authentication, but c-tree Server has not enabled LDAP authentication. If this occurs, the user account will need to be deleted and re-created.

 

LDAP_MODULE

LDAP_MODULE <module_name>

<module_name> specifies the LDAP shared library to load. The default value is libldap.so. On Solaris, libldap.so is the native LDAP library, so this should be used to specify the name of the OpenLDAP version of libldap.so.

LDAP_MODULE is not supported on windows.

Example

LDAP_MODULE libldap.so

 

LDAP_PORT

LDAP_PORT <port>

Specifies the port to use when connecting to the LDAP server. The default is to use the standard LDAP port: 389 for non-SSL connections, and 636 for SSL connections (which is enabled by specifying LDAP_SSL YES in ctsrvr.cfg).

 

LDAP_PREFIX

LDAP_PREFIX <prefix>
  • <prefix> is a string to prepend to the user name that is passed to LDAP.

For example, if you specify LDAP_BASE dc=mycompany,dc=com and LDAP_PREFIX cn= in ctsrvr.cfg, then c-tree Server authenticates the user name MYUSERNAME as:

cn=MYUSERNAME,dc=mycompany,dc=com

 

LDAP_SERVER

LDAP_SERVER  <ldap_host_name>:<ldap_port>

Specifies the host name and port of an LDAP server for authentication.

Example

LDAP_SERVER 192.168.0.15:389

See Also

 

LDAP_SSL

LDAP_SSL YES | NO

If YES is specified, c-tree Server uses SSL when connecting to the LDAP server. The default is NO.

 

LDAP_TIMEOUT

LDAP_TIMEOUT <timeout>

Specifies an LDAP server connection timeout in seconds (default is 60).

Example

LDAP_TIMEOUT 30

See Also

 

LOGIN_ALLOWED_GROUP

LOGIN_ALLOWED_GROUP <group>

When this keyword is specified, only users who are members of the specified group are allowed to connect to the FairCom Server. The FairCom Server returns error LGRP_ERR when a user who is not a member of the specified group attempts to connect to the FairCom Server. If the keyword is not specified, any user who can be authenticated using the specified LDAP server is permitted to connect to the FairCom Server.

Example

LOGIN_ALLOWED_GROUP c-treeUsers

See Also

 

TLS

To enable TLS (SSL), add a SUBSYSTEM COMM_PROTOCOL SSL section to ctsrvr.cfg containing your specified TLS configuration options.

Supported options

SERVER_CERTIFICATE_FILE - provide the name of the PEM-encoded certificate file that contains the FairCom DB server certificate.

SERVER_PRIVATE_KEY_FILE -  indicate the name of the file containing the private key.

SERVER_ENCRYPTED_STORE_FILE - create an encrypted store file.

SSL_CONNECTIONS_ONLY - require the client to use SSL/TLS to connect to the FairCom Server or not.

SSL_CIPHERS - set the encryption ciphers that are allowed to be used for encrypting the SSL connection.

DEBUG_LOG - write messages to the specified <log file>.

VERIFY_CLIENT_CERTIFICATE - require the client to supply an X.509 certificate or not.

X509_AUTHENTICATION - enable or disable using an X.509 certificate at logon for authentication and database authorization

Example:

SUBSYSTEM COMM_PROTOCOL SSL {

;This is the file name of the server certificate
SERVER_CERTIFICATE_FILE c:\certs\server.pem

; This servers private key. It is encrypted in pkcs8 format
SERVER_PRIVATE_KEY_FILEc:\certs\private\server.pkcs8

; master.fkf contains the password for decrypting server.pkcs8
SERVER_ENCRYPTED_STORE_FILE master.fkf

;For SSL you can specify (un-comment) a debug log file name
;DEBUG_LOG ssl.log

SSL_CONNECTIONS_ONLY YES

;Require clients to provide a x509 certificate
VERIFY_CLIENT_CERTIFICATE YES

;Use x509 client certificate for database authentication
x509_AUTHENTICATION YES

;Use the SUBJECT:CN from the client's certificate as their user name
x509_PATH CN
}

 

DIAGNOSTICS TRAP_COMM

DIAGNOSTICS TRAP_COMM

When activated, the DIAGNOSTICS TRAP_COMM keyword instructs the FairCom Server to log incoming communications packets to TRAPCOMM.FCS prior to execution. This log can be played back using the cttrap utility and a debug build of the FairCom Server to observe the results of the client requests, allowing the developer to exactly duplicate and repeat client activities. The trap file, TRAPCOMM.FCS, is created in the server directory by default. To prepend a path onto the trap file name (say to route it to a separate disk), add an entry of the form DIAGNOSTIC_STR <trap file path>. For example, if DIAGNOSTIC_STR /bigdisk/ were in the configuration file, then the trap file would be /bigdisk/TRAPCOMM.FCS.

Notes

  • A fresh TRAMCOMM.FCS file is created on each server startup and wipes out any existing one.
  • TRAPCOMM.FCS isn't completely flushed until the server shuts down, thus it may appear empty until then.

Default: Disabled

See Also

 

SESSION_TIMEOUT

SESSION_TIMEOUT <seconds>

The SESSION_TIMEOUT option forces TCP/IP connections to be removed after the specified number of seconds has elapsed without activity. This option has been verified on Windows, Linux, and Mac OS X.

History

In V11 and later:

For 64-bit FairCom DB servers, a timeout allows each thread to detect and perform its own disconnection in case of a timeout.

  • If SESSION_TIMEOUT is negative, it is ignored.
  • If SESSION_TIMEOUT is less than 5, it is set to 5 so that the minimum SESSION_TIMEOUT value is 5 seconds.

In V11.6.1 and later, SESSION_TIMEOUT also applies to SQL connections.

Default: No timeout

interaction correspondence

Was this article helpful?

Give feedback about this article

Related Articles