Difference between revisions of "OS4X Core configuration"

From OS4X
Jump to navigation Jump to search
 
(300 intermediate revisions by the same user not shown)
Line 10: Line 10:
 
*TCP/IP
 
*TCP/IP
 
*SSL/TLS
 
*SSL/TLS
*ISDN
 
 
*Odette
 
*Odette
 
*Directories
 
*Directories
*Event scripts
+
*Events
 
*Daemon
 
*Daemon
 
*Partner table
 
*Partner table
*GUI niceup
+
*GUI
  
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.
+
Each block is accessible with a link in the head of the configuration panel.
  
 
=== database method ===
 
=== database method ===
Line 35: Line 34:
 
=== TCP/IP ===
 
=== TCP/IP ===
 
This block contains all basic TCP/IP parameters, such as port numbers, timeout values etc.
 
This block contains all basic TCP/IP parameters, such as port numbers, timeout values etc.
 +
 +
[[Image:Config-tcpip.png]]
  
 
==== TCP/IP port of OFTP server ====
 
==== TCP/IP port of OFTP server ====
''DB configuration name: tcp_port''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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 "<code>SOMAXCONN</code>".
 
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 "<code>SOMAXCONN</code>".
  
 
==== TCP/IP port of OFTP server (TLS) ====
 
==== TCP/IP port of OFTP server (TLS) ====
''DB configuration name: tcp_port_tls''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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 "<code>SOMAXCONN</code>". This port must not be the same as the OFTP server port from above.
 
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 "<code>SOMAXCONN</code>". This port must not be the same as the OFTP server port from above.
  
 
==== TCP/IP port of OS4X debug daemon ====
 
==== TCP/IP port of OS4X debug daemon ====
''DB configuration name: debugd_port''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
 
==== TCP/IP timeout ====
''DB configuration name: tcp_timeout''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.
 
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 ====
 
==== TCP/IP OFTP maximum buffersize ====
''DB configuration name: oftp_default_buffersize_tcpip''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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. For configurations with problemous partners like old Seeburger products, please use 800 bytes as buffersize.
 
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. For configurations with problemous partners like old Seeburger products, please use 800 bytes as buffersize.
  
 
==== TCP/IP OFTP maximum credit count ====
 
==== TCP/IP OFTP maximum credit count ====
''DB configuration name: oftp_default_creditcount_tcpip''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.
+
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. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.
  
==== use receiving acceleration? ====
+
==== Outgoing IP address ====
''DB configuration name: oftp_tcpip_rec_acceleration''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || tcp_outgoing_ip
 +
|}
  
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.
+
By default, OS4X lets the operating system guess the correct source IP address for outgoiing connections. With this optional value, you can specify which IP address will be used for outgoing connections (which is also overwritable by partner configuration).
  
Acceleration is incompatible with the following partner software solutions:
+
==== Listener IP address ====
*Seeburger WinElke
+
{|style="background:white"
*Bartsch Software
+
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || tcp_incoming_ip
 +
|}
  
==== use send acceleration? ====
+
OS4X listens to all interfaces for plain TCP and TLS connections. With this configuration you can specify a single IP address which will be bound to the listener process.
''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.
 
Acceleration is incompatible with the following partner software solutions:
 
*Seeburger WinElke
 
*Bartsch Software
 
  
 
=== SSL/TLS parameters ===
 
=== SSL/TLS parameters ===
Line 88: Line 107:
 
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.
 
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 ====
+
[[Image:Config-ssl.png]]
''DB configuration name: tls_local_certificate & tls_server_cert_password''
+
 
 +
==== TLS server certificate file & TLS server certificate password ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
+
==== TLS client certificate file file & TLS client certificate password ====
''DB configuration name: tls_default_client_certificate & tls_client_cert_password''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
 
==== root certificate file & root certificate path ====
''DB configuration name: tls_root_certificate & tls_root_certpath''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
+
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.
 +
 
 +
These variables are (if set) available to processes started by OS4X via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[OS4X Core environment variables]]).
  
 
==== Diffie-Hellman parameter files ====
 
==== Diffie-Hellman parameter files ====
''DB configuration name: dh128_file, dh256_file, dh512_file & dh1024_file''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || dh1024_file & dh2048_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  
+
These files (1024bit and 2048bit) 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''"!
 
close this window now''"!
  
==== Allow self-signed certificates ====
+
==== TLS server: check client certificate validity ====
''DB configuration name: oftpv2_allow_selfsigned_cert''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || tls_server_check_client_cert
 +
|}
 +
 
 +
When this option is activated, all incoming TLS connections will be checked for a client certificate and a validity path for them. In case of self-signed certificates from the client, you have to add them manually (by requesting them from the partners) to your trusted certificate pool.
 +
 
 +
In case of client sessions, OS4X will override a wrong purpose of the server certificate (such as "SSL Client: no").
 +
 
 +
Summarizing:
 +
 
 +
If you have this checkbox enabled (default):
 +
*OS4X's TLS server asks the remote side, if not already presented, during TLS handshake for a client certificate.
 +
*This TLS client certificate is checked against the list of trusted certificates in order to verify a valid certificate chain for the certificate.
 +
*If the certificate chain is trusted, all chain elements are checked against the actually installed certificate revocation lists ("CRLs").
 +
 
 +
If you have this checkbox disabled (not the default, not recommended):
 +
*None of the above checks is being executed.
 +
*Every TLS client can connect to your server without any further client certificate check.
 +
*Recommended only if:
 +
**You have a firewall which applies partner defined rules, so you are sure who is connecting to your TLS server
 +
**Have OFTP2 secure authentification enabled, in addition with the enabled "[[OS4X_Core_configuration#enable_OFTP_message_checker|OFTP message checker]]" (in "Configuration" -> "Daemon") for protocol syntax validity verification (which lowers throughput and consumes higher server CPU).
 +
 
 +
==== Ignore TLS CRL unavailability? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || tls_ignore_crl_unavailable
 +
|}
 +
 
 +
If the above option "check client certificate validity" is activated, it is possible to deactivate the check of an existance of a CRL for all CA certificates which OS4X doesn't have a CRL downloaded yet. This solves the problems with the following log entries the system log:
 +
TLS error: no X509 certificate given in TLS handshake by remote partner
 +
 
 +
openSSL error: TLS network session failed, certificate problem: application verification failure
 +
 
 +
You must download a CRL for the CA of the certificate with the subject '...'
 +
 
 +
certificate verify error 3: unable to get certificate CRL: depth=0, subject: ...
 +
 
 +
==== Archive CRLs? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || archive_crl
 +
|}
 +
 
 +
When activated, all overwritten CRLs will be archived before every update. When deleting CRLs, they will be archived, too.
 +
 
 +
==== Disable automatic CRL handling ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || disable_auto_crl
 +
|}
 +
 
 +
Normally, the OS4X send queue daemon scans all partner certificates for a new CRL URL and add them to the CRL list when not included. By activating this checkbox, you can disable this default behaviour.
 +
 
 +
==== Disable automatic reactivation of CRLs ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || crl_dont_automatic_reactivate
 +
|}
 +
 
 +
If automatic CRL handling is not deactivated, OS4X will enable all found disabled CRL entries found in certificates. If you don't want this behaviour, you can disable the reactivation by enabling this configuration option.
 +
 
 +
==== Ignore CRL download errors of Mendelson ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || crl_ignore_downloaderrors_mendelson
 +
|}
 +
 
 +
Since the CRLs of Mendelson CA are unavailable many times, your system log will be spammed with error message about this situation. Enabling this flag will not post any error logs into OS4X's system log if the download of a Mendelson CA CRL fails.
 +
 
 +
==== Check CRL URLs every x timeslices ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || autocrl_sendq_timeslices
 +
|}
 +
 
 +
The send queue daemon can process every configured amount of timeslices (configured in the daemon section [[OS4X_Core_configuration#time_slice_for_send_queue_daemon|here]]) all trusted certificates and their CRL distribution points. If any is not included in the revocation list yet, it will be added and handled. Cofiguration values above 512 and below 1 will be resetted to 10.
 +
 
 +
==== Maximum age of CRLs ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || maximum_crl_age
 +
|}
 +
 
 +
CRLs carry a date within them which defined when they become invalid. OS4X takes care of such CRLs by downloading and updating the database values according to the new content.
 +
With this configuration parameter you make any CRL entry invalid (and therefore marked for automatic update) which has an older update date than these amount of days before. So, the locally downloaded version of the CRL becomes invalid and gets updated eventually even before the next CRL will be issued.
  
Enabling this checkbox disables the rejection of incoming TLS connections which are secured via a self signed certificate. The default should be on.  
+
This feature is recommended by the OFTP2 working group.
  
 
==== Entropy file for random data ====
 
==== Entropy file for random data ====
''DB configuration name: tls_entropy_file''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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 "<code>/dev/urandom</code>" or "<code>/dev/random</code>"). 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.
 +
 
 +
==== TSL URL ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || TSL_URL
 +
|}
 +
 
 +
This URL defines the position of a list administrated by Odette which contains a list of authorized certificate authorities. If the signed XML could be verified successfully, all contained certificate authorities are added automatically to OS4X.
 +
 
 +
The default value is:
 +
http://www.odette.org/TSL/TSL_OFTP2.XML
 +
 
 +
==== Disable security warnings? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configTlsDisableSecurityWarnings
 +
|}
 +
 
 +
When enabled, OS4X will never complain about insecure TLS cipher usage in connection logs (despite OS4X SmartProxy logs, since the OS4X SmartProxy doesn't support this insecurity "feature").
 +
 
 +
==== TLS ciphers? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp2_tls_ciphers
 +
|}
 +
 
 +
The list of supported TLS ciphers can be configured. See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for more details.
 +
 
 +
==== Enable only PFS ciphers? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configTlsEnablePfs
 +
|}
 +
 
 +
When enabled, all incoming and outgoing TLS traffic will occure with a secure TLS cipher supporting a secure key exchange mechanism. A fallback to a less secure cipher is supported, but logged.
 +
 
 +
==== Allow insecure downgrade of TLS cipher? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configTlsAlllowInsecure
 +
|}
 +
 
 +
In TLS, the most secure sessions are being tried to be initiated. This is done by providing a list of supported ciphers from server to client and vica versa in a prioritized list. If the list leads to a cipher which uses Diffie-Hellman for secure key exchange during session handshake, the used Diffie-Hellman key must be at least 1024bit wide. If this minimum size is not supported by the remote party, the outgoing session will be retried without offering Diffie-Hellman ciphers. A warning will be locked.
 +
 
 +
Due to the Logjam attack in 2015, this behaviour is not recommeded and is strictly out of our support. Use this feature at your own risk!
 +
 
 +
==== Allow partial check of certificate chain? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configTlsAllowPartialChain
 +
|}
 +
 
 +
In case of ca CA certificate in the chain without the required flag "CA:true", OS4X by default closes the TLS session. When enabling this option, the "CA" flag is not required to be present for the end of the certificate chain.
 +
 
 +
----
 +
 
 +
=== Proxy ===
 +
OS4X offers for all HTTP and HTTPS transfer tasks proxy support. In order to use a defined proxy, several options are available. More details can be found [[OS4X HTTP Proxy support|here]]
 +
 
 +
[[Image:Config-proxy.png]]
 +
 
 +
==== Use HTTP proxy? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_enabled
 +
|}
 +
 
 +
If you want to use a proxy, enable this checkbox. If the checkbox is disabled, all proxy relevant environment variables (see [[OS4X HTTP Proxy support]]) are cleared in all proxy using tools and binaries (and thus the forked processes by these binaries also don't have proxy environment variables defined).
 +
 
 +
==== Use user settings/environment variables? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_use_env
 +
|}
 +
 
 +
If your used running OS4X already has environmental variables defined for proper proxy support, you should enable this checkbox. Otherwise (if disabled), you have to configure the proxy in the parameter fields below.
 +
 
 +
==== Proxy hostname or IP ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_host
 +
|}
 +
 
 +
The resolvable hostname or IP address of the proxy server.
 +
 
 +
==== Proxy port number ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_port
 +
|}
 +
 
 +
The port number the proxy server is listening on. Only numbers are allowed here, from range 1-65535. Any other values will lead to misfunctions. Often used values are "8080" or "3128".
  
In order to use TLS, you have to specify a random data source. This is a kernel based character file (like "<code>/dev/urandom</code>" or "<code>/dev/random</code>"). 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.
+
==== Proxy username ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_username
 +
|}
  
=== ISDN parameters ===
+
If your proxy requires user authentification, enter a username here.
Basic ISDN parameters for OFTP connections have to be defined here.
 
  
==== ISDN OFTP maximum buffersize ====
+
==== Proxy password ====
''DB configuration name: oftp_default_buffersize_isdn''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_password
 +
|}
  
As the TCP/IP maximum buffersize (as mentioned above), this numeric value reflects the  
+
If your proxy requires user authentification, enter the valid password for the above defined user.
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. For configurations with problemous partners like old Seeburger products, please use 800 bytes as buffersize.
 
  
==== ISDN OFTP maximum credit count ====
+
==== Proxy type ====
''DB configuration name: oftp_default_creditcount_isdn''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || proxy_type
 +
|}
  
Same as the TCP/IP maximum credit count, this numeric value reflects the number of
+
Different proxy types are supported, you should know which one fits your environment. Possible values are:
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.
+
*SOCKS4
 +
*SOCKS5
 +
*HTTP
 +
 
 +
==== Use OS4X proxy? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4x_proxy_enabled
 +
|}
 +
 
 +
If you want to use OS4X proxy or OS4X OFTP2 SmartProxy, enable this checkbox. Please refer to [[OS4X Proxy|OS4X Proxy]] and [[OS4X SmartProxy|OS4X OFTP2 SmartProxy]] for more detailled information.
 +
----
  
 
=== Odette parameters ===
 
=== 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.
 
Default OFTP parameters for authentifications are configurable here. If no special columns are defined in the partner table below, these values will be used.
 +
 +
[[Image:Config-odette.png]]
  
 
==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====  
 
==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====  
''DB configuration name: default_ssid, default_sfid & default_password''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || default_ssid, default_sfid & default_password
 +
|}
  
 
These elements are only used for the web interface for creating new partners or for  
 
These elements are only used for the web interface for creating new partners or for  
Line 146: Line 385:
 
get the new values for SSID, SFID and password on your side. If you don't configure  
 
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  
 
columns in the partner table configuration below, these values are used for OFTP  
authentification.  
+
authentification.
 +
----
  
 
=== Directories ===
 
=== Directories ===
 
In order to let OS4X know where to find directories and files, these values have to be defined.
 
In order to let OS4X know where to find directories and files, these values have to be defined.
  
 +
[[Image:Config-directories.png]]
 
==== data incoming directory ====
 
==== data incoming directory ====
''DB configuration name: incoming_directory''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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.  
Line 158: Line 402:
  
 
==== data outgoing directory ====
 
==== data outgoing directory ====
''DB configuration name: outgoing_directory''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.
+
This directory will be used by OS4X Webaccess (which is part of OS4X Enterprise) for outgoing jobs when initiating a send job. The plugins
 +
[[OS4X plugin os4xplugin_filemove|os4xplugin_filemove]] and [[OS4X plugin os4xplugin_filecopy|os4xplugin_filecopy]] can refer to this directory by a configuration value.
  
 
==== temporary directory ====
 
==== temporary directory ====
''DB configuration name: tmp_directory''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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 [[OS4X Core configuration#data incoming directory|incoming directory]]. The filesystem must be dimensioned big enough to store a file with at most the maximum  
 
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 [[OS4X Core configuration#data incoming directory|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.  
 
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.  
 +
 +
==== temporary directory (for software updates) ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDirTmpUpdates
 +
|}
 +
 +
Since OS4X Release 2016-01-22, this optionally configurable directory defines where the software updater extracts its content to. This solves issues when writing temporary files during software update to a network attached share as configured in "temporary directory" above.
  
 
==== database backup directory ====
 
==== database backup directory ====
''DB configuration name: backup_directory''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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".  
+
If you want to use the OS4X backup mechanism, 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 ====
 
==== binary installation directory ====
''DB configuration name: bin_directory''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
 
==== script installation directory ====
''DB configuration name: script_directory''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.
 
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' ====
 
==== absolute path to 'openssl' ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || tcp_timeout
 +
|}
 
''DB configuration name: openssl_binary_path''
 
''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.  
+
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.
 +
The used openSSL binary must be of version 0.9.9dev, 1.0.0 or higher to fulfill the functionality for OFTP2.
  
 
==== absolute path to 'rrdtool' ====  
 
==== absolute path to 'rrdtool' ====  
''DB configuration name: rrdtool_binary_path''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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.  
Line 195: Line 471:
  
 
==== RRDB data path ====
 
==== RRDB data path ====
''DB configuration name: rrdb_datapath''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====  
 
==== absolute path to RRDtool TTF file ====  
''DB configuration name: rrdtool_font_path''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
 
==== SQL lost messages file ====
''DB configuration name: sql_lost_messages_file''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.
 
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.
 +
 +
==== Append datestamp to SQL lost messages file? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || sql_lost_messages_file_append_timestamp
 +
|}
 +
 +
If enabled, in case of database inaccessibility, all SQL statements which could not be executed will be logged in the above configured "SQL lost message file", which gets a datestamp appendix to the filename. This datestamp consists of the following:
 +
*a single dot ("<code>.</code>")
 +
*year with 4 digits (like "<code>2009</code>")
 +
*month with 2 digits (like "<code>03</code>")
 +
*day with 2 digits (like "<code>27</code>")
 +
 +
Example with a lost message fole configured to "<code>/opt/os4x/tmp/sql_lost_messages</code>":
 +
/opt/os4x/tmp/sql_lost_messages.20090307
 +
 +
/opt/os4x/tmp/sql_lost_messages.20090130
  
 
==== MySQL dump tool ====
 
==== MySQL dump tool ====
''DB configuration name: mysqldump''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || mysqldump
 +
|}
  
 
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 ===
+
==== Absolute path to send test file ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || send_test_file
 +
|}
 +
 
 +
If configured, a test file can be defined for enqueueing via the partner list or via "Send queue" -> "Add" to simply test the connection functionality. This configured absolute file name will be transmitted.
 +
 
 +
==== Send as virtual filename ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || send_test_vfn
 +
|}
 +
 
 +
This is the virtual filename which will be used for enqueueing the above configured send test file.
 +
 
 +
=== Events ===
 +
[[Image:Config-events.png]]
 +
 
 
First some words about the global behaviour of scripts:
 
First some words about the global behaviour of scripts:
  
 
==== event script usage ====
 
==== 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.
 
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.
 +
 +
Presets exist (which are dynamically calculated with the last saved values for the scripts and binary directory configured [[OS4X_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either OS4X Enterprise (Lite) and/or OS4X 2 Core.
  
 
==== event script sleep time ====
 
==== event script sleep time ====
Line 224: Line 549:
  
 
==== start send script ====
 
==== start send script ====
''DB configuration name: start_send_script & sleep_start_send_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
If a file is getting sent, this script or program will be started with the documented parameters.  
  
 
==== end send script ====
 
==== end send script ====
''DB configuration name: end_send_script & sleep_end_send_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
If a file has finished (successfully or not) sending, this script or program will be started with the documented parameters.  
  
 
==== xERP script ====
 
==== xERP script ====
''DB configuration name: xerp_script & sleep_xerp_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
 
==== start receive script ====
''DB configuration name: start_receive_script & sleep_start_receive_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
If a file is getting received, this script or program will be started with the documented parameters.  
  
 
==== end receive script ====
 
==== end receive script ====
''DB configuration name: end_receive_script & sleep_end_receive_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
If a file has finished (successfully or not) receiving, this script or program will be started with the documented parameters.  
  
 
==== start session script ====
 
==== start session script ====
''DB configuration name: start_session_script & sleep_start_session_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
After a positive OFTP handshake, this script or program will be started with the documented parameters.  
  
 
==== end session script ====
 
==== end session script ====
''DB configuration name: end_session_script & sleep_end_session_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
After a positive OFTP session, this script or program will be started with the documented parameters.  
  
 
==== send queue entry blocked script ====
 
==== send queue entry blocked script ====
''DB configuration name: blocked_script & sleep_blocked_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.  
 
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 ====
 
==== debug daemon log script ====
''DB configuration name: os4xdebugd_log_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.
+
After a debug log has been written, [[OS4X_Core_event_scripts#debug_daemon_log_script|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 ====
 
==== license script & trigger level ====
''DB configuration name: license_script & license_script_hwm''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''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.
 
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.
  
==== Enable automatic update mechanism & OS4X automatic software update script ====
+
==== Enable automatic update mechanism & OS4X automatic software update event ====
''DB configuration name: run_updates_automatically & os4xupdate_script''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || run_updates_automatically & os4xupdate_script
 +
|}
  
 
If the value of ''run_updates_automatically'' is non-zero (if the checkbox is enabled), the automatic update script is started with the received file with the reserved virtual filename "<code>OS4X_UPDATE</code>". This is normally a program of the OS4X distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[OS4X_Core_configuration#run_OS4X_update_program_as_user|run OS4X update program as user]]).
 
If the value of ''run_updates_automatically'' is non-zero (if the checkbox is enabled), the automatic update script is started with the received file with the reserved virtual filename "<code>OS4X_UPDATE</code>". This is normally a program of the OS4X distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[OS4X_Core_configuration#run_OS4X_update_program_as_user|run OS4X update program as user]]).
 +
 +
==== OS4X automatic update post event ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEventUpdatePost
 +
|}
 +
 +
After a software update has been executed via the program "[[OS4X_Core_binaries#os4xupdate|os4xupdate]]", the configurable post event can be started, i.e. for cleanup reasons or informing system management hierachies.
 +
 +
==== enqueue post-event ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enqueue_post_script
 +
|}
 +
 +
This script which will be executed after a successful enqueueing process.
 +
 +
==== OS4X API proxy system log event script ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xapi_proxy_systemlog_script
 +
|}
 +
 +
This script which will be executed after a critical situation of the OS4X Proxy will be logged in the OS4X system log.
 +
 +
==== Event failure event ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || event_failure_script
 +
|}
 +
 +
In case of an error during event execution, this event can be executed.
 +
 +
==== System log event & only non-OK entries fire  ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEventSystemLogEvent
 +
|}
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEventSystemLogEventOnlyNonOk
 +
|}
 +
 +
When an entry to the system log is added, this event can be executed (selective for only non-OK entries).
 +
 +
==== Enable 3DEXPERIENCE integration ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enable3Dexperience
 +
|}
 +
 +
'''Requirement: OS4X Enterprise.''' If this option is enabled, sent files via 3DEXPERIENCE will be handled natively by the 3DEXPERIENCE integration. If enabled, this option disables the next configurable event "Event to be executed for sent non-Enterprise files".
 +
 +
==== Event to be executed for sent non-Enterprise files ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || non_enterprise_send_event
 +
|}
 +
 +
For all files which are sent via non-OS4X Enterprise mechanisms, this event will execute a special end-send event handler.
 +
 +
==== OS4X Enterprise user created event ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_user_created_event
 +
|}
 +
 +
When an OS4X Enterprise user is created this event can handle its parameters.
 +
 +
----
  
 
=== Daemon parameters ===
 
=== Daemon parameters ===
 
The behaviour of all binaries and OS4X programs can be influenced here.
 
The behaviour of all binaries and OS4X programs can be influenced here.
 +
 +
[[Image:Config-daemon.png]]
  
 
==== run OS4X programs as user ====
 
==== run OS4X programs as user ====
''DB configuration name: running_as_user''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || running_as_user
 +
|}
  
 
When starting as user "<code>root</code>", all OS4X binaries will try to switch to this configured user, if available on the running system. Subsequent calls of scripts and other programs are also done in the context of this user. This is extremely useful for runlevel scripts.
 
When starting as user "<code>root</code>", all OS4X binaries will try to switch to this configured user, if available on the running system. Subsequent calls of scripts and other programs are also done in the context of this user. This is extremely useful for runlevel scripts.
 +
 +
'''Double-check that this user exists in the system running OS4X, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''
  
 
==== run OS4X update program as user ====
 
==== run OS4X update program as user ====
''DB configuration name: running_update_as_user''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || running_update_as_user
 +
|}
  
 
If enabled below, automatic software update are being run using this specific username. If changing to the context of this given user fails, the whole update procedure fails. If no username is configured, superuser "<code>root</code>" is used.
 
If enabled below, automatic software update are being run using this specific username. If changing to the context of this given user fails, the whole update procedure fails. If no username is configured, superuser "<code>root</code>" is used.
  
 
==== time slice for send queue daemon ====
 
==== time slice for send queue daemon ====
''DB configuration name: os4xsqd_sleep_time''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xsqd_sleep_time
 +
|}
  
The send queue daemon „os4xsqd2“ waits this amount of seconds before looking at the send queue table and react as needed (send one more entry, wait more time etc.).  
+
The send queue daemon „os4xsqd“ waits this amount of seconds before looking at the send queue table and react as needed (send one more entry, wait more time etc.).  
  
 
==== time slice for receive daemon ====
 
==== time slice for receive daemon ====
''DB configuration name: os4xrd_sleep_time''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xrd_sleep_time
 +
|}
  
 
The receiving daemon „os4xrd2“ waits this amount of seconds before looking at the configuration table and react as needed (wait more time or stop itself).  
 
The receiving daemon „os4xrd2“ waits this amount of seconds before looking at the configuration table and react as needed (wait more time or stop itself).  
  
 
==== delete send queue entries ====
 
==== delete send queue entries ====
''DB configuration name: delete_after_transfer''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || delete_after_transfer
 +
|}
 +
 
 +
This checkbox defines if the send queue table entries should be deleted (not the files itself, only the entry!) after a successful send. (If you need to delete the file itself, you should use the [[OS4X Core configuration#end_send_script|end send script]], which gets the absolute filename as a parameter).
 +
 
 +
If this option is enabled, it automatically disabled the following option "Cleanup of sent send queue entries".
 +
 
 +
==== Cleanup of sent send queue entries ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configSendqueueCleanup
 +
|}
 +
 
 +
If enabled, the send queue daemon cleans up the send queue for all entries with a given age automatically (based on the timestamp of "last change"). Optionally, an event "[[OS4X_Core_event_scripts#Send_queue_cleanup_event|Send queue cleanup event]]" will be executed.
 +
 
 +
===== Age of send queue entries for cleanup (days) =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configSendqueueCleanupDays
 +
|}
 +
 
 +
Send queue entries in status "successfully sent" with the last change date older than this amount of days will be taken into account for automatic cleanup.
  
This checkbox defines if the send queue table entries should be deleted (not the files itself, only the entry!) after a successful send. (If you need to delete the file itself, you should use the [[OS4X Core configuration#end_send_script|end send script]], which gets the absolute filename as a parameter).
+
===== Delete file, if available =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configSendqueueCleanupDeleteFile
 +
|}
 +
 
 +
If this option is enabled, the automatic cleanup mechanism will delete the referenced file on the filesystem. If file deletion will take place, a log message will look like:
 +
Deleted send queue entry '<virt. filename>' and file '<abs. filename>'
 +
 
 +
If this option is disabled or the referenced file doesn't exist, the log message says:
 +
Deleted send queue entry '<virt. filename>'
  
 
==== let all files of send queue be fetchable ====
 
==== let all files of send queue be fetchable ====
''DB configuration name: fetch_all_from_remote''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || fetch_all_from_remote
 +
|}
  
 
Since polling is supported from remote systems, you can define files to be pollable. If you enable this checkbox, all files in your send queue which are in state of "new in queue" and "ready for remote fetch" will be sent in an OFTP session to the partner (otherwise, only entries "ready for remote fetch" are fetchable).  
 
Since polling is supported from remote systems, you can define files to be pollable. If you enable this checkbox, all files in your send queue which are in state of "new in queue" and "ready for remote fetch" will be sent in an OFTP session to the partner (otherwise, only entries "ready for remote fetch" are fetchable).  
  
 
==== overwrite existing incoming files ====
 
==== overwrite existing incoming files ====
''DB configuration name: os4xrd_overwrite''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xrd_overwrite
 +
|}
  
 
If the incoming file exists in the "[[OS4X Core configuration#data incoming directory|incoming directory]]", you can define to overwrite it. Otherwise, the partner will receive an error message saying that the local file already exists. (this might be useful for partners who don't like to reiceive an EEPR [end-to-end- response] message right after a successful filetransfer).  
 
If the incoming file exists in the "[[OS4X Core configuration#data incoming directory|incoming directory]]", you can define to overwrite it. Otherwise, the partner will receive an error message saying that the local file already exists. (this might be useful for partners who don't like to reiceive an EEPR [end-to-end- response] message right after a successful filetransfer).  
 
==== archive received xERP messages & archive sent xERP messages ====
 
''DB configuration name: oftpv2_archive_received_xerp & oftpv2_archive_sent_xerp''
 
 
It may be useful archive positive and/or negative end-to-end responses. These xERP messages can be seen as acknowledgements from the partner (received xERP) or from
 
yourself (sent xERP). The web interface contains a archive viewer on the left hand: "xERP log". This feature may be needed in some countries for legal issues.
 
 
==== use syslog ====
 
''DB configuration name: use_syslog''
 
 
If you turn on this checkbox, major errors will be logged to the server's syslog facility with the severity LOG_ERR. Major errors are table misconfigurations or process dependant messages (fork failures, memory allocation problems etc.).
 
  
 
==== default maximum send tries for send queue daemon ====
 
==== default maximum send tries for send queue daemon ====
''DB configuration name: os4xsqd_max_tries''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xsqd_max_tries
 +
|}
  
The send queue daemon "os4xsqd2" will try to send one or all entries this amount of times. After this amount of unsuccessful tries, one or all send queue entries for that partner will be blocked (which will also get logged into the send log). All entries for a partner get blocked, if a connection problem occurs (i.e. invalid SSID/SFID or password, no physical connection to partner, wrong ISDN number or TCP/IP address etc.). One entry will be blocked if the partner doesn't accept this file. The other files are not affected by that error (i.e. wrong virtual filename, wrong alternative SFID of originator or destination).  
+
The send queue daemon "os4xsqd2" will try to send one or all entries this amount of times. After this amount of unsuccessful tries, one or all send queue entries for that partner will be blocked (which will also get logged into the send log). All entries for a partner get blocked, if a connection problem occurs (i.e. invalid SSID/SFID or password, no physical connection to partner or TCP/IP address etc.). One entry will be blocked if the partner doesn't accept this file. The other files are not affected by that error (i.e. wrong virtual filename, wrong alternative SFID of originator or destination).
  
 
==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
 
==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
''DB configuration name: os4xsqd_add_time & os4xsqd_add_time_factor''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xsqd_add_time & os4xsqd_add_time_factor
 +
|}
  
 
You can influence the time the send queue daemon „os4xsqd2“ will sleep before it tries  
 
You can influence the time the send queue daemon „os4xsqd2“ will sleep before it tries  
Line 340: Line 818:
  
 
==== progress bar refresh time ====
 
==== progress bar refresh time ====
''DB configuration name: progressbar_refresh''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || progressbar_refresh
 +
|}
  
 
OS4X will update all file transfer progress information after this value (in seconds). Because it is database driven, some MySQL server will crash if you have too many  connects to a database in a very short time (which could occur if you transfer very little files with a combination of a small exchange buffer size). If you experience problems with your database server, try increasing this value.  
 
OS4X will update all file transfer progress information after this value (in seconds). Because it is database driven, some MySQL server will crash if you have too many  connects to a database in a very short time (which could occur if you transfer very little files with a combination of a small exchange buffer size). If you experience problems with your database server, try increasing this value.  
 
==== default maximum parallel send processes ====
 
''DB configuration name: default_max_sendq_sendings_per_partner''
 
 
You can define the amount of parallel sending processes globally here. There is also a definable column in the partner table (see below) to set this value on a per-partner base. If you don't have such a column, this default value will be used.
 
  
 
==== allow unsecure OFTP 2 authentification ====
 
==== allow unsecure OFTP 2 authentification ====
''DB configuration name: oftpv2_allow_unsecure_auth''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftpv2_allow_unsecure_auth
 +
|}
  
 
If an OFTP 2 partner is requested to use OFTP 2 authentification but he doesn't support this feature, you may allow to authentificate this partner with the OFTP 1 methods by enabling this checkbox. If you insist to use OFTP 2 authentification, disable the checkbox, so the partner will receive an error message that OFTP 2 secure authentification is needed.  
 
If an OFTP 2 partner is requested to use OFTP 2 authentification but he doesn't support this feature, you may allow to authentificate this partner with the OFTP 1 methods by enabling this checkbox. If you insist to use OFTP 2 authentification, disable the checkbox, so the partner will receive an error message that OFTP 2 secure authentification is needed.  
  
 
==== delete temporary created files of OFTP 2 session ====
 
==== delete temporary created files of OFTP 2 session ====
''DB configuration name: oftpv2_delete_temp_created_files''
+
{|style="background:white"
 
+
|- style="background:lightgrey;"
OS4X creates temporary files by enqueueing files to the send queue or by directly sending a file to an OFTP 2 partner (if the partner is configured to use signing, compression and/or encryption). These temporary files can be deleted by OS4X automatically, but you may also want to keep them for later archiving.
+
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
 
+
|}
==== disable database schema check ====
 
''DB configuration name: disable_check_os4x_tables''
 
  
OS4X checks the database schema with every start of any OS4X binary program. This is very useful for verifying that the OS4X database tables are really up to date. If any table doesn't exists or a column is missing OS4X will try to create the item. The database user therefore needs privileges to create and modify the schema. Leave this checkbox disabled if you want to be on the safe side. Enable the checkbox to disable the schema checks and updates if you encounter database server problems or your database user has no privileges to modify the database.  
+
OS4X creates temporary files by enqueueing files to the send queue or by directly sending a file to an OFTP 2 partner (if the partner is configured to use signing, compression and/or encryption). These temporary files can be deleted by OS4X automatically, but you may also want to keep them for later archiving.
  
 
==== local character set ====
 
==== local character set ====
''DB configuration name: oftpv2_original_charset''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftpv2_original_charset
 +
|}
  
 
OFTP 2 supports UTF-8 formatted information and error messages within the protocol and also extended virtual filenames (up to 999 bytes of UTF-8 formatted text). To translate the UTF-8 text into your local character set and to translate command line interaction from your local character set to UTF-8, you have to define your local character set here. If your local  character set isn't listed here, you can define it in the database (table: "os4x_configuration") manually by entering the character set descriptor in the line where „name“ is "oftpv2_original_charset". All character sets which are supported by "iconv" are supported by OS4X. You get a list of supported character sets on the command line with the program:  
 
OFTP 2 supports UTF-8 formatted information and error messages within the protocol and also extended virtual filenames (up to 999 bytes of UTF-8 formatted text). To translate the UTF-8 text into your local character set and to translate command line interaction from your local character set to UTF-8, you have to define your local character set here. If your local  character set isn't listed here, you can define it in the database (table: "os4x_configuration") manually by entering the character set descriptor in the line where „name“ is "oftpv2_original_charset". All character sets which are supported by "iconv" are supported by OS4X. You get a list of supported character sets on the command line with the program:  
 
  iconv -l
 
  iconv -l
if installed.  
+
if installed.
  
==== illegal characters for virtual filenames ====
+
==== Unblock blocked send queue entries after successful connect? ====
''DB configuration name: illegal_virt_filename_chars''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
 +
|}
  
In order to reject the receipt of files with irregular characters in its names, you can define a list of characters which are not allowed. If you keep this list empty, all files are accepted. If any of the configured characters is found in the announced virtual filename, the file is rejected and the partner receives the message "illegal character in virtual filename".  
+
If enabled, this options lets the OS4X poll binary and receive daemon unblock blocked send queue entries after a incoming or outgoing connection to this partner has been successfully established.
  
==== enable CAPI keep-alive monitor ====
+
==== Disable file restart functionality? ====
''DB configuration name: capi_check_alive_monitor''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDisableFilerestart
 +
|}
  
In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for OS4X after a reboot of the Brick device, enable this feature.
+
If enabled, OS4X doesn't offer file restart functionality (which is offered by default if the communication partner supports it). In this case, the partner is told not to support file resuming, so aborted file transfers will restart in future sessions from the beginning of the file.
 +
 
 +
==== Disable automatic database cleanups / optimizations? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDisableMysqlOptimizeTables
 +
|}
 +
 
 +
OS4X cleans up database tables after a successful delete operation (in MySQL via "<code>OPTIMIZE TABLE</code>", in SQLite via "<code>VACUUM</code>" command). Enabling this configuration option disables the automatic cleanup of tables. '''Warning:''' could make your database grow in size if you don't clean up on your own!
  
 
==== enable OFTP message checker ====
 
==== enable OFTP message checker ====
''DB configuration name: oftp_message_checker''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp_message_checker
 +
|}
  
 
To secure your server, an OFTP message checker examines each transfered package for validity. This suppresses protocol attacks from remote and helps to avoid NULL pointer exceptions and other well-known attacks.  
 
To secure your server, an OFTP message checker examines each transfered package for validity. This suppresses protocol attacks from remote and helps to avoid NULL pointer exceptions and other well-known attacks.  
  
 
==== send queue entry status after abort ====
 
==== send queue entry status after abort ====
''DB configuration name: sendq_entry_status_after_abort''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || sendq_entry_status_after_abort
 +
|}
  
 
You can define the status of a send queue entry after manual abort here. It may be useful to avoid a race between an administrator and the send queue daemon if he aborts the file transfer but the send queue daemon grabs it afterwards because the time slice has taken account. Valid options are "new in queue", "successfully sent", "blocked" and "ready for remote fetch".  
 
You can define the status of a send queue entry after manual abort here. It may be useful to avoid a race between an administrator and the send queue daemon if he aborts the file transfer but the send queue daemon grabs it afterwards because the time slice has taken account. Valid options are "new in queue", "successfully sent", "blocked" and "ready for remote fetch".  
  
==== enable script logging ====
+
==== enable statistics & RRDtools refresh time ====
''DB configuration name: enable_script_logging''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enable_statistics & rrd_refresh
 +
|}
 +
 
 +
As configured above with the RRDtool paths and directories, you have the possibility to activate or deactivate the scripting functionality here. The statistics contain the average transfer speed of a partner (incoming and outgoing as separate databases). If any of the above configured RRDtool path or binary is unavailable, scripting is disabled, even if you enable it here. The refresh time is the time is seconds when statistical data is transfered into the Round Robin database. This time period depends also on the database configuration of the RRDB and is closely dependant from the creation process which is intergrated into OS4X (if an RRDB file doesn't exist). The default of 10 seconds should not be changed!
 +
 
 +
'''NEW:''' If statistics are enabled, a seperate logging table will be filled with information how many files have been transfered (in the ways "sent" and "received" with or without success. This amount of transfered filed is being displayed in the partner list and the partner "edit" details.
 +
 
 +
==== Append timestamp to received file ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || rec_append_timestamp_to_filename
 +
|}
 +
 
 +
Some partners may send you files with the same virtual  filename, but different timestamps. In order to receive these files properly, an appendix is added to the filename containing the announced timestamp of the file. This also helps to receive the same file from different partners at the same time.
 +
Beware: the timestamp syntax has changed from OFTP 1 to OFTP 2!
 +
 
 +
The appendix of the filename is as follows:
 +
*OFTP 1.0 - OFTP 1.3: "<code><datestamp><timestamp>0000</code>", i.e. "<code>200903171423590000</code>"
 +
*OFTP 1.4 and OFTP2: "<code><datestamp><timestamp><counter></code>", i.e. "<code>200903171423590523</code>"
  
Enabling this feature logs all script calls, parameters, returncodes and output to the script logs. In the web interface, you can take a look at the script logs with the link „Script log“. In this interface, you can also restart event scripts (even if they have changed in the configuration: you can then execute the original  or the new one, depending on executability of the script file).  
+
The main difference between both names is that the "counter" field in older OFTP sessions will be emulated via "<code>0000</code>".
  
==== enable statistics & RRDtools refresh time ====
+
==== Append destination SFID to received file ====
''DB configuration name: enable_statistics & rrd_refresh''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonAppendSFIDRec
 +
|}
  
As configured above with the RRDtool paths and directories, you have the possibility to activate or deactivate the scripting functionality here. The statistics contain the average transfer speed of a partner (incoming and outgoing as separate databases). If any of the above configured RRDtool path or binary is unavailable, scripting is disabled, even if you enable it here. The refresh time is the time is seconds when statistical data is transfered into the Round Robin database. This time period depends also on the database configuration of the RRDB and is closely dependant from the creation process which is intergrated into OS4X (if an RRDB file doesn't exist). The default of 10 seconds should not be changed!
+
If enabled, the received file will contain the destination SFID attached with a dot ("<code>.</code>") in front of the SFID to the filename. This influences both the temporary and absolute filename after transfer.
  
==== append timestamp to received file ====
+
==== Append PID of receive process to received file ====
''DB configuration name: rec_append_timestamp_to_filename''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonAppendPIDRec
 +
|}
  
Some partners may send you files with the same virtual  filename, but different timestamps. In order to receive these files properly, an appendix is added to the filename containing the announced timestamp of the file. This also helps to receive the same file from different partners at the same time.  
+
If enabled, the received file will contain the process ID (so-called "PID") attached with a dot ("<code>.</code>") in front of the PID to the filename. This influences both the temporary and absolute filename after transfer.
Beware: the timestamp syntax has changed from OFTP 1 to OFTP 2!
 
  
 
==== OFTPv1: Don't wait for EERP message ====
 
==== OFTPv1: Don't wait for EERP message ====
''DB configuration name: oftpv1_dont_wait_for_eerp''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftpv1_dont_wait_for_eerp
 +
|}
  
 
The normal behaviour of a send queue item is as follows:  
 
The normal behaviour of a send queue item is as follows:  
Line 417: Line 945:
 
*successfully sent: partner acknowleged file (entry may be deleted if configured)  
 
*successfully sent: partner acknowleged file (entry may be deleted if configured)  
 
If an partner doesn't send an EERP message, the send queue entry will exist forever. In order to avoid this, the send queue entry may get the status „successfully sent“ after successful send by enabling this checkbox (and may be deleted if the above checkbox „delete send queue entries“ is enabled). Beware: the xERP scripts won't be executed any more because no send queue entry will be found matching the parameters given in any EERP or NERP message. '''This feature just affects OFTP v1 partners, not OFTP 2!'''  
 
If an partner doesn't send an EERP message, the send queue entry will exist forever. In order to avoid this, the send queue entry may get the status „successfully sent“ after successful send by enabling this checkbox (and may be deleted if the above checkbox „delete send queue entries“ is enabled). Beware: the xERP scripts won't be executed any more because no send queue entry will be found matching the parameters given in any EERP or NERP message. '''This feature just affects OFTP v1 partners, not OFTP 2!'''  
 +
 +
==== Enable automatic update mechanism? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || run_updates_automatically
 +
|}
 +
 +
Activating this feature enables the usage of automatic software and lowers the administrative tasks to keep the software up-to-date.
 +
 +
==== Send queue daemon partner organizing mechanism ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || sqd_partner_organizing
 +
|}
 +
 +
If you want to configure a massive parallel installation to be handled by the send queue daemon without shared memory segments for information handling which partner has how many lines online, you may want to switch this configuration value to "database values". The default of "shared memory segments" works perfectly for single instances of OS4X and should be set only this way. '''CAVEAT: when using database values only for parallel channel information on send queue partners, there exists a timeframe when the information is invalid (this is when the send queue daemon forks a new process up to the database update command execution). During this little amount of time, more parallel processes may exist than configured for this partner.'''
 +
 +
===== take ALL server IDs into account =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || sqd_db_partner_organizing_all
 +
|}
 +
 +
If the above configuration of "Send queue daemon partner organizing mechanism" is set to "database values", then only this server ID could be inspected or ALL used servers can be inspected for parallel channels. '''Enabling this checkbox is the recommended value for this configuration!'''
 +
 +
===== also take receive queue into account =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || sqd_partner_organizing_use_recq
 +
|}
 +
 +
If the above configuration of "Send queue daemon partner organizing mechanism" is set to "database values", it's possible to active the check of the send queue for active partner connections. This amount of active connections will be added to the calculation of active connections for opening new connections during send queue daemon handling.
 +
 +
==== Should OS4X send queue daemon unblock all blocked entries on startup? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xsqd_unblock_on_start
 +
|}
 +
 +
The default behaviour of OS4X send queue daemon on startup: if enabled, the daemon unblocks all blocked send queue entry for the configured server ID. The behaviour up to 2007-11-24 was like enabling this feature.
 +
 +
==== Identify remote partner via incoming medium, too? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || partner_search_medium
 +
|}
 +
 +
When enabled, the OS4X receive daemon checks for the given medium the partner connects to the server and identifies the partner with this information in addition to the given SSID and password. This feature is very handy when several partner entries with the same SSID and password exist for different reasons.
 +
 +
==== Don't send EERP messages immediately in OFTP 1.x sessions? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || no_instant_eerp
 +
|}
 +
 +
When enabled, OS4X doesn't send instantly EERP (end-to-end-response) messages to the remote partner containing the default parameters. If enabled, you have to create the EERP message manually (or programatically) in order to be sent correctly to the partner.
 +
 +
==== Receive all files if partner is authentificated?====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || receive_catch_all
 +
|}
 +
 +
In order to receive '''ALL''' files of a authenticated partner (via SSID and password), without any check of locally defined originator and/or destination SFID, please active this checkbox. All files are being received without any error, even if no partner has been configured for this configuration of SFIDs. You should design your post-processing of the received file via the "[[OS4X_Core_event_scripts#end_receive_script|end receive script]]" on your own.
 +
 +
==== Cleanup queues on daemon startup? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || cleanup_queues
 +
|}
 +
 +
If enabled, a successful start of a send or receive queue daemons cleans up the respective queue with the following rules:
 +
*server ID matches the started daemon
 +
*send queue daemon "<code>os4xsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
 +
*receive queue daemon "<code>os4xrd</code>": Remove all files with the same server ID
 +
 +
Because it's a quite destructive option, the default is ''off''.
 +
 +
==== Should invalid restart positions deactivate restart of file? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || dont_restart_invalid_offset
 +
|}
 +
 +
If enabled, all files given with a restart position bigger than proposed file size won't restart file transfer and begin at the start of the file (i.e. if file size is 44123kB, but restart position is available at 49876kB, because the physical file is 51832kB big; received file size is bigger that the proposed 44123kB because the file '''is''' bigger).
 +
 +
''Note:'' Volvo needs this flag to be turned on in special conditions.
 +
 +
==== Activate OFTP2 secure authentification directly after certificate delivery? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || activate_ssidauth_after_delivery
 +
|}
 +
 +
If enabled, the partner switch "use OFTP2 secure authentification" will be enabled right after an automatic import of a certificate delivery.
 +
Please note that this may influence the behaviour of new connections: they may be aborted if the configuration flag [[OS4X_Core_configuration#allow_unsecure_OFTP_2_authentification|allow unsecure OFTP 2 authentification]] is disabled and this partner wants to connect the next time and doesn't have the same settings activated.
 +
 +
==== Enable per-partner virtual file naming recognition? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || per_partner_sfiddsn
 +
|}
 +
 +
If enabled, an incoming file will be checked against a list of configured partner entries with the configured SFID (originator and destination) and in addition to this normal behaviour, against a list of configured virtual filenames (so-called "DSN", "Virtual File '''D'''ata'''s'''et '''N'''ame" or "SFIDDSN"). These allowed virtual filenames are configurable at a per-partner basis, so they are an additional switch which partner entry is handling this special filename.
 +
 +
If multiple partner entries match, first one will be used.
 +
 +
==== Fetch EERPs? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonFetchEerp
 +
|}
 +
 +
If enabled, OS4X's send queue daemon will contact the remote partner for every file which is in the send queue status "waiting for remote acknowledge". In the newly created session, the partner has the chance to send the EERP or NERP message for any file.
 +
The maximum amount of configured sessions for a partner is being used (if available and configured properly in the "partner table" configuration). No more than the maximum of this amount of sessions will be opened, summarized for poll queue, send queue files and EERP fetching entries.
 +
 +
==== Fetch EERPs every x timeslice ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonFetchEerpTimeslice
 +
|}
 +
 +
If EERP fetching is enabled, this factor is being used to increase the time between two connect tries of the OS4X send queue daemon when trying to fetch one or more EERP messages of a partner.
 +
 +
==== Disable unsuccessful fetch logs? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonFetchDisableUnsucessfulLogs
 +
|}
 +
 +
Since 2021-03-10, OS4X can disable fetch log in loglevel "warning" for unsuccessful fetch tries (which may fill up your send logs quite fast).
 +
 +
==== Don't deactivate dir.scanner entries on error? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDirscannerDontDeactivate
 +
|}
 +
 +
If enabled, the send queue daemon will not deactivate diresctory scanner entries if an error occurs with the according enttry (i.e directory not available, permission errors etc.). By default, this configuration option is disabled and the daemon will deactivate such entries, logging this in the system logs.
 +
 +
==== Don't add logs with 'host is down' message? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || cconfigDaemonDirscannerDontLogHostdown
 +
|}
 +
 +
If enabled, directory scanner rules won't add logs when the source directory is offline due to an offline file server (resulting in a log message "host is down").
 +
 +
==== Allow underscore character ("<code>_</code>") in virtual filenames? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonAllowUnderscoresInVirtFilenames
 +
|}
 +
 +
Some OFTP and OFTP2 systems out in the wild support the underscore character in virtual filenames, which is unsupported by the RFC. In order to support this common mistake of standard interpretation, OS4X supports this non-standard character in addition to the well-defined characters, which are:
 +
<pre>
 +
The numerals:              0 to 9
 +
The upper case letters:    A to Z
 +
The following special set:  / - . & ( ) space
 +
</pre>
 +
 +
 +
==== Enable OFTP buffer compression? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp_compression_cap
 +
|}
 +
 +
In OFTP, file transmissions are divided in small buffers. These buffers may be compressed. Other than the OFTP2 compression, this compression mechanism is not that much optimized in its input data. In order to propagate the functionality in session initialization phase, enable this feature. If the remote party doesn't support this feature, it will be dynamically turned off within the OFTP handshake process.
 +
 +
==== Poll back identified partner on incoming TSL error? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || pollback_on_tsl_error
 +
|}
 +
 +
If a uniquely identified partner polls your server and a TLS error occurs (i.e. certificate chain unknown), this option initiates a poll to this partner. In many cases, this can bypass certificate problems on remote systems.
 +
 +
 +
==== Enable boost mode for parallel sessions? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || sqd_boost
 +
|}
 +
 +
If enabled, the send queue daemon forks as many send processes for a partner (up to the configured partner amount of parallel sessions) sequentially instead of waiting for the configured send queue daemon time slice. '''Be warned: a massive system load may occur (RAM, CPU load and parallel database connections)!'''
 +
 +
----
 +
 +
=== OS4X Enterprise ===
 +
The behaviour of OS4X Enterprise can be influenced in the following three topics:
 +
 +
[[Image:Config-Enterprise.png]]
 +
 +
==== OS4X Enterprise - Basic ====
 +
 +
===== is OS4X Enterprise installed? =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4x_enterprise
 +
|}
 +
 +
If you enable this checkbox, the web interface expands its funtionality needed to administrate OS4X Enterprise, an enhanced version of OS4X. Disabling this checkbox
 +
turns OS4X into its default configuration of OS4X Core. If you are interested in features of OS4X Enterprise, contact your software dealer or write an email to info@os4x.com .
 +
 +
===== default country =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || default_country_idx
 +
|}
 +
 +
When creating a new location entry in the OS4X partner database and using OS4X Enterprise, a country has to be selected for this location. For easy administration, a default country is configurable with with configuration. This configuration is only visible if OS4X Enterprise is installed (and the above checkbox is enabled).
 +
 +
===== default receive plugin group =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || default_rec_plugin_pkg
 +
|}
 +
 +
This pulldownmenu contains all defined plugin packages. You should select a plugin package which will be run after a job is completely received (i.e. after the receive file sorter has collected all needed files). This configuration is only visible if OS4X Enterprise is installed (and the above checkbox is
 +
enabled).
 +
 +
===== default send plugin group =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || default_send_plugin_pkg
 +
|}
 +
 +
The configured default send plugin group is used to pre-configure a plugin group which is used for newly added partners. This plugin group will be configured at company level (the highest hierarchy level) for the new partner.
 +
 +
===== enable multi-protocol support? =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4x_enterprise_other_protocols
 +
|}
 +
 +
In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the OS4X send queue for outgoing files), you may define and use other protocols for data transfer to partners. Enable this checkbox to get more options on then. See [[OS4X Enterprise - other protocols]] for more details about administration.
 +
 +
===== define own company =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4x_enterprise_own_company
 +
|}
 +
 +
For a finer grained target address code search, you can define your own company here. If "no selection - enable multi-client-support" is selected, all address codes of all companies will be used for recipient search.
 +
 +
===== Default recipient for incoming jobs =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_default_rec
 +
|}
 +
 +
By default, no recipient is configured for inomcings jobs in initial state. By defining a default recipient here, this person will be defined as the initial recipient, leading to an execution of the configured plugin group of this recipient if no other plugin changes this recipient successfully.
 +
 +
===== Path for jobs of directory scanner =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_dirscanner_jobdir
 +
|}
 +
 +
This name defines the path (relative to the [[OS4X_Core_configuration#data_outgoing_directory|outgoing directory]]) wherein the directory scanner will create jobs. The job number will be appended to this given directory name. Relative path information can be used, too (using "../" definitions).
 +
 +
Examples (with a default [[OS4X_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/os4x/outgoing</code>"):
 +
*definition: <code>os4x-dirscanner-enterprise-job-</code>
 +
*resulting path (for job 123): <code>/opt/os4x/outgoing/os4x-dirscanner-enterprise-job-123/</code>
 +
 +
===== Enable auto-addresscode functionality =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_auto_adrcode
 +
|}
 +
 +
When enabled, editing a recipient adds the ability to create a new unique address code, based on values of other persons in that company. The algorithm tries to identify a numeric element of the existing address code and increments it until an unused value is available. This functionality may fail for address codes without a numeric element.
 +
 +
===== Enable addresscode uniqueness checks =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_unique_adrcode
 +
|}
 +
 +
When enabled, the administrative web interface warns an administrator if the configured address code is used by another person in the same company. This is done by marking the input field as invalid, adding a hover mask for a textual information that this address code is used already.
 +
 +
===== Disable automatic addresscode conversion =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configGuiAddresscodeDontConvert
 +
|}
 +
 +
When enabled, the administrative web interface doesn't convert the addresscode into upper case, so it's usable for other purposes than ENGDAT routing.
 +
 +
===== Shall errornous sendings abort jobs =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEnterpriseAbortJobRejectedFiles
 +
|}
 +
 +
When enabled, the "end send" event of OS4X Core will abort jobs if sending is errornous.
 +
 +
===== Serialize incoming jobs =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEnterpriseSerializeIncomingJobs
 +
|}
 +
 +
OS4X Enterprise receive jobs will be collected in a database table and executed plugin after plugin, job after job in a serialized way (not in parallel) in order to save server resources.
 +
 +
===== Enable big job support =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterpriseEnableBigJobs
 +
|}
 +
 +
Enabling this feature migrates the database table for job XML information from a medium text to a long text format, offering more space to be saved (but consuming much more space).
 +
 +
===== Job abort event =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_job_abort_script
 +
|}
 +
 +
If an OS4X Enterprise job aborts, [[OS4X_Core_event_scripts#OS4X_Enterprise_job_abort_script|this event]] will be executed.
 +
 +
===== Send job abort plugin group =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || send_job_abort_plugin_pkg
 +
|}
 +
 +
If an OS4X Enterprise send job aborts, this configurable plugin group can be executed.
 +
 +
===== Receive job abort plugin group =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || rec_job_abort_plugin_pkg
 +
|}
 +
 +
If an OS4X Enterprise receive job aborts, this configurable plugin group can be executed.
 +
 +
===== Absolute AJAX URL for job restore processes =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_archive_restore_url
 +
|}
 +
 +
For archived jobs, this URL will be called via JSONP in order to restore the job.
 +
 +
===== Name of parameter for restore AJAX call =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_archive_restore_parametername
 +
|}
 +
 +
When restoring OS4X Enterprise jobs via the above configured URL, this is the name of the parameter containing the archive ID.
 +
 +
===== Event to be executed for sent non-Enterprise files =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || non_enterprise_send_event
 +
|}
 +
 +
If you use OS4X Core and OS4X Enterprise events in parallel, this event will be fired if a "end_send" will be executed for non-Enterprise enqueued files.
 +
 +
===== Name of JSONP callback parameter =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enterprise_archive_restore_callbackname
 +
|}
 +
Due to JSONP, this is the name of the required callback function parameter. The default value (if empty) is "<code>callback</code>".
 +
 +
===== VW REST API file upload - cXML data transfer =====
 +
This topic is covered in a special article [[OS4X Enterprise VW EDI cXML upload feature]].
 +
 +
==== OS4X Enterprise - Webaccess ====
 +
 +
===== Webaccess URL =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_url
 +
|}
 +
The URL to OS4X webaccess (without trailing slash), typically used within templates.
 +
 +
===== Webaccess login logo URL =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_login_logo
 +
|}
 +
An alternative logo URL (absolute or relative is supported) for displaying in the login prompt of OS4X Webaccess.
 +
 +
===== Webaccess logged in logo URL =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_loggedin_logo
 +
|}
 +
 +
When defined, a customized logo can be added to the logged-in view of OS4X Webaccess in the top right corner. Absolute or relative URLs are supported.
 +
 +
===== Disable password reset functionality =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_disable_pwdreset
 +
|}
 +
 +
If you want to disable the [[OS4X_Webaccess_installation_and_configuration#Password_reset_functionality|user password reset functionality]], please enable this checkbox.
 +
 +
===== Password reset mail template =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEnterpriseWebaccessPwdResetTemplate
 +
|}
 +
 +
The HTML mail template used for password reset link.
 +
 +
===== Don't show receive queue view =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_disable_recq
 +
|}
 +
If you don't want the receive queue to be displayed to end-users in OS4X Webaccess, enable this checkbox. The receive queue view doesn't contain any administrative operations.
 +
 +
===== Don't show send queue view =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_disable_sendq
 +
|}
 +
If you don't want the send queue to be displayed to end-users in OS4X Webaccess, enable this checkbox. The send queue view doesn't contain any administrative operations.
 +
 +
===== Show incoming jobs without recipient =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_show_invalid_rec_jobs
 +
|}
 +
When enabled, this feature adds jobs without a valid recipient to the list of incoming jobs for all users.
 +
 +
===== Session timeout (min) =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_session_timeout
 +
|}
 +
You can set a session for timeout for OS4X Webaccess sessions here. Without any interaction, an old session expires automatically after that amount of minutes.
 +
 +
===== Highlight address code in ENGDAT filenames =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_highlight_addresscode
 +
|}
 +
If ENGDAT filenames are not interpreted into real filenames (as given i.e. in ENGDAT abstract files, these files are quite technical to read. In order to highlight the address code contained in the filename, enabling this configuration options offers to highlight this address code with the following methods:
 +
*bold (configuration variable "<code>webaccess_highlight_addresscode_bold</code>")
 +
*underlined (configuration variable "<code>webaccess_highlight_addresscode_underline</code>")
 +
*italic (configuration variable "<code>webaccess_highlight_addresscode_italic</code>")
 +
 +
===== Show all incoming jobs of department =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_show_dep_jobs_incoming
 +
|}
 +
OS4X Webaccess normally shows only jobs of the corresponding user who is logged in. In order to show all incoming jobs of the department the user is contained, enable this checkbox.
 +
 +
===== Show all outgoing jobs of department =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_show_dep_jobs_outgoing
 +
|}
 +
OS4X Webaccess normally shows only jobs of the corresponding user who is logged in. In order to show all outgoing jobs of the department the user is contained, enable this checkbox.
 +
 +
===== Include given name in search =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_search_given_name
 +
|}
 +
When searching for persons in OS4X Webaccess (in any situation), the given name (aka. the "first name") is not searched for by default. By enabling this configuration option, searching for the given name is being activated, too.
 +
 +
===== Don't show popup when adding recipient =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webaccess_ignore_recipient_add
 +
|}
 +
When adding a new recipient to a send job, a popup occurs when not enabled. If enabled, no popup will occur.
 +
 +
=== Allow users to receive files from the internet? ===
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configEnterpriseWebaccessEnableCloudJob
 +
|}
 +
If enabled, users can specify a remote URL which will be downloaded to the OS4X webserver and transfomed into a receive job. The download location is configurable via [[OS4X_Core_main_configuration_file#WEBACCESS_UPLOAD_DIRECTORY|WEBACCESS_UPLOAD_DIRECTORY in os4x.conf]], if not set the [[OS4X_Core_configuration#temporary_directory|OS4X temp. directory]] will be used. The OS4X [[OS4X_Core_configuration#Proxy|HTTP proxy settings]] are respected. Remote downloads create receive log entries with the Medium set to 'HTTP' containing success state, throughput and the effective URL that has been downloaded.
 +
 +
==== OS4X Enterprise - Plugins ====
 +
The default behaviour of all plugins can be changed here. The behaviour can be overridden by a configured, set up at each level of partner hierarchy.
 +
 +
----
 +
 +
=== OFTP2 ===
 +
OFTP2 relevant options are configurable here:
 +
 +
[[Image:Config-OFTP2.png]]
 +
 +
==== delete temporary created files of OFTP 2 session ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
 +
|}
 +
 +
If enabled (all other values than zero, '<code>0</code>') all files created for temporary usage in OFTP2 sessions and session preparations will not be deleted. This is useful for debugging the created files and meta-information.
 +
 +
==== Enable offline handling of OFTP2 transfered files? ====
 +
'''THIS FEATURE HAS BEEN REMOVED 2018-08-30!'''
 +
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || offline_oftp2_filehandling
 +
|}
 +
 +
If enabled (all other values than zero, '<code>0</code>') incoming OFTP2 files (which need to be handled by any security mechanism, such as signature checking, decompression and/or decryption, will be held in an offline queue, which will then be evaluated by the OS4X offline daemon.
 +
 +
===== pre-script for offline tool =====
 +
'''THIS FEATURE HAS BEEN REMOVED 2018-08-30!'''
 +
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || offline_oftp2_pre_script
 +
|}
 +
 +
If OFTP2 offline handling is enabled, you may enter here the absolute path to an executable which will be executed by the OS4X offline handler before the offline handler processes the file. This is normally a transferer script.
 +
 +
===== post-script for offline tool =====
 +
'''THIS FEATURE HAS BEEN REMOVED 2018-08-30!'''
 +
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || offline_oftp2_post_script
 +
|}
 +
 +
If OFTP2 offline handling is enabled, you may enter here the absolute path to an executable which will be executed by the OS4X offline handler after the offline handler has processed a file. This is normally a cleanup script.
 +
 +
===== remove successfully handled offline OFTP2 file entries =====
 +
'''THIS FEATURE HAS BEEN REMOVED 2018-08-30!'''
 +
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
 +
|}
 +
 +
If OFTP2 offline handling is enabled, successfully processed files will be removed from the offline queue (the database table only, not from the filesystem!) if this feature is activated.
 +
 +
==== Activate OFTP2 secure authentification directly after certificate delivery? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || activate_ssidauth_after_delivery
 +
|}
 +
 +
If enabled, OS4X activates secure authentification method for the given partner right after an automatic certificate exchange.
 +
 +
==== Don't send EERP messages immediately in OFTP2 sessions? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || no_instant_oftp2_eerp
 +
|}
 +
 +
After successful receipt of an OFTP2 file, you may suppress the automatic sending of an EERP by activating this feature. You should ensure to send an EERP via "[[OS4X_Core_binaries#os4xeq_.2F_os4xeq2|os4xeq]]" with all parameters given in the "[[OS4X_Core_event_scripts#end_receive_script|end receive script]]".
 +
 +
==== Send EERP in synchronous session? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configOftp2SyncEerp
 +
|}
 +
 +
In OFTP2, file handling (like decompression, signature verification and decryption) is being processed in an asynchronous, forked process (because this handling can take a very long time in terms of network connections; many minutes are not uncommon). If you have to deal with synchronous data transfers where an EERP '''MUST''' be transfered in the same OFTP2 session, you can enable this option. Beware of the (default: 1MB) size limit of received files for enabling this feature.
 +
 +
==== Maximum size of sync. EERP files (in kB) ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configOftp2SyncEerpMaxsize
 +
|}
 +
 +
If the above mentioned synchronous EERP handling for OFTP2 is enabled, you have to define a filesize limit of the transfered file. Files bigger that this limit are not handled by the synchronous EERP process.
 +
 +
==== Add log entry for synchronous EERP handling ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configOftp2SyncEerpLog
 +
|}
 +
 +
If synchronous file handling takes place, an optional log entry can be places in the receive log every time this process is activated. '''Warning:''' may increase your receive log massively!
 +
 +
==== Delete original OFTP2 handled files which have been enqueued by send queue daemon? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || deleteToBeEnqueuedTouchedFiles
 +
|}
 +
 +
If a file, which has been in status 10 ("''to be enqueued for OFTP2''"), may result in a temporary OFTP2 file if one of the options for OFTP2 file handling is enabled (compression, signing or encryption). If this is the case, the original file would stay in it's original state. When enabling this feature, OS4X deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
 +
----
 +
 +
==== OFTP2 security policy ====
 +
Starting with OS4X release 2016-08-16, you can define which security settings match your internal company security policy with easy-to-answer configurations. The following parameters help to configure these values in an easy way. These settings are only relevant for the reception of files, sending files with another settings is possible nevertheless with potentionally different partner settings.
 +
 +
The following configuration options can be defined to a behaviour explained below:
 +
*File encryption (dabase configuration name: "<code>oftp2_policy_encrypted</code>")
 +
*File compression (dabase configuration name: "<code>oftp2_policy_compressed</code>")
 +
*File signature (dabase configuration name: "<code>oftp2_policy_signed</code>")
 +
 +
The configuration options explained:
 +
*unconfigured: All files are accepted
 +
*Allow: All files are accepted, both with activated and deactivated security option.
 +
*Require: The security option '''MUST''' be activated for incoming files, otherwise the file will be rejected with an appropriate error message.
 +
*Reject: The security option '''MUST NOT''' be activated for incoming files, otherwise the file will be rejected with an appropriate error message.
 +
*Require partner value: Require partner value: The file must be sent by the remote party according to the settings which are activated or deactivated in your partner configuration. If the security option is not fulfilled, the file will be rejected with an appropriate error message.
 +
 +
If a security policy is not fulfilled, an offered file will be rejected. A log entry in the receive log will occur per file. The partner is given the information not to retry this sending process again.
 +
 +
===== Allow fallback to unsecure OFTP 2 authentification =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftpv2_allow_unsecure_auth
 +
|}
 +
 +
If enabled (all other values than zero, '<code>0</code>') it is possible to connect to OS4X with a disabled secure authentification mechanism, even if the identified partner (via SSID and password) has a secure authentification method activated. If this configuration is disabled (which is the default), OFTP2 sessions are directly closed with a secure session error message.
 +
 +
===== Preferred cipher suite =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp2_policy_preferred_cs
 +
|}
 +
 +
This configured cipher suite will be the preferred one for incoming files. With the option below, files using another cipher suite can be rejected. The list of cipher suites is dynamically obtained from the OFTP2 system. If the configuration value is "Use partner configured value", incoming files shall (or must, depending on the option below) be using the cipher suite which is defined at partner level.
 +
 +
===== Deny other cipher suites than the preferred =====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp2_policy_deny_unpreferred_cs
 +
|}
 +
 +
If a ciphersuite is configured in "Preferred cipher suite" and incoming files use another cipher suite, this option will reject the incoming file with an appropriate error message.
 +
 +
==== External IP address or hostname of this OFTP2 system ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftp2_external_hostname
 +
|}
 +
 +
This configuration option is used in new certificate signing requests as the common name ("CN") of this OFTP2 system.
 +
 +
==== Activate auto-cleanup of old certificates? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configOftp2AutoCleanup
 +
|}
 +
 +
Since certificates will expire, OS4X will warn you about this fact. If you want OS4X to clean up expired certificates automatically (so you don't have to do this manually), you can enable this checkbox.
 +
 +
==== Automatically enable disabled certificates? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configOftp2AutoEnableInactiveCert
 +
|}
 +
 +
If an old certificate has been archived by the mechanism above, disabled (say: not yet enabled) certificates can be enabled dynamically. This is also a mechanism for automatic handling during certificate renewal.
 +
 +
==== Disable certificate check at every CMS cipher usage? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || ciphersuite_extended_certificate_check
 +
|}
 +
 +
By default, all used certificates in CMS file handling (used in OFTP2 sec.auth., file signature, file encryption and signed EERPs) will verify the trust of the certificate by checking against all available and trusted CRLs. This uses much resources, which can be disabled. If this feature is disabled, revoked certificates will only identified in incoming and outgoing TLS sessions.
 +
 +
==== Serialize incoming files ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configOftp2SerializeIncomingFiles
 +
|}
 +
 +
If a received file via OFTP2 is handled by CMS (i.e. using file signature, file encryption and/or file compression) the file will be processed in a child process directly upon receipt of the file. If you receive a massive amount of files in a short period of time, parallel processes will take place, consuming ressources. Enabling this feature will save the information of the received file in a database table and process them after a [[OS4X_Core_configuration#time_slice_for_receive_daemon|time slice of the receive daemon]]. The received files will be handled one after another, saving system ressources. The file will be saved beforehand in the [[OS4X_Core_configuration#data_incoming_directory|incoming directory]] with a filename suffix "<code>.part</code>" (which is handy for ignoring these files in directory scanner rules).
 +
 +
=== Logging ===
 +
Logging enables OS4X to insert human readable messages into log tables. You may turn some features on or off to suite your needs.
 +
 +
[[Image:Config-logging.png]]
 +
 +
==== use syslog ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || use_syslog
 +
|}
 +
 +
If you turn on this checkbox, major errors will be logged to the server's syslog facility with the severity LOG_ERR. Major errors are table misconfigurations or process dependant messages (fork failures, memory allocation problems etc.).
 +
 +
==== enable log vault ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enable_log_vault
 +
|}
 +
 +
Enabling this feature activates code to move log entries from the direct access log tables to slower log vault tables, where all messages (older than a configurable amount of days) are kept. This enhances the access to the online logs.
 +
 +
==== maximum age for fast logs ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || logvault_days
 +
|}
 +
 +
After this amount of days, log entries will be moved from one log to the vault.
 +
 +
==== move send logs every x timeslices ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || logvault_sendq_timeslices
 +
|}
 +
 +
The entries older than the above configured value ('maximum age') of the send log will be moved to the slower vault every this amount of time slices of the send queue daemon. This configuration value cooperates with the configuration value 'time slice for send queue daemon'. Only logs belonging to that server ID will be moved to the vault!
 +
 +
==== move receive logs every x timeslices ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || logvault_recq_timeslices
 +
|}
 +
 +
The entries older than the above configured value ('maximum age') of the receive log will be moved to the slower vault every this amount of time slices of the receive queue daemon. This configuration value cooperates with the configuration value 'time slice for receive daemon'. Only logs belonging to that server ID will be moved to the vault!
 +
 +
==== archive received xERP messages & archive sent xERP messages ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || oftpv2_archive_received_xerp & oftpv2_archive_sent_xerp
 +
|}
 +
 +
It may be useful archive positive and/or negative end-to-end responses. These xERP messages can be seen as acknowledgements from the partner (received xERP) or from
 +
yourself (sent xERP). The web interface contains a archive viewer on the left hand: "xERP log". This feature may be needed in some countries for legal issues.
 +
 +
==== enable script logging ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enable_script_logging
 +
|}
 +
 +
Enabling this feature logs all script calls, parameters, returncodes and output to the script logs. In the web interface, you can take a look at the script logs with the link „Script log“. In this interface, you can also restart event scripts (even if they have changed in the configuration: you can then execute the original  or the new one, depending on executability of the script file).
 +
 +
==== Enable directory scanner logging? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || enable_dirscanner_logging
 +
|}
 +
 +
If enabled, the [[OS4X Directory Scanner|directory scanner]] logs every single execution script based on the found file.
  
 
==== Enable continuous write of OS4X debug daemon output? ====
 
==== Enable continuous write of OS4X debug daemon output? ====
''DB configuration name: os4xdebugd_contzinuous_write''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xdebugd_continuous_write
 +
|}
  
 
When enabling this feature, the OS4X debug daemon creates a debug log file (and starts the configured event script if existant) after the ring buffer is full. In this case, no message is lost.
 
When enabling this feature, the OS4X debug daemon creates a debug log file (and starts the configured event script if existant) after the ring buffer is full. In this case, no message is lost.
  
==== Enable automatic update mechanism? ====
+
If this feature is enabled, starting with OS4X release 2015-08-25 a button with the label "Collect today's logs" is available which lets you send all collected debug daemon dump files of this day and enqueue it to a specific partner for debugging. Requirements for this feature are:
''DB configuration name: run_updates_automatically''
+
*OS4X debug daemon is running
 +
*The temporary directory is accessible and writable by the OS4X debug daemon
 +
*The event "debug daemon log event" does not change the filename prefix "os4x-logfile-<YYYYmmdd>" (where "YYYY" is the current year with four digits, "mm" is the actual month starting at "01" with two digits and "dd" is the actual day, starting with "01" and two digits).
 +
 
 +
The partner to which the files are being enqueued is possible to be searched. By default, the partner "OS4X-Update" is searched. If the partner is not found, no partner search is pre-set and the whole partner list is being presented. If exactly this pre-set partner "OS4X-Update" is found, it it selected automatically, so you don't have to click on it to activate the selection. Only if a single partner is selected in the partner search list, the files are being enqueued to this partner after submission (either via "Save" button or via double click).
 +
 
 +
The virtual filenames of the logfiles is "OS4X-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>OS4X logs - automatically enqueued via administrative web interface</code>".
 +
 
 +
==== Absolute path to logfile of OS4X API ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xapi_logfile
 +
|}
 +
 
 +
The OS4X API, which is the background service for OS4X Webaccess and OS4X Proxy, logs into this file.
 +
 
 +
==== Absolute path to logfile of OS4X API (CLI) ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xapi_cli_logfile
 +
|}
  
Activating this feature enables the usage of automatic software and lowers the administrative tasks to keep the software up-to-date.
+
The OS4X API, which is the background service for OS4X Webaccess and OS4X Proxy, logs into this file if called in command line mode. Beware that the user who calls the OS4Xapi must be able to write to this file. If the file doesn't exist, it will be createad (as long as write permissions exist in the target directoy; the owner of the newly created file will be this user which may be important for future write with another user).
  
==== is OS4X Enterprise installed? ====
+
==== OS4X API loglevel ====
''DB configuration name: os4x_enterprise''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || os4xapi_loglevel
 +
|}
  
If you enable this checkbox, the web interface expands its funtionality needed to administrate OS4X Enterprise, an enhanced version of OS4X. Disabling this checkbox
+
The above configured file will be written in the configured log level.
turns OS4X into its default configuration of OS4X Core. If you are interested in features of OS4X Enterprise, contact your software dealer or write an email to info@os4x.com .
 
  
==== default receive plugin group ====
+
==== Suppress unsuccessful connect log entries? ====
''DB configuration name: default_rec_plugin_pkg''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || suppress_unsuccessful_connect_logs
 +
|}
  
This pulldownmenu contains all defined plugin packages. You should select a plugin package which will be run after a job is completely received (i.e. after the receive file sorter has collected all needed files). This configuration is only visible if OS4X Enterprise is installed (and the above checkbox is enabled).
+
If an incoming connection fails before OFTP handshake could be initiated, a logging entry is normally made in the style of:
 +
unsuccessful connect try from IP 'aaa.bbb.ccc.ddd'
 +
If you want to ignore these messages (i.e. when using a system monitoring which just watches if the TCP/IP port is open), enable this feature.
  
==== default country for partner entries ====
+
This configuration also suppresses AS2 logs where no valid partner, no valid filename and no valid message ID is presented in the HTTP(S) data stream.
''DB configuration name: default_country_idx''
 
  
When creating a new company entry in the OS4X partner database and using OS4X Enterprise, a country has to be selected for this partner. For easy administration, a default country is configurable with with configuration. This configuration is only visible if OS4X Enterprise is installed (and the above checkbox is enabled).
+
==== Log ADOdb messages (requires DEBUG level) ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || log_adodb
 +
|}
  
=== Partner table parameters ===
+
If enabled, the OS4Xapi will add massive logging content to the configured OS4Xapi log file (only available in DEBUG or TRACE mode).
The main advantage of OS4X is the configurable partner table definition. With this feature, you can set up OS4X to use your partner definition table (or if using MySQL 5: even views are supported). With this feature, OS4X is successfully connected to SWAN, for which also presets exist.
 
  
For easy administration, presets exist for the own OS4X internal partner table setup (where all features of OS4X are supported) and SWAN presets in the web interface.
+
==== Disable OS4X Heartbeat messages? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || disable_heartbeat_logs
 +
|}
  
==== partner table name ====
+
If [https://www.os4x.com/en/support/os4x-heartbeat/ OS4X Heartbeat] is ordered as a service, this configuration option disables these external availability checks from the receive logs.
''DB configuration name: partnerdb_tablename''
 
  
This alphanumeric field describes the table name of your partners. All SQL statements will be done using this table. (Note: the defined tableprefix doesn't affect this table name!)
+
==== Don't log Censys Scanner entities in system log? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDisableCensysLogs
 +
|}
  
==== active column ====
+
Censys Scanner seems to scan for vulnerable TLS services on the public internet, flooding the OS4X's system log with massive messages. This option removes such messages, containing the log text "census-scanner".
''DB configuration name: partnerdb_active''
 
  
If your partner table schema support enabled and/or disabled entries, this column defined the availability of a partner. If a non-zero is found in this column, a partner is seen as "''active''", otherwise (in case of zero) as "''inactive''". "''inactive''" partner entries are not taken into account for license purpose.
+
==== Directory scanner - Don't add logs with 'host is down' message? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDirscannerDontLogHostdown
 +
|}
  
If this column isn't configured, all entries are used as active entries.
+
If a directory scanner rule applies to a mounted directory where the server is unavailable, this option suppresses log messages containing "host is down" in the directory scanner logs.
  
==== partner index column ====
+
==== Directory scanner - Don't add logs with 'no such file or directory' message? ====
''DB configuration name: partnerdb_index''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDirscannerDontLogNoSuchFile
 +
|}
  
Each partner needs a numeric value (big integer as a maximum data type) for identifying the partner internally. This number will be re-used in all other tables refering to a partner entry.  
+
Sometimes a recognized file is instantly removed from a directory scanner observed directory. This also applies to directories which are unavailable (i.e. subdirectories of a mounted share). This option eliminates the log message "no such file or directory" in the directory scanner logs.
  
==== partner shortname column ====
+
==== Directory scanner - Don't add logs with 'permission denied' message? ====
''DB configuration name: partnerdb_shortname''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDirscannerDontLogPermission
 +
|}
  
A partner must have a so called shortname, which will be referenced by all binaries. Also, the shortname is used in logs and displaying the send and receive queue. The maximum length of the field is 255 characters.  
+
If a directory or file is inaccessible by the directory scanner by permission rules, this option suppresses log entries stating "permission denied" in the directory scanner logs. This option also enables OS4X to ignore messages "Software caused connection abort".
  
==== partner additional description column ====
+
==== Directory scanner - Don't add logs with 'device or resource busy? ====
''DB configuration name: partnerdb_longname''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configDaemonDirscannerDontLogDeviceResourceBusy
 +
|}
  
Additional field used only in the partner list web interface of OS4X. This settings has no effect to any daemon or program of OS4X, it's just for free information. If set and the column exists, the content of this column is printed in the partner list.
+
If a directory or file is inaccessible by the directory scanner, this option suppresses log entries stating "device or resource busy" in the directory scanner logs.
  
==== partner's SSID column, partner's SFID column & partner's password column ====
 
''DB configuration name: partnerdb_his_ssid, partnerdb_his_sfid & partnerdb_his_password''
 
  
In order to identify an incoming connection,  these columns will  be used for authentification. Also, the send queue is using these columns if no alternative values are given. The maximum length of SSID and SFID is 25 characters, the password has a size of 8 characters.
 
  
==== partner's TCP/IP address column (IP or hostname) & partner's ISDN number column ====
+
----
''DB configuration name: partnerdb_his_tcp_address''
 
  
These columns are used for defining the TCP/IP hostname or IP address (for TCP/IP or ENX connections) or ISDN number for that partner. The columns can be the same. This
+
=== GUI ===
(or these) column(s) are/is used also for identifying partners.  
+
The GUI offers some parameters which influence the default behaviour.
  
==== partner's TCP/IP port number column ====
+
[[Image:ConfigGui.png]]
''DB configuration name: partnerdb_his_tcp_port & partnerdb_his_tcp_default_port''
 
  
If a column exists which reflects the partner's TCP/IP port of the remote OFTP system, you can define it here. If it doesn't exist in your partner table, you can disable it by enabling the checkbox: the default value of 3305 will be used instead. If the row is defined and also the checkbox is active, the default value will be used.
+
==== Send signals to running processes ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || webgui_kill_processes
 +
|}
  
==== partner's TCP/IP TLS port number column ====
+
The PHP backend can send running processes a signal, i.e. for reloading their configuration (when clicking "Save") or cancelling transfer processes. If the webserver is not running on the same machine as the OS4X daemons do, or if the webserver user is not privileged to send signals to running OS4X processes (i.e. they are running in another user context), you should disable this checkbox, otherwise (which is the default) keep it activated for a seamless integration of GUI and backend.
''DB configuration name: partnerdb_his_tcp_port_tls & partnerdb_his_tcp_default_port_tls''
 
  
If a column exists which reflects the partner's TCP/IP TLS port of the remote OFTP system, you can define it here. If it doesn't exist in your partner table, you can disable it by enabling the checkbox: the default value of 6619 will be used instead. If the row is defined and also the checkbox is active, the default value will be used.
+
==== Disable PID check of daemons ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || disable_PID_checks
 +
|}
  
==== partner's ISDN number column ====
+
The OS4Xapi can check if daemons which should run with a given process ID really exist. If they don't exist, the OS4Xapi will cleanup running information (= their PIDs) in the database. This feature is available in Linux and MacOS, partially in AIX. If you get unwanted results, disable this feature.
''DB configuration name: partnerdb_his_isdn_number''
 
  
Configure the column containing the ISDN number of the partner here. This may also be the same column as the TCP/IP address, OS4X is clever enough to interpret this value on-the-fly.
+
==== Show partners with unknown medium ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || display_partners_with_unknown_medium
 +
|}
  
==== column defining connection type (ISDN, TCP/IP or TCP/IP TLS secured) ====
+
Since the configurable partner database schema is highly configurable, many partner entries may have an unknown transmission medium configured (valid values are configurable for unencrypted TCP/IP and encrypted TCP/IP aka. TLS). If this configuration option is enabled, all partners (even with unknown medium values) are displayed in the partner list.
''DB configuration name: partnerdb_his_addresstype''
 
  
In order to check if the remote system has a connection type of ISDN, TCP/IP (ENX) or TLS secured TCP/IP connection, you have to define a column which reflects this value. This is also important if the columns for TCP/IP address and ISDN number are the same.
+
==== Enable simple configuration ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || simple_config_gui
 +
|}
  
==== value for connection type in above defined colum defining ISDN connection, value for connection type in above defined colum defining TCP/IP connection & value for connection type in above defined column defining TLS over TCP/IP connection ====
+
In many installations, most complex situation are not needed for this installation. As a minimizer for unneeded configuration options, most uncommon configuration options are not visible when enabling this configuration option. Elements which are hidden when this config option is activated are:
''DB configuration name: partnerdb_his_connect_isdn_value, partnerdb_his_connect_tcp_value & partnerdb_his_connect_tcp_tls_value''
+
*Configuration:
 +
**TCP/IP
 +
**Events
 +
**Daemon
 +
**OFTP2
 +
**Logging
 +
**Partner table
 +
*Programs:
 +
**Partner import
 +
*Cipher suites
  
The above configured column contains values defining which partner has a connection type of ISDN and which one uses TCP/IP or TLS secured TCP/IP. These numeric values
+
Partner management for OFTP2 is also more easy, so a more or less incomplex system will be shown in order to allow non-common users to administrate the system well.
define which value should be interpreted as an ISDN, TCP/IP or TCP/IP (TLS) connection type. The value must be unsigned integer, values 0-255.
 
  
==== my SSID column, my SFID colum & my password column ====
+
==== Min. age for expiration warning of certificates ====
''DB configuration name: partnerdb_my_ssid & partnerdb_my_default_ssid, partnerdb_my_sfid & partnerdb_my_default_sfid, partnerdb_my_password & partnerdb_my_default_password''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || gui_cert_warning_days
 +
|}
  
In order to use different SSID, SFID and password for default authentification with a partner, you can define here columns which reflect your values. If your partner table doesn't support this type of columns, you can disable these ones with enabling the corresponding checkbox which will result in using the default values above.
+
The administrative web interface can show expiring certificate warnings and expired certificate errors in the tab "Welcome", section "Possible configuration problems". The configured amount of days are used for calculation which certificates to display.
The OS4X send queue daemon behaves the way that the alternative values in the send queue can overwrite these values (if set to a non NULL value).  
 
  
==== partner's X.25 number column ====
+
==== Theme for administrative GUI ====
''DB configuration name: partnerdb_his_x25_number''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || gui_theme
 +
|}
  
Mostly french partners use non-default X.25 address for ISDN connections. Therefor, a column must be defined which reflects the X.25 address used during connections with  these partners. If the value of the column is empty (NULL, an empty string or non-numeric), the value will not be used.  
+
The admin web interface supports the switch of the used theme for displaying information. You can switch the theme without saving dynamically. When saving this config, all subsequent calls to the web interface will switch to the configured theme.
  
==== TCP/IP receive/send acceleration column ====
+
==== Disable health check of database ====
''DB configuration name: partnerdb_tcpip_rec_accel_column & partnerdb_tcpip_rec_accel_use_defaults, partnerdb_tcpip_send_accel_column & partnerdb_tcpip_send_accel_use_defaults''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || gui_disable_db_healthcheck
 +
|}
  
This technique is used to accelerate TCP/IP transfers. If your partner doesn't like this type of acceleration (i.e. partners who use Seeburger products), you can define a column which reflects to use the acceleration or not. A value of zero („0“) means disabling the acceleration, non-zero means enabling this feature. If your partner table doesn't have such a feature column, you can disable it by using the default value. If the colum is defined and the checkbox for using default value is enabled, the default will be used.
+
Disabling the database health check will not include database table checks in the section "Possible configuration option" in the "Welcome" tab of the administrative web interface. By disabling these checks, you can lower your database overhead massively.
  
Acceleration is incompatible with the following partner software solutions:
+
==== Filtered filesystems from "Welcome" tab ====
*Seeburger WinElke
+
The administrative web interface shows the filling state of all mounted filesystems, except the filesystems contained in the list of excluded filesystems. A filesystem can be exluded from the displayed list by clicking on the entry bar on the "Welcome" page, then answering "Yes" to the delete question. The deleted file system(s) are listed here in a grid, where they can be removed so the removed entry will be displayed again on the welcome page.
*Bartsch Software
 
  
==== amount of parallel sendings ====
+
==== User own defined URLs ====
''DB configuration name: partnerdb_parallel_sendings_column & partnerdb_parallel_sendings_use_defaults''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || use_own_defined_urls
 +
|}
  
The default amount of parallel sending processes can be defined per each partner seperately, if you define a table column here. The numerical value (integer) is used to  open that many parallel connections. If not such a column is present, you can use the default value defined above (in the „daemon parameters“ section) by enabling the "use default" checkbox.
+
If enabled, the menu on the left side in the administrative web interface will add an entry with a configured name (see below).
 
==== partner's OFTP version column ====
 
''DB configuration name: partnerdb_used_oftp_version''
 
  
This numeric column (float) must have the value „1“ for OFTPv1 partners of "2" for OFTP 2 partners. If no value is in the column, OFTPv1.4 will be used.
+
==== Name of entry ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || own_defined_urls_menuentry_name
 +
|}
  
OS4X interprets the following values of version encodings:
+
The name of the menu entry which contains user-defined URLs is changeable.
*'<code>1</code>' -> OFTP 1.4, OFTP release coded value: <code>4</code>
 
*'<code>1.0</code>' -> OFTP 1.0, OFTP release coded value: <code>1</code>
 
*'<code>1.1</code>' -> OFTP 1.1, OFTP release coded value: <code>1</code>
 
*'<code>1.2</code>' -> OFTP 1.2, OFTP release coded value: <code>1</code>
 
*'<code>1.3</code>' -> OFTP 1.3, OFTP release coded value: <code>2</code>
 
*'<code>1.4</code>' -> OFTP 1.4, OFTP release coded value: <code>4</code>
 
*'<code>2</code>' -> OFTP 2, OFTP release coded value: <code>5</code>
 
*'<code>2.0</code>' -> OFTP 2, OFTP release coded value: <code>5</code>
 
  
Any other value will fallback to OFTP 1.4, coded value: <code>4</code>
+
==== Own defined URLs ====
 +
If enabled, the administrative web interface adds the possibility to configure a list of URLs for viewing within the administrative web interface as a closeable tabbed entry. The included URL is being integrated via an IFRAME, so if the integrated page doesn't allow this functionality (i.e. thorugh a META tag), the content will stay empty. Keep in mind that many popular dynamic sites don't allow this type of integration. Have a look into your JavaScript console if any errors occur.
  
==== partner's OFTP 2 cipher suite column ====
+
=== AS2 ===
''DB configuration name: partnerdb_used_oftp2_ciphersuite''
+
The AS2 functionality is configurable per-partner and globally. The global parameters are configurable here.
  
The cipher suite used for outgoing files and connections is defined in this integer column. Valid values are 0-99.  
+
[[File:Bildschirmfoto 2020-09-30 um 11.00.09.png]]
  
==== partner's OFTP 2 compression column ====
+
==== TCP/IP port for HTTP communication listener ====
''DB configuration name: partnerdb_oftp2_compression''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2HttpPort
 +
|}
  
The compression algorithm for that partner for outgoing files is defined in this integer column. Valid values are zero („0“) or one („1“), but may vary on future implementations.  
+
This is the numeric port of the plain TCP/IP listener for incoming HTTP sessions.
  
==== partner's OFTP 2 signing column ====
+
==== TCP/IP port for HTTPS communication listener ====
''DB configuration name: partnerdb_oftp2_sign''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2HttpsPort
 +
|}
  
==== partner's OFTP 2 encryption column ====
+
This is the numeric port of the encrypted TLS listener for incoming HTTPS sessions.
''DB configuration name: partnerdb_oftp2_encrypt''
 
  
==== partner's OFTP 2 secure authentification column ====
+
==== Use OFTP2 certificate for HTTPS? ====
''DB configuration name: partnerdb_oftp2_sec_auth''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2UseOftp2Cert
 +
|}
  
==== partner's OFTP 2 signed EERP/NERP column ====
+
When enabling this checkbox, the OS4X OFTP2 certificate is being used as HTTPS TLS certificate (the most easy way to support HTTPS).
''DB configuration name: partnerdb_oftp2_req_sig_eerp''
 
  
These numeric columns describes if a feature will be used for outgoing files to that partner (non-zero value) or not (zero value).
+
==== HTTPS certificate ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2HttpsServerCert
 +
|}
  
=== GUI niceup parameters ===
+
If the OFTP2 certificate is not used for HTTPS, a separate HTTPS certificate file can be configured for encrypted HTTPS connections. The file must contain the public certificate (optionally included chain) and RSA/DSA unprotected private key.
In order to make the OS4X web interface more useful, some parameters can be defined to configure the web interface to your needs.
 
  
==== progressbar in send and rec queue will be displayed using the following media type ====
+
==== AS2 TLS ciphers ====
''DB configuration name: progressbar_flash''
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2TlsCiphers
 +
|}
  
You can select if you want to see the progress bar using plain HTML code (which needs a manual reload of the page to get the acual state) or a Flash based progress bar, which doesn't need a manual refresh of the page.
+
The list of TLS ciphers is configurable for the TLS handshake. An example on how to suppress Qualys ROCKET scan report is:
 +
*<code>DEFAULT@SECLEVEL=2</code>
  
==== relative path in web interface for success soundfile & relative path in web interface for abort soundfile ====
+
openSSL TLS cipher configurations are supported here with a maximum length of 255 characters (so it's best to use groups for in- and exclusion).
''DB configuration name: pgbar_sucess_soundfile & pgbar_abort_soundfile''
 
  
If the progress bar is configured as Flash, you can define a sound file (valid formats: MP3, OGG or WAV) which will be played after a successful or unsuccessful file transfer. The file position is relative to the web interface!
+
==== External URL ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2ExternalUrl
 +
|}
  
==== lines per page ====
+
The external URL is contained in outgoing messages, defining where to post the corresponding asynchronous MDN to.
''DB configuration name: lines_per_page''
 
  
In order to support different display resolutions, you can define how many lines of results will be displayed on one page. This affects the partner administration and all logs.
+
==== Overwrite existing incoming files ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2Overwrite
 +
|}
  
==== truncate strings ====
+
If any incoming file has the same name on the filesystem, this option enables OS4X AS2 to overwrite this file.
''DB configuration name: truncate_strings_length''
 
  
To make send and receive queue more readable, you can define how many characters of a file will be displayed in the columns.
+
==== Append Unix timestamp (incl. microsends) to received file? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2AppendTimestamp
 +
|}
  
==== gray out (dim) send queue entries ====
+
If a new file is received, the current timestamp incl. microseconds of the running operating system will be appended to the filename in order to make it unique.
''DB configuration name: dim_out_sendq''
 
  
If you enable this feature, send queue entries will become more and more gray the more send tries they have. Useful if you want to see which entries are old.
+
==== Ignore certificate purpose for signature checks? ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2IgnoreCertPurpose
 +
|}
  
==== show hashes in xERP list ====
+
If enabled, the purpose of the used certificate for a specific functionality is not checked and used anyway (even if the certificate usage forbids this).
''DB configuration name: show_hashes_in_web_interface''
 
  
OFTP 2 supports file hashes in xERP messages. If you don't want to download them from the list and view them manually, OS4X can display them in the xERP log directly as
+
==== Write temporary logs & Keep logs ... days ====
hexadecimal values.
+
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2Debug
 +
|}
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2KeepDays
 +
|}
  
==== show partners with unknown medium ====
+
If enabled, all incoming messages will be saved for a configurable time period into the database for later analysis. You can download a dump of that data via the button "Download logs".
''DB configuration name: display_partners_with_unknown_medium''
 
  
Escpecially useful for non-OS4X partner table configuration. You can disable the occurance of partners in the partners list with unknown media types.
+
==== Relative filename for undefined receive files ====
 +
{|style="background:white"
 +
|- style="background:lightgrey;"
 +
| '''DB configuration name:''' || configAs2EmptyRecFilename
 +
|}
  
==== progressbar refresh time ====
+
If (against the RFC) no filename is specified by the sender, OS4X AS2 can use this filename as a default value. Inform your opponent sending party to correctly define a transmission filename if this happens regularly.
''DB configuration name: progressbar_refresh_webinterface''
 
  
In order to lower database traffic, the time interval for progress information retrieval is configurable for the Flash progress bar plugin separately.
+
=== Send queue displayed columns ===
 +
The list of columns configure the default state of the columns when opening the send queue overview. The columns can be re-activated afterwards via the column header management.
  
 +
----
 
=== other interesting configurable values ===
 
=== other interesting configurable values ===
 
Some values are not configurable via web interface, but also have a useful meaning when running OS4X. These configuration value names are:
 
Some values are not configurable via web interface, but also have a useful meaning when running OS4X. These configuration value names are:
 
*<code>os4xclientd_port</code>: TCP/IP port of the program OS4X client daemon
 
*<code>os4xclientd_port</code>: TCP/IP port of the program OS4X client daemon
*<code>os4xrd_stop_req</code>: When set to non-zero value, the OS4X receive daemon will stop in the next iteration after the time slice. This feature can be used to stop the daemon when no permissions to kill the process are granted.
 
*<code>os4xsqd_stop_req</code>: When set to non-zero value, the OS4X send queue daemon will stop in the next iteration after the time slice. This feature can be used to stop the daemon when no permissions to kill the process are granted.
 
 
*<code>webinterface_path</code>: Absolute path of the web interface on the webserver. This is useful for upgrading processes in order to update the path correctly.
 
*<code>webinterface_path</code>: Absolute path of the web interface on the webserver. This is useful for upgrading processes in order to update the path correctly.

Latest revision as of 12:12, 13 November 2024

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
  • Odette
  • Directories
  • Events
  • Daemon
  • Partner table
  • GUI

Each block is accessible with a link in the head of the configuration panel.

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

OS4X is highly configurable. 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.

Config-tcpip.png

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. For configurations with problemous partners like old Seeburger products, please use 800 bytes as buffersize.

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. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

Outgoing IP address

DB configuration name: tcp_outgoing_ip

By default, OS4X lets the operating system guess the correct source IP address for outgoiing connections. With this optional value, you can specify which IP address will be used for outgoing connections (which is also overwritable by partner configuration).

Listener IP address

DB configuration name: tcp_incoming_ip

OS4X listens to all interfaces for plain TCP and TLS connections. With this configuration you can specify a single IP address which will be bound to the listener process.


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.

Config-ssl.png

TLS server certificate file & TLS server 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.

TLS client certificate file file & TLS 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.

These variables are (if set) available to processes started by OS4X via the environment variables "CA_FILE" and "CA_PATH" (see also OS4X Core environment variables).

Diffie-Hellman parameter files

DB configuration name: dh1024_file & dh2048_file

These files (1024bit and 2048bit) 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"!

TLS server: check client certificate validity

DB configuration name: tls_server_check_client_cert

When this option is activated, all incoming TLS connections will be checked for a client certificate and a validity path for them. In case of self-signed certificates from the client, you have to add them manually (by requesting them from the partners) to your trusted certificate pool.

In case of client sessions, OS4X will override a wrong purpose of the server certificate (such as "SSL Client: no").

Summarizing:

If you have this checkbox enabled (default):

  • OS4X's TLS server asks the remote side, if not already presented, during TLS handshake for a client certificate.
  • This TLS client certificate is checked against the list of trusted certificates in order to verify a valid certificate chain for the certificate.
  • If the certificate chain is trusted, all chain elements are checked against the actually installed certificate revocation lists ("CRLs").

If you have this checkbox disabled (not the default, not recommended):

  • None of the above checks is being executed.
  • Every TLS client can connect to your server without any further client certificate check.
  • Recommended only if:
    • You have a firewall which applies partner defined rules, so you are sure who is connecting to your TLS server
    • Have OFTP2 secure authentification enabled, in addition with the enabled "OFTP message checker" (in "Configuration" -> "Daemon") for protocol syntax validity verification (which lowers throughput and consumes higher server CPU).

Ignore TLS CRL unavailability?

DB configuration name: tls_ignore_crl_unavailable

If the above option "check client certificate validity" is activated, it is possible to deactivate the check of an existance of a CRL for all CA certificates which OS4X doesn't have a CRL downloaded yet. This solves the problems with the following log entries the system log:

TLS error: no X509 certificate given in TLS handshake by remote partner
openSSL error: TLS network session failed, certificate problem: application verification failure
You must download a CRL for the CA of the certificate with the subject '...'
certificate verify error 3: unable to get certificate CRL: depth=0, subject: ...

Archive CRLs?

DB configuration name: archive_crl

When activated, all overwritten CRLs will be archived before every update. When deleting CRLs, they will be archived, too.

Disable automatic CRL handling

DB configuration name: disable_auto_crl

Normally, the OS4X send queue daemon scans all partner certificates for a new CRL URL and add them to the CRL list when not included. By activating this checkbox, you can disable this default behaviour.

Disable automatic reactivation of CRLs

DB configuration name: crl_dont_automatic_reactivate

If automatic CRL handling is not deactivated, OS4X will enable all found disabled CRL entries found in certificates. If you don't want this behaviour, you can disable the reactivation by enabling this configuration option.

Ignore CRL download errors of Mendelson

DB configuration name: crl_ignore_downloaderrors_mendelson

Since the CRLs of Mendelson CA are unavailable many times, your system log will be spammed with error message about this situation. Enabling this flag will not post any error logs into OS4X's system log if the download of a Mendelson CA CRL fails.

Check CRL URLs every x timeslices

DB configuration name: autocrl_sendq_timeslices

The send queue daemon can process every configured amount of timeslices (configured in the daemon section here) all trusted certificates and their CRL distribution points. If any is not included in the revocation list yet, it will be added and handled. Cofiguration values above 512 and below 1 will be resetted to 10.

Maximum age of CRLs

DB configuration name: maximum_crl_age

CRLs carry a date within them which defined when they become invalid. OS4X takes care of such CRLs by downloading and updating the database values according to the new content. With this configuration parameter you make any CRL entry invalid (and therefore marked for automatic update) which has an older update date than these amount of days before. So, the locally downloaded version of the CRL becomes invalid and gets updated eventually even before the next CRL will be issued.

This feature is recommended by the OFTP2 working group.

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.

TSL URL

DB configuration name: TSL_URL

This URL defines the position of a list administrated by Odette which contains a list of authorized certificate authorities. If the signed XML could be verified successfully, all contained certificate authorities are added automatically to OS4X.

The default value is:

http://www.odette.org/TSL/TSL_OFTP2.XML

Disable security warnings?

DB configuration name: configTlsDisableSecurityWarnings

When enabled, OS4X will never complain about insecure TLS cipher usage in connection logs (despite OS4X SmartProxy logs, since the OS4X SmartProxy doesn't support this insecurity "feature").

TLS ciphers?

DB configuration name: oftp2_tls_ciphers

The list of supported TLS ciphers can be configured. See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for more details.

Enable only PFS ciphers?

DB configuration name: configTlsEnablePfs

When enabled, all incoming and outgoing TLS traffic will occure with a secure TLS cipher supporting a secure key exchange mechanism. A fallback to a less secure cipher is supported, but logged.

Allow insecure downgrade of TLS cipher?

DB configuration name: configTlsAlllowInsecure

In TLS, the most secure sessions are being tried to be initiated. This is done by providing a list of supported ciphers from server to client and vica versa in a prioritized list. If the list leads to a cipher which uses Diffie-Hellman for secure key exchange during session handshake, the used Diffie-Hellman key must be at least 1024bit wide. If this minimum size is not supported by the remote party, the outgoing session will be retried without offering Diffie-Hellman ciphers. A warning will be locked.

Due to the Logjam attack in 2015, this behaviour is not recommeded and is strictly out of our support. Use this feature at your own risk!

Allow partial check of certificate chain?

DB configuration name: configTlsAllowPartialChain

In case of ca CA certificate in the chain without the required flag "CA:true", OS4X by default closes the TLS session. When enabling this option, the "CA" flag is not required to be present for the end of the certificate chain.


Proxy

OS4X offers for all HTTP and HTTPS transfer tasks proxy support. In order to use a defined proxy, several options are available. More details can be found here

Config-proxy.png

Use HTTP proxy?

DB configuration name: proxy_enabled

If you want to use a proxy, enable this checkbox. If the checkbox is disabled, all proxy relevant environment variables (see OS4X HTTP Proxy support) are cleared in all proxy using tools and binaries (and thus the forked processes by these binaries also don't have proxy environment variables defined).

Use user settings/environment variables?

DB configuration name: proxy_use_env

If your used running OS4X already has environmental variables defined for proper proxy support, you should enable this checkbox. Otherwise (if disabled), you have to configure the proxy in the parameter fields below.

Proxy hostname or IP

DB configuration name: proxy_host

The resolvable hostname or IP address of the proxy server.

Proxy port number

DB configuration name: proxy_port

The port number the proxy server is listening on. Only numbers are allowed here, from range 1-65535. Any other values will lead to misfunctions. Often used values are "8080" or "3128".

Proxy username

DB configuration name: proxy_username

If your proxy requires user authentification, enter a username here.

Proxy password

DB configuration name: proxy_password

If your proxy requires user authentification, enter the valid password for the above defined user.

Proxy type

DB configuration name: proxy_type

Different proxy types are supported, you should know which one fits your environment. Possible values are:

  • SOCKS4
  • SOCKS5
  • HTTP

Use OS4X proxy?

DB configuration name: os4x_proxy_enabled

If you want to use OS4X proxy or OS4X OFTP2 SmartProxy, enable this checkbox. Please refer to OS4X Proxy and OS4X OFTP2 SmartProxy for more detailled information.


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.

Config-odette.png

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.

Config-directories.png

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

This directory will be used by OS4X Webaccess (which is part of OS4X Enterprise) for outgoing jobs when initiating a send job. The plugins os4xplugin_filemove and os4xplugin_filecopy can refer to this directory by a configuration value.

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.

temporary directory (for software updates)

DB configuration name: configDirTmpUpdates

Since OS4X Release 2016-01-22, this optionally configurable directory defines where the software updater extracts its content to. This solves issues when writing temporary files during software update to a network attached share as configured in "temporary directory" above.

database backup directory

DB configuration name: backup_directory

If you want to use the OS4X backup mechanism, 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: tcp_timeout

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. The used openSSL binary must be of version 0.9.9dev, 1.0.0 or higher to fulfill the functionality for OFTP2.

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.

Append datestamp to SQL lost messages file?

DB configuration name: sql_lost_messages_file_append_timestamp

If enabled, in case of database inaccessibility, all SQL statements which could not be executed will be logged in the above configured "SQL lost message file", which gets a datestamp appendix to the filename. This datestamp consists of the following:

  • a single dot (".")
  • year with 4 digits (like "2009")
  • month with 2 digits (like "03")
  • day with 2 digits (like "27")

Example with a lost message fole configured to "/opt/os4x/tmp/sql_lost_messages":

/opt/os4x/tmp/sql_lost_messages.20090307
/opt/os4x/tmp/sql_lost_messages.20090130

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.

Absolute path to send test file

DB configuration name: send_test_file

If configured, a test file can be defined for enqueueing via the partner list or via "Send queue" -> "Add" to simply test the connection functionality. This configured absolute file name will be transmitted.

Send as virtual filename

DB configuration name: send_test_vfn

This is the virtual filename which will be used for enqueueing the above configured send test file.

Events

Config-events.png

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.

Presets exist (which are dynamically calculated with the last saved values for the scripts and binary directory configured here). These presets could be used for easy resetting the script configuration to either OS4X Enterprise (Lite) and/or OS4X 2 Core.

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.

Enable automatic update mechanism & OS4X automatic software update event

DB configuration name: run_updates_automatically & os4xupdate_script

If the value of run_updates_automatically is non-zero (if the checkbox is enabled), the automatic update script is started with the received file with the reserved virtual filename "OS4X_UPDATE". This is normally a program of the OS4X distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: run OS4X update program as user).

OS4X automatic update post event

DB configuration name: configEventUpdatePost

After a software update has been executed via the program "os4xupdate", the configurable post event can be started, i.e. for cleanup reasons or informing system management hierachies.

enqueue post-event

DB configuration name: enqueue_post_script

This script which will be executed after a successful enqueueing process.

OS4X API proxy system log event script

DB configuration name: os4xapi_proxy_systemlog_script

This script which will be executed after a critical situation of the OS4X Proxy will be logged in the OS4X system log.

Event failure event

DB configuration name: event_failure_script

In case of an error during event execution, this event can be executed.

System log event & only non-OK entries fire

DB configuration name: configEventSystemLogEvent
DB configuration name: configEventSystemLogEventOnlyNonOk

When an entry to the system log is added, this event can be executed (selective for only non-OK entries).

Enable 3DEXPERIENCE integration

DB configuration name: enable3Dexperience

Requirement: OS4X Enterprise. If this option is enabled, sent files via 3DEXPERIENCE will be handled natively by the 3DEXPERIENCE integration. If enabled, this option disables the next configurable event "Event to be executed for sent non-Enterprise files".

Event to be executed for sent non-Enterprise files

DB configuration name: non_enterprise_send_event

For all files which are sent via non-OS4X Enterprise mechanisms, this event will execute a special end-send event handler.

OS4X Enterprise user created event

DB configuration name: enterprise_user_created_event

When an OS4X Enterprise user is created this event can handle its parameters.


Daemon parameters

The behaviour of all binaries and OS4X programs can be influenced here.

Config-daemon.png

run OS4X programs as user

DB configuration name: running_as_user

When starting as user "root", all OS4X binaries will try to switch to this configured user, if available on the running system. Subsequent calls of scripts and other programs are also done in the context of this user. This is extremely useful for runlevel scripts.

Double-check that this user exists in the system running OS4X, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!

run OS4X update program as user

DB configuration name: running_update_as_user

If enabled below, automatic software update are being run using this specific username. If changing to the context of this given user fails, the whole update procedure fails. If no username is configured, superuser "root" is used.

time slice for send queue daemon

DB configuration name: os4xsqd_sleep_time

The send queue daemon „os4xsqd“ waits this amount of seconds before looking at the send queue table and react as needed (send one more entry, wait more time etc.).

time slice for receive daemon

DB configuration name: os4xrd_sleep_time

The receiving daemon „os4xrd2“ waits this amount of seconds before looking at the configuration table and react as needed (wait more time or stop itself).

delete send queue entries

DB configuration name: delete_after_transfer

This checkbox defines if the send queue table entries should be deleted (not the files itself, only the entry!) after a successful send. (If you need to delete the file itself, you should use the end send script, which gets the absolute filename as a parameter).

If this option is enabled, it automatically disabled the following option "Cleanup of sent send queue entries".

Cleanup of sent send queue entries

DB configuration name: configSendqueueCleanup

If enabled, the send queue daemon cleans up the send queue for all entries with a given age automatically (based on the timestamp of "last change"). Optionally, an event "Send queue cleanup event" will be executed.

Age of send queue entries for cleanup (days)
DB configuration name: configSendqueueCleanupDays

Send queue entries in status "successfully sent" with the last change date older than this amount of days will be taken into account for automatic cleanup.

Delete file, if available
DB configuration name: configSendqueueCleanupDeleteFile

If this option is enabled, the automatic cleanup mechanism will delete the referenced file on the filesystem. If file deletion will take place, a log message will look like:

Deleted send queue entry '<virt. filename>' and file '<abs. filename>'

If this option is disabled or the referenced file doesn't exist, the log message says:

Deleted send queue entry '<virt. filename>'

let all files of send queue be fetchable

DB configuration name: fetch_all_from_remote

Since polling is supported from remote systems, you can define files to be pollable. If you enable this checkbox, all files in your send queue which are in state of "new in queue" and "ready for remote fetch" will be sent in an OFTP session to the partner (otherwise, only entries "ready for remote fetch" are fetchable).

overwrite existing incoming files

DB configuration name: os4xrd_overwrite

If the incoming file exists in the "incoming directory", you can define to overwrite it. Otherwise, the partner will receive an error message saying that the local file already exists. (this might be useful for partners who don't like to reiceive an EEPR [end-to-end- response] message right after a successful filetransfer).

default maximum send tries for send queue daemon

DB configuration name: os4xsqd_max_tries

The send queue daemon "os4xsqd2" will try to send one or all entries this amount of times. After this amount of unsuccessful tries, one or all send queue entries for that partner will be blocked (which will also get logged into the send log). All entries for a partner get blocked, if a connection problem occurs (i.e. invalid SSID/SFID or password, no physical connection to partner or TCP/IP address etc.). One entry will be blocked if the partner doesn't accept this file. The other files are not affected by that error (i.e. wrong virtual filename, wrong alternative SFID of originator or destination).

additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon

DB configuration name: os4xsqd_add_time & os4xsqd_add_time_factor

You can influence the time the send queue daemon „os4xsqd2“ will sleep before it tries to send an send queue entry. The formula for calculating the additional sleep is as follows:

(add. waiting time) = (connect try)*(add. sleeping time)*(add. sleeping time factor) 

progress bar refresh time

DB configuration name: progressbar_refresh

OS4X will update all file transfer progress information after this value (in seconds). Because it is database driven, some MySQL server will crash if you have too many connects to a database in a very short time (which could occur if you transfer very little files with a combination of a small exchange buffer size). If you experience problems with your database server, try increasing this value.

allow unsecure OFTP 2 authentification

DB configuration name: oftpv2_allow_unsecure_auth

If an OFTP 2 partner is requested to use OFTP 2 authentification but he doesn't support this feature, you may allow to authentificate this partner with the OFTP 1 methods by enabling this checkbox. If you insist to use OFTP 2 authentification, disable the checkbox, so the partner will receive an error message that OFTP 2 secure authentification is needed.

delete temporary created files of OFTP 2 session

DB configuration name: oftpv2_delete_temp_created_files

OS4X creates temporary files by enqueueing files to the send queue or by directly sending a file to an OFTP 2 partner (if the partner is configured to use signing, compression and/or encryption). These temporary files can be deleted by OS4X automatically, but you may also want to keep them for later archiving.

local character set

DB configuration name: oftpv2_original_charset

OFTP 2 supports UTF-8 formatted information and error messages within the protocol and also extended virtual filenames (up to 999 bytes of UTF-8 formatted text). To translate the UTF-8 text into your local character set and to translate command line interaction from your local character set to UTF-8, you have to define your local character set here. If your local character set isn't listed here, you can define it in the database (table: "os4x_configuration") manually by entering the character set descriptor in the line where „name“ is "oftpv2_original_charset". All character sets which are supported by "iconv" are supported by OS4X. You get a list of supported character sets on the command line with the program:

iconv -l

if installed.

Unblock blocked send queue entries after successful connect?

DB configuration name: unblock_blocked_sendqueue_entries_after_poll

If enabled, this options lets the OS4X poll binary and receive daemon unblock blocked send queue entries after a incoming or outgoing connection to this partner has been successfully established.

Disable file restart functionality?

DB configuration name: configDaemonDisableFilerestart

If enabled, OS4X doesn't offer file restart functionality (which is offered by default if the communication partner supports it). In this case, the partner is told not to support file resuming, so aborted file transfers will restart in future sessions from the beginning of the file.

Disable automatic database cleanups / optimizations?

DB configuration name: configDaemonDisableMysqlOptimizeTables

OS4X cleans up database tables after a successful delete operation (in MySQL via "OPTIMIZE TABLE", in SQLite via "VACUUM" command). Enabling this configuration option disables the automatic cleanup of tables. Warning: could make your database grow in size if you don't clean up on your own!

enable OFTP message checker

DB configuration name: oftp_message_checker

To secure your server, an OFTP message checker examines each transfered package for validity. This suppresses protocol attacks from remote and helps to avoid NULL pointer exceptions and other well-known attacks.

send queue entry status after abort

DB configuration name: sendq_entry_status_after_abort

You can define the status of a send queue entry after manual abort here. It may be useful to avoid a race between an administrator and the send queue daemon if he aborts the file transfer but the send queue daemon grabs it afterwards because the time slice has taken account. Valid options are "new in queue", "successfully sent", "blocked" and "ready for remote fetch".

enable statistics & RRDtools refresh time

DB configuration name: enable_statistics & rrd_refresh

As configured above with the RRDtool paths and directories, you have the possibility to activate or deactivate the scripting functionality here. The statistics contain the average transfer speed of a partner (incoming and outgoing as separate databases). If any of the above configured RRDtool path or binary is unavailable, scripting is disabled, even if you enable it here. The refresh time is the time is seconds when statistical data is transfered into the Round Robin database. This time period depends also on the database configuration of the RRDB and is closely dependant from the creation process which is intergrated into OS4X (if an RRDB file doesn't exist). The default of 10 seconds should not be changed!

NEW: If statistics are enabled, a seperate logging table will be filled with information how many files have been transfered (in the ways "sent" and "received" with or without success. This amount of transfered filed is being displayed in the partner list and the partner "edit" details.

Append timestamp to received file

DB configuration name: rec_append_timestamp_to_filename

Some partners may send you files with the same virtual filename, but different timestamps. In order to receive these files properly, an appendix is added to the filename containing the announced timestamp of the file. This also helps to receive the same file from different partners at the same time. Beware: the timestamp syntax has changed from OFTP 1 to OFTP 2!

The appendix of the filename is as follows:

  • OFTP 1.0 - OFTP 1.3: "<datestamp><timestamp>0000", i.e. "200903171423590000"
  • OFTP 1.4 and OFTP2: "<datestamp><timestamp><counter>", i.e. "200903171423590523"

The main difference between both names is that the "counter" field in older OFTP sessions will be emulated via "0000".

Append destination SFID to received file

DB configuration name: configDaemonAppendSFIDRec

If enabled, the received file will contain the destination SFID attached with a dot (".") in front of the SFID to the filename. This influences both the temporary and absolute filename after transfer.

Append PID of receive process to received file

DB configuration name: configDaemonAppendPIDRec

If enabled, the received file will contain the process ID (so-called "PID") attached with a dot (".") in front of the PID to the filename. This influences both the temporary and absolute filename after transfer.

OFTPv1: Don't wait for EERP message

DB configuration name: oftpv1_dont_wait_for_eerp

The normal behaviour of a send queue item is as follows:

  • new in queue: waiting for transfer
  • taken by send queue: session active, waiting for transfer
  • send in progress: active transfer
  • waiting for remote acknowledge: waiting for EERP or NERP from partner
  • successfully sent: partner acknowleged file (entry may be deleted if configured)

If an partner doesn't send an EERP message, the send queue entry will exist forever. In order to avoid this, the send queue entry may get the status „successfully sent“ after successful send by enabling this checkbox (and may be deleted if the above checkbox „delete send queue entries“ is enabled). Beware: the xERP scripts won't be executed any more because no send queue entry will be found matching the parameters given in any EERP or NERP message. This feature just affects OFTP v1 partners, not OFTP 2!

Enable automatic update mechanism?

DB configuration name: run_updates_automatically

Activating this feature enables the usage of automatic software and lowers the administrative tasks to keep the software up-to-date.

Send queue daemon partner organizing mechanism

DB configuration name: sqd_partner_organizing

If you want to configure a massive parallel installation to be handled by the send queue daemon without shared memory segments for information handling which partner has how many lines online, you may want to switch this configuration value to "database values". The default of "shared memory segments" works perfectly for single instances of OS4X and should be set only this way. CAVEAT: when using database values only for parallel channel information on send queue partners, there exists a timeframe when the information is invalid (this is when the send queue daemon forks a new process up to the database update command execution). During this little amount of time, more parallel processes may exist than configured for this partner.

take ALL server IDs into account
DB configuration name: sqd_db_partner_organizing_all

If the above configuration of "Send queue daemon partner organizing mechanism" is set to "database values", then only this server ID could be inspected or ALL used servers can be inspected for parallel channels. Enabling this checkbox is the recommended value for this configuration!

also take receive queue into account
DB configuration name: sqd_partner_organizing_use_recq

If the above configuration of "Send queue daemon partner organizing mechanism" is set to "database values", it's possible to active the check of the send queue for active partner connections. This amount of active connections will be added to the calculation of active connections for opening new connections during send queue daemon handling.

Should OS4X send queue daemon unblock all blocked entries on startup?

DB configuration name: os4xsqd_unblock_on_start

The default behaviour of OS4X send queue daemon on startup: if enabled, the daemon unblocks all blocked send queue entry for the configured server ID. The behaviour up to 2007-11-24 was like enabling this feature.

Identify remote partner via incoming medium, too?

DB configuration name: partner_search_medium

When enabled, the OS4X receive daemon checks for the given medium the partner connects to the server and identifies the partner with this information in addition to the given SSID and password. This feature is very handy when several partner entries with the same SSID and password exist for different reasons.

Don't send EERP messages immediately in OFTP 1.x sessions?

DB configuration name: no_instant_eerp

When enabled, OS4X doesn't send instantly EERP (end-to-end-response) messages to the remote partner containing the default parameters. If enabled, you have to create the EERP message manually (or programatically) in order to be sent correctly to the partner.

Receive all files if partner is authentificated?

DB configuration name: receive_catch_all

In order to receive ALL files of a authenticated partner (via SSID and password), without any check of locally defined originator and/or destination SFID, please active this checkbox. All files are being received without any error, even if no partner has been configured for this configuration of SFIDs. You should design your post-processing of the received file via the "end receive script" on your own.

Cleanup queues on daemon startup?

DB configuration name: cleanup_queues

If enabled, a successful start of a send or receive queue daemons cleans up the respective queue with the following rules:

  • server ID matches the started daemon
  • send queue daemon "os4xsqd": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
  • receive queue daemon "os4xrd": Remove all files with the same server ID

Because it's a quite destructive option, the default is off.

Should invalid restart positions deactivate restart of file?

DB configuration name: dont_restart_invalid_offset

If enabled, all files given with a restart position bigger than proposed file size won't restart file transfer and begin at the start of the file (i.e. if file size is 44123kB, but restart position is available at 49876kB, because the physical file is 51832kB big; received file size is bigger that the proposed 44123kB because the file is bigger).

Note: Volvo needs this flag to be turned on in special conditions.

Activate OFTP2 secure authentification directly after certificate delivery?

DB configuration name: activate_ssidauth_after_delivery

If enabled, the partner switch "use OFTP2 secure authentification" will be enabled right after an automatic import of a certificate delivery. Please note that this may influence the behaviour of new connections: they may be aborted if the configuration flag allow unsecure OFTP 2 authentification is disabled and this partner wants to connect the next time and doesn't have the same settings activated.

Enable per-partner virtual file naming recognition?

DB configuration name: per_partner_sfiddsn

If enabled, an incoming file will be checked against a list of configured partner entries with the configured SFID (originator and destination) and in addition to this normal behaviour, against a list of configured virtual filenames (so-called "DSN", "Virtual File Dataset Name" or "SFIDDSN"). These allowed virtual filenames are configurable at a per-partner basis, so they are an additional switch which partner entry is handling this special filename.

If multiple partner entries match, first one will be used.

Fetch EERPs?

DB configuration name: configDaemonFetchEerp

If enabled, OS4X's send queue daemon will contact the remote partner for every file which is in the send queue status "waiting for remote acknowledge". In the newly created session, the partner has the chance to send the EERP or NERP message for any file. The maximum amount of configured sessions for a partner is being used (if available and configured properly in the "partner table" configuration). No more than the maximum of this amount of sessions will be opened, summarized for poll queue, send queue files and EERP fetching entries.

Fetch EERPs every x timeslice

DB configuration name: configDaemonFetchEerpTimeslice

If EERP fetching is enabled, this factor is being used to increase the time between two connect tries of the OS4X send queue daemon when trying to fetch one or more EERP messages of a partner.

Disable unsuccessful fetch logs?

DB configuration name: configDaemonFetchDisableUnsucessfulLogs

Since 2021-03-10, OS4X can disable fetch log in loglevel "warning" for unsuccessful fetch tries (which may fill up your send logs quite fast).

Don't deactivate dir.scanner entries on error?

DB configuration name: configDaemonDirscannerDontDeactivate

If enabled, the send queue daemon will not deactivate diresctory scanner entries if an error occurs with the according enttry (i.e directory not available, permission errors etc.). By default, this configuration option is disabled and the daemon will deactivate such entries, logging this in the system logs.

Don't add logs with 'host is down' message?

DB configuration name: cconfigDaemonDirscannerDontLogHostdown

If enabled, directory scanner rules won't add logs when the source directory is offline due to an offline file server (resulting in a log message "host is down").

Allow underscore character ("_") in virtual filenames?

DB configuration name: configDaemonAllowUnderscoresInVirtFilenames

Some OFTP and OFTP2 systems out in the wild support the underscore character in virtual filenames, which is unsupported by the RFC. In order to support this common mistake of standard interpretation, OS4X supports this non-standard character in addition to the well-defined characters, which are:

 The numerals:               0 to 9
 The upper case letters:     A to Z
 The following special set:  / - . & ( ) space


Enable OFTP buffer compression?

DB configuration name: oftp_compression_cap

In OFTP, file transmissions are divided in small buffers. These buffers may be compressed. Other than the OFTP2 compression, this compression mechanism is not that much optimized in its input data. In order to propagate the functionality in session initialization phase, enable this feature. If the remote party doesn't support this feature, it will be dynamically turned off within the OFTP handshake process.

Poll back identified partner on incoming TSL error?

DB configuration name: pollback_on_tsl_error

If a uniquely identified partner polls your server and a TLS error occurs (i.e. certificate chain unknown), this option initiates a poll to this partner. In many cases, this can bypass certificate problems on remote systems.


Enable boost mode for parallel sessions?

DB configuration name: sqd_boost

If enabled, the send queue daemon forks as many send processes for a partner (up to the configured partner amount of parallel sessions) sequentially instead of waiting for the configured send queue daemon time slice. Be warned: a massive system load may occur (RAM, CPU load and parallel database connections)!


OS4X Enterprise

The behaviour of OS4X Enterprise can be influenced in the following three topics:

Config-Enterprise.png

OS4X Enterprise - Basic

is OS4X Enterprise installed?
DB configuration name: os4x_enterprise

If you enable this checkbox, the web interface expands its funtionality needed to administrate OS4X Enterprise, an enhanced version of OS4X. Disabling this checkbox turns OS4X into its default configuration of OS4X Core. If you are interested in features of OS4X Enterprise, contact your software dealer or write an email to info@os4x.com .

default country
DB configuration name: default_country_idx

When creating a new location entry in the OS4X partner database and using OS4X Enterprise, a country has to be selected for this location. For easy administration, a default country is configurable with with configuration. This configuration is only visible if OS4X Enterprise is installed (and the above checkbox is enabled).

default receive plugin group
DB configuration name: default_rec_plugin_pkg

This pulldownmenu contains all defined plugin packages. You should select a plugin package which will be run after a job is completely received (i.e. after the receive file sorter has collected all needed files). This configuration is only visible if OS4X Enterprise is installed (and the above checkbox is enabled).

default send plugin group
DB configuration name: default_send_plugin_pkg

The configured default send plugin group is used to pre-configure a plugin group which is used for newly added partners. This plugin group will be configured at company level (the highest hierarchy level) for the new partner.

enable multi-protocol support?
DB configuration name: os4x_enterprise_other_protocols

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the OS4X send queue for outgoing files), you may define and use other protocols for data transfer to partners. Enable this checkbox to get more options on then. See OS4X Enterprise - other protocols for more details about administration.

define own company
DB configuration name: os4x_enterprise_own_company

For a finer grained target address code search, you can define your own company here. If "no selection - enable multi-client-support" is selected, all address codes of all companies will be used for recipient search.

Default recipient for incoming jobs
DB configuration name: enterprise_default_rec

By default, no recipient is configured for inomcings jobs in initial state. By defining a default recipient here, this person will be defined as the initial recipient, leading to an execution of the configured plugin group of this recipient if no other plugin changes this recipient successfully.

Path for jobs of directory scanner
DB configuration name: enterprise_dirscanner_jobdir

This name defines the path (relative to the outgoing directory) wherein the directory scanner will create jobs. The job number will be appended to this given directory name. Relative path information can be used, too (using "../" definitions).

Examples (with a default outgoing directory path of "/opt/os4x/outgoing"):

  • definition: os4x-dirscanner-enterprise-job-
  • resulting path (for job 123): /opt/os4x/outgoing/os4x-dirscanner-enterprise-job-123/
Enable auto-addresscode functionality
DB configuration name: enterprise_auto_adrcode

When enabled, editing a recipient adds the ability to create a new unique address code, based on values of other persons in that company. The algorithm tries to identify a numeric element of the existing address code and increments it until an unused value is available. This functionality may fail for address codes without a numeric element.

Enable addresscode uniqueness checks
DB configuration name: enterprise_unique_adrcode

When enabled, the administrative web interface warns an administrator if the configured address code is used by another person in the same company. This is done by marking the input field as invalid, adding a hover mask for a textual information that this address code is used already.

Disable automatic addresscode conversion
DB configuration name: configGuiAddresscodeDontConvert

When enabled, the administrative web interface doesn't convert the addresscode into upper case, so it's usable for other purposes than ENGDAT routing.

Shall errornous sendings abort jobs
DB configuration name: configEnterpriseAbortJobRejectedFiles

When enabled, the "end send" event of OS4X Core will abort jobs if sending is errornous.

Serialize incoming jobs
DB configuration name: configEnterpriseSerializeIncomingJobs

OS4X Enterprise receive jobs will be collected in a database table and executed plugin after plugin, job after job in a serialized way (not in parallel) in order to save server resources.

Enable big job support
DB configuration name: enterpriseEnableBigJobs

Enabling this feature migrates the database table for job XML information from a medium text to a long text format, offering more space to be saved (but consuming much more space).

Job abort event
DB configuration name: enterprise_job_abort_script

If an OS4X Enterprise job aborts, this event will be executed.

Send job abort plugin group
DB configuration name: send_job_abort_plugin_pkg

If an OS4X Enterprise send job aborts, this configurable plugin group can be executed.

Receive job abort plugin group
DB configuration name: rec_job_abort_plugin_pkg

If an OS4X Enterprise receive job aborts, this configurable plugin group can be executed.

Absolute AJAX URL for job restore processes
DB configuration name: enterprise_archive_restore_url

For archived jobs, this URL will be called via JSONP in order to restore the job.

Name of parameter for restore AJAX call
DB configuration name: enterprise_archive_restore_parametername

When restoring OS4X Enterprise jobs via the above configured URL, this is the name of the parameter containing the archive ID.

Event to be executed for sent non-Enterprise files
DB configuration name: non_enterprise_send_event

If you use OS4X Core and OS4X Enterprise events in parallel, this event will be fired if a "end_send" will be executed for non-Enterprise enqueued files.

Name of JSONP callback parameter
DB configuration name: enterprise_archive_restore_callbackname

Due to JSONP, this is the name of the required callback function parameter. The default value (if empty) is "callback".

VW REST API file upload - cXML data transfer

This topic is covered in a special article OS4X Enterprise VW EDI cXML upload feature.

OS4X Enterprise - Webaccess

Webaccess URL
DB configuration name: webaccess_url

The URL to OS4X webaccess (without trailing slash), typically used within templates.

Webaccess login logo URL
DB configuration name: webaccess_login_logo

An alternative logo URL (absolute or relative is supported) for displaying in the login prompt of OS4X Webaccess.

Webaccess logged in logo URL
DB configuration name: webaccess_loggedin_logo

When defined, a customized logo can be added to the logged-in view of OS4X Webaccess in the top right corner. Absolute or relative URLs are supported.

Disable password reset functionality
DB configuration name: webaccess_disable_pwdreset

If you want to disable the user password reset functionality, please enable this checkbox.

Password reset mail template
DB configuration name: configEnterpriseWebaccessPwdResetTemplate

The HTML mail template used for password reset link.

Don't show receive queue view
DB configuration name: webaccess_disable_recq

If you don't want the receive queue to be displayed to end-users in OS4X Webaccess, enable this checkbox. The receive queue view doesn't contain any administrative operations.

Don't show send queue view
DB configuration name: webaccess_disable_sendq

If you don't want the send queue to be displayed to end-users in OS4X Webaccess, enable this checkbox. The send queue view doesn't contain any administrative operations.

Show incoming jobs without recipient
DB configuration name: webaccess_show_invalid_rec_jobs

When enabled, this feature adds jobs without a valid recipient to the list of incoming jobs for all users.

Session timeout (min)
DB configuration name: webaccess_session_timeout

You can set a session for timeout for OS4X Webaccess sessions here. Without any interaction, an old session expires automatically after that amount of minutes.

Highlight address code in ENGDAT filenames
DB configuration name: webaccess_highlight_addresscode

If ENGDAT filenames are not interpreted into real filenames (as given i.e. in ENGDAT abstract files, these files are quite technical to read. In order to highlight the address code contained in the filename, enabling this configuration options offers to highlight this address code with the following methods:

  • bold (configuration variable "webaccess_highlight_addresscode_bold")
  • underlined (configuration variable "webaccess_highlight_addresscode_underline")
  • italic (configuration variable "webaccess_highlight_addresscode_italic")
Show all incoming jobs of department
DB configuration name: webaccess_show_dep_jobs_incoming

OS4X Webaccess normally shows only jobs of the corresponding user who is logged in. In order to show all incoming jobs of the department the user is contained, enable this checkbox.

Show all outgoing jobs of department
DB configuration name: webaccess_show_dep_jobs_outgoing

OS4X Webaccess normally shows only jobs of the corresponding user who is logged in. In order to show all outgoing jobs of the department the user is contained, enable this checkbox.

Include given name in search
DB configuration name: webaccess_search_given_name

When searching for persons in OS4X Webaccess (in any situation), the given name (aka. the "first name") is not searched for by default. By enabling this configuration option, searching for the given name is being activated, too.

Don't show popup when adding recipient
DB configuration name: webaccess_ignore_recipient_add

When adding a new recipient to a send job, a popup occurs when not enabled. If enabled, no popup will occur.

Allow users to receive files from the internet?

DB configuration name: configEnterpriseWebaccessEnableCloudJob

If enabled, users can specify a remote URL which will be downloaded to the OS4X webserver and transfomed into a receive job. The download location is configurable via WEBACCESS_UPLOAD_DIRECTORY in os4x.conf, if not set the OS4X temp. directory will be used. The OS4X HTTP proxy settings are respected. Remote downloads create receive log entries with the Medium set to 'HTTP' containing success state, throughput and the effective URL that has been downloaded.

OS4X Enterprise - Plugins

The default behaviour of all plugins can be changed here. The behaviour can be overridden by a configured, set up at each level of partner hierarchy.


OFTP2

OFTP2 relevant options are configurable here:

Config-OFTP2.png

delete temporary created files of OFTP 2 session

DB configuration name: oftpv2_delete_temp_created_files

If enabled (all other values than zero, '0') all files created for temporary usage in OFTP2 sessions and session preparations will not be deleted. This is useful for debugging the created files and meta-information.

Enable offline handling of OFTP2 transfered files?

THIS FEATURE HAS BEEN REMOVED 2018-08-30!

DB configuration name: offline_oftp2_filehandling

If enabled (all other values than zero, '0') incoming OFTP2 files (which need to be handled by any security mechanism, such as signature checking, decompression and/or decryption, will be held in an offline queue, which will then be evaluated by the OS4X offline daemon.

pre-script for offline tool

THIS FEATURE HAS BEEN REMOVED 2018-08-30!

DB configuration name: offline_oftp2_pre_script

If OFTP2 offline handling is enabled, you may enter here the absolute path to an executable which will be executed by the OS4X offline handler before the offline handler processes the file. This is normally a transferer script.

post-script for offline tool

THIS FEATURE HAS BEEN REMOVED 2018-08-30!

DB configuration name: offline_oftp2_post_script

If OFTP2 offline handling is enabled, you may enter here the absolute path to an executable which will be executed by the OS4X offline handler after the offline handler has processed a file. This is normally a cleanup script.

remove successfully handled offline OFTP2 file entries

THIS FEATURE HAS BEEN REMOVED 2018-08-30!

DB configuration name: oftp2_offlinefile_remove_entries

If OFTP2 offline handling is enabled, successfully processed files will be removed from the offline queue (the database table only, not from the filesystem!) if this feature is activated.

Activate OFTP2 secure authentification directly after certificate delivery?

DB configuration name: activate_ssidauth_after_delivery

If enabled, OS4X activates secure authentification method for the given partner right after an automatic certificate exchange.

Don't send EERP messages immediately in OFTP2 sessions?

DB configuration name: no_instant_oftp2_eerp

After successful receipt of an OFTP2 file, you may suppress the automatic sending of an EERP by activating this feature. You should ensure to send an EERP via "os4xeq" with all parameters given in the "end receive script".

Send EERP in synchronous session?

DB configuration name: configOftp2SyncEerp

In OFTP2, file handling (like decompression, signature verification and decryption) is being processed in an asynchronous, forked process (because this handling can take a very long time in terms of network connections; many minutes are not uncommon). If you have to deal with synchronous data transfers where an EERP MUST be transfered in the same OFTP2 session, you can enable this option. Beware of the (default: 1MB) size limit of received files for enabling this feature.

Maximum size of sync. EERP files (in kB)

DB configuration name: configOftp2SyncEerpMaxsize

If the above mentioned synchronous EERP handling for OFTP2 is enabled, you have to define a filesize limit of the transfered file. Files bigger that this limit are not handled by the synchronous EERP process.

Add log entry for synchronous EERP handling

DB configuration name: configOftp2SyncEerpLog

If synchronous file handling takes place, an optional log entry can be places in the receive log every time this process is activated. Warning: may increase your receive log massively!

Delete original OFTP2 handled files which have been enqueued by send queue daemon?

DB configuration name: deleteToBeEnqueuedTouchedFiles

If a file, which has been in status 10 ("to be enqueued for OFTP2"), may result in a temporary OFTP2 file if one of the options for OFTP2 file handling is enabled (compression, signing or encryption). If this is the case, the original file would stay in it's original state. When enabling this feature, OS4X deletes this original file for security reasons from the filesystem. WARNING: no undo or recovery is available!


OFTP2 security policy

Starting with OS4X release 2016-08-16, you can define which security settings match your internal company security policy with easy-to-answer configurations. The following parameters help to configure these values in an easy way. These settings are only relevant for the reception of files, sending files with another settings is possible nevertheless with potentionally different partner settings.

The following configuration options can be defined to a behaviour explained below:

  • File encryption (dabase configuration name: "oftp2_policy_encrypted")
  • File compression (dabase configuration name: "oftp2_policy_compressed")
  • File signature (dabase configuration name: "oftp2_policy_signed")

The configuration options explained:

  • unconfigured: All files are accepted
  • Allow: All files are accepted, both with activated and deactivated security option.
  • Require: The security option MUST be activated for incoming files, otherwise the file will be rejected with an appropriate error message.
  • Reject: The security option MUST NOT be activated for incoming files, otherwise the file will be rejected with an appropriate error message.
  • Require partner value: Require partner value: The file must be sent by the remote party according to the settings which are activated or deactivated in your partner configuration. If the security option is not fulfilled, the file will be rejected with an appropriate error message.

If a security policy is not fulfilled, an offered file will be rejected. A log entry in the receive log will occur per file. The partner is given the information not to retry this sending process again.

Allow fallback to unsecure OFTP 2 authentification
DB configuration name: oftpv2_allow_unsecure_auth

If enabled (all other values than zero, '0') it is possible to connect to OS4X with a disabled secure authentification mechanism, even if the identified partner (via SSID and password) has a secure authentification method activated. If this configuration is disabled (which is the default), OFTP2 sessions are directly closed with a secure session error message.

Preferred cipher suite
DB configuration name: oftp2_policy_preferred_cs

This configured cipher suite will be the preferred one for incoming files. With the option below, files using another cipher suite can be rejected. The list of cipher suites is dynamically obtained from the OFTP2 system. If the configuration value is "Use partner configured value", incoming files shall (or must, depending on the option below) be using the cipher suite which is defined at partner level.

Deny other cipher suites than the preferred
DB configuration name: oftp2_policy_deny_unpreferred_cs

If a ciphersuite is configured in "Preferred cipher suite" and incoming files use another cipher suite, this option will reject the incoming file with an appropriate error message.

External IP address or hostname of this OFTP2 system

DB configuration name: oftp2_external_hostname

This configuration option is used in new certificate signing requests as the common name ("CN") of this OFTP2 system.

Activate auto-cleanup of old certificates?

DB configuration name: configOftp2AutoCleanup

Since certificates will expire, OS4X will warn you about this fact. If you want OS4X to clean up expired certificates automatically (so you don't have to do this manually), you can enable this checkbox.

Automatically enable disabled certificates?

DB configuration name: configOftp2AutoEnableInactiveCert

If an old certificate has been archived by the mechanism above, disabled (say: not yet enabled) certificates can be enabled dynamically. This is also a mechanism for automatic handling during certificate renewal.

Disable certificate check at every CMS cipher usage?

DB configuration name: ciphersuite_extended_certificate_check

By default, all used certificates in CMS file handling (used in OFTP2 sec.auth., file signature, file encryption and signed EERPs) will verify the trust of the certificate by checking against all available and trusted CRLs. This uses much resources, which can be disabled. If this feature is disabled, revoked certificates will only identified in incoming and outgoing TLS sessions.

Serialize incoming files

DB configuration name: configOftp2SerializeIncomingFiles

If a received file via OFTP2 is handled by CMS (i.e. using file signature, file encryption and/or file compression) the file will be processed in a child process directly upon receipt of the file. If you receive a massive amount of files in a short period of time, parallel processes will take place, consuming ressources. Enabling this feature will save the information of the received file in a database table and process them after a time slice of the receive daemon. The received files will be handled one after another, saving system ressources. The file will be saved beforehand in the incoming directory with a filename suffix ".part" (which is handy for ignoring these files in directory scanner rules).

Logging

Logging enables OS4X to insert human readable messages into log tables. You may turn some features on or off to suite your needs.

Config-logging.png

use syslog

DB configuration name: use_syslog

If you turn on this checkbox, major errors will be logged to the server's syslog facility with the severity LOG_ERR. Major errors are table misconfigurations or process dependant messages (fork failures, memory allocation problems etc.).

enable log vault

DB configuration name: enable_log_vault

Enabling this feature activates code to move log entries from the direct access log tables to slower log vault tables, where all messages (older than a configurable amount of days) are kept. This enhances the access to the online logs.

maximum age for fast logs

DB configuration name: logvault_days

After this amount of days, log entries will be moved from one log to the vault.

move send logs every x timeslices

DB configuration name: logvault_sendq_timeslices

The entries older than the above configured value ('maximum age') of the send log will be moved to the slower vault every this amount of time slices of the send queue daemon. This configuration value cooperates with the configuration value 'time slice for send queue daemon'. Only logs belonging to that server ID will be moved to the vault!

move receive logs every x timeslices

DB configuration name: logvault_recq_timeslices

The entries older than the above configured value ('maximum age') of the receive log will be moved to the slower vault every this amount of time slices of the receive queue daemon. This configuration value cooperates with the configuration value 'time slice for receive daemon'. Only logs belonging to that server ID will be moved to the vault!

archive received xERP messages & archive sent xERP messages

DB configuration name: oftpv2_archive_received_xerp & oftpv2_archive_sent_xerp

It may be useful archive positive and/or negative end-to-end responses. These xERP messages can be seen as acknowledgements from the partner (received xERP) or from yourself (sent xERP). The web interface contains a archive viewer on the left hand: "xERP log". This feature may be needed in some countries for legal issues.

enable script logging

DB configuration name: enable_script_logging

Enabling this feature logs all script calls, parameters, returncodes and output to the script logs. In the web interface, you can take a look at the script logs with the link „Script log“. In this interface, you can also restart event scripts (even if they have changed in the configuration: you can then execute the original or the new one, depending on executability of the script file).

Enable directory scanner logging?

DB configuration name: enable_dirscanner_logging

If enabled, the directory scanner logs every single execution script based on the found file.

Enable continuous write of OS4X debug daemon output?

DB configuration name: os4xdebugd_continuous_write

When enabling this feature, the OS4X debug daemon creates a debug log file (and starts the configured event script if existant) after the ring buffer is full. In this case, no message is lost.

If this feature is enabled, starting with OS4X release 2015-08-25 a button with the label "Collect today's logs" is available which lets you send all collected debug daemon dump files of this day and enqueue it to a specific partner for debugging. Requirements for this feature are:

  • OS4X debug daemon is running
  • The temporary directory is accessible and writable by the OS4X debug daemon
  • The event "debug daemon log event" does not change the filename prefix "os4x-logfile-<YYYYmmdd>" (where "YYYY" is the current year with four digits, "mm" is the actual month starting at "01" with two digits and "dd" is the actual day, starting with "01" and two digits).

The partner to which the files are being enqueued is possible to be searched. By default, the partner "OS4X-Update" is searched. If the partner is not found, no partner search is pre-set and the whole partner list is being presented. If exactly this pre-set partner "OS4X-Update" is found, it it selected automatically, so you don't have to click on it to activate the selection. Only if a single partner is selected in the partner search list, the files are being enqueued to this partner after submission (either via "Save" button or via double click).

The virtual filenames of the logfiles is "OS4X-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "OS4X logs - automatically enqueued via administrative web interface".

Absolute path to logfile of OS4X API

DB configuration name: os4xapi_logfile

The OS4X API, which is the background service for OS4X Webaccess and OS4X Proxy, logs into this file.

Absolute path to logfile of OS4X API (CLI)

DB configuration name: os4xapi_cli_logfile

The OS4X API, which is the background service for OS4X Webaccess and OS4X Proxy, logs into this file if called in command line mode. Beware that the user who calls the OS4Xapi must be able to write to this file. If the file doesn't exist, it will be createad (as long as write permissions exist in the target directoy; the owner of the newly created file will be this user which may be important for future write with another user).

OS4X API loglevel

DB configuration name: os4xapi_loglevel

The above configured file will be written in the configured log level.

Suppress unsuccessful connect log entries?

DB configuration name: suppress_unsuccessful_connect_logs

If an incoming connection fails before OFTP handshake could be initiated, a logging entry is normally made in the style of:

unsuccessful connect try from IP 'aaa.bbb.ccc.ddd'

If you want to ignore these messages (i.e. when using a system monitoring which just watches if the TCP/IP port is open), enable this feature.

This configuration also suppresses AS2 logs where no valid partner, no valid filename and no valid message ID is presented in the HTTP(S) data stream.

Log ADOdb messages (requires DEBUG level)

DB configuration name: log_adodb

If enabled, the OS4Xapi will add massive logging content to the configured OS4Xapi log file (only available in DEBUG or TRACE mode).

Disable OS4X Heartbeat messages?

DB configuration name: disable_heartbeat_logs

If OS4X Heartbeat is ordered as a service, this configuration option disables these external availability checks from the receive logs.

Don't log Censys Scanner entities in system log?

DB configuration name: configDaemonDisableCensysLogs

Censys Scanner seems to scan for vulnerable TLS services on the public internet, flooding the OS4X's system log with massive messages. This option removes such messages, containing the log text "census-scanner".

Directory scanner - Don't add logs with 'host is down' message?

DB configuration name: configDaemonDirscannerDontLogHostdown

If a directory scanner rule applies to a mounted directory where the server is unavailable, this option suppresses log messages containing "host is down" in the directory scanner logs.

Directory scanner - Don't add logs with 'no such file or directory' message?

DB configuration name: configDaemonDirscannerDontLogNoSuchFile

Sometimes a recognized file is instantly removed from a directory scanner observed directory. This also applies to directories which are unavailable (i.e. subdirectories of a mounted share). This option eliminates the log message "no such file or directory" in the directory scanner logs.

Directory scanner - Don't add logs with 'permission denied' message?

DB configuration name: configDaemonDirscannerDontLogPermission

If a directory or file is inaccessible by the directory scanner by permission rules, this option suppresses log entries stating "permission denied" in the directory scanner logs. This option also enables OS4X to ignore messages "Software caused connection abort".

Directory scanner - Don't add logs with 'device or resource busy?

DB configuration name: configDaemonDirscannerDontLogDeviceResourceBusy

If a directory or file is inaccessible by the directory scanner, this option suppresses log entries stating "device or resource busy" in the directory scanner logs.



GUI

The GUI offers some parameters which influence the default behaviour.

ConfigGui.png

Send signals to running processes

DB configuration name: webgui_kill_processes

The PHP backend can send running processes a signal, i.e. for reloading their configuration (when clicking "Save") or cancelling transfer processes. If the webserver is not running on the same machine as the OS4X daemons do, or if the webserver user is not privileged to send signals to running OS4X processes (i.e. they are running in another user context), you should disable this checkbox, otherwise (which is the default) keep it activated for a seamless integration of GUI and backend.

Disable PID check of daemons

DB configuration name: disable_PID_checks

The OS4Xapi can check if daemons which should run with a given process ID really exist. If they don't exist, the OS4Xapi will cleanup running information (= their PIDs) in the database. This feature is available in Linux and MacOS, partially in AIX. If you get unwanted results, disable this feature.

Show partners with unknown medium

DB configuration name: display_partners_with_unknown_medium

Since the configurable partner database schema is highly configurable, many partner entries may have an unknown transmission medium configured (valid values are configurable for unencrypted TCP/IP and encrypted TCP/IP aka. TLS). If this configuration option is enabled, all partners (even with unknown medium values) are displayed in the partner list.

Enable simple configuration

DB configuration name: simple_config_gui

In many installations, most complex situation are not needed for this installation. As a minimizer for unneeded configuration options, most uncommon configuration options are not visible when enabling this configuration option. Elements which are hidden when this config option is activated are:

  • Configuration:
    • TCP/IP
    • Events
    • Daemon
    • OFTP2
    • Logging
    • Partner table
  • Programs:
    • Partner import
  • Cipher suites

Partner management for OFTP2 is also more easy, so a more or less incomplex system will be shown in order to allow non-common users to administrate the system well.

Min. age for expiration warning of certificates

DB configuration name: gui_cert_warning_days

The administrative web interface can show expiring certificate warnings and expired certificate errors in the tab "Welcome", section "Possible configuration problems". The configured amount of days are used for calculation which certificates to display.

Theme for administrative GUI

DB configuration name: gui_theme

The admin web interface supports the switch of the used theme for displaying information. You can switch the theme without saving dynamically. When saving this config, all subsequent calls to the web interface will switch to the configured theme.

Disable health check of database

DB configuration name: gui_disable_db_healthcheck

Disabling the database health check will not include database table checks in the section "Possible configuration option" in the "Welcome" tab of the administrative web interface. By disabling these checks, you can lower your database overhead massively.

Filtered filesystems from "Welcome" tab

The administrative web interface shows the filling state of all mounted filesystems, except the filesystems contained in the list of excluded filesystems. A filesystem can be exluded from the displayed list by clicking on the entry bar on the "Welcome" page, then answering "Yes" to the delete question. The deleted file system(s) are listed here in a grid, where they can be removed so the removed entry will be displayed again on the welcome page.

User own defined URLs

DB configuration name: use_own_defined_urls

If enabled, the menu on the left side in the administrative web interface will add an entry with a configured name (see below).

Name of entry

DB configuration name: own_defined_urls_menuentry_name

The name of the menu entry which contains user-defined URLs is changeable.

Own defined URLs

If enabled, the administrative web interface adds the possibility to configure a list of URLs for viewing within the administrative web interface as a closeable tabbed entry. The included URL is being integrated via an IFRAME, so if the integrated page doesn't allow this functionality (i.e. thorugh a META tag), the content will stay empty. Keep in mind that many popular dynamic sites don't allow this type of integration. Have a look into your JavaScript console if any errors occur.

AS2

The AS2 functionality is configurable per-partner and globally. The global parameters are configurable here.

Bildschirmfoto 2020-09-30 um 11.00.09.png

TCP/IP port for HTTP communication listener

DB configuration name: configAs2HttpPort

This is the numeric port of the plain TCP/IP listener for incoming HTTP sessions.

TCP/IP port for HTTPS communication listener

DB configuration name: configAs2HttpsPort

This is the numeric port of the encrypted TLS listener for incoming HTTPS sessions.

Use OFTP2 certificate for HTTPS?

DB configuration name: configAs2UseOftp2Cert

When enabling this checkbox, the OS4X OFTP2 certificate is being used as HTTPS TLS certificate (the most easy way to support HTTPS).

HTTPS certificate

DB configuration name: configAs2HttpsServerCert

If the OFTP2 certificate is not used for HTTPS, a separate HTTPS certificate file can be configured for encrypted HTTPS connections. The file must contain the public certificate (optionally included chain) and RSA/DSA unprotected private key.

AS2 TLS ciphers

DB configuration name: configAs2TlsCiphers

The list of TLS ciphers is configurable for the TLS handshake. An example on how to suppress Qualys ROCKET scan report is:

  • DEFAULT@SECLEVEL=2

openSSL TLS cipher configurations are supported here with a maximum length of 255 characters (so it's best to use groups for in- and exclusion).

External URL

DB configuration name: configAs2ExternalUrl

The external URL is contained in outgoing messages, defining where to post the corresponding asynchronous MDN to.

Overwrite existing incoming files

DB configuration name: configAs2Overwrite

If any incoming file has the same name on the filesystem, this option enables OS4X AS2 to overwrite this file.

Append Unix timestamp (incl. microsends) to received file?

DB configuration name: configAs2AppendTimestamp

If a new file is received, the current timestamp incl. microseconds of the running operating system will be appended to the filename in order to make it unique.

Ignore certificate purpose for signature checks?

DB configuration name: configAs2IgnoreCertPurpose

If enabled, the purpose of the used certificate for a specific functionality is not checked and used anyway (even if the certificate usage forbids this).

Write temporary logs & Keep logs ... days

DB configuration name: configAs2Debug
DB configuration name: configAs2KeepDays

If enabled, all incoming messages will be saved for a configurable time period into the database for later analysis. You can download a dump of that data via the button "Download logs".

Relative filename for undefined receive files

DB configuration name: configAs2EmptyRecFilename

If (against the RFC) no filename is specified by the sender, OS4X AS2 can use this filename as a default value. Inform your opponent sending party to correctly define a transmission filename if this happens regularly.

Send queue displayed columns

The list of columns configure the default state of the columns when opening the send queue overview. The columns can be re-activated afterwards via the column header management.


other interesting configurable values

Some values are not configurable via web interface, but also have a useful meaning when running OS4X. These configuration value names are:

  • os4xclientd_port: TCP/IP port of the program OS4X client daemon
  • webinterface_path: Absolute path of the web interface on the webserver. This is useful for upgrading processes in order to update the path correctly.