Difference between revisions of "OS4X Core configuration"

From OS4X
Jump to navigation Jump to search
Line 206: Line 206:
  
 
As a useful tool from each MySQL distribution, the tool "<code>mysqldump</code>" is used in the OS4X backup script for doing its job.
 
As a useful tool from each MySQL distribution, the tool "<code>mysqldump</code>" is used in the OS4X backup script for doing its job.
 +
 +
=== Event scripts ===
 +
First some words about the global behaviour of scripts:
 +
 +
==== event script usage ====
 +
Every time the configuration of OS4X is checked by a binary (which is at start time or when processing the signal 1 - SIGHUP), the event script configuration is checked. If a script is non-existant and/or the execute permissions don't allow the execution of a configured script, it won't get executed. No warning will be printed out or logged somewhere.
 +
 +
==== event script sleep time ====
 +
Sometimes it is very handy if the event scripts are started with a little lag. This can be especially interesting if the „end receive“ or „end send“ scripts are called very fast because of small transfer files (i.e. ENGDAT abstract file). If you experience problems with your EDI system (i.e. it doesn't catch all files), try to increase the appropriate value. Keep in mind that the OFTP session waits that time you configured the sleep time. Setting the values very high increases the risk of a disconnect if the remote site has very little timeouts configured! More than 5 seconds should not be normal!
 +
 +
==== start send script ====
 +
''DB configuration name: start_send_script & sleep_start_send_script''
 +
 +
If a file is getting sent, this script or program will be started with the documented parameters.
 +
 +
==== end send script ====
 +
''DB configuration name: end_send_script & sleep_end_send_script''
 +
 +
If a file has finished (successfully or not) sending, this script or program will be started with the documented parameters.
 +
 +
==== xERP script ====
 +
''DB configuration name: xerp_script & sleep_xerp_script''
 +
 +
If an EERP or NERP (OFTP 2 only) message is received, this script will be started. OS4X tries to find a send queue entry which conforms to the given parameters in order to set the values for comment, absolute path etc. If no send queue entry can be found that matches the given parameters in the EERP or NERP message, the script won't be executed. This script receives the same parameters as the [[OS4X Core configuration#end send script|end send script]] script.
 +
 +
==== start receive script ====
 +
''DB configuration name: start_receive_script & sleep_start_receive_script''
 +
 +
If a file is getting received, this script or program will be started with the documented parameters.
 +
 +
==== end receive script ====
 +
''DB configuration name: end_receive_script & sleep_end_receive_script''
 +
 +
If a file has finished (successfully or not) receiving, this script or program will be started with the documented parameters.
 +
 +
==== start session script ====
 +
''DB configuration name: start_session_script & sleep_start_session_script''
 +
 +
After a positive OFTP handshake, this script or program will be started with the documented parameters.
 +
 +
==== end session script ====
 +
''DB configuration name: end_session_script & sleep_end_session_script''
 +
 +
After a positive OFTP session, this script or program will be started with the documented parameters.
 +
 +
==== send queue entry blocked script ====
 +
''DB configuration name: blocked_script & sleep_blocked_script''
 +
 +
If a send queue entry gets blocked (i.e. wrong authentification, unsupported virtual filename at the remote site, connection problems), this scripts will be started. If more than one entry for a partner gets blocked, each send queue entry will start its own blocked script.
 +
 +
==== debug daemon log script ====
 +
''DB configuration name: os4xdebugd_log_script''
 +
 +
After a debug log has been written, this script will be started. This can be the case when asking for a debug log interactively (or with starting the appropriate program manually) or, if configured, when automatically created debug logs are written.
 +
 +
==== license script & trigger level ====
 +
''DB configuration name: license_script & license_script_hwm''
 +
 +
This script will be started after a configurable trigger level (in percent) is exceeded. Its main porpuse is to inform a responsible person that a new license should be obtained or other actions should be taken.

Revision as of 18:31, 10 April 2007

Accessing configuration

OS4X stores its core configuration in one simple database table. The configuration can therefor be changed in two ways:

  • using the comfortable web interface
  • using a database client program to change the values manually.

Because of the quite non-understandable names of the configuration values, all configuration value names are listed in each block of configuration for manual editing.

web interface method

The OS4X web interface includes an entry in the left menu for the core configuration. Its name is "Configuration". The configuration web interface is segmentated into the following blocks:

  • TCP/IP
  • SSL/TLS
  • ISDN
  • Odette
  • Directories
  • Event scripts
  • Daemon
  • Partner table
  • GUI niceup

Each block is accessible with a link in the head of the configuration panel. Also, each block is entitled with its name and a link to access the top of the form.

database method

The table "[tableprefix]configuration" (default: "os4x_configuration") contains two columns:

  • name
  • value

The column "name" is the name of the configuration which is affected.

The column "value" reflects the configuration value, limited to 255 characters.

All boolean values react that the a value of zero ("0") if false and all other values are true.

Configurable values

The following configuration parameters show the position in the web GUI, beginning in the top. Each configuration name as used in all binaries, web interface, scripts etc. are listed in each block and explained as needed.

TCP/IP

This block contains all basic TCP/IP parameters, such as port numbers, timeout values etc.

TCP/IP port of OFTP server

DB configuration name: tcp_port

This numeric value between 1 and 65535 describes the TCP/IP port the OFTP server is watching for incoming connections. The maximum of parallel incoming connections is limited by the operating system kernel and can be influenced by the kernel parameter "SOMAXCONN".

TCP/IP port of OFTP server (TLS)

DB configuration name: tcp_port_tls

This numeric value between 1 and 65535 describes the TCP/IP port the OFTP server is watching for incoming OFTP2 connections which are secured by TLS. The maximum of parallel incoming connections is limited by the operating system kernel and can be influenced by the kernel parameter "SOMAXCONN". This port must not be the same as the OFTP server port from above.

TCP/IP port of OS4X debug daemon

DB configuration name: debugd_port

This numeric value between 1 and 65535 describes the TCP/IP port the OFTP server is watching for debug output. Every OS4X program generates this output. The daemon collects this data and is able to dump this data in an encrypted file. This must not be the same as OFTP or OFTP 2 server ports.

TCP/IP timeout

DB configuration name: tcp_timeout

This numeric value defines the maxmimum number of seconds between two TCP/IP packages to arrive. If this value is too low you might get network disconnects, setting this value very high means that a network disconnect will be discovered very late.

TCP/IP OFTP maximum buffersize

DB configuration name: oftp_default_buffersize_tcpip

During the OFTP handshake, the maximum size of a data buffer will be commited. This value reflects the maximum size of such data buffers. The minimum value is 128, the maximum can be should not be over 65535 (because of TCP/IP packaging). The higher the value, the faster the data transfer rate will be (but it depends on the partner side). On unreliable connections, use the default value of 2048 bytes.

TCP/IP OFTP maximum credit count

DB configuration name: oftp_default_creditcount_tcpip

As the OFTP maximum buffersize, this value will be commited with the partner during a OFTP handshake. The number defines the amount of uncommited data buffers send to the receiver during file transfers. Increasing this value also increases the throughput. On unreliable connections you should use the default of 20. This is a different value than used for ISDN connections.

use receiving acceleration?

DB configuration name: oftp_tcpip_rec_acceleration

This technique is used to accelerate incoming TCP/IP connection by pre-sending the so-called "OFTP credits" (which are used for handshaking OFTP data buffers) during file transfers. If your partner doesn't like this type of acceleration (i.e. partners who use Seeburger products), you have to disable it. You also have the chance to define a row in the partner table to define partner based acceleration.

use send acceleration?

DB configuration name: oftp_tcpip_send_acceleration

Enabling this feature turns on code to ignore the first OFTP credit messages during file transfer. This tunes up transfer speed up to factor 100. The number of "ignored" OFTP credits is calculated dynamically via the agreed value of the buffersize during protocol handshake, based on a maximum TCP/IP package size of 60000 bytes (where 65536 bytes are possible). If you experience transfer aborts, disable this feature.

SSL/TLS parameters

For securing TLS sessions over TCP/IP networks (such as internet), you need to give some information about your local certificates. These information don't have to be the same as for file based security.

local certificate file & local certificate password

DB configuration name: tls_local_certificate & tls_server_cert_password

Absolute path to the OFTP server certificate (in PEM format) for OFTP over TCP/IP (TLS secured). If the certificate is password-protected, you may enter it in the password field.

local client certificate file & client certificate password

DB configuration name: tls_default_client_certificate & tls_client_cert_password

Absolute path to the OFTP server certificate (in PEM format) for OFTP over TCP/IP (TLS secured). If the certificate is password-protected, you may enter it in the password field.

root certificate file & root certificate path

DB configuration name: tls_root_certificate & tls_root_certpath

The root certificates are used to authentificate partners which have certificates of unknown signers. At least one of these fields must be filled (even if the root certificate path doesn't contain any root certificates). The certificates must be in PEM format.

Diffie-Hellman parameter files

DB configuration name: dh128_file, dh256_file, dh512_file & dh1024_file

These files (128bit, 256bit, 512bit and 1024bit) contain prime numbers, which are the basis for TLS encrypted connections. If the file is writable, or the file doesn't exist and the directory is writable, you can generate a new file from the web interface by using the link "Recalculate" or "Generate" in the web interface, which opens a new window which executes the command. Don't close this window until you can read the message "You can close this window now"!

Allow self-signed certificates

DB configuration name: oftpv2_allow_selfsigned_cert

Enabling this checkbox disables the rejection of incoming TLS connections which are secured via a self signed certificate. The default should be on.

Entropy file for random data

DB configuration name: tls_entropy_file

In order to use TLS, you have to specify a random data source. This is a kernel based character file (like "/dev/urandom" or "/dev/random"). If your operating system doesn't support such a random file (like AIX 5.1), you can generate such a file on your own (i.e. with the tool "ssh-rand-helper" from any openSSL installation). At least 256 bytes of random data must exist in this file.

ISDN parameters

Basic ISDN parameters for OFTP connections have to be defined here.

ISDN OFTP maximum buffersize

DB configuration name: oftp_default_buffersize_isdn

As the TCP/IP maximum buffersize (as mentioned above), this numeric value reflects the maximum size of a OFTP data buffer. It may result to problems if this is set to values higher than your ISDN controllers can use for maximum transfer size, which is limited by CAPI2.0 to 4096 bytes. The minimum is 128 bytes.

ISDN OFTP maximum credit count

DB configuration name: oftp_default_creditcount_isdn

Same as the TCP/IP maximum credit count, this numeric value reflects the number of OFTP data exchange buffers before a little handshake will be done by the OFTP protocol.

Odette parameters

Default OFTP parameters for authentifications are configurable here. If no special columns are defined in the partner table below, these values will be used.

my default SSID, my default SFID, my default OFTP password, change every partner entry

DB configuration name: default_ssid, default_sfid & default_password

These elements are only used for the web interface for creating new partners or for changing all partner values. If the checkbox is enabled, all partners in the partner table will get the new values for SSID, SFID and password on your side. If you don't configure columns in the partner table configuration below, these values are used for OFTP authentification.

Directories

In order to let OS4X know where to find directories and files, these values have to be defined.

data incoming directory

DB configuration name: incoming_directory

After successful file transfers (receiving), this directory defines where the incoming files will be stored. This directory must be on the same filesystem as the temporary directory (see below), otherwise you will get an error message in syslog (if enabled) that moving incoming files cannot be done. The filesystem must be dimensioned big enough to store a file with at most the maximum transfer size. I.e., if you receive a file of 200MB, you will need to have 200MB free on this filesystem, otherwise an error message will be sent to the partner (that the local filesystem is not big enough) and an entry to the receive log will be added.

data outgoing directory

DB configuration name: outgoing_directory

In order to enqueue a new file, the file selector of the web interface (in the send queue) will point to this directory first. Also, OS4X Enterprise uses this directory for outgoing files selected by a client.

temporary directory

DB configuration name: tmp_directory

During incoming file transfers, the file fragments will be stored in this directory. Keep in mind (as mentioned above) to set this directory to the same filesystem as the incoming directory. The filesystem must be dimensioned big enough to store a file with at most the maximum transfer size. I.e., if you receive a file of 200MB, you will need to have 200MB free on this filesystem, otherwise an error message will be sent to the partner (that the local filesystem is not big enough) and an entry to the receive log will be added.

database backup directory

DB configuration name: backup_directory

If you want to use the OS4X backup mechamism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "os4xbackup" and "os4xrestore".

binary installation directory

DB configuration name: bin_directory

This directory points to your binary installation of OS4X. It also contains the license key, so if you receive a license error, first check the existence of this directory and the file "license.key" in it. This entry is also used for the web interface to start the daemons.

script installation directory

DB configuration name: script_directory

This directory points to your script installation of OS4X. It contains helpful scripts, such as database backup and restore scripts and maybe other useful tools. The OS4X web interface uses this definition.

absolute path to 'openssl'

DB configuration name: openssl_binary_path

OS4X uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running OS4X processes.

absolute path to 'rrdtool'

DB configuration name: rrdtool_binary_path

In order to use statistics, you have to define the path to „rrdtool“, the Round Robin database tool by Tobias Oetiker. The standard OS4X distribution contains a pre-compiled version which works within OS4X. If the file configured isn't executable, statistics are disabled. The program is used to create databases within OS4X binaries, push data in it and to display the results as graphical output in the web interface. The latest version of "rrdtool" can be found under http://oss.oetiker.ch/rrdtool/. On his website he has also Amazon wishlists, so if you want to support his great work, please donate some gifts.

RRDB data path

DB configuration name: rrdb_datapath

In this path, OS4X creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running OS4X. If the path isn't writable or doesn't exists, statistics are disabled. For each partner, a file is generated for incoming transfer and for outgoing. The total consumption on the filessystem is about 315kB per partner.

absolute path to RRDtool TTF file

DB configuration name: rrdtool_font_path

The statistical overview needs a font file (as Truetype font). Without this font file, you won't get any textual information in the statistic graphs.

SQL lost messages file

DB configuration name: sql_lost_messages_file

If the configured MySQL server isn't reachable at any time, the SQL statements which are being sent to the MySQL server are logged into this file. If the file doesn't exists it will be created, so the directory must be writable for the user running OS4X. The file itself (if it exists) must also be writable by the user running OS4X.

MySQL dump tool

DB configuration name: mysqldump

As a useful tool from each MySQL distribution, the tool "mysqldump" is used in the OS4X backup script for doing its job.

Event scripts

First some words about the global behaviour of scripts:

event script usage

Every time the configuration of OS4X is checked by a binary (which is at start time or when processing the signal 1 - SIGHUP), the event script configuration is checked. If a script is non-existant and/or the execute permissions don't allow the execution of a configured script, it won't get executed. No warning will be printed out or logged somewhere.

event script sleep time

Sometimes it is very handy if the event scripts are started with a little lag. This can be especially interesting if the „end receive“ or „end send“ scripts are called very fast because of small transfer files (i.e. ENGDAT abstract file). If you experience problems with your EDI system (i.e. it doesn't catch all files), try to increase the appropriate value. Keep in mind that the OFTP session waits that time you configured the sleep time. Setting the values very high increases the risk of a disconnect if the remote site has very little timeouts configured! More than 5 seconds should not be normal!

start send script

DB configuration name: start_send_script & sleep_start_send_script

If a file is getting sent, this script or program will be started with the documented parameters.

end send script

DB configuration name: end_send_script & sleep_end_send_script

If a file has finished (successfully or not) sending, this script or program will be started with the documented parameters.

xERP script

DB configuration name: xerp_script & sleep_xerp_script

If an EERP or NERP (OFTP 2 only) message is received, this script will be started. OS4X tries to find a send queue entry which conforms to the given parameters in order to set the values for comment, absolute path etc. If no send queue entry can be found that matches the given parameters in the EERP or NERP message, the script won't be executed. This script receives the same parameters as the end send script script.

start receive script

DB configuration name: start_receive_script & sleep_start_receive_script

If a file is getting received, this script or program will be started with the documented parameters.

end receive script

DB configuration name: end_receive_script & sleep_end_receive_script

If a file has finished (successfully or not) receiving, this script or program will be started with the documented parameters.

start session script

DB configuration name: start_session_script & sleep_start_session_script

After a positive OFTP handshake, this script or program will be started with the documented parameters.

end session script

DB configuration name: end_session_script & sleep_end_session_script

After a positive OFTP session, this script or program will be started with the documented parameters.

send queue entry blocked script

DB configuration name: blocked_script & sleep_blocked_script

If a send queue entry gets blocked (i.e. wrong authentification, unsupported virtual filename at the remote site, connection problems), this scripts will be started. If more than one entry for a partner gets blocked, each send queue entry will start its own blocked script.

debug daemon log script

DB configuration name: os4xdebugd_log_script

After a debug log has been written, this script will be started. This can be the case when asking for a debug log interactively (or with starting the appropriate program manually) or, if configured, when automatically created debug logs are written.

license script & trigger level

DB configuration name: license_script & license_script_hwm

This script will be started after a configurable trigger level (in percent) is exceeded. Its main porpuse is to inform a responsible person that a new license should be obtained or other actions should be taken.