Seon - User contributions [en]

Seon VMware virtualized image - mail configuration

2018-06-19T08:15:47Z

Admin: /* Relay authentification */

The Seonvirtual Linux environment comes with a pre-installed Mail Transfer Agent (MTA) called "Exim" in version 4. You can configure Exim4 to your needs in order to send emails within your system environment.

== Basics ==
Exim4 is best configured on command line (i.e. via SSH) via a dialog based system. This system easily helps you to accomplish your configuration task.

The command to be executed as root is:
dpkg-reconfigure exim4-config
The following informational prompt asks you to confirm the "OK" button:

[[Image:Dpkg-reconfigure exim4-config.png]]

== Direct mail sending - without mail relay ==
If you can send emails directly via SMTP (i.e. your Seon machine has direct internet access), you can choose the first option "<code>internet site; mail is sent and received directly using SMTP</code>":

[[Image:Dpkg-reconfigure exim4-config-1.png]]

You will then need the following settings:
*System mail name: The full qualified domain name (FQDN) of the Seon system (i.e. "<code>seon.de</code>", "<code>c-works.de</code>" or whatever your mail domain is).
*IP-addresses to listen on for incoming SMTP connections: ''(keep default)'' <code>127.0.0.1 ; ::1</code>
*Other destinations for which mail is accepted: ''(keep default)''
*Domains to relay mail for: ''(keep default)'' [empty]
*Machines to relay mail for: ''(keep default)'' [empty]
*Keep number of DNS-queries minimal (Dial-on-Demand)? ''(keep default)'' No
*Delivery method for local mail: ''(keep default or change to whatever your prefered type is)'' <code>mbox format in /var/mail/</code>
*Split configuration into small files? ''(keep default)'' No

== Mail sending over SMTP relay (aka. "smarthost") ==
If your network provides an existing mail server, the option "<code>mail sent by smarthost; received via SMTP or fetchmail</code>" will be the best one:

[[Image:Dpkg-reconfigure exim4-config-2.png]]

*System mail name: The full qualified domain name (FQDN) of the Seon system (i.e. "<code>seon.de</code>", "<code>c-works.de</code>" or whatever your mail domain is).
*IP-addresses to listen on for incoming SMTP connections: ''(keep default)'' <code>127.0.0.1 ; ::1</code>
*Other destinations for which mail is accepted: ''(keep default)''
*Machines to relay mail for: ''(keep default)'' [empty]
*IP address or host name of the outgoing smarthost: ''The IP/hostname of the relay host.''
*Hide local mail name in outgoing mail? ''(keep default)'' No
*Keep number of DNS-queries minimal (Dial-on-Demand)? ''(keep default)'' No
*Delivery method for local mail: ''(keep default or change to whatever your prefered type is)'' <code>mbox format in /var/mail/</code>
*Split configuration into small files? Yes

=== Relay authentification ===
If you need to authenticate against an existing relay host with a given username and password, you have to do the following:
*Edit the file "<code>/etc/exim4/passwd.client</code>" with your favorite editor (i.e. "<code>vi</code>")
vi /etc/exim4/passwd.client
*Add a line with the following syntax:
yourdomain.com:user@yourdomain.com:yourpassword
*If authentification fails (which can be examined in the Exim's logfile "<code>/var/log/exim4/mainlog</code>"), try the following syntax:
*:user@yourdomain.com:yourpassword
*Reload the configuration of Exim:
update-exim4.conf
*Create the file "<code>/etc/exim4/exim4.conf.localmacros</code>" with the following content:
AUTH_CLIENT_ALLOW_NOTLS_PASSWORDS = 1
*Restart Exim:
service exim4 restart

== Change sender's mail address ==
Seon's mailing functionality is running as a [[Seon_Core_configuration#run_Seon_programs_as_user|configured user]] (which is normally the webserver user, in this case "<code>www-data</code>"). You can configure that this user ("<code>www-data</code>") is mapped to another outgoing email address.

In our example, all mails sent by Seon shall be sent by the email address "<code>seon@mydomain.com</code>":
*Edit the file "<code>/etc/email-addresses</code>" with your favorite editor, i.e. "<code>vi</code>":
vi /etc/email-addresses
*Add a line with the [[Seon_Core_configuration#run_Seon_programs_as_user|configured user]] running Seon ("<code>www-data</code>"):
www-data: seon@mydomain.com

== Troubleshooting ==
In any case of problems, take a look at Exim's log file:
tail -f /var/log/exim4/mainlog

You can send emails with the system's "<code>sendmail</code>" program:
echo test | sendmail contact@seon.de

Seon Core configuration

2018-05-29T19:21:40Z

Admin: /* Daemon parameters */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL client: no").

Summarizing:

If you have this checkbox enabled (default):
*Seon'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 "[[Seon_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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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, Seon will warn you about this fact. If you want Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon Core configuration

2018-05-29T19:20:01Z

Admin: /* Daemon parameters */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL client: no").

Summarizing:

If you have this checkbox enabled (default):
*Seon'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 "[[Seon_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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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.

==== Be absolute RFC restrictive? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rfc_conformity
|}

This optional parameter enables strict RFC conformity. This enables:
*Closure of TCP/IP connection after partner closes connection only (no pro-active socket closing)
*Sending CD message even if the partner doesn't want to (EFPA['N']). This unwanted "C"hange "D"irection request break OFTP sessions with (at least) Axway products.

==== Fetch EERPs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerp
|}

If enabled, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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, Seon will warn you about this fact. If you want Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon Enterprise partner migration

2018-05-11T11:15:43Z

Admin: /* Generic CSV */

Seon Enterprise offers various import possibilities of hierarchical data of partner information. If none of the offeres solutions fits your needs, please contact us in order to search for a valid solution, we will help you out.

== Doing ==
Most partner import processes are executed via the administrative web interface. Locate the menu entry point "Programs" -> "Partner import":

[[Image:Partner import.png]]

== Daxware import ==
Daxware 2002 installations can export their partner information in CSV format, so the two steps have to be executed in the following order:
#Import "partner companies and locations" CSV
#Import "departments and recipients" CSV
The second step is based on the first step, so it would make no sense to switch the order of import.

== Hüngsberg/Wiberg Daxware (with OFTP2) ==
The Hüngsberg Daxware / Wiberg Daxware solution supporting OFTP2 can be imported in three sequential steps:
#Import the file "passw.dax" containing all OFTP stations
#Import the file "partner.dax" containing the OFTP2 configuration of all stations
#Import a CSV file of the MS-SQL database table "dbo.engdatProfileElements"

The CSV file of the database table can be extracted from the database via Microsoft's SQL Server Management Studio. Select all entries of this database table, copy&paste the data into a spreadsheet application (like Excel or Libre-/OpenOffice and save the contained data including the header line into a new CSV file.

There must exist a header line. The format of the header line is (26 fields):
ID;ParentID;ProfileName;LogischeAdresse;EngdatCode;Kurzname;Abteilung;Name;Firma;Strasse;PLZ;Ort;Land;Tel;Fax;eMail;Text;Application;ApplicationVersion;Format;FormatVersion;DataCode;FileStatus;TextFile;ZIP;oftpid

The imported entities have the following configuration:
*All OFTP partners have the plugin group for send jobs defined as configured in [[Seon_Core_configuration#default_send_plugin_group|Configuration -> Seon Enterprise -> Default send plugin group]]
*All OFTP2 partners with active security parameters are being polled to obtain their certificate from the TLS server, so network availability must be given. In this step, the own TLS server certificate is being used for all local operations.
*All values "NULL" are replaced with empty definitions.
*If no location name is being defined in the CSV file, a default value "-" is used.
*If no department name is being defined in the CSV file, a default value "-" is used.
*The name and surname of persons is being extracted via the field "Name". If no valid name is configured, the name is extracted from the field "ProfileName".

== EurexC ==
The import of EurexC based systems can be divided in two supported versions:
*Versions of EurexC CAD base which have the partner configuration in a file named "<code>xx020.d</code>"
*Versions of EurexC CAD base which have the partner configuration in a file named "<code>xx030.d</code>"

When enabling the checkbox "Purge existing partners before migration", all partners will be deleted before migration starts.

When enabling the checkbox "Create dummy hierarchy for Seon Enterprise", a location with the same name as the partner is created for every entry. In this location, a department "OFTP" is added, where a user "Admin" is being added. This checkbox is only available if [[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|Seon Enterprise]] is enabled in the configuration.

All special characters, i.e. german umlauts, are converted to newline due to the fact that the encoding is unknown.

== WinElke ==
WinElke systems which are based on MS Access databases can be imported on a limited amount of platforms which support the binaries for the required tools. Just upload the MS Access file if the button is enabled.

== SWAN 3.x ==
The partner databae schema must exist in the same database which Seon is working on. If the underlying tables exist, but the button is disabled, please contact us in order to verify your (possibly inconsistent) data.

== CSV ==

=== Daxware CSV ===
Via the Daxware import possibility, you can generate CSV files with a given format in order to import your partner data. The format of the files must follow a fix syntax.

The CSV for companies and locations (in one file) must contain exactly this following header line as the first line to be contained in the CSV file:
Companyname;Street;Housenumber;PostalCode;City;Country;Phonenumber;Fax;SSID;SFID;Net;Address;Password;Characterset;Fileformat;Recordsize

The second file for departments and recipients must contain exactly this following header line as the first line to be contained in the CSV file:
Companyname;Companylocation;Lastname;Firstname;Phonenumber;Mobilenumber;Faxnumber;eMail;Department;Password;Userrole

The references between the two files are the names of the company (1. "Companyname" = 2. "Companyname" ) and the location name 1. "City" = 2. "Companylocation").

The field names indicate the value of the entity. Some words about special values:
*Companies and locations CSV:
**<code>Net</code>: The textual value "<code>ISDN</code>" masks this as an ISDN connectivity partner, the given address is then the ISDN number. Otherwise, it's implicitely a TCP/IP connection partner, the address is then the TCP/IP hostname or IP address.
**The own values of the local SSID, SFID and password are taken from the configuration of "[[Seon_Core_configuration#Odette_parameters|Odette parameters]]" in the section "[[Seon_Core_configuration|Configuration]]"
**all partner companies with the same name are being updated; all others are inserted
*Departments and recipients CSV:
**Entries with the same department, same company, same first name and same last name are updated; all others are inserted
**all departments of a given location with the same department name are being updated; all others are inserted

=== Generic CSV ===
In addition to the above documented Daxware CSV format, you can upload a CSV formatted file for departments and recipients with two more attributes (starting with Seon release 2015-04-29):
*address code
*username
The header of the CSV file must be:
Companyname;Companylocation;Lastname;Firstname;Phonenumber;Mobilenumber;Faxnumber;eMail;Department;Password;Userrole;AddressCode;Username

The field "Companyname" must be the shortname of the referenced company entry.

== DDX ==
The migration of DDX databases is supported, if all requirements are fulfilled:
*Seon Enterprise is licensed (needed for the complete functionality).
*The Oracle database client is installed an usable on the webserver, also the PHP module is available and properly installed (''this is the case for the pre-installed Seon virtual appliance'').
*The database connection is known to the DDX database (reachable via network connection).

All entities available in the database will be migrated. These are:
*The own company structure, selectable from a list of available entities.
*All other communication partners, both OFTP and FTP systems are supported.
*All jobs are migrated, including meta-information like date, sender, recipient and files (including relative, absolute and virtual file path/-name information).

Depending on the speed of your system(s), the migration should not take longer than 10 minutes.

[[Category:Seon Enterprise]]

Seon Server-side plugin philosophy

2018-04-06T09:26:42Z

Admin:

Server-side Seon plugins are programs which are executed during job processing. Plugins can be any type of executable: compiled programs, Java programs, shell/Perl/PHP/... scripts. Plugins can be put together into so-called plugin groups.

There are two types of plugins:
*Synchronous plugins: will be executed by the plugin handler. The starting process waits until end of plugin execution.
*Asynchronous plugins: will be executed by the plugin handler and job processing instantly stops. The job receives the status 'waiting for asynchronous plugin'. The plugin itself is responsible to start the asynchronous plugin handler at its end. Asynchronous plugins must understand the parameter "<code>-c</code>" in order to cancel job processing asynchronously.

Plugins receive an XML as parameter which contain all job parameters. The plugin may modify this XML file. The plugin handler starts the plugin with the last actual XML file, afterwards it reads in this XML file and saves is in the database as the actual XML.

The standard output "stdout" and "stderr" will be read in and saved in the plugins logs, attached to the actual job.

The return code of the executed plugin is received by the plugin handler (synchronous or asynchronous). If the return code is zero (0), job processing continues. If it's non-zero, job processing stops and the job receives the status "aborted".

At the end of plugin execution (even successful or unsuccessful), all files contained in the job XML with the attribute "<code>copy</code>" or "<code>ENGDAT</code>" will be deleted from the filesystem.

=== plugin parameters ===

Plugins must understand several combinations of parameters.

==== normal behaviour ====
Plugins receive one parameter: the absolute path of an XML file. All job information will be parsed from this XML file.

==== normal behaviour with configuration ====
Plugins receive two parameters: the absolute paths of two XML files. All job information will be parsed from the first XML file, the runtime configuration from the second. More information in the [[Seon Enterprise plugin configuration|plugin configuration]] documentation.

==== automatic plugin installation ====
The only parameter is "<code>-a</code>". The plugin checks its availability in the plugin database table and its configuration parameters. This mode is usually used for automatic updates and installation.

==== configuration ====
In order to display configuration possibilities, plugins may support the parameter "<code>-x</code>". The output of the plugin must be a plugin with a special structure. Refer to the [[Seon Enterprise plugin configuration|plugin configuration]] documentation for more information.

==== asynchronous plugin abort ====
Asynchronous plugins must understand the parameter "<code>-c</code>" as first parameter in order to cancel the job, given as second parameter.

=== Synchronity ===
Asynchronous plugin will cause the job to wait for further external notification in order to continue its work. This is done via the program "seon_async_plugin_handler".

Starting with Seon release 2016-06-02, a dynamic handling of (a)synchronity is possible. A plugin may send a signal "<code>SIGUSR1</code>" to a process, which handles the plugin execution. This process is given by the environment variable
SEON_ENTERPRISE_PLUGIN_MGT_PID
The following two situations can occur:
*An synchronous plugin will switch to synchronous
*A synchronous plugin will switch to asynchronous
A log message in the plugin logs of a job document this behaviour in detail.

[[Category:Seon Enterprise]]

Seon Core configuration

2018-03-01T07:41:06Z

Admin: /* OFTP2 */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL client: no").

Summarizing:

If you have this checkbox enabled (default):
*Seon'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 "[[Seon_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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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.

==== Be absolute RFC restrictive? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rfc_conformity
|}

This optional parameter enables strict RFC conformity. This enables:
*Closure of TCP/IP connection after partner closes connection only (no pro-active socket closing)
*Sending CD message even if the partner doesn't want to (EFPA['N']). This unwanted "C"hange "D"irection request break OFTP sessions with (at least) Axway products.

==== Fetch EERPs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerp
|}

If enabled, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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, Seon will warn you about this fact. If you want Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon Core configuration

2018-02-19T15:52:43Z

Admin: /* TLS server: check client certificate validity */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL client: no").

Summarizing:

If you have this checkbox enabled (default):
*Seon'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 "[[Seon_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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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.

==== Be absolute RFC restrictive? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rfc_conformity
|}

This optional parameter enables strict RFC conformity. This enables:
*Closure of TCP/IP connection after partner closes connection only (no pro-active socket closing)
*Sending CD message even if the partner doesn't want to (EFPA['N']). This unwanted "C"hange "D"irection request break OFTP sessions with (at least) Axway products.

==== Fetch EERPs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerp
|}

If enabled, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon Core configuration

2018-02-19T15:50:43Z

Admin: /* TLS server: check client certificate validity */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL client: no").

Summarizing:

If you have this checkbox disabled (default):
*Seon'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 enabled (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 "[[Seon_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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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.

==== Be absolute RFC restrictive? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rfc_conformity
|}

This optional parameter enables strict RFC conformity. This enables:
*Closure of TCP/IP connection after partner closes connection only (no pro-active socket closing)
*Sending CD message even if the partner doesn't want to (EFPA['N']). This unwanted "C"hange "D"irection request break OFTP sessions with (at least) Axway products.

==== Fetch EERPs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerp
|}

If enabled, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon Core list of possible log entries

2018-02-19T15:17:28Z

Admin: /* system log */

This list of possible log entries (both receive, send and system logs) gives you an overview of all logs that could appear and what they mean in detail.

The messages are listed in no special order. It's possible that this list doesn't contain all messages that can arise!

== send log ==
=== <code>unknown type of connectivity for entry ...</code> ===
All sending processes try to obtain the medium of that partner from the configured partner table (see [[Seon Core configuration#Partner table parameters]]). If no numeric value can be resolved to a configured medium, this message is logged. The misleading value is contained in this message.

=== <code>sending of file '...' aka '..' aborted: partner has asked for an invalid restart position of ... kB while we offered ... kB</code> ===
OFTP offers a restart mechanism for file transfers. In this errornous case, the remote side wants to use a bigger restart position than Seon (as sender) proposed to use. According to chapter 5.3.4 - "SFPA - Start File Positive Answer" of RFC 2204, the restart position given by the remote (receiving) side must be equal or lower than the sender proposed.

=== <code>sending of file '...' aka '...' aborted: partner has asked for an invalid restart position</code> ===
OFTP offers a restart mechanism for file transfers. In this errornous case, the remote side wants to use a bigger restart position than Seon (as sender) proposed to use. According to chapter 5.3.4 - "SFPA - Start File Positive Answer" of RFC 2204, the restart position given by the remote (receiving) side must be equal or lower than the sender proposed. In difference to the above message, this one appears AFTER the calculation of amount of credits to be sent in case of using the send acceleration.

=== <code>restarting file transfer at position ... kB</code> ===
The file transfer begins at the documented position (not at the beginning of the file).

=== <code>sending of file '...' aka '...' aborted by user at position ... kB of ... kB</code> ===
During transfer of the file, a user interrupted the transfer by sending the process a signal so the transfer and connection will be aborted.

=== <code>sending of file '...' aka '...' aborted at position ... kB of ... kB: send queue entry removed</code> ===
As a "last option", Seon supports the deletion of send queue entries and recognizing in the active transfer process that "his" entry is removed during transfer. In this case, during updating the progress information, the send process checks the existance of the send queue entry. If not existant, the process aborts the file transfer and adds this message to the send logs.

=== <code>sending of file '...' aka '...' failed at position ... kB of ... kB</code> ===
A network or ISDN connection problem causes the physical or logical connection to be closed, causing this error message. The problem itself is logged in another message.

=== <code>all send queue entries for this partner have been blocked because of connection problems</code> ===
If connection problems to a partner exist (like physical line problem, wrong credentials, wrong SFID etc.), after the maximum send tries of a send queue entry ALL entries for that partner are blocked in order to save connection costs.

=== <code>a send queue entry for this partner has been blocked because of sending problems</code> ===
If a partners refuses the receipt of this specific file and the maximum send try count is reached, this file entry is blocked. All other file entries in the send queue remain in its original state.

=== <code>Error creating connection BIO</code> ===
For SSL/TLS secured TCP/IP connections, an internal handler is needed which is called "BIO". This "BIO" is not available here.

=== <code>Error connecting to remote machine</code> ===
When connecting to a remote partner via SSL/TLS over TCP/IP and the remote system doesn't answer, this message is logged.

=== <code>Error connecting SSL object</code> ===
An error occured during the SSL/TLS handshake with the remote partner.

=== <code>openSSL error: peer certificate: ...</code> ===
An error occured during the check of validity of the remote (partner's) SSL/TLS certificate. The error message (from openSSL) is printed out in this log entry.

=== <code>OFTP ERROR: ESID received during filetransfer (normal termination)</code> ===
During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this case, no error code was given by the remote side.

=== <code>OFTP ERROR: ESID received during filetransfer (reason: ...)</code> ===
During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this casean error code was given by the remote side and the textual interpretation is listed in the message.

=== <code>error in verifying data ...</code> ===
The verification process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in signing data ...</code> ===
The signing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in decrypting data</code> ===
The decrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in encrypting data</code> ===
The encrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in compressing data</code> ===
The compression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in decompressing data</code> ===
The decompression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in hashing data</code> ===
The hashing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

Hashing is normally done internally only (called in Seon itself when a file is successfully received).

=== <code>error in compressing signed data</code> ===
The compression process of OFTP2 signed data failed. The used command, returncode and output is appended in the log message.

=== <code>error in extracting certificate from automatic certificate delivery</code> ===
During automatic certificate exchange of OFTP2, the remote certificate is extracted from a CMS package (a special file). During the extraction, an error occured.

=== <code>reveived signed EERP from partner invalid: verification command returned with code ...</code> ===
During verification of a signed OFTP2 EERP (end-to-end-response, something like a file confirmation), the OFTP2 internal signature verification process returned with a returncode which was not zero (the actual value is added to this message).

=== <code>reveived signed EERP from partner invalid in field EERPDSN: raw content is '...'</code> ===
During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPDSN, which is the virtual filename.

The EERP is not archived, as it is not valid.

=== <code>reveived signed EERP from partner invalid in field EERPDATE: raw content is '...'</code> ===
During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPDATE, which is the virtual file datestamp (format: YYYYMMDD, i.e. 20070516).

The EERP is not archived, as it is not valid.

=== <code>reveived signed EERP from partner invalid in field EERPTIME: raw content is '...'</code> ===
During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPTIME, which is the virtual file timestamp (format: HHMMSScccc, i.e. 1533530001).

The EERP is not archived, as it is not valid.

=== <code>reveived signed EERP from partner invalid in field EERPDEST: raw content is '...'</code> ===
During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPDEST, which is the virtual file destination SFID.

The EERP is not archived, as it is not valid.

=== <code>reveived signed EERP from partner invalid in field EERPORIG: raw content is '...'</code> ===
During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPORIG, which is the virtual file originator SFID.

The EERP is not archived, as it is not valid.

=== <code>reveived signed EERP from partner invalid in field EERPHSH: raw content is '...'</code> ===
During verification of a signed OFTP2 EERP, the signed value of the EERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is EERPHSH, which is the virtual file hash (i.e. binary SHA1 or SHA256 hash).

The EERP is not archived, as it is not valid.

=== <code>reveived signed EERP from partner invalid: could not execute verification command</code> ===
The verification process of a signed EERP cannot be started.

=== <code>reveived signed NERP from partner invalid: verification command returned with code ...</code> ===
During verification of a signed OFTP2 NERP (end-to-end-response, something like a negative file confirmation), the OFTP2 internal signature verification process returned with a returncode which was not zero (the actual value is added to this message).

=== <code>reveived signed NERP from partner invalid in field NERPDSN: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPDSN, which is the virtual filename.

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid in field NERPDATE: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPDATE, which is the virtual file datestamp (format: YYYYMMDD, i.e. 20070516).

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid in field NERPTIME: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPTIME, which is the virtual file timestamp (format: HHMMSScccc, i.e. 1533530001).

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid in field NERPDEST: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPDEST, which is the virtual file destination SFID.

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid in field NERPORIG: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPORIG, which is the virtual file originator SFID.

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid in field NERPCREA: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPCREA, which is the creator SFID of the NERP message.

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid in field NERPHSH: raw content is '...'</code> ===
During verification of a signed OFTP2 NERP, the signed value of the NERP contains a different value than the unsigned one. The raw content of the signed value is contained in this message. The field is NERPHSH, which is the virtual file hash (i.e. binary SHA1 or SHA256 hash).

The NERP is not archived, as it is not valid.

=== <code>reveived signed NERP from partner invalid: could not execute verification command</code> ===
The verification process of a signed NERP cannot be started.

=== <code>RemoteCAPI error: invalid authentification. Check environment variables CAPI_USER and CAPI_PASSWD</code> ===
The configured RemoteCAPI authentification parameters are incorrect. This error message could also occur if the RemoteCAPI device (normally a BinTec Brick) is under heavy load.

=== <code>ISDN CAPI error 0x.... while connecting to partner: ....</code> ===
The hexadecimal and textually resolved error code explain what the reason of not connecting to a partner is. For easy reading, all known ISDN error codes are resolved into human-readable text (like 'user busy', 'no free line' or something like that).

=== <code>ISDN CAPI error: no free line available on RemoteCAPI device (... controller(s) checked)</code> ===
No more lines are available for outgoing calls on all your configured ISDN CAPI controllers. Check your installation, your incoming and outgoing channels (don't forget non-OFTP connections like PPP, isdnlogin etc.!).

=== <code>connection aborted by user</code> ===
An OFTP connection was aborted during the exchange of protocol information by receiving a signal.

=== <code>OFTP ERROR: handled credit count is zero</code> ===
During OFTP handshake, the credit count is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

=== <code>OFTP ERROR: handled buffer size is zero</code> ===
During OFTP handshake, the buffer size is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

=== <code>OFTP NERP ...: remote problem with virtual file '...': ...</code> ===
The remote partner claims that there is a problem with the given file on the partner's side. The reason code and text is appended in this message.

=== <code>OFTP SFNA ...: sending file '...' (aka '...') failed: ...</code> ===
The remote side doesn't accept the file that Seon wants to send before transfer. The reason code and text is listed in the message.

=== <code>ODETTE EFNA ...: ...</code> ===
The end-of-file-transfer message contains an error. The error code and reason text is appended to this message. The file is not transfered correctly then.

=== <code>ODETTE DISCONNECT ERROR ...: ...</code> ===
The OFTP connection unexpectedly died with a remote connectin close with a given error (text interpretation is also contained in the message).

=== <code>partner acknowledges receipt of virtual file '...'</code> ===
Speaks for itself: the file is sent and received correctly.

=== <code>OFTP2 session aborted: secure authentification required, no SECD message received by partner</code> ===
In case of OFTP2 secure authentification, the partner was requested to start the secure authentification mechanism. In this errornous case, he didn't. You may enable this configuration parameter: [[Seon Core configuration#allow unsecure OFTP 2 authentification]] or disable "use OFTP2 secure authentification" in the partner configuration.

=== <code>OFTP2 session aborted: secure authentification required (by ourself), no SECD message received by partner</code> ===
In case of OFTP2 secure authentification, the partner was requested to start the secure authentification mechanism. In this errornous case, he didn't. You may enable this configuration parameter: [[Seon Core configuration#allow unsecure OFTP 2 authentification]] or disable "use OFTP2 secure authentification" in the partner configuration.

=== <code>session aborted: invalid challange ('...' != '...')</code> ===
The OFTP2 security mechanism contains an exchange of a challenge (20 bytes of random data), which is signed by the remote side and returned. The signed data field is checked and the original data. Here, the original data wasn't returned, but another data package. The OFTP2 connection is closed then.

=== <code>session aborted: invalid challange (returncode of verifying command was not 0)</code> ===
The verification process of the OFTP2 secure authentification mechanism returned a value non-zero, so the authentification was unsuccessful.

=== <code>session aborted: secure authentification required (by ourself), no AURP message received by partner</code> ===
In the protocol for secure authentification of OFTP2, no regular message (in this case: AURP) was received. The OFTP session has been closed.

=== <code>rejected receive of file: invalid virtual filename '...'</code> ===
The receipt of the given virtual file was denied because it contains invalid characters in its name. You may re-configure the following option to make it work the next time: [[Seon Core configuration#illegal characters for virtual filenames|illegal characters for virtual filenames]]

=== <code>ISDN ERROR: disconnect</code> ===
The ISDN connect was closed unexpectedly. The reason why is contained in another log entry.

=== <code>successful poll to partner</code> ===
The physical connection to a partner was established successfully.

=== <code>unsuccessful poll to partner</code> ===
The physical connection to a partner was not established successfully.

=== <code>beginning transfer of file '...' (aka '...')</code> ===
The outgoing transfer of a file to the partner begins.

=== <code>sending file '...' (aka '...') failed: unable to open file</code> ===
The outgoing transfer of a file failed because the file could not be opened. Check existance and permissions.

=== <code>correct transfer of file '...' (aka '...') @ ... kB/s</code> ===
The file was transfered correctly (at a given overall throughput) and the remote side confirmed the correct transfer only by size of the file (not the content!).

=== <code>incorrect transfer of file '...' (aka '...'): ... (@ ... kB/s)</code> ===
The remote partner doesn't confirm that the given file was transfered correctly (mostly a problem of file size, restart position, fault in byte count).

=== <code>error connecting to partner: '...' (address: '...')</code> ===
When trying to connect to a partner via TCP/IP, the remote side didn't answer. The error message is created by the operating system running Seon, so it may vary from system to system.

=== <code>OFTP error: no SSRM received</code> ===
When connecting to a remote system, the OFTP protocol states that the called side has to send a message (SSRM) in order to state that it's an OFTP system. This special message was not sent, but something else was received. So, the physical connection was successfully made, but no OFTP server is answering.

=== <code>wrong remote password (transmitted: '...', Seon database value: '...')</code> ===
When connecting to a remote partner, the OFTP credentials (password & SSID) are transfered and checked. In this case, the expected value from the remote side doesn't match the locally stored. For easy administration, you may just copy & paste the values to the partner configuration (if you know what you are doing).

=== <code>wrong remote SSID (transmitted: '...', Seon database value: '...')</code> ===
When connecting to a remote partner, the OFTP credentials (password & SSID) are transfered and checked. In this case, the expected value from the remote side doesn't match the locally stored. For easy administration, you may just copy & paste the values to the partner configuration (if you know what you are doing).

=== <code>OFTP protocol error: command contained invalid data</code> ===
The remote side sent an invalid OFTP protocol message. This leads to an OFTP protocol violation and an abort of the connection.

=== <code>OFTP2 ERROR: secure authentification needed, but partner doesn't support this feature. Either set flag 'OFTP2 allow unsecure authentification' in basic configuration or inform partner.</code> ===
When awaiting OFTP2 secure authentification, the remote side doesn't support it. Either change the partner configuration or inform the partner to support it.

=== <code>OFTP2 is not supported in this version of Seon. Please upgrade Seon and get a new license.</code> ===
Stands for itself: in some special variants of Seon, the OFTP2 protocol is unsupported, but recognized. In order to support it, upgrade the Seon binary installation and the license.

== receive log ==
=== <code>restarting file transfer at position ... kB</code> ===
The file transfer begins at the documented position (not at the beginning of the file).

=== <code>receiving of file '...' aka '...' aborted by user at position ... kB of (approx.) ... kB</code> ===
During transfer of the file, a user interrupted the transfer by sending the process a signal so the transfer and connection will be aborted.

=== <code>receiving of file '...' aka '...' aborted at position ... kB of (approx.) ... kB: receive queue entry removed</code> ===
As a "last option", Seon supports the deletion of receive queue entries and recognizing in the active transfer process that "his" entry is removed during transfer. In this case, during updating the progress information, the receive process checks the existance of the receive queue entry. If not existant, the process aborts the file transfer and adds this message to the receive logs.

=== <code>OFTP ERROR: ESID received during filetransfer (normal termination)</code> ===
During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this case, no error code was given by the remote side.

=== <code>OFTP ERROR: ESID received during filetransfer (reason: ...)</code> ===
During receiving a file, the remote side wants to close the OFTP connection unexpectedly. In this casean error code was given by the remote side and the textual interpretation is listed in the message.

=== <code>OFTP ERROR: no valid OFTP header found during file transfer (but character '...')</code> ===
During a OFTP session, all commands are exchanged with a command header. In this errornous case, no known command header was found.

=== <code>unsuccessful connect try from ISDN number '...'</code> ===
A remote partner from the given ISDN number called Seon, but discontinued the OFTP protocol. If a partner has this number configured, the log entry is a receive log entry, if no partner was found, this entry is in the system logs.

=== <code>unsuccessful connect try from IP '...'</code> ===
A remote partner from the given IP address connected to Seon, but discontinued the OFTP protocol. If a partner has this IP address configured, the log entry is a receive log entry, if no partner was found, this entry is in the system logs.

=== <code>error in verifying data ...</code> ===
The verification process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in signing data ...</code> ===
The signing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in decrypting data</code> ===
The decrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in encrypting data</code> ===
The encrypting process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in compressing data</code> ===
The compression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in decompressing data</code> ===
The decompression process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

=== <code>error in hashing data</code> ===
The hashing process of OFTP2 data failed. The used command, returncode and output is appended in the log message.

Hashing is normally done internally only (called in Seon itself when a file is successfully received).

=== <code>error in compressing signed data</code> ===
The compression process of OFTP2 signed data failed. The used command, returncode and output is appended in the log message.

=== <code>error in extracting certificate from automatic certificate delivery</code> ===
During automatic certificate exchange of OFTP2, the remote certificate is extracted from a CMS package (a special file). During the extraction, an error occured.

=== <code>malformed remote certificate request: message was not signed, it was compressed or signed EERP request was given</code> ===
A wrong message was received for automatic certificate exchange. The special virtual filenames are reserved for automatic certificate exchange:
*<code>ODETTE_CERTIFICATE_REQUEST</code>
*<code>ODETTE_CERTIFICATE_DELIVER</code>
*<code>ODETTE_CRL_REQUEST</code>
*<code>ODETTE_CRL_DELIVER</code>

=== <code>fulfilled remote remote certificate request by adding my local public certificate to the send queue</code> ===
An automatic certificate exchange request is fulfilled by adding the local public certificate for this partner to the send queue in a special format.

=== <code>something went wrong during remote certificate request</code> ===
The automatic OFTP2 certificate exchange mechanism has a problem during reacting on a remote request. The complete error message, including command, returncode, parameters etc. is logged in another log message.

=== <code>successfully read in automatic certificate delivery</code> ===
The automatic certificate exchange of OFTP2 successfully imported a remote certificate.

=== <code>successfully handled incoming file '...' (file was ...)</code> ===
A file which was signed, compressed and/or encrypted was handled successfully (and is now available for further processing).

=== <code>Error loading CA file and/or directory</code> ===
When creating a SSL/TLS client or server, the CA file or CA directory could not be loaded. At least one of them must be defined and exist!

=== <code>Error setting default CA file and/or directory</code> ===
The default CA file or directory could not be set up by a SSL/TLS client or server of Seon. Check the configured values: [[Seon Core configuration#SSL.2FTLS_parameters|Seon Core configuration#SSL/TLS_parameters]]

=== <code>Error loading certificate from file '...': not in PEM format, file does not exist or invalid password supplied.</code> ===
The local client or server certificate could nbot be loaded. Check the file, format, access, the password (if set). Maybe it could be expired.

=== <code>Error loading certificate from file '...': not in PEM format or invalid password supplied.</code> ===
The local client or server certificate exists, but is not readable (invalid format or invalid password). Check the content.

=== <code>Error setting cipher list (no valid ciphers)</code> ===
TLS is not available. This should '''never''' happen!

=== <code>beginning transfer of file '...' (aka '...')</code> ===
The outgoing transfer of a file to the partner begins.

=== <code>NETWORK ERROR: disconnecting during transfer of file '...' at ... kB of (approx.) ... kB</code> ===
The network link was shut down during the receipt of the file at the given position.

=== <code>correct transfer of file '...' (description: '...') @ ... kB/s</code> ===
The file was transfered correctly (at a given overall throughput) and the remote side confirmed the correct transfer only by size of the file (not the content!).
The description is the OFTP2 UTF8 encoded description of the file, converted to the target character set configured at [[Seon Core configuration#local character set]]

=== <code>correct transfer of file '...' @ ... kB/s</code> ===
The file was transfered correctly (at a given overall throughput) and the remote side confirmed the correct transfer only by size of the file (not the content!).

=== <code>rejected receive of file: invalid virtual filename '...'</code> ===
The receipt of the given virtual file was denied because it contains invalid characters in its name. You may re-configure the following option to make it work the next time: [[Seon Core configuration#illegal characters for virtual filenames]]

=== <code>no space for file '...' (... kB) left on filesystem '...'</code> ===
The local filesystem for temporary and incoming data is not big enough to hold the file the partner wants to send. Make more space.

=== <code>file '...' already exists</code> ===
The local file already exists with the given filename in the incoming directory. Two options:
*Enable the date- and timestamp-appendix to the filename if you receive the same filename but you are sure they are different ones. This adds the stamps to the filename the partner sends. Parameter: [[Seon Core configuration#append timestamp to received file]]
*Enable overwrite of incoming files: [[Seon Core configuration#overwrite existing incoming files]]

=== <code>wrong local SFID (database value: '...', transmitted: '...')</code> ===
When receiving a file, Seon searches for partner entries in the defined partner table. If more than one entry matching the parameters password, SSID and SFID exist (both originator and destination; local and remote), the last entry will be used. If the found entry doesn't match the local SFID value, this error message will be added. You may change the local SFID in the partner's configuration in order to receive files from this remote system.

=== <code>wrong originator SFID (transmitted: '...', database value: '...')</code> ===
When receiving a file, Seon searches for partner entries in the defined partner table. If more than one entry matching the parameters password, SSID and SFID exist (both originator and destination; local and remote), the last entry will be used. If the found entry doesn't match the remote SFID value, this error message will be added. You may change the remote SFID in the partner's configuration in order to receive files from this remote system.

=== <code>session aborted: secure authentification required (by ourself), no AURP message received by partner</code> ===
In the protocol for secure authentification of OFTP2, no regular message (in this case: AURP) was received. The OFTP session has been closed.

=== <code>wrong remote SFID (transmitted: '...', no entry found for combination with SSID, password and SFID)</code> ===
If no entry exists for this remote SFID in the database, the file can not be received (because it cannot be assigned to any partner). Search and/or modify partner configuration.

=== <code>partner acknowledges receipt of virtual file '...'</code> ===
Speaks for itself: the file is sent and received correctly.

=== <code>OFTP protocol error: command contained invalid data</code> ===
The remote side sent an invalid OFTP protocol message. This leads to an OFTP protocol violation and an abort of the connection.

=== <code>wrong remote password (is: '...', should be: '...')</code> ===
When a remote partner is calling, the OFTP credentials (password & SSID) are transfered and checked. In this case, the expected value from the remote side doesn't match the locally stored. For easy administration, you may just copy & paste the values to the partner configuration (if you know what you are doing).

=== <code>partner unknown for SSID '...' and password '...'</code> ===
No partner at all was found for these OFTP credentials.

=== <code>OFTP ERROR: handled credit count is zero</code> ===
During OFTP handshake, the credit count is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

=== <code>OFTP ERROR: handled buffer size is zero</code> ===
During OFTP handshake, the buffer size is handled to the lowest value proposed by both partners. In this errornous case, the commited value is zero, which causes a protocol error.

=== <code>OFTP error: no valid SSID received</code> ===
The expected SSID was malformed. The OFTP connection was closed then.

=== <code>not updated cipher suite variable '...' of cipher suite '...' with new certificate delivery value because:</code> ===
During an automatic certificate update, Seon tries to insert new values for all configured cipher suite variables. If a partner uses a defined environment for special import rules (which is empty by default until to create it), all cipher suite variables are checked against that ruleset. If a rule forbids to import the new certificate delivery into this variable, it's displayed in the logs. This may have several reasons:
*this is wanted behaviour (mostly the case)
*the partner delivers the wrong certificate
*the partner updated his certificate policy and didn't inform you
In the last case, you should contact your partner and check the OFTP2 certificate settings in a bilateral way.

=== <code>TLS error: no valid X509 certificate given in TLS handshake by remote partner</code> ===
The TLS server process (the receive daemon process with the name "seonrd_tcpip_tls") got an incoming connection with an invalid, unknown, not-trusted or even without an X509v3 certificate at all. This can have many causes:
*the client doesn't provide any certificate at all
*the provided certificate is revoked (another log entry will show this)
*the provided certificate is issued by an unknown CA
*the provided certificate includes a CRL URL which is unknown until this connect (the CRL will be added to the CRL list and will be updated in the next time slice of the send queue daemon)

== system log ==
If no partner could be found for a specific receive or send log message, or if the message is that generic, the entry will be put into the system log.

=== <code>Remote CAPI timed out (possible reboot of device). Aborting session.</code> ===
As a feature request, a reboot or hangup of a RemoteCAPI device is now logged in the systems log for each active transfer. So, a possible reboot of a Brick during the transfer of multiple files results into multiple (the amount of open transfers) system log entries.

=== <code>license invalid</code> ===
Hopefully speaks for itself: the license or its content is invalid. Please obtain a valid license.

=== <code>CURL error x while fetching CRL from URL [...]</code> ===
Seon is able to download files via HTTP and HTTPS in order to maintain its CRLs as actual as possible. In addition, the TSL handler updates the list of trusted certificates via a download of a signed XML file from a [[Seon_Core_configuration#TSL_URL|configured]] URL. If anything goes wrong, the error is displayed then. You may then check the URL manually, or check the optional [[Seon_Core_configuration#Proxy|proxy settings]] which has the [[Seon HTTP Proxy support|documented behaviour]].

=== <code>Seon database successfully actualized</code> ===
Seon updates its database schema automatically, if it is [[Seon_Core_configuration#disable_database_schema_check|not deactivated]]. In addition, after an invocation of the automatic software update, Seon updates the database schema forced. Every time this happens, this log entry is added after a successful update.

=== <code>certificate verify error x</code> ===
During a TLS connect, the receive daemon checks the certificate chain of the incoming connection in order to ensure security. If anything goes wrong in this process, it's logged with detailed information here.

Since the partner information could not be found, this log entry resides in the system log.

=== <code>You must download a CRL for the CA of the certificate with the subject ...</code> ===
During an incoming connection via TLS, the partner certificate chain contains a certificate with an unknown CRL. This CRL (if any is given) is added automatically to the CRL list, but not actualized during this TLS session. The next timeslice the send queue daemon detects an old or invalid CRL, it actualizes it. So your partner with the given certificate chain should connect right after the import of the actualized CRL. If no CRL is available online, you have to upload it manually via the [[Seon 2 Core - CRL management]].

=== <code>successfully handled TSL XML content</code> ===
The TSL updating mechanism succeeded in importing and actualizing all trusted entities of the Odette Trusted Service List XML file.

More details on TSL can be found [[Seon 2 Core - TSL|here]].

=== <code>Seon TSL: trusting new certificate with subject ...</code> ===
Seon added successfully a trust to an entity of the TSL from Odette. The trusted entity subject is display here.

More details on TSL can be found [[Seon 2 Core - TSL|here]].

=== <code>TLS error during connect try from [IP or hostname]: peer did not return a certificate</code> ===
During the TLS handshake the error occured, that the TLS client (your communication partner) didn't return a TLS client certificate when he was requested to do so. You may lower your security settings in "Configuration" -> "TLS" by disabling the option "TLS server: check client certificate validity".

Seon Core configuration

2018-02-19T15:16:56Z

Admin: /* OFTP2 */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL Server: no").

==== 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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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.

==== Be absolute RFC restrictive? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rfc_conformity
|}

This optional parameter enables strict RFC conformity. This enables:
*Closure of TCP/IP connection after partner closes connection only (no pro-active socket closing)
*Sending CD message even if the partner doesn't want to (EFPA['N']). This unwanted "C"hange "D"irection request break OFTP sessions with (at least) Axway products.

==== Fetch EERPs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerp
|}

If enabled, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon plugin seonplugin scp upload

2018-01-30T09:45:21Z

Admin: /* Configuration */

== Purpose ==
For simple SCP/SFTP upload tasks, this plugin can transfer all job files to a target SCP/SFTP server.

== Configuration ==
The plugin must be configured on per-partner level and has no global configuration.

Configuration parameters are:
*Target server: server hostname or IP address of SSH server being addressed.
*SCP port: default port 22, but can be changed to any valid TCP/IP port on which the remote SSH server is listening.
*Target path: target path where to upload files to.
*Username: username which is being authentificated at the remote server.
*Password: plaintext password (if available) for the user being authentificated.
*Key file: absolute path to the SSH key file of the user being authentificated.
*Debug output: enable more debug output for analyzing transmission problems.
*Enable SCP mode: If SFTP is not available, plain SCP mode can be activated with this option. '''Beware:''' enabling this option disabled the support of directory structures on remote site.

The target directory may contain variables, which are resolved at runtime of the plugin. The list of usable variables is:
*%j: job number
*%d: day of job creation (two digits)
*%m: month of job creation (two digits)
*%Y: year of job creation (four digits)
*%H: hour of job creation (two digits, 24h format)
*%M: minute of job creation (two digits)
*%S: second of job creation (two digits)
*%D: job direction (either "<code>incoming</code>" or "<code>outgoing</code>")
*%r: recipient partner shortname
*%s: sender partner shortname
*%t: recipient location
*%u: recipient department
*%v: recipient name
*%w: recipient last name
*%x: recipient address code
*%g: sender location
*%h: sender department
*%i: sender name
*%J: sender last name
*%k: sender address code
*%e: depending on the job direction, the partner shortname of the external communication partner
**for incoming jobs: sender partner shortname (see "<code>%s</code>")
**job outgoing (or undefined job directions): recipient partner shortname (see "<code>%r</code>")
*%a: ENGDAT Message Reference [UNH0062] (if given, otherwise empty)
*%b: ENGDAT Document Number [MID1004] (if given, otherwise empty)

Since Seon Build 20180129 the following variables are available:
*%p: sender partner's event parameter
*%P: recipient partner's event parameter
*%Q: depending on the job direction, the event parameter of the external communication partner:
**incoming jobs: sender's event parameter (= "<code>%p</code>")
**outgoing jobs or undefined job direction: recipient's company shortname (= "<code>%P</code>")

== Behaviour ==
The plugin loops over all files of the job and handles them separately (one after another). For each file, the plugin
*Connects to the SSH server
*Uploads the file to the target directory with its absolute filename. The local filename is being analyzed if a "job directory" exists for this job. If it exists, the file is being translated into a path without the job directory, so subdirectories at remote side are possible (i.e. when extracting a ZIP archive with subdirectories before transmission). If no job directory definition exists, the basename of the file is being used.

[[Category:Plugins]]

Seon plugin seonplugin filemove

2018-01-30T09:44:22Z

Admin: /* Configuration */

[[Category:Plugins]]
== Puropose ==

Move all files of a job into a defined target directory. The default assumption is:
*<[[Seon Core configuration#data_incoming_directory|data incoming directory]]>/<jobnummer> for incoming jobs
*<[[Seon Core configuration#data_outgoing_directory|data_outgoing_directory]]>/<jobnummer> for outgoing or jobs of unknown type

== Requirements ==

* File <code>/etc/seon.conf</code> or configuration file pointed to in environment variable <code>$Seon_CFGFILE</code>. Via the used configuration file, the information are retrieved used by the plugin (such as default configuration etc.).

== Configuration ==

The target directory can be set up to contain variables. These variables are exchanged by runtime information of the Seon job, in which context the plugin is run.

The usable variables are:
*%j: job number
*%d: day of job creation (two digits)
*%m: month of job creation (two digits)
*%Y: year of job creation (four digits)
*%H: hour of job creation (two digits, 24h format)
*%M: minute of job creation (two digits)
*%S: second of job creation (two digits)
*%D: job direction: "<code>incoming</code>" or "<code>outgoing</code>"
*%r: recipient partner shortname
*%s: sender partner shortname
*%t: recipient location name
*%u: recipient department name
*%v: recipient first name
*%w: recipient family name
*%x: recipient address code
*%g: sender location name
*%h: sender department name
*%i: sender first name
*%J: sender family name
*%k: sender address code

Since Seon 3 Build 20140227 the following variable is available:
*%e: depending on the job direction, the company shortname of the external communication partner:
**incoming jobs: sender's company shortname (= "<code>%s</code>")
**outgoing jobs or undefined job direction: recipient's company shortname (= "<code>%r</code>")

Since Seon 3 Build 201508117 the following variables are available:
*%a: ENGDAT Message Reference [UNH0062] (if available, otherwise empty)
*%b: ENGDAT Document Number [MID1004] (if available, otherwise empty)

Since Seon 3 Build 20160407 the following variables are available:
*%y: recipient's username ("unknown" if empty)
*%l: sender's username ("unknown" if empty)

Since Seon Build 20180129 the following variables are available:
*%p: sender partner's event parameter
*%P: recipient partner's event parameter
*%Q: depending on the job direction, the event parameter of the external communication partner:
**incoming jobs: sender's event parameter (= "<code>%p</code>")
**outgoing jobs or undefined job direction: recipient's company shortname (= "<code>%P</code>")

== Examples ==
All examples rely on an outgoing job 76 from and to the company "c-works"
/opt/seon/tmp/%r/seon_job_%j/
renders to:
/opt/seon/tmp/c-works/seon_job_76

----
/opt/seon/tmp/%D/%r/%j
renders to:
/opt/seon/tmp/outgoing/c-works/76

== Return values ==
*0: everything OK
*1: Configfile (/etc/seon.conf or value of environment variable "<code>Seon_CFGFILE</code>", read in as file) cannot be found or database unavailable.
*2: License error
*3: XML parameter file cannot be parsed
*4: Files cannot be moved

Seon plugin seonplugin filecopy

2017-11-03T07:41:22Z

Admin:

[[Category:Plugins]]
== Puropose ==

Copy all files of a job into a defined target directory. The default assumption is:
*<[[Seon Core configuration#data_incoming_directory|data incoming directory]]>/<jobnummer> for incoming jobs
*<[[Seon Core configuration#data_outgoing_directory|data_outgoing_directory]]>/<jobnummer> for outgoing or jobs of unknown type

== Requirements ==

* File <code>/etc/seon.conf</code> or configuration file pointed to in environment variable <code>$Seon_CFGFILE</code>. Via the used configuration file, the information are retrieved used by the plugin (such as default configuration etc.).

== Configuration ==

The target filename can be set up to contain variables. These variables are exchanged by runtime information of the Seon job, in which context the plugin is run.

The usable variables are:
*%j: job number
*%d: day of job creation (two digits)
*%m: month of job creation (two digits)
*%Y: year of job creation (four digits)
*%H: hour of job creation (two digits, 24h format)
*%M: minute of job creation (two digits)
*%S: second of job creation (two digits)
*%D: job direction: "<code>incoming</code>" or "<code>outgoing</code>"
*%r: recipient partner shortname
*%s: sender partner shortname
*%t: recipient location name
*%u: recipient department name
*%v: recipient first name
*%w: recipient family name
*%x: recipient address code
*%g: sender location name
*%h: sender department name
*%i: sender first name
*%J: sender family name
*%k: sender address code

Since Seon 3 Build 20140227 the following variable is available:
*%e: depending on the job direction, the company shortname of the external communication partner:
**incoming jobs: sender's company shortname (= "<code>%s</code>")
**outgoing jobs or undefined job direction: recipient's company shortname (= "<code>%r</code>")

Since Seon 3 Build 201508117 the following variables are available:
*%a: ENGDAT Message Reference [UNH0062] (if available, otherwise empty)
*%b: ENGDAT Document Number [MID1004] (if available, otherwise empty)

Since Seon 3 Build 20160407 the following variables are available:
*%y: recipient's username ("unknown" if empty)
*%l: sender's username ("unknown" if empty)

== Examples ==
All examples rely on an outgoing job 76 from and to the company "c-works"
/opt/seon/tmp/%r/seon_job_%j/
renders to:
/opt/seon/tmp/c-works/seon_job_76

----
/opt/seon/tmp/%D/%r/%j
renders to:
/opt/seon/tmp/outgoing/c-works/76

== Return values ==
*0: everything OK
*1: Configfile (/etc/seon.conf or value of environment variable "<code>Seon_CFGFILE</code>", read in as file) cannot be found or database unavailable.
*2: License error
*3: XML parameter file cannot be parsed
*4: Files cannot be copied

Seon plugin seonplugin filemove

2017-11-03T07:36:51Z

Admin:

[[Category:Plugins]]
== Puropose ==

Move all files of a job into a defined target directory. The default assumption is:
*<[[Seon Core configuration#data_incoming_directory|data incoming directory]]>/<jobnummer> for incoming jobs
*<[[Seon Core configuration#data_outgoing_directory|data_outgoing_directory]]>/<jobnummer> for outgoing or jobs of unknown type

== Requirements ==

* File <code>/etc/seon.conf</code> or configuration file pointed to in environment variable <code>$Seon_CFGFILE</code>. Via the used configuration file, the information are retrieved used by the plugin (such as default configuration etc.).

== Configuration ==

The target directory can be set up to contain variables. These variables are exchanged by runtime information of the Seon job, in which context the plugin is run.

The usable variables are:
*%j: job number
*%d: day of job creation (two digits)
*%m: month of job creation (two digits)
*%Y: year of job creation (four digits)
*%H: hour of job creation (two digits, 24h format)
*%M: minute of job creation (two digits)
*%S: second of job creation (two digits)
*%D: job direction: "<code>incoming</code>" or "<code>outgoing</code>"
*%r: recipient partner shortname
*%s: sender partner shortname
*%t: recipient location name
*%u: recipient department name
*%v: recipient first name
*%w: recipient family name
*%x: recipient address code
*%g: sender location name
*%h: sender department name
*%i: sender first name
*%J: sender family name
*%k: sender address code

Since Seon 3 Build 20140227 the following variable is available:
*%e: depending on the job direction, the company shortname of the external communication partner:
**incoming jobs: sender's company shortname (= "<code>%s</code>")
**outgoing jobs or undefined job direction: recipient's company shortname (= "<code>%r</code>")

Since Seon 3 Build 201508117 the following variables are available:
*%a: ENGDAT Message Reference [UNH0062] (if available, otherwise empty)
*%b: ENGDAT Document Number [MID1004] (if available, otherwise empty)

Since Seon 3 Build 20160407 the following variables are available:
*%y: recipient's username ("unknown" if empty)
*%l: sender's username ("unknown" if empty)

== Examples ==
All examples rely on an outgoing job 76 from and to the company "c-works"
/opt/seon/tmp/%r/seon_job_%j/
renders to:
/opt/seon/tmp/c-works/seon_job_76

----
/opt/seon/tmp/%D/%r/%j
renders to:
/opt/seon/tmp/outgoing/c-works/76

== Return values ==
*0: everything OK
*1: Configfile (/etc/seon.conf or value of environment variable "<code>Seon_CFGFILE</code>", read in as file) cannot be found or database unavailable.
*2: License error
*3: XML parameter file cannot be parsed
*4: Files cannot be moved

Seon plugin seonplugin filemove

2017-11-03T07:35:35Z

Admin:

[[Category:Plugins]]
== Puropose ==

Move all files of a job into a defined target directory. The default assumption is:
*<[[Seon Core configuration#data_incoming_directory|data incoming directory]]>/<jobnummer> for incoming jobs
*<[[Seon Core configuration#data_outgoing_directory|data_outgoing_directory]]>/<jobnummer> for outgoing or jobs of unknown type

== Requirements ==

* File <code>/etc/seon.conf</code> or configuration file pointed to in environment variable <code>$Seon_CFGFILE</code>. Via the used configuration file, the information are retrieved used by the plugin (such as default configuration etc.).

== Configuration ==

The target filename can be set up to contain variables. These variables are exchanged by runtime information of the Seon job, in which context the plugin is run.

The usable variables are:
*%j: job number
*%d: day of job creation (two digits)
*%m: month of job creation (two digits)
*%Y: year of job creation (four digits)
*%H: hour of job creation (two digits, 24h format)
*%M: minute of job creation (two digits)
*%S: second of job creation (two digits)
*%D: job direction: "<code>incoming</code>" or "<code>outgoing</code>"
*%r: recipient partner shortname
*%s: sender partner shortname
*%t: recipient location name
*%u: recipient department name
*%v: recipient first name
*%w: recipient family name
*%x: recipient address code
*%g: sender location name
*%h: sender department name
*%i: sender first name
*%J: sender family name
*%k: sender address code

Since Seon 3 Build 20140227 the following variable is available:
*%e: depending on the job direction, the company shortname of the external communication partner:
**incoming jobs: sender's company shortname (= "<code>%s</code>")
**outgoing jobs or undefined job direction: recipient's company shortname (= "<code>%r</code>")

Since Seon 3 Build 201508117 the following variables are available:
*%a: ENGDAT Message Reference [UNH0062] (if available, otherwise empty)
*%b: ENGDAT Document Number [MID1004] (if available, otherwise empty)

Since Seon 3 Build 20160407 the following variables are available:
*%y: recipient's username ("unknown" if empty)
*%l: sender's username ("unknown" if empty)

== Examples ==
All examples rely on an outgoing job 76 from and to the company "c-works"
/opt/seon/tmp/%r/seon_job_%j/
renders to:
/opt/seon/tmp/c-works/seon_job_76

----
/opt/seon/tmp/%D/%r/%j
renders to:
/opt/seon/tmp/outgoing/c-works/76

== Return values ==
*0: everything OK
*1: Configfile (/etc/seon.conf or value of environment variable "<code>Seon_CFGFILE</code>", read in as file) cannot be found or database unavailable.
*2: License error
*3: XML parameter file cannot be parsed
*4: Files cannot be moved

Seon plugin seonplugin ftp upload

2017-09-15T11:24:36Z

Admin:

[[Category:Plugins]]
== Purpose ==
For simple FTP upload tasks, this plugin can transfer all job files to a target FTP server

== Configuration ==
The plugin must be configured on per-partner level and has no global configuration.

Configuration parameters are:
*Server: server incl. protocol being used. Supported protocols are (at least, but not limited to) "ftp".
**Syntax: <nowiki>ftp://<ip or hostname></nowiki>
**Traling slashed are being eliminated automatically, but you should not configure these.
**Example: <code>ftp://192.168.1.2</code> or <code>ftp://ftp.myserver.com</code>
*Path: target path where to upload files to.
**Syntax: /<pathToUpload>
**Example: <code>/upload</code>
**Missing leading slashes will be appended automatically, but you should configure this.
**Trailing slashes will be removed automatically, but you should not configure these.
*''(optionally)'' Username: The username used for login to the server.
*''(optionally)'' Password: The password used for login to the server.
*''(optionally)'' Verbose output: all protocol specific communication (incoming and outgoing) will be logged.
*''(optionally)'' Disable proxy: no proxy will be used, even is there is one configured elsewhere in the system.
*''(optionally)'' Force HTTP 1.0 for proxy communication: Bugfix for several proxy systems which support HTTP 1.0 (i.e. for FTP transfers), but don't support the default HTTP 1.1 behaviour.

== Behaviour ==
The plugin loops over all files of the job and handles them separately (one after another). For each file, the plugin
*connects to the FTP server
*uploads the file to the target directory with the temporary name with a leading dot ("<code>.</code>") in front of the virtual filename
*after upload, the file is being renamed to the virtual filename without the leading dot.

Since the plugin has no specific configuration for proxies, the plugin uses the system-wide proxy settings of your system (see [[Seon HTTP Proxy support]]).

When using a FTP proxy, you have to define an environment variable, either:
*ftp_proxy
*all_proxy
The syntax of these environment variables is the same as the one for HTTP (described [[Seon HTTP Proxy support|here]]).

== Protocol support ==
The plugin is compiled with the following contained protocols. For details, please refer to the CURL library:
* DICT
* FILE
* FTP
* FTPS
* GOPHER
* HTTP
* HTTPS
* IMAP
* IMAPS
* POP3
* POP3S
* RTSP
* SCP
* SFTP
* SMB
* SMBS
* SMTP
* SMTPS
* TELNET
* TFTP

Seon Core environment variables

2017-08-25T08:13:00Z

Admin:

Environment variables are created and/or set by all Seon binaries, which values are based on the configuration of Seon. These variables are:
*<code>Seon_CFGFILE</code>: [[Seon Core main configuration file|Seon main configuration file (absolute path information)]]
*<code>Seon_IN_DIR</code>: [[Seon_Core_configuration#data_incoming_directory|incoming data directory]]
*<code>Seon_OUT_DIR</code>: [[Seon_Core_configuration#data_outgoing_directory|outgoing data directory]]
*<code>Seon_TMP_DIR</code>: [[Seon_Core_configuration#temporary_directory|temporary data directory]]
*<code>Seon_BIN_DIR</code>: [[Seon_Core_configuration#binary_installation_directory|binary program directory]]
*<code>Seon_SCRIPT_DIR</code>: [[Seon_Core_configuration#script_installation_directory|script installation directory]]
*<code>Seon_BACKUP_DIR</code>: [[Seon_Core_configuration#database_backup_directory|backup directory]]
*<code>RAND_FILE</code>: [[Seon_Core_configuration#Entropy_file_for_random_data|entropy file for OFTP2 needs]]
*<code>OPENSSL_BIN</code>: [[Seon_Core_configuration#absolute_path_to_.27openssl.27|absolute path to openSSL binary]]
*<code>RRDTOOL_BIN</code>: [[Seon_Core_configuration#absolute_path_to_.27rrdtool.27|absolute path to RRDtools binary]]
*<code>RRDB_DATAPATH</code>: [[Seon_Core_configuration#RRDB_data_path|RRD data path]]
*<code>Seon_WEBGUI_DIR</code>: web interface installation directory
*<code>CA_FILE</code>: [[Seon_Core_configuration#root_certificate_file_.26_root_certificate_path|configured absolute path to the root certificate file]]
*<code>CA_PATH</code>: [[Seon_Core_configuration#root_certificate_file_.26_root_certificate_path|configured absolute path to the root certificate directory]]

The following environment variables are extracted form the global Seon configuration file (default: <code>/etc/seon.conf</code>):
*<code>Seon_DB_HOST</code>
*<code>Seon_DB_USER</code>
*<code>Seon_DB_PWD</code>
*<code>Seon_DB_NAME</code>
*<code>Seon_DB_SOCKET</code>
*<code>Seon_DB_PORT</code>
*<code>Seon_DB_TYPE</code>: either "<code>mysql</code>", "<code>DB2</code>" or "<code>sqlite3</code>"

All processes started by Seon (event scripts, plugins, etc.) have access to these environment variables.
The environment variable "<code>Seon_CFGFILE</code>" points to the absolute path to the Seon main configuration file. This has two effects:
*you may start Seon programs in a shell where this variable is set without using the parameter "<code>-C</code>" for all binaries (because the environment variable points to the correct position of the configfile)
*all subsequent processes started by Seon (like event scripts) don't have to bother about the given configfile (like plugins of Seon Enterprise).

== Database performance benchmarking ==
Available in Seon 3 Core, an environment variable can be set to log all database access timing information into that given file:
Seon_DB_BENCHMARKLOG
You can set this variable to an absolute filename where Seon logs all innformation (example: "ksh" or "bash"):
export Seon_DB_BENCHMARKLOG=/tmp/db2perf.log
This file logs the connect and query time for every single database access, resulting in a fast growing file. The content if this file looks like this (using DB2 database abstraction layer, others like MySQL start with "<code>MySQL</code>"):
<pre>
DB2 connect: 0.052482 seconds
DB2 SQL query: 0.126631 seconds
DB2 connect: 0.032447 seconds
DB2 SQL query: 0.004983 seconds
DB2 connect: 0.029555 seconds
DB2 SQL query: 0.004500 seconds
DB2 connect: 0.031012 seconds
DB2 SQL query: 0.001324 seconds
</pre>

Seon Core configuration

2017-08-22T08:12:51Z

Admin: /* Seon Enterprise - Basic */

== Accessing configuration ==
Seon 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 Seon web interface includes an entry in the left menu for the core configuration. Its name is "<code>Configuration</code>". The configuration web interface is segmentated into the following blocks:
*TCP/IP
*SSL/TLS
*ISDN
*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]<code>configuration</code>" (default: "<code>seon_configuration</code>") contains two columns:
*name
*value
The column "<code>name</code>" is the name of the configuration which is affected.

The column "<code>value</code>" reflects the configuration value, limited to 255 characters.

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

== Configurable values ==
Seon 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.

[[Image:Config-tcpip.png]]

==== TCP/IP port of OFTP server ====
{|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>".

==== TCP/IP port of OFTP server (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.

==== TCP/IP port of Seon debug daemon ====
{|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 Seon 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 ====
{|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.

==== TCP/IP OFTP maximum buffersize ====
{|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.

==== TCP/IP OFTP maximum credit count ====
{|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.

----

=== 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.

[[Image:Config-ssl.png]]

==== 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.

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

==== root certificate file & root certificate path ====
{|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.

These variables are (if set) available to processes started by Seon via the environment variables "<code>CA_FILE</code>" and "<code>CA_PATH</code>" (see also [[Seon Core environment variables]]).

==== Diffie-Hellman parameter files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || dh128_file, dh256_file, dh512_file & dh1024_file
|}

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

==== TLS server: check client certificate validity ====
{|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, Seon will override a wrong purpose of the server certificate (such as "SSL Server: no").

==== 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 Seon 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 Seon 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, Seon 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.

==== 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 [[Seon_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. Seon 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 ====
{|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 Seon.

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, Seon will never complain about insecure TLS cipher usage in connection logs (despite Seon SmartProxy logs, since the Seon SmartProxy doesn't support this insecurity "feature").

==== 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.

----

=== Proxy ===
Seon 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 [[Seon 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 [[Seon 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 Seon 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".

==== Proxy username ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_username
|}

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

==== Proxy password ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || proxy_password
|}

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

==== Proxy type ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon proxy? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_proxy_enabled
|}

If you want to use Seon proxy or Seon OFTP2 SmartProxy, enable this checkbox. Please refer to [[Seon Proxy|Seon Proxy]] and [[Seon SmartProxy|Seon OFTP2 SmartProxy]] for more detailled information.
----

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

[[Image:Config-isdn.png]]

==== ISDN OFTP maximum buffersize ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_buffersize_isdn
|}

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

==== ISDN OFTP maximum credit count ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp_default_creditcount_isdn
|}

Same as the TCP/IP maximum credit count, this numeric value reflects the number of
OFTP data exchange buffers before a little handshake will be done by the OFTP protocol. For configurations with problemous partners like old Seeburger products, please use 20 as credit count.

==== ISDN force confirmation of each DATA_B3 package ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_force_confirm_each_data_b3
|}

In ISDN, all data is transfered in 128 byte blocks, so-called "DATA B3 packages". Each package has to be confirmed by the remote partner, so the ISDN subsystem can remove unneeded memory and do some cleanup. If the remote partner doesn't confirm all DATA B3 packages, you may force him do so by enabling this checkbox. The ISDN subsystem sets a special flag in the DATA B3 package so nearly every ISDN counter system should confirm the receipt of that package, even if it's not explicitely implemented.

==== maximum amount of unconfirmed CAPI DATA B3 packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || max_capi_sliding_window_size
|}

Different ISDN systems support a different amount of unconfirmed DATA B3 packages (see above). The normal CAPI standard of seven (7) unconfirmed DATA packages should never be reached, so you should be one or two packages lower than that limit in order to achieve the maximum of transport speed. Special CAPI ISDN implementations support more that the standard of seven packages, i.e. Bintec Bricks (they support up to 15). It doesn't make any sense to use that amount of unconfirmed data buffers, it doesn't speed up the transfer any more. If you receive CAPI timeouts, you should lower this amount of packages.

==== Don't wait for DATA B3 confirmation packages ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || isdn_dont_wait_for_data_b3_conf
|}

If your ISDN system supports an extreme data throughput and nearly unlimited amount of unconfirmed DATA B3 packages lying around, you may ignore and don't wait for DATA B3 confirmation packages by enabling this '''highly unsupported''' feature. If you encounter line disconnects, disable this feature!

Background: In "''normal''" ISDN wildlife, each DATA B3 indication package indicates that other DATA B3 confirmation packages (up to this point of protocol transfer time) have been received. TIf you transfer very little files, it may be annoying waiting for each single data confirm package, you could send the file "as is" and wait for the OFTP protocol confirmation instead of waiting for the ISDN subsystem to acknowledge each single small piece of data sent. In some cases it's helpful, in most it's not! '''Just keep the setting disabled as long as you know exactly what you are doing!'''

==== enable CAPI keep-alive monitor ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || capi_check_alive_monitor
|}

In order to use a Brick R4x00 or above, you have to enable this feature. Also, if you don't want to watch for Seon after a reboot of the Brick device, enable this feature.
Activating this feature, Seon checks every defined controller every 60 seconds for availability. If a controller is inaccessible, it tries the connectivity again after 60 seconds.
---

=== 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.

[[Image:Config-odette.png]]

==== my default SSID, my default SFID, my default OFTP password, change every partner entry ====
{|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
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 Seon know where to find directories and files, these values have to be defined.

[[Image:Config-directories.png]]
==== data 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.
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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || outgoing_directory
|}

This directory will be used by Seon Webaccess (which is part of Seon Enterprise) for outgoing jobs when initiating a send job. The plugins
[[Seon plugin seonplugin_filemove|seonplugin_filemove]] and [[Seon plugin seonplugin_filecopy|seonplugin_filecopy]] can refer to this directory by a configuration value.

==== temporary 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 [[Seon 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.

==== database backup directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || backup_directory
|}

If you want to use the Seon backup mechanism, you need to define a directory where the SQL dump files will be stored. This directory is needed for the scripts "seonbackup" and "seonrestore".

==== binary installation directory ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || bin_directory
|}

This directory points to your binary installation of Seon. 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || script_directory
|}

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

==== absolute path to 'openssl' ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || tcp_timeout
|}
''DB configuration name: openssl_binary_path''

Seon uses openSSL as basis for all OFTP 2 file security functions. The configured binary must exist and be executable for the user running Seon 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' ====
{|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 Seon distribution contains a pre-compiled version which works within Seon. If the file configured isn't executable, statistics are disabled. The program is used to create databases within Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rrdb_datapath
|}

In this path, Seon creates, stores, modifies and searches the files for statistics. The directory must be writable by the user running Seon. 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 ====
{|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.

==== 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 Seon. The file itself (if it exists) must also be writable by the user running Seon.

==== 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/seon/tmp/sql_lost_messages</code>":
/opt/seon/tmp/sql_lost_messages.20090307

/opt/seon/tmp/sql_lost_messages.20090130

==== MySQL dump tool ====
{|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 Seon backup script for doing its job.

==== send test file ====
If configured correctly, Seon displays a link [[Image:System-software-update.gif]] for test purposes for a partner. A given file can be sent with a given virtual filename to that partner for checking the OFTP connection.

=== Events ===
[[Image:Config-events.png]]

First some words about the global behaviour of scripts:

==== event script usage ====
Every time the configuration of Seon 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 [[Seon_Core_configuration#binary_installation_directory|here]]). These presets could be used for easy resetting the script configuration to either Seon Enterprise (Lite) and/or Seon 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 ====
{|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.

==== 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.

==== 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. Seon 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 [[Seon Core configuration#end send script|end send script]] script.

==== 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.

==== 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.

==== 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.

==== 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.

==== send queue entry 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.

==== debug daemon log script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_log_script
|}

After a debug log has been written, [[Seon_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 ====
{|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.

==== Enable automatic update mechanism & Seon automatic software update event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || run_updates_automatically & seonupdate_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>SEON-UPDATE</code>". This is normally a program of the Seon distribution in order to update the installation via signed files. This program changes its user context to the configured user (see: [[Seon_Core_configuration#run_Seon_update_program_as_user|run Seon update program as user]]).

==== Seon automatic update post event ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configEventUpdatePost
|}

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

==== enqueue post-script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || enqueue_post_script
|}

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

==== Seon API proxy system log event script ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_proxy_systemlog_script
|}

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

=== Daemon parameters ===
The behaviour of all binaries and Seon programs can be influenced here.

[[Image:Config-daemon.png]]

==== run Seon programs as user ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || running_as_user
|}

When starting as user "<code>root</code>", all Seon 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 Seon, that is has a home directory which is accessible and writable and that this user has a shell configured which is runnable!'''

==== run Seon update program 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.

==== time slice for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_sleep_time
|}

The send queue daemon „seonsqd“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_sleep_time
|}

The receiving daemon „seonrd2“ 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 ====
{|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 [[Seon 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.

===== 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 ====
{|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).

==== overwrite existing incoming files ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonrd_overwrite
|}

If the incoming file exists in the "[[Seon 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).

==== default maximum send tries for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_max_tries
|}

The send queue daemon "seonsqd2" 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).

==== additional sleeping time for send queue daemon & additional sleeping time factor for send queue daemon ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_add_time & seonsqd_add_time_factor
|}

You can influence the time the send queue daemon „seonsqd2“ 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || progressbar_refresh
|}

Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|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.

==== delete temporary created files of OFTP 2 session ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftpv2_delete_temp_created_files
|}

Seon 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 Seon automatically, but you may also want to keep them for later archiving.

==== local character set ====
{|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: "seon_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 Seon. 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || unblock_blocked_sendqueue_entries_after_poll
|}

If enabled, this options lets the Seon 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? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonDisableFilerestart
|}

If enabled, Seon 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
|}

Seon 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 ====
{|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.

==== send queue 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".

==== enable statistics & RRDtools refresh time ====
{|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 Seon (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>"

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

==== Append destination SFID to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendSFIDRec
|}

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 PID of receive process to received file ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonAppendPIDRec
|}

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.

==== OFTPv1: Don't wait for EERP message ====
{|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:
*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? ====
{|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 Seon 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 Seon send queue daemon unblock all blocked entries on startup? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonsqd_unblock_on_start
|}

The default behaviour of Seon 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.

==== Enable offline handling of OFTP2 transfered files? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_filehandling
|}

Since version 2007-12-01, Seon is able to handle OFTP 2 offline, so the security features of OFTP2 can be used in an insecure network segment. Enable this feature in order to use [[seon_oftp2_offlinehandling]] to handle the received files semi-manually.

===== pre-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_pre_script
|}

This script is executed before the handling process starts. It may be used to transfer the file itself from one location to another. Parameters are documented [[Seon oftp2 offlinehandling#pre-script|here]]

===== post-script for offline tool =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || offline_oftp2_post_script
|}

This script is executed after the handling process starts. It may be used to clean up the environment. Parameters are documented [[Seon oftp2 offlinehandling#post-script|here]]

===== remove successfully handled offline OFTP2 file entries =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || oftp2_offlinefile_remove_entries
|}

If this flag is enabled, successfully handled files will be removed from the list of received files. It's highly recommended to turn this flag on.

==== Identify remote partner via incoming medium, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || partner_search_medium
|}

When enabled, the Seon 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, Seon 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 "[[Seon_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>seonsqd</code>": Reset all files in status "taken by send queue" and "send in progress" to "new in queue"
*receive queue daemon "<code>seonrd</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 [[Seon_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.

==== Be absolute RFC restrictive? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || rfc_conformity
|}

This optional parameter enables strict RFC conformity. This enables:
*Closure of TCP/IP connection after partner closes connection only (no pro-active socket closing)
*Sending CD message even if the partner doesn't want to (EFPA['N']). This unwanted "C"hange "D"irection request break OFTP sessions with (at least) Axway products.

==== Fetch EERPs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerp
|}

If enabled, Seon'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 Seon send queue daemon when trying to fetch one or more EERP messages of a partner.

==== Fetch EERPs for ISDN partners, too? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || configDaemonFetchEerpIsdnToo
|}

Since 2016-11-28, by default OS4X only fetches EERPs for TCP/IP and TLS partners (before this release, also ISDN partners are being contacted for missing EERPs). If you activate this checkbox, also ISDN partners are being contacted for missing EERPs (files in the send queue with status "waiting for remote acknowledge). '''Be aware that in combination with the send queue daemon time slice parameter and the EERP timeslice factor, the send queue daemons initiates outgoing sessions which can generate connection costs!'''

==== 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.

==== 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, Seon 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>

----

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

[[Image:Config-Enterprise.png]]

==== Seon Enterprise - Basic ====

===== is Seon Enterprise installed? =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_enterprise
|}

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

===== default country =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || default_country_idx
|}

When creating a new company entry in the Seon partner database and using Seon 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 Seon 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 Seon 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:''' || seon_enterprise_other_protocols
|}

In order to enable other protocols in addition to OFTP and OFTP2 (which is handled via the Seon 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 [[Seon Enterprise - other protocols]] for more details about administration.

===== define own company =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seon_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 [[Seon_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 [[Seon_Core_configuration#data_outgoing_directory|outgoing directory path]] of "<code>/opt/seon/outgoing</code>"):
*definition: <code>seon-dirscanner-enterprise-job-</code>
*resulting path (for job 123): <code>/opt/seon/outgoing/seon-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 Seon Core will abort jobs if sending is errornous.

===== 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 Seon 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 Seon Core and Seon 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>".

==== Seon Enterprise - Webaccess ====

===== 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 Seon 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 Seon Webaccess in the top right corner. Absolute or relative URLs are supported.

===== Encrypt Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}

If required, Seon Webaccess can encrypt the session information in the database via AES256 algorithm and hashed via SHA1 hashing algorithm.

===== Compress Webaccess session information =====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}

If required, Seon Webaccess can compress the session information in the database via bzip2 algorithm.

===== 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 Seon 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 Seon 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 Seon 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
|}
Seon 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
|}
Seon 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 Seon 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.

==== Seon 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? ====
{|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 Seon offline daemon.

===== pre-script for offline tool =====
{|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 Seon offline handler before the offline handler processes the file. This is normally a transferer script.

===== post-script for offline tool =====
{|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 Seon offline handler after the offline handler has processed a file. This is normally a cleanup script.

===== remove successfully handled offline OFTP2 file entries =====
{|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, Seon 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 "[[Seon_Core_binaries#seoneq_.2F_seoneq2|seoneq]]" with all parameters given in the "[[Seon_Core_event_scripts#end_receive_script|end receive script]]".

==== 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, Seon deletes this original file for security reasons from the filesystem. '''WARNING: no undo or recovery is available!'''
----

==== OFTP2 security policy ====
Starting with Seon 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 Seon 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.

=== Logging ===
Logging enables Seon 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 [[Seon Directory Scanner|directory scanner]] logs every single execution script based on the found file.

==== Enable continuous write of Seon debug daemon output? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seondebugd_continuous_write
|}

When enabling this feature, the Seon 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 Seon 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:
*Seon debug daemon is running
*The temporary directory is accessible and writable by the Seon debug daemon
*The event "debug daemon log event" does not change the filename prefix "seon-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 "Seon-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 "Seon-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 "Seon-LOGFILE-<counter>" where "<counter" is an incremented number, starting with 1 (one). The comment of the automatically enqueued files is "<code>Seon logs - automatically enqueued via administrative web interface</code>".

==== Absolute path to logfile of Seon API ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_logfile
|}

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

==== Seon API loglevel ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || seonapi_loglevel
|}

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

==== Suppress unsuccessful connect log entries? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

----

=== GUI ===
The GUI offers some parameters which influence the default behaviour.

[[Image:ConfigGui.png]]

==== Send signals to running processes ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 Seon daemons do, or if the webserver user is not privileged to send signals to running Seon 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || disable_PID_checks
|}

The Seonapi can check if daemons which should run with a given process ID really exist. If they don't exist, the Seonapi 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ISDN, 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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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
**ISDN
**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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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 ====
{|style="background:white"
|- style="background:lightgrey;"
| '''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.

=== 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 Seon. These configuration value names are:
*<code>seonclientd_port</code>: TCP/IP port of the program Seon client daemon
*<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.

Seon Enterprise - Job management

2017-08-08T13:58:30Z

Admin: /* Restart job */

== Requirements ==
In order to manage Seon Enterprise jobs, Seon Enterprise must be enabled via "Configuration" -> "Seon Enterprise" -> "[[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|Is Seon Enterprise installed?]]". After enabling this checkbox, the menu on the left panel expands and the category "Jobs" contains "Send jobs" and "Receive jobs":

[[Image:Seon-menu-jobs.png]]

== Job types ==
Two job type exist:
*incoming jobs
*outgoing jobs

The two type of jobs differ in the selected plugin group used for plugin execution. The plugin groups used are:

=== Incoming jobs ===
The configured "[[Seon_Core_configuration#default_receive_plugin_group|default receive plugin group]]" is the first plugin group executed. The main task of this plugin group should to define a sender and/or recipient of this incoming job.

After this plugin group executed, the configured plugin group of the found recipient is being executed (this plugin group is intended to execute partner dependand logic), where the following logic is used:
*if configured, use the configured receive plugin group of the recipient
*if no recipient receive plugin group is configured, use the receive plugin group of the department
*if no department receive plugin group is configured, use the receive plugin group of the location
*if no location receive plugin group is configured, use the receive plugin group of the partner
*if no partner receive plugin group is configured, set the job to aborted and log this in the plugin logs stating that there is no receive plugin group defined.

=== Outgoing jobs ===
The configured send plugin group of the recipient of the send job is executed, using the following logic:
*if configured, use the configured send plugin group of the recipient of the job
*if no recipient send plugin group is configured, use the send plugin group of the department
*if no department send plugin group is configured, use the send plugin group of the location
*if no location send plugin group is configured, use the send plugin group of the partner
*if no partner send plugin group is configured, set the job to aborted and log this in the plugin logs stating that there is no send plugin group defined.

== Managing jobs interactively ==
Given a job list (either send of receive jobs), the web interface shows a table of all jobs:

[[Image:Sample-joblist-receive-jobs.png]]

The columns contain links to more actions:
*info icon (left): link to job overview and management
*sender / receiver: all separate entities (recipient, department, location and partner) are links to the corresponding "edit" pages
*status: a link to display only jobs of exactly that status

=== Job details ===
When clicking on the job info icon, the job details get displayed:

=== Details and actions ===
[[Image:Job-view-details-and-actions.png]]

This part offers access to the "initial" and "actual" job XML for viewing, displaying in source and even editing the entries. These entries are saved in the database.
*Actual XML: actual job description used for the next plugin execution of, for finished jobs, the last state of the job.
*Initial XML: XML containing all information of the job at initial state. Used for restarting the job.

The XML entries are saved in the database table "<code>${tableprefix}xml_files</code>", where the ID ("<code>idx</code>") is the GET parameter of the link accessing the XML (when hovering with the mouse over the link, most browsers show the target link).

The buttons have the following functions:
*Restart: Restart the job, executing the recipient's plugin group from scratch
**Outgoing jobs: restart the send plugin group of the recipient
**Incoming jobs: restart the receive plugin group of the recipient
*Cancel: set a cancel bit in the database to abort the job after the actual plugin being executed. If the actual plugin being executed is an asynchronous plugin, this asynchronous plugin will be executed with the parameter "''-c''" and the job number in order to let it abort cleanly. See [[Seon_Server-side_plugin_philosophy|Seon Server side plugin philosophy]].
*Reload: actualize this overview.
*Add comment: add a comment to the job's plugin logs.
*Route: set a new recipient and start its receive plugin group.

==== Plugin status ====
[[Image:Job-view-details-status.png]]

The actual plugin status shows the status of the job and, if in execution of a synchronous or asynchronous plugin, the actual plugin name.

==== Plugin logs (textual) ====
[[Image:Job-view-details-plugin-logs-detail.png]]

When clicking on the "+" sign on the left below the graphical plugin logs, the textual plugin logs gets displayed with date of execution, plugin name, date, output and returncode of the plugin (where a value of zero "0" is successful/green, any other value shows an errornous red line).

==== XML view ====
Displaying and editing XML entries of Seon jobs is possible via links in the job detail view. There are three access modes available:
*XML: interpreted form, formatted via a stylesheet saved in the database. This output is a human-readable view of the XML content.
[[Image:Job-actual-xml-html-view.png]]
*source: Sourcecode of the XML for professional interpretation.
[[Image:Job-actual-xml-source.png]]
*edit: edit content of the XML saved in the database, mostly used to modify job information on-the-fly for later restarts.
[[Image:Job-actual-xml-edit.png]]

== Managing jobs from command line ==
Some handy functions are available to manage jobs without a GUI.

=== Restart job ===
This binary "<code>[[seonrestart]]</code>" is internally used by the web interface to restart jobs.

=== Cancel job ===
The binary
seoncancel
in the configured [[Seon_Core_configuration#binary_installation_directory|binary installation directory]] sets a cancel bit in the database to abort the job after the actual plugin being executed. If the actual plugin being executed is an asynchronous plugin, this asynchronous plugin will be executed with the parameter "''-c''" and the job number in order to let it abort cleanly. See [[Seon_Server-side_plugin_philosophy|Seon Server side plugin philosophy]].

The only paramater is either the job number (in numeric format) or an XML file describing the Seon job with a standard XML schema:
<pre>
seonbox:bin haraldlatzko$ ./seoncancel
Seon cancel plugin v1.0

Usage: ./seoncancel <jobnumber|xml_file>
</pre>
This binary is internally used by the web interface.

[[Category:Seon Enterprise]]

Seon Enterprise - Job management

2017-08-08T13:58:03Z

Admin: /* Restart job */

== Requirements ==
In order to manage Seon Enterprise jobs, Seon Enterprise must be enabled via "Configuration" -> "Seon Enterprise" -> "[[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|Is Seon Enterprise installed?]]". After enabling this checkbox, the menu on the left panel expands and the category "Jobs" contains "Send jobs" and "Receive jobs":

[[Image:Seon-menu-jobs.png]]

== Job types ==
Two job type exist:
*incoming jobs
*outgoing jobs

The two type of jobs differ in the selected plugin group used for plugin execution. The plugin groups used are:

=== Incoming jobs ===
The configured "[[Seon_Core_configuration#default_receive_plugin_group|default receive plugin group]]" is the first plugin group executed. The main task of this plugin group should to define a sender and/or recipient of this incoming job.

After this plugin group executed, the configured plugin group of the found recipient is being executed (this plugin group is intended to execute partner dependand logic), where the following logic is used:
*if configured, use the configured receive plugin group of the recipient
*if no recipient receive plugin group is configured, use the receive plugin group of the department
*if no department receive plugin group is configured, use the receive plugin group of the location
*if no location receive plugin group is configured, use the receive plugin group of the partner
*if no partner receive plugin group is configured, set the job to aborted and log this in the plugin logs stating that there is no receive plugin group defined.

=== Outgoing jobs ===
The configured send plugin group of the recipient of the send job is executed, using the following logic:
*if configured, use the configured send plugin group of the recipient of the job
*if no recipient send plugin group is configured, use the send plugin group of the department
*if no department send plugin group is configured, use the send plugin group of the location
*if no location send plugin group is configured, use the send plugin group of the partner
*if no partner send plugin group is configured, set the job to aborted and log this in the plugin logs stating that there is no send plugin group defined.

== Managing jobs interactively ==
Given a job list (either send of receive jobs), the web interface shows a table of all jobs:

[[Image:Sample-joblist-receive-jobs.png]]

The columns contain links to more actions:
*info icon (left): link to job overview and management
*sender / receiver: all separate entities (recipient, department, location and partner) are links to the corresponding "edit" pages
*status: a link to display only jobs of exactly that status

=== Job details ===
When clicking on the job info icon, the job details get displayed:

=== Details and actions ===
[[Image:Job-view-details-and-actions.png]]

This part offers access to the "initial" and "actual" job XML for viewing, displaying in source and even editing the entries. These entries are saved in the database.
*Actual XML: actual job description used for the next plugin execution of, for finished jobs, the last state of the job.
*Initial XML: XML containing all information of the job at initial state. Used for restarting the job.

The XML entries are saved in the database table "<code>${tableprefix}xml_files</code>", where the ID ("<code>idx</code>") is the GET parameter of the link accessing the XML (when hovering with the mouse over the link, most browsers show the target link).

The buttons have the following functions:
*Restart: Restart the job, executing the recipient's plugin group from scratch
**Outgoing jobs: restart the send plugin group of the recipient
**Incoming jobs: restart the receive plugin group of the recipient
*Cancel: set a cancel bit in the database to abort the job after the actual plugin being executed. If the actual plugin being executed is an asynchronous plugin, this asynchronous plugin will be executed with the parameter "''-c''" and the job number in order to let it abort cleanly. See [[Seon_Server-side_plugin_philosophy|Seon Server side plugin philosophy]].
*Reload: actualize this overview.
*Add comment: add a comment to the job's plugin logs.
*Route: set a new recipient and start its receive plugin group.

==== Plugin status ====
[[Image:Job-view-details-status.png]]

The actual plugin status shows the status of the job and, if in execution of a synchronous or asynchronous plugin, the actual plugin name.

==== Plugin logs (textual) ====
[[Image:Job-view-details-plugin-logs-detail.png]]

When clicking on the "+" sign on the left below the graphical plugin logs, the textual plugin logs gets displayed with date of execution, plugin name, date, output and returncode of the plugin (where a value of zero "0" is successful/green, any other value shows an errornous red line).

==== XML view ====
Displaying and editing XML entries of Seon jobs is possible via links in the job detail view. There are three access modes available:
*XML: interpreted form, formatted via a stylesheet saved in the database. This output is a human-readable view of the XML content.
[[Image:Job-actual-xml-html-view.png]]
*source: Sourcecode of the XML for professional interpretation.
[[Image:Job-actual-xml-source.png]]
*edit: edit content of the XML saved in the database, mostly used to modify job information on-the-fly for later restarts.
[[Image:Job-actual-xml-edit.png]]

== Managing jobs from command line ==
Some handy functions are available to manage jobs without a GUI.

=== Restart job ===
This binary "[[seonrestart]]" is internally used by the web interface to restart jobs.

=== Cancel job ===
The binary
seoncancel
in the configured [[Seon_Core_configuration#binary_installation_directory|binary installation directory]] sets a cancel bit in the database to abort the job after the actual plugin being executed. If the actual plugin being executed is an asynchronous plugin, this asynchronous plugin will be executed with the parameter "''-c''" and the job number in order to let it abort cleanly. See [[Seon_Server-side_plugin_philosophy|Seon Server side plugin philosophy]].

The only paramater is either the job number (in numeric format) or an XML file describing the Seon job with a standard XML schema:
<pre>
seonbox:bin haraldlatzko$ ./seoncancel
Seon cancel plugin v1.0

Usage: ./seoncancel <jobnumber|xml_file>
</pre>
This binary is internally used by the web interface.

[[Category:Seon Enterprise]]

Seon Enterprise - internal job handling

2017-08-08T13:54:02Z

Admin:

Seon Enterprise offers a functionality to create internal send jobs locally in your Seon environment without the need sending files via the OFTP protocol.
This is convenient if you are transferring files within your company or if you have made your Seon available for third-party users, like an external company which is using your Seon Webaccess.

In order to achieve that, you will need to set up a new plugin group and configure it at destination level.

== Requirements ==

For this feature, you will need:

*Seon Enterprise Lite license
*Seon Release 2015-03-31 or newer installed

== Configuration ==
=== Plugin groups ===
All logic in sending internal jobs is done via special plugin groups.

==== Send plugin group ====
Select ''Plugin groups'' in your Seon admin-interface and create a new plugin group. You also may clone your default send plugin group and remove all
the unnecessary entries which are used for OFTP transmission (like enqueueing plugins, ENGDAT handling etc.):

[[Image:internal_send.png]]

Optionally, you also can set up an e-mail notification or transmission PDF plugin, if you want to keep the sender and/or recipient informed. Close the windows by clicking on ''save'' afterwards.

==== Receive plugin group ====

If you want to keep both the files of your send and receive jobs in your directories ('''beware: this doubles your data consumption'''), you also can set up a plugin group for incoming internal jobs.
Select ''Plugin groups'' in your Seon admin-interface and edit the plugin group for your incoming jobs (default: "receive - mail to recipient").

[[Image:receive_plugin_group.png]]

=== Partner administration ===
In the next step go to the partner administration and edit an existing entry. You are not required to fill out all fieldsets - some of them can be omitted, like the OFTP credentials:

==== Send plugin group ====
[[Image:new_partner_with_plugin_grp.png]]

Select the "internal send plugin group" (created above) for your send jobs in the fieldset "Seon Enterprise / Plugin groups". Now you are prepared to transfer files locally on your server, using an internal send job process.

==== Receive plugin group ====

This optional step is needed if you want to keep the files for both incoming and outgoing jobs in separate directories. However, this is not mandatory. If you opt not to choose that, you will only have your files in your sending jobs folder.

[[Image:mail_to_recipient.png]]

After that, click on the configure button and activate the following checkboxes of the plugin "copy plugin":
* Don't add "copy" attribute
* Only copy if job is internal

[[Image:configure_plugin_group.png]]

[[Category:Seon Enterprise]]

Seon internet job sharing

2017-08-08T13:53:47Z

Admin:

Seon Enterprise offers a functionality to share Seon jobs via a simple "share" function. With this function enabled, an Seon Webaccess user may share an Seon job via email to a given destination for a given timeframe, optionally secured with a password.

== Requirements ==
For this feature, you need:
*Seon Enterprise license
*Seon Release 2015-03-19 or newer installed
*properly configured mail transfer agent for mailing purposes (for Seonvirtual users, see the documentation [[Seon VMware virtualized image - mail configuration]])
*PHP 5.3.7 or newer for security options

== Configuration ==
In order to enable the feature, navigate in the administrative web interface to "Configuration" -> "Seon Enterprise" -> "Webaccess":

[[Image:Google ChromeScreenSnapz190.png]]

By default, the option is disabled. The configuration options have the following meanings:
*External Seonapi URL: Seon Webaccess offers a secured Seonapi implementation (in a seperate directory, "<code>webaccess/seonapi/index.php</code>"), which needs to be available to external communication partners. Many customers offer Seon Webaccess to external partners, these may offer the subdirectory without problems. Side note: using Apache & [http://httpd.apache.org/docs/2.2/en/mod/mod_rewrite.html mod_rewrite], you can write specific URL rules which have a nicer name for external partners.
*Mail sender address: With this optional setting, you can define the SMTP "From:" field in the sent mail.
*Mail templates (german & english): Absolute path to a file containing the text for the sent mail. See below for usable variables in this mail text.
*Send as HTML: the generated mail will be sent as HTML email.
*Mail subject (german & english): The mail subject.
*Error page: A valid HTML body code which will be displayed to a user who tries to access the service without proper link or with an invalid password.

== Mail templating ==
For the above mentioned "Mail template file" (available in german and english), the content of the file will be interpreted and variables will be substituted with actual values. The following variables are available:
*<code>#link#</code>: The dynamic http(s) link to the shared job.
*<code>#firstName#</code>: The given name of the user initiating the sharing process.
*<code>#lastName#</code>: The family name of the user initiating the sharing process.
*<code>#desc#</code>: A string combining last name and given name, separated by a comma and a space character (i.e. "Koch, Harald")
*<code>#telephone#</code>: The telephone number of the user initiating the sharing process.
*<code>#fax#</code>: The facsimile number of the user initiating the sharing process.
*<code>#email#</code>: The email address of the user initiating the sharing process.
*<code>#country#</code>: The country name of the user initiating the sharing process.
*<code>#department#</code>: The department name of the user initiating the sharing process.
*<code>#location#</code>: The location name of the user initiating the sharing process.
*<code>#company#</code>: The company name of the user initiating the sharing process: if a longname is configured, the longname will be used, otherwise the shortname will be used.

The sent mail will be encoded in UTF-8 characters.

The example for this documentation is based on this mail template:
<pre>
Sehr geehrter Adressat,

#firstName# #lastName# (#email#) hat Ihnen Daten zur Verfügung gestellt:

#link#

Ihr Seon Enterprise
</pre>

== User interaction ==
Users can share any viewable jobs where the files are still available (say: archived jobs cannot be shared, since their data files are not available). If a job is downloadable, it is shareable.

Sharing is done in the job detail view. If sharing is enabled, a button appears in the toolbar:

[[Image:Google ChromeScreenSnapz191.png]]

The language of the shared job depends on the user's language in Seon Webaccess:
*If the user is using the german web interface, the german mail will be sent.
*If the user is using another language, the english mail will be sent.

After clicking on the button, the following window appears:

[[Image:Google ChromeScreenSnapz192.png]]

The user has to enter a valid email address. Optionally, he can assign a password for this shared job. In this case, both password must be the same. The password is hashed securely and not saved in plain text in the database, so later-on recovery is impossible!

The timeframe for availability of this shared link is configurable, by default a timeframe of 48 hours is selected.

After submitting the shared job, the user gets an informational window:

[[Image:Google ChromeScreenSnapz193.png]]

If a password was supplied, the user is informed that this password must be communicated to the data recipient.

== Recipient's view ==
The job recipient obtains the link to the job via the configured email template. An example could be:

[[Image:MailScreenSnapz001.png]]

The link in this email contains a hash which represents the shared job.

After clicking on the link, Seon Enterprise offers the data of the file. If an authentification password is configured, the user must prompt his password into a webbrowser prompt field:

[[Image:FirefoxScreenSnapz050.png]]

The text "Passwort" depends on the language of the shared job:
*For a german shared shared job (say: user is logged in Seon Webaccess with german language, the mail is sent in german): the text says "Passwort"
*For all other languages, the text says "Password"

== Automatic share expiration ==
The running send queue daemon takes care about expired job shared and deletes them from the shared list.

== Logging ==
Properly accessed jobs which are downloaded by users are logged in the plugin logs of the job:

[[Image:Google ChromeScreenSnapz195.png]]

The log is dynamically build based on the information if the job is shared with a password or without a password.

The cleanup process of shared jobs is logged in the Seon's system log:

[[Image:Google ChromeScreenSnapz202.png]]

== Administration ==
If job sharing is active, a new menu entry appears in the administrative web interface in "Seon Enterprise jobs":

[[Image:Google ChromeScreenSnapz196.png]]

With this menu entry, a list of all shared jobs is available:

[[Image:Google ChromeScreenSnapz198.png]]

The information speak for itself:
*With the trash icon button, you can delete an entry.
*The job number is the referenced job.
*User: the initiator of the shared job. This field is clickable in order to administrate the user directly.
*Valid until: the date of expiration of the job share.
*Hash: the unique share hash, which is also included in the link contained the email.
*Password protected: this read-only checkbox shows if the initiator of the job share has given a password.
*URL: The actually available URL to access this shared job. The link is dynamically build upon the above mentioned configuration URL.
*Email: the addressed email for the share link.
*Language: the initiator's user language.

Deleting an entry will be logged in the job's plugin logs:

[[Image:Google ChromeScreenSnapz201.png]]

[[Category:Seon Enterprise]]

Seon Enterprise - job processing at given time

2017-08-08T13:53:27Z

Admin:

It may be needed that an Seon Enterprise job is being sent at a given time, configured by the initiator of the send job. For that reason, Seon introduces a solution for time shifted job processing.
== Requirements ==
For this feature, you need:
*Seon Enterprise license
*Seon Release 2015-02-24 or newer installed

== Configuration ==
The configuration consists of several parts. These are:
=== Webaccess configuration ===
Enable the configuration option "Configuration" -> "Seon Enterprise" -> "Webaccess" -> "Enable time selection by user". Save this configuration.

[[Image:Google ChromeScreenSnapz176.png]]

=== Configure plugin group ===
In order to support this feature the plugin group running for outgoing jobs must contain the plugin "Wait for send time" before the point of processing you want to execute after waiting time. This will surely be the transmission plugin, used for transferring files. Technically spoken you can insert the plugin at any position you want.

For a better handling, clone your existing plugin group for sending tasks and give the clone a unique name:

[[Image:Google ChromeScreenSnapz177.png]] [[Image:Google ChromeScreenSnapz178.png]]

Then, edit your cloned plugin group and add the plugin "Wait for send time" to the plugins, position it by drag&drop at the requested position where you want to wait for given send time (normally: before "enqueue to Seon"):

[[Image:Google ChromeScreenSnapz179.png]]

[[Image:Google ChromeScreenSnapz180.png]]

[[Image:Google ChromeScreenSnapz181.png]]

=== Assign new plugin group to partner ===
You may assign the new plugin group containing the "Wait for send time" plugin to any partner at any hierarchy level.

[[Image:Google ChromeScreenSnapz182.png]]

== Usage in Seon Webaccess ==
After any recipient in an Seon send job is addressed, a popup notification (if not disabled) informs the user about the new functionality:

[[Image:Google ChromeScreenSnapz183.png]]

A new section for time configuration is available after the list of files. The implemented functionality for this time selection is:
*Users cannot define time in the past.
*The date picker is based on the configured language (format and entity names).
*When selecting a time in the past, the GUI automatically resets the values to the current time.

If enabled, the send job obtains a new send time information which will be interpreted by the plugin inserted in the send plugin group (see above).

[[Image:Google ChromeScreenSnapz184.png]]

== Logging in plugin logs ==
The job contains a plugin log in the administrative web interface, which tells you the time and date information about the job.

[[Image:Google ChromeScreenSnapz185.png]]

After this point of time is reached, the send queue daemon (which has a short timeslice value) ensures that the job is being started again.

[[Category:Seon Enterprise]]

Seon Enterprise - Fetch files from (S)FTP server

2017-08-08T13:53:17Z

Admin:

Seon offers an easy way to create Seon Enterprise receive jobs from FTP server content. This solution is based on two mechanisms:
#Mount remote server directory as a local directory.
#Configure the [[Seon Directory Scanner]] to that mounted directory, create Seon Enterprise receive jobs.

This documentation covers all technical aspects to implement a functionality to automatically fetch new files from a (S)FTP server.

== Assumption ==
All details explained here are based on the freely available pre-installed [[Seon VMware virtualized image]], which is also available for other virtualization solutions via OVA. In general, all solutions explained here can be used in any modern Linux environment. All steps explained here must be executed as user "<code>root</code>" unless any other documentation states to switch user context.

In this example, the following attributes are used:
*User running Seon: "<code>www-data</code>", group "<code>www-data</code>".
*Target mount point for FTP directory: <code>/mnt/ftp/server1</code>
*Target FTP server: 192.168.20.71, username "<code>seon</code>", password "<code>seon</code>"
*Path on server containing files for Seon Enterprise jobs: "<code>to_be_retrieved</code>"
Your user which is connecting to the server must be able to delete files, since after transmission the file will be deleted from the server.

== Install required packages ==
You need to install the following packages for (S)FTP mounting:
apt-get -y install sshfs curlftpfs

== Change user group membership ==
The user running Seon (configured in [[Seon_Core_configuration#run_Seon_programs_as_user|"Configuration" -> "Daemon" -> "Run Seon programs as user"]]) must be added in the user group "fuse":
adduser www-data fuse

== Change permissions of /dev/fuse ==
By default, the required device file "<code>/dev/fuse</code>" is only writable by user "<code>root</code>". We need to extend the permissions:
chgrp fuse /dev/fuse
chmod g+rw /dev/fuse

== Create target mountpoint ==
The FTP target directory must be mounted somewhere into the local filesystem to be readable by Seon. You may use any (in best case empty) directory. We need this directory name later for the configuration of the Seon directory scanner. The owner of the target directory must be the [[Seon_Core_configuration#run_Seon_programs_as_user|configured user running Seon]]):
mkdir -p /mnt/ftp/server1
chown www-data.www-data /mnt/ftp/server1

== Save FTP credentials securely ==
In order to automatically connect to the (S)FTP server, save the credentials in a single line in the following file:
/root/.netrc
The syntax of the file is simple: per line, one server can be given by its name (hostname or IP), followed by keywords for username and password, with their values. Example:
machine 192.168.20.71 login seon password seon
This file must have permissions to be readable only by root, so you might change the permissions after creating / modifying the file:
chmod 600 /root/.netrc

== Add server mount for bootup ==
Many situations for different FTP servers may occur. Some common situations are documented here. To let the (S)FTP server be mounted at bootup (which is the most common way), you have to add a line to the filesystem table file:
/etc/fstab
You have to change the IP address (and possibly username) and mount point accordingly to your needs.
=== Add simple FTP server ===
The line to be added has the following syntax:
curlftpfs#192.168.20.71 /mnt/ftp/server1 fuse auto,allow_other,disable_eprt,_netdev 0 0

=== Add FTPS server ===
The line to be added has the following syntax:
curlftpfs#192.168.20.71 /mnt/ftp/server1 fuse auto,allow_other,disable_eprt,_netdev,ssl,no_verify_peer 0 0

=== Add FTP over implicit TLS server ===
The line to be added has the following syntax:
curlftpfs#192.168.20.71 /mnt/ftp/server1 fuse auto,allow_other,disable_eprt,_netdev,ssl 0 0

=== Add FTP over explicit TLS server ===
The line to be added has the following syntax:
curlftpfs#192.168.20.71 /mnt/ftp/server1 fuse auto,allow_other,disable_eprt,_netdev,ssl_control 0 0

=== Add SFTP (FTP over SSH) ===
You have to know the absolute path fro the remote server to be mounted for that task. For an automatic mount, you need to save your own SSH public key in the remote system's file "<code>~/.ssh/authorized_keys</code>". This enabled an automatic login without password prompt (if allowed by the remote SSH server).
sshfs#seon@192.168.20.71:/home/seon/ /mnt/ftp/server1 fuse auto,_netdev 0 0

=== Using a proxy server ===
When using a proxy server, you have to add an option to the entry line in "<code>/etc/fstab</code>":
proxy=http://username:password@proxy-server:3128
A complete line in "<code>/etc/fstab</code>" would be:
curlftpfs#192.168.20.71 /mnt/ftp/server1 fuse auto,allow_other,disable_eprt,_netdev,proxy=http://proxyuser:proxypwd@proxy-server:3128 0 0

Beware that the credentials are saved in a system-wide readable format, so use a pre-defined proxy user only for that task (i.e. with limited permissions). You may also want to set up the proxy environment variable as described in [[Seon HTTP Proxy support]].

== Testing server connection ==
After having added the appropriate entry in "<code>/etc/fstab</code>", execute the following command to mount the file system:
mount -a
If no error occurs, the target mountpoint shows the content of the remote server.

== Add directory scanner rule ==
In the administrative web interface, navigate to "Queues" -> "Dir.scanner". In the toolbar on top of the panel, click on the button "Add". In the opening window, configure your directory scanner rule according to your setting of your mounted directory:

[[Image:Dirscanner Receive job.png]]

Be sure to use "Seon Enterprise receive job" as type selection, since this implies that the files are "incoming" files, not to be sent to external partners. For file selection (per Seon job), two possibilites exist:
*Multiple files in one Seon job: if your Seon jobs are divided into subdirectories (relative to the directory configured in "Directory" above), you can generate Seon Enterprise jobs based on the content of these directories. One job will be created per directory.
*Single file per Seon job: if files are lying in that directory without logic, you can create incoming jobs, one per file.

The sender of the job is for documentation reasons only, commonly you configure a person of a sender company who is resonsible for the data or service.

The recipient of the job is used to calculate the executed plugin group. The configured plugin group for receive jobs is executed.

== Side notes ==
*During the transfer of files from the mounted server, the directory scanner waits until the end of the current task. This is required due to the uniqueness of exactly one process per Seon, it is the basis of all directory scanner rules.
*The used solution "curlftpfs" automatically reconnects if server connection is lost.
*In many cases, the time stamps of the files on a mounted file system are relatively seen not the same as the local system. "curlftpfs" does provide a mechanism to transfer only files from the server which are not used by other processes (i.e. upload of the same file from other source). You can solve errornous situations by the following approach:
**during upload, name the file with a pre- or postfix name (i.e. "*.uploading")
**configure the regular expression of your scanning rule not to pick such files
**rename the correctly uploaded file to a name without such a pre- or postfix name
**if nothing helps, you can use a separate mechanism, i.e. cron, to move files to a target directory which is then configured as the scanned directory of the directory scanner
*During the transfer of the files from an external server, the Seon Enterprise job itself is created, the status "waitig for files" is given. The plugin logs contain information about what is actually in progress:
[[Image:Dirscanner move file log.png]]

== External documentation ==
Since technologies from external sources are used, there exist several good documentation about mounting remote file systems into your Linux environment. The technology basically used is called "fuse", which is a file system support in user space (instead of kernel space, which is normal for Unix).

External ressources:
*http://fuse.sourceforge.net/
*http://curlftpfs.sourceforge.net/
*http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems#httpfs - a list of supported file systems

[[Category:Seon Enterprise]]

Seon Enterprise - Job management

2017-08-08T13:52:53Z

Admin:

== Requirements ==
In order to manage Seon Enterprise jobs, Seon Enterprise must be enabled via "Configuration" -> "Seon Enterprise" -> "[[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|Is Seon Enterprise installed?]]". After enabling this checkbox, the menu on the left panel expands and the category "Jobs" contains "Send jobs" and "Receive jobs":

[[Image:Seon-menu-jobs.png]]

== Job types ==
Two job type exist:
*incoming jobs
*outgoing jobs

The two type of jobs differ in the selected plugin group used for plugin execution. The plugin groups used are:

=== Incoming jobs ===
The configured "[[Seon_Core_configuration#default_receive_plugin_group|default receive plugin group]]" is the first plugin group executed. The main task of this plugin group should to define a sender and/or recipient of this incoming job.

After this plugin group executed, the configured plugin group of the found recipient is being executed (this plugin group is intended to execute partner dependand logic), where the following logic is used:
*if configured, use the configured receive plugin group of the recipient
*if no recipient receive plugin group is configured, use the receive plugin group of the department
*if no department receive plugin group is configured, use the receive plugin group of the location
*if no location receive plugin group is configured, use the receive plugin group of the partner
*if no partner receive plugin group is configured, set the job to aborted and log this in the plugin logs stating that there is no receive plugin group defined.

=== Outgoing jobs ===
The configured send plugin group of the recipient of the send job is executed, using the following logic:
*if configured, use the configured send plugin group of the recipient of the job
*if no recipient send plugin group is configured, use the send plugin group of the department
*if no department send plugin group is configured, use the send plugin group of the location
*if no location send plugin group is configured, use the send plugin group of the partner
*if no partner send plugin group is configured, set the job to aborted and log this in the plugin logs stating that there is no send plugin group defined.

== Managing jobs interactively ==
Given a job list (either send of receive jobs), the web interface shows a table of all jobs:

[[Image:Sample-joblist-receive-jobs.png]]

The columns contain links to more actions:
*info icon (left): link to job overview and management
*sender / receiver: all separate entities (recipient, department, location and partner) are links to the corresponding "edit" pages
*status: a link to display only jobs of exactly that status

=== Job details ===
When clicking on the job info icon, the job details get displayed:

=== Details and actions ===
[[Image:Job-view-details-and-actions.png]]

This part offers access to the "initial" and "actual" job XML for viewing, displaying in source and even editing the entries. These entries are saved in the database.
*Actual XML: actual job description used for the next plugin execution of, for finished jobs, the last state of the job.
*Initial XML: XML containing all information of the job at initial state. Used for restarting the job.

The XML entries are saved in the database table "<code>${tableprefix}xml_files</code>", where the ID ("<code>idx</code>") is the GET parameter of the link accessing the XML (when hovering with the mouse over the link, most browsers show the target link).

The buttons have the following functions:
*Restart: Restart the job, executing the recipient's plugin group from scratch
**Outgoing jobs: restart the send plugin group of the recipient
**Incoming jobs: restart the receive plugin group of the recipient
*Cancel: set a cancel bit in the database to abort the job after the actual plugin being executed. If the actual plugin being executed is an asynchronous plugin, this asynchronous plugin will be executed with the parameter "''-c''" and the job number in order to let it abort cleanly. See [[Seon_Server-side_plugin_philosophy|Seon Server side plugin philosophy]].
*Reload: actualize this overview.
*Add comment: add a comment to the job's plugin logs.
*Route: set a new recipient and start its receive plugin group.

==== Plugin status ====
[[Image:Job-view-details-status.png]]

The actual plugin status shows the status of the job and, if in execution of a synchronous or asynchronous plugin, the actual plugin name.

==== Plugin logs (textual) ====
[[Image:Job-view-details-plugin-logs-detail.png]]

When clicking on the "+" sign on the left below the graphical plugin logs, the textual plugin logs gets displayed with date of execution, plugin name, date, output and returncode of the plugin (where a value of zero "0" is successful/green, any other value shows an errornous red line).

==== XML view ====
Displaying and editing XML entries of Seon jobs is possible via links in the job detail view. There are three access modes available:
*XML: interpreted form, formatted via a stylesheet saved in the database. This output is a human-readable view of the XML content.
[[Image:Job-actual-xml-html-view.png]]
*source: Sourcecode of the XML for professional interpretation.
[[Image:Job-actual-xml-source.png]]
*edit: edit content of the XML saved in the database, mostly used to modify job information on-the-fly for later restarts.
[[Image:Job-actual-xml-edit.png]]

== Managing jobs from command line ==
Some handy functions are available to manage jobs without a GUI.

=== Restart job ===
The binary
seonrestart
in the configured [[Seon_Core_configuration#binary_installation_directory|binary installation directory]] manages the job to use its initial XML to restart the job with the configured plugin group of the recipient.
*Outgoing jobs: restart the send plugin group of the recipient
*Incoming jobs: restart the receive plugin group of the recipient

The only paramater is either the job number (in numeric format) or an XML file describing the Seon job with a standard XML schema:
<pre>
seonbox:bin haraldlatzko$ ./seonrestart
Seon restart plugin v1.0

Usage: ./seonrestart <jobnumber|xml_file>
</pre>
This binary is internally used by the web interface.

=== Cancel job ===
The binary
seoncancel
in the configured [[Seon_Core_configuration#binary_installation_directory|binary installation directory]] sets a cancel bit in the database to abort the job after the actual plugin being executed. If the actual plugin being executed is an asynchronous plugin, this asynchronous plugin will be executed with the parameter "''-c''" and the job number in order to let it abort cleanly. See [[Seon_Server-side_plugin_philosophy|Seon Server side plugin philosophy]].

The only paramater is either the job number (in numeric format) or an XML file describing the Seon job with a standard XML schema:
<pre>
seonbox:bin haraldlatzko$ ./seoncancel
Seon cancel plugin v1.0

Usage: ./seoncancel <jobnumber|xml_file>
</pre>
This binary is internally used by the web interface.

[[Category:Seon Enterprise]]

Seon Enterprise - importing ENGPART

2017-08-08T13:52:43Z

Admin:

== How are ENGPART imports handled in Seon? ==
ENGPART import is based on Seon jobs which has a clearly defined sender and recipient, files and meta information. The only (one) data file in this just is the ENGPART file itself.

The following behaviour is implemented in the ENGPART import:
*Locations:
**Previously imported locations will be updated (referenced by their IDs, set by the sender's ENGPART creator)
**Existing location with the same description will be updated
**non-existant locations will be created
*Departments:
**Previously imported departments will be updated (referenced by their IDs, set by the sender's ENGPART creator)
**Previously imported departments will be moved from other locations (if they exist in another locations of the partner) (referenced by their IDs, set by the sender's ENGPART creator)
**Existing departments with the same description in the selected location will be used
**Existing departments with the same description in the others locations will be moved
**non-existant departments will be created in the referenced location
*Users:
**Previously imported users will be updated (referenced by their IDs, set by the sender's ENGPART creator)
**Previously imported users will be moved from other departments (if they exist in another department of the partner) (referenced by their IDs, set by the sender's ENGPART creator)
**If no user is found, a search over the selected department will be executed (searching for first and last name). Existing users will be updated.
**If no user is found, a search over all departments in all sites will be executed (searching for first and last name). Existing users will be updated and moved.
**If no user is found, a search over the selected department will be executed (searching for email address). Existing users will be updated.
**If no user is found, a search over all departments in all sites will be executed (searching for email address). Existing users will be updated and moved.
**non-existant users will be created in the referenced department

For all found entities without an ENGPART ID, this internal ID will be configured to the entity in order to find the entity in future imports as fast as possible.

== How are ENGPART jobs recognized? ==
There are two ways of incoming ENGPART jobs:
*Automatically received via OFTP. The ENGDAT abstract file contains an information that the job is an ENGPART job. The plugin "[[Seon plugin seonplugin_engdatv2_decode]]" interprets that special attribute, logs out this situation in the job plugin logs and stops further processing of the job (even if a recipient has a defined receive plugin group).
*Manual file upload with configuration of the sending company.

== Supported ENGPART versions ==
Two versions of ENGPART are supported:
*ENGPART v3: special formatted and complex to understand ASCII based file
*ENGPART v4: XML based, well defined format

== Attributes to be imported ==
*Locations:
**Name
**Street
**Postal code
**City
**Country
*Departments:
**Name
**Country
*User:
**First and last name
**Phone number
**Fax number
**Email address
**Address code
**Country

== Handling automatically received ENGPART jobs ==
This chapter deals with handling automatically received ENGPARTs.
=== Information about new ENGPARTs ===
Seon's administrative web interface shows a section "''Possible configuration problems''" in the "''Welcome''" tab of the interface. When there are unhandled ENGPART jobs available, a message shows up with a shortcut button to this panal:

[[Image:ENGPART welcomeTab.png]]

Alternatively, navigate to "Programs" -> "ENGPART import" in the menu on the left:

[[Image:ENGPART import menu left.png]]

=== ENGPART overview ===
The opening panel shows all available ENGPART jobs, including sender information, job number, status and an action button for importing this ENGPART:

[[Image:ENGPART import panel.png]]

Click on the "Import ENGPART" icon in order to start the import wizard.

=== Import ENGPART - step 1: introduction ===
An introduction shows some details about the ENGPART job, as the job number, sender and date of receipt:

[[Image:ENGPART import step1.png]]

Click on the "Next" button to proceed.

=== Import ENGPART - step 2: select entities for import ===
The following tree overview lets you en- or disable entities (such as locations, departments and users) for import. The selection is being saved in the background for later usage, so if you cancel the process and return to the import wizard later, your selection will be the same as you have left it:

[[Image:ENGPART import step2.png]]

Some rules are important:
*When disabling a location, all included departments and users are disabled, too.
*When disabling a department, all included users are disabled, too.
*When enabling a department in a disabled location, the above location will be enabled, too.
*When enabling a user in a disabled location and a disabled site, the above department and location are enabled, too.

(De-)select the needed entities to be imported into the sender's structure and press "Next".

=== Import ENGPART - step 3: finish the import ===
If you want, you can abort the import process here and return to your selection later. If you want to import the previously selected entities, press "Finish".

[[Image:ENGPART import step3.png]]

=== Import ENGPART - step 4: finished the import ===
The upcoming popup shows you the successful import process of the ENGPART. After that step, all selected entities are imported into the partner schema of the sender's company.

[[Image:ENGPART import step4.png]]

== Handling manually uploaded ENGPARTs ==
If you receive an ENGPART file from an external source, you can upload it easy with the upload button on the top of the panel:

=== Start upload process ===
[[Image:ENGPART upload step1.png]]

Use the webbrowser's file select browser to navigate to your ENGPART file you wish to upload:

[[Image:ENGPART upload select file.png]]

=== Select sender of ENGPART ===
In order to reference a sender of the ENGPART, a partner entry must be set up. If no sender is configured, the ENGPART job gets the status "''failed to import''". Select the corresponding partner and click on the "Save" button.

[[Image:ENGPART upload step2.png]]

=== Proceed with the import wizard ===
The rest of the process is the same as handling an automatically received ENGPART job, jump to the chapter [[Seon_Enterprise_-_importing_ENGPART#Import_ENGPART_-_step_1:_introduction|Import ENGPART - step 1: introduction]]

[[Category:Seon Enterprise]]

Seon Enterprise - sending ENGPART

2017-08-08T13:52:31Z

Admin:

== ENGPART - background information ==
An ENGPART file is a file in a textual format which contains organisational hierarchy information and technical descriptions about your OFTP environment. It contains:
*details about your company, such as address
*information about locations
*information about departments
*information about end-users of the system, such as eMail address, address codes etc.

There are two common versions of this file available:
*ENGPART v3: special formatted and complex to understand ASCII based file
*ENGPART v4: XML based, well defined format

== Requirements ==
In order to send an ENGPART from the Seon integrated partner database, there are some requirements to be met:
*Configuration option "[[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|Is Seon Enterprise installed]]" has to be enabled
*Your complete company structure has to be defined in the Seon partner database
*Your own and the remote partner must have a technical contact configured at top level. That a mandatory field in ENGPART, so no companies without this field will be available for ENGPART target selection
*Send queue daemon is running

== Doing ==
In order to send an ENGPART file to a partner, check the requirements. If they are met, proceed by selecting the menu item "Programs" in the administrative web interface, then "ENGPART export". In the new tab in the main frame, select the version your partner understands, your own company and the remote partner you want to address and click on the button "Send ENGPART".

[[Image:EngpartExportMenuEntry.png]]

== Verification ==
Two files will be added to the send queue:
*ENGDAT abstract file ("<code>*002001</code>")
*ENGPART file ("<code>*002002</code>")

Check the send logs for verification of the send process of these files.

[[Category:Seon Enterprise]]

Seon Enterprise

2017-08-08T13:52:20Z

Admin:

Seon Enterprise brings a lot of new functionality. The documentation consists of several chapters:

[[Seon Enterprise - Seon Webaccess configuration]] - Configuration options in "Configuration" -> "Seon Enterprise"

[[Seon Web access installation and configuration]]

[[Seon Enterprise user authentification]] - internal with password or PAM

*[[PAM configuration for Windows Active Directory]]

[[Seon Enterprise partner migration]]

[[Seon Enterprise partner management]]
*[[Seon Enterprise recipient configuration]]
*[[Seon Enterprise job view configuration]] - make Seon job accessible throughout different organizational entities

[[Seon Server-side plugin philosophy]]

[[Seon client-side plugin philosophy]] - managing local data processing in Seon Webaccess (i.e. CatiaV5 integration)

[[Seon plugin groups]]

[[Seon Enterprise plugins]]

[[Seon Enterprise - other protocols]]

[[Seon Enterprise - sending ENGPART]]

[[Seon Enterprise - importing ENGPART]]

[[Seon Enterprise - Job management]]

[[Seon Enterprise - Fetch files from (S)FTP server]]

[[Seon Enterprise - job processing at given time]]

[[Seon internet job sharing|Seon Enterprise - internet job sharing]]

[[Seon Enterprise - internal job handling]]

== additional binary documentation ==

On top of Seon Core, Seon Enterprise introduces some new programs, needed for the handling of Seon Enterprise. These programs are:

*seon_async_plugin_handler
*seoncancel
*seonclientd
*seon_extract_recipient_email_from_xml
*seon_extract_sender_email_from_xml
*seon_recfile_sorter
*[[seonrestart]]
*seonroute
*seon_sqd_async_handler
*seon_sqd_blocked_handler
*seon_engpart_send
*[[seon_create_enterprise_sendjob]]

Seon Enterprise - other protocols

2017-08-08T13:51:30Z

Admin:

Seon Enterprise supports a freely definable amount of other protocols. As a basis for such a connectivity, a protocol script must be implemented which must support a single file as parameter (a XML file which contains details about what to do and with which configuration).

Configuration of all protocol dependant parameters can be done on per-partner panel. Every protocol can obtain as many parameters as wanted.

The following pre-defined and well-supported protocols are supported by Seon Enterprise (Lite):
*anonymous WebDAV
*FTP
*FTPS
*key-authentificated SCP
*key-authentificated SFTP

== Activating support for other protocols ==
*Enable the checkbox "Configuration" -> "Seon Enterprise" -> "[[Seon_Core_configuration#enable_multi-protocol_support.3F|Enable multi-protocol support?]]" and save this configuration
*Edit your partner according to the protocol definition by explicitely activating the checkbox "Use this protocol?" for exactly one (other) protocol:
[[Image:Seon enterprise configure ftp.png]]
*Be sure to configure a plugin group for a recipient which includes the plugin "enqueue to Seon" since this plugin executes the process of sending via another protocol instead of OFTP

== Detailled internals ==
In Seon Enterprise, an unlimited amount of other protocols can be defined (when enabled) via the menu link "Other protocols". Each protocol has a name, commands for execution and variables. The only command used at the moment is the "put command" for sending files.

=== Commands ===
The configured commands are:
*''list command: list content of a directory (unused at the moment)''
*put command: send files
*''get command: download files (unused at the moment)''
*''delete command: delete remote file (unused at the moment)''

An example is as follows:

[[Image:Ftp protocol definition.png]]

=== Variables ===
In order to configure each partner with separate values, variables are neccessary to be defined. These are linked by a hyperlink in the most-right column of the protocol definition list. Each variable of a protocol will be filled with partner-specific values via the web interface dynamically.

[[Image:Protocol variable definition.png]]

=== Execution ===
In order to send files to a configured partner, the plugin "enqueue to Seon" must be executed in the send plugin group. Refer to the documentation "[[Seon Server-side plugin philosophy|Seon_Server-side_plugin_philosophy]]" for more details.

This plugin analyzes the configured protocol and starts, if configured, the configured put command in an asynchronous process. Keep in mind that the plugin "enqueue to Seon" is an asynchronous plugin which stops plugin execution of the send job after returning. So, 2 seconds after a successful return of the plugin "enqueue to Seon", the put command will be executed. Variable definitions are filled with values and given as parameter to the put command. The parameters of the command are:
#temporary file containing all configured protocol variables with their values, also a node containing all files
#filename for output

The protocol script has to implement the mechanism of parsing the XML file. In default protocol implementations, all files are being transfered with their virtual filename as remote filename.

After execution, the protocol command handler analyzes the returncode of the protocol command, passing it to the asynchronous plugin handler of the job (0=successful, any other value=error) and appends the protocol output as plugin log to the Seon send job.

If any further plugin is configured in the plugin group, it will be executed by the asynchronous plugin handler.

=== Protocols and software updates ===
The standard protocols are always updated to the new distribution. If you need to re-configure a protocol, please clone the configuration to a new protocol definition including new variable definitions. In this case, no software update will harm your special implementation. Place the directory of your new protocol definition somewhere above the directory of the factory-delivered directories (which is "<code>/opt/seon/scripts/protocols</code>" by default). As an example, use "<code>/opt/seon/scripts/yourProtocolDefinition</code>".

[[Category:Seon Enterprise]]

Seon plugin groups

2017-08-08T13:51:09Z

Admin:

Defined Seon plugins can be grouped into plugin groups. These plugin groups can be administrated via web GUI. Configured plugin groups are available for any hierarchical level (company, location, department and recipient) to be defined for incoming and outgoing jobs.

=== Plugin group usage ===
There are three cases for plugin group using: incoming ''before a recipient is known'', incoming jobs ''when a recipient is known'' and outgoing jobs.

==== Outgoing jobs ====
The most easiest case is the outgoing job: all job parameters are known when the job starts. In this case, a usable plugin group for sending jobs are searched. This is done in four steps:
*search for a send plugin group at the configured defined recipient
*if not found: search for a send plugin group at the configured defined recipient department
*if not found: search for a send plugin group at the configured defined recipient location
*if not found: search for a send plugin group at the configured defined recipient company
If no send plugin group is defined in any of these hierarchy levels, the job gets the status "''aborted''" and a log entry is added to the job (complaining about a non-configured send plugin group for that recipient).

The first found plugin group with its configuration (if any is set) is used for that outgoing job. It's processed from the first to the last plugin of that plugin group.

==== Incoming jobs before a recipient is known ====
When an incoming job starts (after all files are received for that job), the globally configured [[Seon_Core_configuration#default_receive_plugin_group| default receive plugin group]] will be executed. Its main goal should be defining the correct recipient (and optionally the sender; globally: interpreting the hopefully available ENGDAT abstract file).

==== Incoming jobs when a recipient is known ====
After the execution of the [[Seon_Core_configuration#default_receive_plugin_group| default receive plugin group]], the recipient plugin group is searched:
*search for a receive plugin group at the configured defined recipient
*if not found: search for a receive plugin group at the configured defined recipient department
*if not found: search for a receive plugin group at the configured defined recipient location
*if not found: search for a receive plugin group at the configured defined recipient company
If no receive plugin group is defined in any of these hierarchy levels, the job gets the status "''aborted''" and a log entry is added to the job (complaining about a non-configured receive plugin group for that recipient).

If the [[Seon_Core_configuration#default_receive_plugin_group| default receive plugin group]] is also configured at recipient's side, the plugin group will not be executed a second time since addressing has been fulfilled with the first run. A log message
Same plugin group defined for 'default receive plugin group' and recipient, skipping unnecessary execution.
will be added to the plugin logs of the job.

The first found plugin group with its configuration (if any is set) is used for that incoming job. It's processed from the first to the last plugin of that plugin group.

=== plugin group management ===
==== listing plugin groups ====
When Seon Enterprise is installed properly (see [[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|is Seon Enterprise installed?]]), the left-hand menu contains '''Plugin groups'''. Clicking on that link opens the list of configured plugins:

[[Image:Plugingroup list.png]]

==== creating plugin group ====
In order to add a new plugin group, click on the "''Add''" button:
[[Image:add.png]]

This leads you to the "''Adding plugin group''" form. You have to give the new plugin group a unique name.

[[Image:Insert plugingroup.png]]

After submitting the form, a new plugin group has been created and will be listed in the plugin group list.

==== editing plugin group name ====
You may change the name of any plugin group by clicking on the "''edit''" icon [[Image:pencil.png]]. The next screen asks you to change the name:

[[Image:Edit plugingroup.png]]

By submitting the form the name changes. This namechange has no influence to any configured partner since the internal ID is always used.

==== managing plugin group ====
In order to manage the content of a plugin group, click on the plugin group name (this is a hyperlink) in the plugin group list. The next screen displays the content of the selected plugin group:

[[Image:Manage plugingroup.png]]

The already selected plugins are listed in a table, representing a top-down view of this group. The first executed plugin group is displayed at the top. The plugin name itself is a link to the plugin administration page.

In order to add a plugin to the end of the plugin group, select the appropriate plugin from the plugin pulldown menu and submit the form by clicking on "add plugin". Plugins are removable by clicking on the "''delete plugin''" icon [[Image:delete.png]].
To move a selected plugin in the execution order down, click on the "''move down''" icon [[Image:Arrow down.gif]]. To move a plugin up, click on the "''move up''" icon [[Image:Arrow up.gif]].

==== cloning plugin group ====
In order to clone a plugin group (which is useful if you want to create a new plugin group which will contain mostly the same plugins in the same order as the original plugin group), you may click on the "''clone plugin group''" icon [[Image:Edit-copy.gif]]. The new name has to be defined in the next step:

[[Image:Clone plugin group.png]]

By submitting a new name, the existing plugin group will be cloned to the new name.

==== deleting plugin group ====
In order to delete a plugin group, click on the delete icon on the left side of the appropriate row: [[Image:delete.png]]

If the plugin group is configured in any partner entity (company, location, department or recipient) or basic configuration, these entities will be displayed here:

[[Image:Delete plugin group.png]]

By submitting the form, the plugin group will be deleted and all affected entities will receive a "no plugin group defined" configuration.

[[Category:Seon Enterprise]]

Seon client-side plugin philosophy

2017-08-08T13:50:57Z

Admin:

== Abstract ==
'''100% pure Java-free!'''

With the local processing ability of Seon Webaccess, you can do the following client-side:
*dynamically retrieve locally available environments
*list a structured hierarchy of directory with aliases within a selected environment, sourcing them locally in the context of the logged in user in the client machine
*list content of the selected directory, offerung filtering and file type selection
*export selected (single or multiple) files with a configured program or script
*grab the created files, upload it to an outgoing send job, keeping the log output for every file for possibly later processing

From end-user's view, the selection works as follows:
#Select environment (''last selected environment is saved and pre-selected in future calls'')
#Search and select DLName
#Search and select file(s) for export
#Start export process

In case of success, the output file(s) will be added to the send job, in case of error an error message shows the output of the process.

All scripts/programs for every situation can be located on a defined web position (http(s) URL) or available at a local or remote path.

File selection via this solution is available with a button in the "new send job" view:

[[Image:NewJobFileSelection DLName.png]]

Receiving jobs to available DLNames is possible via a dynamic DLName selection:

[[Image:FetchJobFileSelection DLName.png]]

== Requirements ==
For this functionality, you need:
*Seon Webaccess Webbrowser plugin version 1.4.0 and up
*Configured environment for local processing
**All commands must be configured for the used environment in the used operating system

Supported operating systems:
*Windows
*Linux
*Mac OS X
*generic "other" operating systems, addressed via "unsupported operating system"

Executability of the configured programs/scripts must be given.

== Configuration ==
Enable the configuration option "Enable local client process execution" in "Configuration" -> "Seon Enterprise", section "Seon Webaccess":

[[Image:Enable local client process execution.png]]

When enabled, a tabbed panel offers the configuration of the script/program location for every platform. In case that the platform cannot be selected correctly, the fallback "Other" will be used.

=== Supported script locations ===
There are two modes for script locations:
*Web locations: starting with "<code>http</code>", these locations will trigger a special logic by downloading them to the client in case of execution. The download location is a temporary location, whatever the operating system offers as a temporary path (may be influenced by user settings).
*Local location: all configurations which don't start with "<code>http</code>" will start the configured script at the configured position. These must be locally available paths.

In case of a web location, the client checks if the location is approved by the user. For non-approved locations, the user will be prompted for the first time of access to the URL if he allows to download and execute the program/script from the given position.

=== Special files ===
In Windows, script types with the file extension "<code>.vbs</code>" will lead to an invocation of the Visual Basic interpreter in command line mode, which suppresses the opening of annoying command shell windows ("<code>cmd.exe</code>") during execution.

== Script / Programs ==
There exist three configuration options for the following cases:
*Environment listing script: tool to resolve environments usable by the client
*DLName listing script: tool to deliver a list of directories, given in a special format also known as "DLName"
*Export script: tool to export selected files in the used environment

=== Windows scripting hints ===
When dealing with the pipe symbol "<code>|</code>" scripting could be sometimes tricky. Be sure to escape the pipe for output in scripts. Example:
@echo off
echo dc_r1^|Daimler AG
echo pag^|Porsche AG
echo bmw^|BMW AG

=== Environment listing script ===
The environment list script will be executed dynamically on the client to list all available environment:

[[Image:StreamingSmoke envList.png]]

Parameters:
*none
Expected returncode:
*0: in case of success
*non 0: in case of errors

Output (written to standard output ["<code>stdout</code>"]) must have the following line syntax:
<internal ID>|<Descriptor for GUI>
Lines may be seperated by linefeed or carriage-return/linefeed. The internal ID will be re-used later. The separator is the "pipe" symbol "<code>|</code>".

Example output:
dc_r19|Daimler AG
pag|Porsche AG
bmw|BMW AG

=== DLName listing script ===
The DLName listing script will be executed after selection of the environment in order to show all available directories/DLNames. All DLNames must be written to standard output, the output expected there will be used for the DLName list.

[[Image:StreamingSmoke dlnames.png]]

Parameters:
#internal ID of the environment retrieved above

Expected returncode:
*0: in case of success
*non 0: in case of errors

Output (written to standard output ["<code>stdout</code>"]) must have the following line syntax:
<DLName>;<Windows path>;<Unix (Mac, Linux; unsupported OS) path>;[<optionally: parent DLName>]

Lines may be seperated by linefeed or carriage-return/linefeed. The internal ID will be re-used later. The separator is the "pipe" symbol.

Example output:
00000000-START;d:\tmp;/catiav5/s1/mx/00000000;
DRAWINGS;d:\tmp\2d;/catiav5/s1/mx/2d;00000000-START
MODELS;d:\tmp\3d;/catiav5/s1/mx/3d;00000000-START

Multiple hierarchy steps are supported, as long as the referenced element is available above (say: in upper lines). DLNames must be unique!

=== Export script ===
The export script will be executed if:
*the user double-clicks on an entry in the directory listing, leading to an export of the selected entity
*the users clicks on the export button above the file listing

[[Image:StreamingSmoke export.png]]

Parameters:
#internal ID of the environment retrieved above
#absolute path to input file
#absolute path to output file

Expected returncode:
*0: in case of success
*non 0: in case of errors

Output (written to standard output ["<code>stdout</code>"]) will be attached to the plugin output (with a maximum size of 32kB) of the exported file in case of success. In case of unsuccessful export, the output will be used to display error messages to the user.

==== Format of input file ====
The input file will be a line-seperated list of files with absolute paths which are intended to be exported. Example:
D:\catiaV5\s1\env\mx\00000000\testfile1
D:\catiaV5\s1\env\mx\00000000\testfile2
D:\catiaV5\s1\env\mx\00000000\testfile3
D:\catiaV5\s1\env\mx\00000000\testfile4
D:\catiaV5\s1\env\mx\00000000\testfile5

Depending on the client's operating system, the input list contains windows or unix paths. Windows path information may include slashes ("<code>/</code>") instead of backslashes ("<code>\</code>") as directory separator.

==== Format of output file ====
The expected output file will be a line-seperated list of files with absolute paths. Each file, splitted on a new line, will be used to upload this file. The output file list must not be the exact copy of the input file list, so a dynamic behaviour can be implemented here. Example:
C:\temp\catiaV5_export.tar

The file upload mechanism will not delete any dynamically file, so it's your (asynchronous) task to delete these (possibly created) files on your own.

== Logging ==
Local process execution and file handling will be logged in the plugin's logger, which writes its information to a defined location:
*Windows:
%USERPROFILE%\AppData\LocalLow\Seon\logs\StreamingSmokePlugin.log
*Mac OS X:
$HOME/Library/Application Support/Seon/logs/StreamingSmokePlugin.log

[[Category:Seon Enterprise]]

Seon Server-side plugin philosophy

2017-08-08T13:50:45Z

Admin:

Seon Enterprise job view configuration

2017-08-08T13:50:34Z

Admin:

Seon support a mechanism where Seon Enterprise (send and receive) jobs are visible to others than the person the job is attached to. This includes access to all meta information of the job, the files if available and actions for this job, such as downloading, restart, forwarding, print etc.

This functionality, available since Seon release 2015-02-20, replaces the configuration option "department view of Seon Webaccess jobs". If this configuration was enabled during update time, the software migration creates an entry for every department so that the department view is restored as configured. The mechanism is new, the end result is the same.

== Examples ==
*An Seon Enterprise job sent by user A is also visible to a specific user B
*An Seon Enterprise job sent by user A is also visible to all members of a specific department C
*An Seon Enterprise job sent by user A is also visible to all members of a specific department D
*An Seon Enterprise job sent by user A is also visible to all members of a specific company E
*All jobs for department F are visible to a specific person G
*All jobs for location H are visible to a specific department J
*...

With this functionality, you can configure situations like:
*Administrative users can see jobs of all entities.
*Members of an administrative department can see jobs of specific companies, locations, departments etc.
*"Project" / "teamwork" / any kind of collaboration service, so specific users gain access to pseudo-recipients of jobs, addressed as anonymous recipients from external.

== Configuration ==
The partner hierarchy of Seon consists of four levels:
#company
#location
#department
#recipient / end user

The configuration of such an allocation is possible at every level of hierarchy, via a button at the bottom of the configuration in the fieldset "Seon Enterprise / Plugin groups". This fieldset is only visible to already created entities, so adding entities to a company actually don't have such a functionality. Edit the entity of desire for configuring the viewable jobs.

=== Configuration rules ===
The same as configuring plugin groups, you can define a limitation at every hierarchical level. The deepest configuration takes place, so above configurations won't be used. Example:
*Rules configured at location level override rules configured at company level
*Rules configured at department level override rules configured at company and location level
*Rules configured at end user level override rules configured at company, location and department level

With this mechanism, you can define rules very precisely.

=== Selecting entities ===
When configuring rules, you have to selected entities to which the selected entity (i.e. company, location, department or end-user) has access to. This is done via a tree selection, which is scrollable and resizable:

[[Image:Google ChromeScreenSnapz158.png]]

If only active entities are requested, press the button "Only show active entries":

[[Image:Google ChromeScreenSnapz159.png]]

Some rules for enabling entities:
*When enabled an entity, the above entities will be deselected (since a "deeper" selection overrides the above one). This deselection is made automatically for you.
*When an entity is moved to a new location, it saves its selected state. Example: If a department is activated, and later-on moved to another location or another partner, the selected department will still be active in selection, even in the new location.
*When clicking on the button "Only show active entries", this action implies that the actual selection will be saved before a re-displaying takes place.

=== Editing at company level ===
[[Image:Google ChromeScreenSnapz160.png]]

=== Editing at location level ===
[[Image:Google ChromeScreenSnapz161.png]]

=== Editing at department level ===
[[Image:Google ChromeScreenSnapz163.png]]

=== Editing at recipient / end user level ===
[[Image:Google ChromeScreenSnapz164.png]]

== Resetting configuration ==
If any selection is made at a level, the button "Reset config" becomes active. When clicking this button, a confirmation question is being asked if you really want to delete the configuration. When accepting the question with "Yes", the configuration will be deleted for this entry at this level:

[[Image:Google ChromeScreenSnapz165.png]] [[Image:Google ChromeScreenSnapz168.png]]

After having resetted the configuration, the reset button becomes inactive.

[[Category:Seon Enterprise]]

Seon Enterprise recipient configuration

2017-08-08T13:50:25Z

Admin:

Seon Enterprise supports a mechanism (often referred as "multi-client capability") which is the ability to confige very precisely to which entities a user of the sytsem has access to send send jobs.

== Examples ==
*Members of a company A may only send jobs to company B, C and D
*Members of company A1, location L1 should only be able to send jobs to company B, but members of company A1, location L2 should be able to send jobs to company C. Members of company A1, location L3 should be able to send jobs to both company B and C.
*Members of department D1 should be able to send to members of company C1, but only location L1 or department D1.

== Configuration ==
The partner hierarchy of Seon consists of four levels:
#company
#location
#department
#recipient / end user

The configuration of such an allocation is possible at every level of hierarchy, via a button an the buttom of the configuration in the fieldset "Seon Enterprise / Plugin groups". This fieldset is only visible to already created entities, so adding entities to a company actually don't have such a functionality. Edit the entity of desire for configuring the assignment of recipients.

=== Configuration rules ===
The same as configuring plugin groups, you can define a limitation at every hierarchical level. The deepest configuration takes place, so above configurations won't be used. Example:
*Rules configured at location level override rules configured at company level
*Rules configured at department level override rules configured at company and location level
*Rules configured at end user level override rules configured at company, location and department level

With this mechanism, you can define rules very precisely.

=== Selecting entities ===
When configuring rules, you have to selected entities in which an allowed recipient must be placed in. This done via a tree selection, which is scrollable and resizable:

[[Image:Google ChromeScreenSnapz123.png]]

If only active entities are requested, press the button "Only show active entries":

[[Image:Google ChromeScreenSnapz124.png]]

Limiting possible recipients to this (above) selection would lead in Seon Webaccess to a list of possible recipients as in this screenshot:

[[Image:Google ChromeScreenSnapz125.png]]

Some rules for enabling entities:
*When enabled an entity, the above entities will be deselected (since a "deeper" selection overrides the above one). This deselection is made automatically for you.
*When an entity is moved to a new location, it saves its selected state. Example: If a department is activated, and later-on moved to another location or another partner, the selected department will still be active in selection, even in the new location.
*When clicking on the button "Only show active entries", this action implies that the actual selection will be saved before a re-displaying takes place.

=== Editing at company level ===
[[Image:Google ChromeScreenSnapz111.png]]

=== Editing at location level ===
[[Image:Google ChromeScreenSnapz114.png]]

=== Editing at department level ===
[[Image:Google ChromeScreenSnapz115.png]]

=== Editing at recipient / end user level ===
[[Image:Google ChromeScreenSnapz116.png]]

== Resetting configuration ==
If any selection is made at a level, the button "Reset config" becomes active. When clicking this button, a confirmation question is being asked if you really want to delete the configuration. When accepting the question with "Yes", the configuration will be deleted for this entry at this level:

[[Image:Google ChromeScreenSnapz117.png]] [[Image:Google ChromeScreenSnapz119.png]]

After having resetted the configuration, the reset button becomes inactive.

== Limitations ==
This mechanism does not include entities of the "recently addressed" persons (say: if a limitation has occured after a send job has been initiated to a specific person, the user is still able to select this used recipient from the pull-down list of already addressed recipients). Also, the functionality "Reply" in the job details of an Seon job in Seon Webaccess is unimpressed by this functionality.

[[Category:Seon Enterprise]]

Seon Enterprise partner management

2017-08-08T13:49:04Z

Admin:

=== Partner hierarchy ===
Seon Enterprise contains a four-level partner hierarchy (as used in the industry standard ENGDAT):
*[[Seon Core partner administration|partner]]
*[[Seon_Enterprise_partner_management#location_management|location]]
*[[Seon_Enterprise_partner_management#department_management|department]]
*[[Seon_Enterprise_partner_management#person_management|person]]

[[Image:Seon Enterprise partnerlist.png]]

These four levels are implemented in Seon Enterprise as a 1:1 relation, so a location can only be contained in one [[Seon_Core_partner_administration|partner company entry]], same to the departments and recipients.

In case of Seon Core, only the first level exists (partner), the following are not needed.

=== partner management (Seon Core & Seon Enterprise) ===
Seon Core is based on partner entries in the configured partner database table. In order to administrate these entries via web interface, refer to the following possible tasks . For a commandline based administration, refer to the binary [[Seon_Core_binaries#seonped|seonped]].

[[listing partners]]

[[creating partner]]

[[editing partner]]

[[deleting partner]]

----
''(Seon Enterprise below)''

=== location management (Seon Enterprise) ===
[[listing locations]]

[[creating location]]

[[editing location]]

[[deleting location]]

=== department management (Seon Enterprise) ===
[[listing departments]]

[[creating department]]

[[editing department]]

[[deleting department]]

=== person management (Seon Enterprise) ===
[[listing persons]]

[[creating person]]

[[editing person]]

[[deleting person]]

[[Category:Seon Enterprise]]

Seon Enterprise partner migration

2017-08-08T13:48:52Z

Admin:

Seon Enterprise offers various import possibilities of hierarchical data of partner information. If none of the offeres solutions fits your needs, please contact us in order to search for a valid solution, we will help you out.

== Doing ==
Most partner import processes are executed via the administrative web interface. Locate the menu entry point "Programs" -> "Partner import":

[[Image:Partner import.png]]

== Daxware import ==
Daxware 2002 installations can export their partner information in CSV format, so the two steps have to be executed in the following order:
#Import "partner companies and locations" CSV
#Import "departments and recipients" CSV
The second step is based on the first step, so it would make no sense to switch the order of import.

== Hüngsberg/Wiberg Daxware (with OFTP2) ==
The Hüngsberg Daxware / Wiberg Daxware solution supporting OFTP2 can be imported in three sequential steps:
#Import the file "passw.dax" containing all OFTP stations
#Import the file "partner.dax" containing the OFTP2 configuration of all stations
#Import a CSV file of the MS-SQL database table "dbo.engdatProfileElements"

The CSV file of the database table can be extracted from the database via Microsoft's SQL Server Management Studio. Select all entries of this database table, copy&paste the data into a spreadsheet application (like Excel or Libre-/OpenOffice and save the contained data including the header line into a new CSV file.

There must exist a header line. The format of the header line is (26 fields):
ID;ParentID;ProfileName;LogischeAdresse;EngdatCode;Kurzname;Abteilung;Name;Firma;Strasse;PLZ;Ort;Land;Tel;Fax;eMail;Text;Application;ApplicationVersion;Format;FormatVersion;DataCode;FileStatus;TextFile;ZIP;oftpid

The imported entities have the following configuration:
*All OFTP partners have the plugin group for send jobs defined as configured in [[Seon_Core_configuration#default_send_plugin_group|Configuration -> Seon Enterprise -> Default send plugin group]]
*All OFTP2 partners with active security parameters are being polled to obtain their certificate from the TLS server, so network availability must be given. In this step, the own TLS server certificate is being used for all local operations.
*All values "NULL" are replaced with empty definitions.
*If no location name is being defined in the CSV file, a default value "-" is used.
*If no department name is being defined in the CSV file, a default value "-" is used.
*The name and surname of persons is being extracted via the field "Name". If no valid name is configured, the name is extracted from the field "ProfileName".

== EurexC ==
The import of EurexC based systems can be divided in two supported versions:
*Versions of EurexC CAD base which have the partner configuration in a file named "<code>xx020.d</code>"
*Versions of EurexC CAD base which have the partner configuration in a file named "<code>xx030.d</code>"

When enabling the checkbox "Purge existing partners before migration", all partners will be deleted before migration starts.

When enabling the checkbox "Create dummy hierarchy for Seon Enterprise", a location with the same name as the partner is created for every entry. In this location, a department "OFTP" is added, where a user "Admin" is being added. This checkbox is only available if [[Seon_Core_configuration#is_Seon_Enterprise_installed.3F|Seon Enterprise]] is enabled in the configuration.

All special characters, i.e. german umlauts, are converted to newline due to the fact that the encoding is unknown.

== WinElke ==
WinElke systems which are based on MS Access databases can be imported on a limited amount of platforms which support the binaries for the required tools. Just upload the MS Access file if the button is enabled.

== SWAN 3.x ==
The partner databae schema must exist in the same database which Seon is working on. If the underlying tables exist, but the button is disabled, please contact us in order to verify your (possibly inconsistent) data.

== CSV ==

=== Daxware CSV ===
Via the Daxware import possibility, you can generate CSV files with a given format in order to import your partner data. The format of the files must follow a fix syntax.

The CSV for companies and locations (in one file) must contain exactly this following header line as the first line to be contained in the CSV file:
Companyname;Street;Housenumber;PostalCode;City;Country;Phonenumber;Fax;SSID;SFID;Net;Address;Password;Characterset;Fileformat;Recordsize

The second file for departments and recipients must contain exactly this following header line as the first line to be contained in the CSV file:
Companyname;Companylocation;Lastname;Firstname;Phonenumber;Mobilenumber;Faxnumber;eMail;Department;Password;Userrole

The references between the two files are the names of the company (1. "Companyname" = 2. "Companyname" ) and the location name 1. "City" = 2. "Companylocation").

The field names indicate the value of the entity. Some words about special values:
*Companies and locations CSV:
**<code>Net</code>: The textual value "<code>ISDN</code>" masks this as an ISDN connectivity partner, the given address is then the ISDN number. Otherwise, it's implicitely a TCP/IP connection partner, the address is then the TCP/IP hostname or IP address.
**The own values of the local SSID, SFID and password are taken from the configuration of "[[Seon_Core_configuration#Odette_parameters|Odette parameters]]" in the section "[[Seon_Core_configuration|Configuration]]"
**all partner companies with the same name are being updated; all others are inserted
*Departments and recipients CSV:
**Entries with the same department, same company, same first name and same last name are updated; all others are inserted
**all departments of a given location with the same department name are being updated; all others are inserted

=== Generic CSV ===
In addition to the above documented Daxware CSV format, you can upload a CSV formatted file for departments and recipients with two more attributes (starting with Seon release 2015-04-29):
*address code
*username
The header of the CSV file must be:
Companyname;Companylocation;Lastname;Firstname;Phonenumber;Mobilenumber;Faxnumber;eMail;Department;Password;Userrole;AddressCode;Username

== DDX ==
The migration of DDX databases is supported, if all requirements are fulfilled:
*Seon Enterprise is licensed (needed for the complete functionality).
*The Oracle database client is installed an usable on the webserver, also the PHP module is available and properly installed (''this is the case for the pre-installed Seon virtual appliance'').
*The database connection is known to the DDX database (reachable via network connection).

All entities available in the database will be migrated. These are:
*The own company structure, selectable from a list of available entities.
*All other communication partners, both OFTP and FTP systems are supported.
*All jobs are migrated, including meta-information like date, sender, recipient and files (including relative, absolute and virtual file path/-name information).

Depending on the speed of your system(s), the migration should not take longer than 10 minutes.

[[Category:Seon Enterprise]]

PAM configuration for Windows Active Directory

2017-08-08T13:48:36Z

Admin:

If you want to configure Seon to authentificate users with the configured username via a centralized Windows Active Directory service, you have to configure the PAM security system of the underlying Unix environment.

''This documentation is based on the Seonvirtual VMware image, which uses the latest Debian Linux distribution. If you have any other distribution, you may re-use these information in order to configure your environment accordingly.''

Configuring the connectivity consists of several steps, which are described here:

== Declarations ==
In this documentation, several values will be used for hostnames, domain name, usernames and password. These are only examples and must be changed according to your environment.

AD server:
Hostname and aliases: 192.168.1.65
name alias: w2k8
local hostname seen from Windows side: dc.w2k8.c-works.net
Active directory domain name: w2k8.c-works.net
Kerberos realm: W2K8.C-WORKS.NET
(The kerberos realm is the domain name in upper case characters!)

User for connecting to domain (with administrative rights, but without permission to login interactively on AD server):
Username: pamauth
Password: Test1234
User to be authentificated (as an example) and configured in Seon:
Username: adUsername1
Password: Seonpwd

Username: seon
Password: Test1234

[[Image:MMC Active Directory users and computers.png]]

All commands on the Linux side are executed in the context of the user "<code>root</code>".

== Network availability ==
The AD server must be reachable via network on the Linux side:
<pre>
seonvirtual:~# ping -c 3 dc.w2k8.c-works.net
PING dc.w2k8.c-works.net (192.168.1.65) 56(84) bytes of data.
64 bytes from 192.168.1.65: icmp_req=1 ttl=128 time=0.762 ms
64 bytes from 192.168.1.65: icmp_req=2 ttl=128 time=0.737 ms
64 bytes from 192.168.1.65: icmp_req=3 ttl=128 time=0.659 ms

--- dc.w2k8.c-works.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2013ms
rtt min/avg/max/mdev = 0.659/0.719/0.762/0.049 ms
</pre>

== Synchronize time ==
The underlying security model relies on synchronized time between (Active Directory) server and (Linux Seon) client). Windows Active Directory servers offer a NTP server which can be used for time synchronization.
ntpdate dc.w2k8.c-works.net
If the domain controller server doesn't run as time server, be sure to use the same time source for local and remote time synchronization.

== Install required software ==
The PAM user authentification relies on two packages:
*Winbind
*Samba
*Kerberos
If not installed already, install these packages through the local Linux packaging system:
apt-get install winbind samba krb5-kdc
During installation of Kerberos, you will be asked for a default realm: leave this entry empty, we will configure it afterwards.

== Configure Samba ==
You have to configure the Samba component. Edit the file "<code>/etc/samba/smb.conf</code>" with your favorite text editor and make the following changes in the configuration section '<code>global</code>':
[global]
security = '''ads'''
realm = '''W2K8.C-WORKS.NET'''
password server = '''192.168.1.65'''
workgroup = '''W2K8'''
client ntlmv2 auth = yes
encrypt passwords = yes
winbind use default domain = yes
winbind refresh tickets = yes
restrict anonymous = 2

== Restart services ==
In order to activate the changes, restart the needed services:
seonvirtual:/etc/samba# '''/etc/init.d/winbind stop'''
Stopping the Winbind daemon: winbind.
seonvirtual:/etc/samba# '''/etc/init.d/samba restart'''
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
seonvirtual:/etc/samba# '''/etc/init.d/winbind start'''
Starting the Winbind daemon: winbind.

== Configure Kerberos ==
Run the following command in order to configure Kerberos interactively:
dpkg-reconfigure krb5-config
Answer the following question according to our default values as described above:
Default Kerberos version 5 realm: W2K8.C-WORKS.NET
Add locations of default Kerberos servers to /etc/krb5.conf? - Yes
Kerberos servers for your realm: dc.w2k8.c-works.net (''the IP address 192.168.1.65 would be valid, too'')
Administrative server for your Kerberos realm: dc.w2k8.c-works.net (''the IP address 192.168.1.65 would be valid, too'')

== Initialize Kerberos ==
Setting up Kerberos with the Active Directory server will be finished via authentificating as administrative user of the domain:
kinit pamauth@W2K8.C-WORKS.NET
Be sure to give the Kerberos realm name in uppercase characters completely!

== Join domain ==
In order to join the domain, execute the following command, passing the username of a valid administrative user of the domain:
net ads join -U pamauth
After giving the correct password, an informational output must state that the domain join succeeded (warnings about DNS updates may appear, they can be ignored):
seonvirtual:~# net ads join -U pamauth
Enter pamauth's password:
Using short domain name -- W2K8
'''Joined 'SeonVIRTUAL' to realm 'w2k8.c-works.net''''
''No DNS domain configured for localhost. Unable to perform DNS Update.''
''DNS update failed!''

== Configure PAM to use Winbind ==
Create or edit the file "<code>/etc/pam.d/seon</code>" to contain the following line in order to allow Seon PAM authentification to use Winbind (which now uses Active Directory via Kerberos):
auth required pam_winbind.so

== Restart Winbind a last time ==
Restart Winbind for a last time in order to refresh its ressources:
seonvirtual:/etc/samba# /etc/init.d/winbind start
Starting the Winbind daemon: winbind.

== Configure user to authentificate via PAM ==
You can now configure your Seon Webaccess users to use PAM as authentification method:

[[Image:Seonadmin configure user PAM auth.png]]

You can also use the username declaration including the domain name:

[[Image:Seon webaccess login with domain user.png]]

== Troubleshooting ==
If authentification fails without any reason, a good starting point to react is to restart Winbind (before raising loglevels in Winbind, Samba and/or Kerberos):
seonvirtual:/etc/samba# '''/etc/init.d/winbind restart'''
Any logging in Samba, Winbind, Kerberos and the kernel logs contain reasons why authentification may have failed.

[[Category:Seon Enterprise]]

Seon Enterprise user authentification

2017-08-08T13:48:27Z

Admin:

== User authentification methods ==
Seon supports two user authentification methods. Addition methods could be implemented in the future.

=== internal authentification ===
The user will be authentificated via a given username and a hashed password. This one-way hashed password is not recreatable and stored as a text field in the Seon database. If you want to authentificate users with given credentials, you have to define a username and a non-empty password. The user will be able to change his password via [[Seon Webaccess]], the end-user interface.

=== PAM ===
PAM ("Pluggable Authentication Modules") support a dynamic mode of authentification of users. In this way, a system administrator is able to define how users of Seon will be authentificated. PAM is also used in many single-sign-on (SSO) environments. Many modules exist for PAM, so LDAP, MS Active Directory, NIS and other third-party authentification modes are available. In order to use PAM, you have to know the service name Seon uses. Its fix-coded value is
seon
So you have to create a file in your PAM configuration directory, which is in most cases
/etc/pam.d
The name of the file is the service name, so the absolute path to the Seon PAM configuration file is:
/etc/pam.d/seon
The content could be copied from existing configurations, the only method used is "<code>auth</code>". Here an example:
auth required pam_nologin.so
auth sufficient pam_securityserver.so
auth sufficient pam_unix.so
auth required pam_deny.so

==== Documentation links ====
For more information on PAM, refer to the documentation, available at http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/

Some possible modules are documented here: http://www.kernel.org/pub/linux/libs/pam/modules.html

An example on how to authentificate users via MS Active Directory: http://developer.novell.com/wiki/index.php/HOWTO:_Configure_Ubuntu_for_Active_Directory_Authentication

[[Category:Seon Enterprise]]

Seon Web access installation and configuration

2017-08-08T13:48:12Z

Admin:

== Directory configuration ==
The user running the web server must be able to read, execute and write the following directories:
*[[Seon_Core_configuration#data_outgoing_directory|data outgoing directory]]
*[[Seon_Core_configuration#temporary_directory|temporary directory]]

== Large file support ==
Uploading files bigger than 2GB is a matter of the used webserver (i.e. Apache). Most common distributions include an Apache binary which is compiled with LARGEFILE support (which enables the upload of such big files).
Also, your Web browser must support this feature, so it's most common to use the latest version available.

Starting from Q3/2013, Seon Webaccess offers a HTML5 file upload mechanism which supports files bigger than 2GB. Please configure your PHP backend to a maximum file upload and POST size of at least 128MB (which is a maximum single slice size of the divided file).

== Direct job access ==
Starting with Seon 2014-12-09, you can point a user to a specific job in Seon Webaccess. This is done by a URL "GET" parameter, namely:
job
A URL to Seon Webaccess, pointing to job 18877 could be:
http://seon-server/webaccess/index.html?job=18877

If the logged in user is not allowed to view this job, nothing happens. If the user is allowed, the job will be the active tab in Seon Webaccess after successful login.

== Pre-setting username ==
Starting with Seon 2015-01-20, you can preset a username which will be filled in the login prompt. The URL parameter is:
username
A URL to Seon Webaccess, using user "kochha" will be:
http://seon-server/webaccess/index.html?username=kochha

[[Category:Seon Enterprise]]

Seon Enterprise - Seon Webaccess configuration

2017-08-08T13:47:53Z

Admin:

The following configuration parameters, configurable in "Configuration" -> "Seon Enterprise" influence the behaviour of Seon Webaccess, the end user web interface for using Seon Enterprise functionality.

[[Image:Configuration Seon Webaccess.png]]

=== Encrypt Webaccess session information? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_encrypt
|}
If enabled, Seon Webaccess saves the session information for the logged in user in the database encrypted. This increases the CPU load of the webserver.

=== Compress Webaccess session information? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_compress
|}
If enabled, Seon Webaccess saves the session information for the logged in user in the database compressed. This increases the CPU load of the webserver.

=== Don't show receive queue view? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_disable_recq
|}
Seon Webaccess can show the receive queue (without administrative capabilities) to the end-user in a stripped view, containing company name, progress information etc. If you don't want this, you can disable the rendering of this overview for every user.

=== Don't show send queue view? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_disable_sendq
|}
Seon Webaccess can show the send queue (without administrative capabilities) to the end-user in a stripped view, containing company name, progress information etc. If you don't want this, you can disable the rendering of this overview for every user.

=== Show incoming jobs without recipient? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_show_invalid_rec_jobs
|}
Jobs without a valid recipient must normally be handled seperately, i.e. by routing them to a target destination. If you don't want to invest this administrative overhead, you can give users of Seon Webaccess the possibility to view incoming jobs without recipient. They can handle the job as a normal receive job, including fetching files, forward this job etc.

=== Session timeout ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_session_timeout
|}
After this configured timeout (in minutes) Seon Webaccess removes stale sessions of logged in users.

=== Highlight address code in ENGDAT filenames? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_highlight_addresscode
|}
If a filename is not converted to a human-readable filename (i.e. if the sender didn't define it in an ENGDAT abstract file), the filename can be hard to read. In order to increase the readability of the address code of the file (which defined the recipient of the file), it can be highlighted in the following ways:

*bold
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_highlight_addresscode_bold
|}
*underlined
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_highlight_addresscode_underline
|}
*italic
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_highlight_addresscode_italic
|}

=== Enable local client process execution? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_use_streamingSmoke
|}
Seon Webaccess offers a plugin for local file execution ("local CAD system integration"). If this configuration option is enabled, and if the corresponding platform dependant configuration is set up correctly, the user gets a possibility to process files before upload.

The platform dependant script configurations are:
*Windows:
**Environment listing script URL: <code>streamingSmoke_list_url_Windows</code>
**DLName listing script URL: <code>streamingSmoke_dlname_url_Windows</code>
**Export script URL: <code>streamingSmoke_exec_url_Windows</code>
*Mac OS X:
**Environment listing script URL: <code>streamingSmoke_list_url_MacOSX</code>
**DLName listing script URL: <code>streamingSmoke_dlname_url_MacOSX</code>
**Export script URL: <code>streamingSmoke_exec_url_MacOSX</code>
*Linux:
**Environment listing script URL: <code>streamingSmoke_list_url_Linux</code>
**DLName listing script URL: <code>streamingSmoke_dlname_url_Linux</code>
**Export script URL: <code>streamingSmoke_exec_url_Linux</code>
*Other:
**Environment listing script URL: <code>streamingSmoke_list_url_unsupportedPlatform</code>
**DLName listing script URL: <code>streamingSmoke_dlname_url_unsupportedPlatform</code>
**Export script URL: <code>streamingSmoke_exec_url_unsupportedPlatform</code>

=== Show all incoming jobs of department? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_show_dep_jobs_incoming
|}
If a department view of incoming jobs is wanted, enable this configuration option.

==== Hide recipient column for incoming jobs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_hide_incoming_jobs_recipients_column
|}
If the department view of incoming jobs is enabled, a column is added to the job list containing the recipient of the job. Enabling this configuration option eliminated this column.

=== Show all outgoing jobs of department? ===
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_show_dep_jobs_outgoing
|}
If a department view of outgoing jobs is wanted, enable this configuration option.

==== Hide sender column for outgoing jobs? ====
{|style="background:white"
|- style="background:lightgrey;"
| '''DB configuration name:''' || webaccess_hide_incoming_jobs_recipients_column
|}
If the department view of incoming jobs is enabled, a column is added to the job list containing the sender of the job. Enabling this configuration option eliminated this column.

[[Category:Seon Enterprise]]

Category:Seon Enterprise

2017-08-08T13:47:32Z

Admin: Created blank page

Seonrestart

2017-08-08T13:47:20Z

Admin: Created page with "== Binary == The program to restart an Seon job is installed in the configure binary installation directory (default:..."

== Binary ==
The program to restart an Seon job is installed in the configure [[Seon_Core_configuration#binary_installation_directory|binary installation directory]] (default: <code>/opt/seon/bin/</code>). The name is "<code>seonrestart</code>".

== Syntax ==
If you start the program without any parameters, it displays its syntax:
<pre>
seon:~ $ /opt/seon/bin/seonrestart
Seon restart plugin v3.0

Usage: /opt/seon/bin/seonrestart <jobnumber|xml_file> [0|1: from scratch] [stepNumber, default: 0 (only, if from scratch is disabled)]
</pre>

Parameters explained:
*1: job number or XML file: the job number must be a numeric decimal value without proceeding zeroes. If no job number is extracted from this parameter, the parameter is treated as a file parameter. The file will be interpreted as Seon job XML, where in the XPath "<code>/Seon_job/job_information/job_number</code>" the job number will be extrated.
*(optional) 2: value 0 or 1: restart job from scratch. This option is only valid for incoming jobs, where the configured "[[Seon_Core_configuration#default_receive_plugin_group|default receive plugin group]]" will be executed before the extracted recipient's plugin group.
*(optional) 3: step number: if the job is not restarted from scratch (see parameter 2), it is possible to restart a job from a given plugin index. This is the step number, beginning from 1 in the extracted plugin group of the job recipient.

== Behaviour ==
If the job to be canceled is in a state of "waiting for asynchronous plugin", the asynchronous plugin will be called with the cancel option ("<code>-c</code>") so it can cleanup its working files correctly. Afterwards, the job is being restarted and plugin execution will be done. The program "<code>seonrestart</code>" will not wait until the plugin group is finished, it forks a child process which runs independantly.

== Licensing ==
A valid Seon Enterprise (Lite) license is required.

== Requirements ==
*The job number must exist, of the job XML must contain an extractable job number.
*The job must be linked to a valid initial job XML (which is not the case for unfinished receive jobs).
*The recipient of the job must have a configured plugin group according to the direction of the job.

[[Category:Seon Enterprise]]

Seon Enterprise

2017-08-08T13:47:00Z

Admin:

Seon Enterprise brings a lot of new functionality. The documentation consists of several chapters:

[[Seon Enterprise - Seon Webaccess configuration]] - Configuration options in "Configuration" -> "Seon Enterprise"

[[Seon Web access installation and configuration]]

[[Seon Enterprise user authentification]] - internal with password or PAM

*[[PAM configuration for Windows Active Directory]]

[[Seon Enterprise partner migration]]

[[Seon Enterprise partner management]]
*[[Seon Enterprise recipient configuration]]
*[[Seon Enterprise job view configuration]] - make Seon job accessible throughout different organizational entities

[[Seon Server-side plugin philosophy]]

[[Seon client-side plugin philosophy]] - managing local data processing in Seon Webaccess (i.e. CatiaV5 integration)

[[Seon plugin groups]]

[[Seon Enterprise plugins]]

[[Seon Enterprise - other protocols]]

[[Seon Enterprise Light - allowed plugins]]

[[Seon Enterprise - sending ENGPART]]

[[Seon Enterprise - importing ENGPART]]

[[Seon Enterprise - Job management]]

[[Seon Enterprise - Fetch files from (S)FTP server]]

[[Seon Enterprise - job processing at given time]]

[[Seon internet job sharing|Seon Enterprise - internet job sharing]]

[[Seon Enterprise - internal job handling]]

== additional binary documentation ==

On top of Seon Core, Seon Enterprise introduces some new programs, needed for the handling of Seon Enterprise. These programs are:

*seon_async_plugin_handler
*seoncancel
*seonclientd
*seon_extract_recipient_email_from_xml
*seon_extract_sender_email_from_xml
*seon_recfile_sorter
*[[seonrestart]]
*seonroute
*seon_sqd_async_handler
*seon_sqd_blocked_handler
*seon_engpart_send
*[[seon_create_enterprise_sendjob]]

Seon plugin seonplugin manipulate xml

2017-07-27T10:00:30Z

Admin: Created page with "Category:Plugins == Purpose == Manipulate job XML nodes via regular expressions, based on the content of the same or other XML nodes of the job XML. == Requirements == *S..."

[[Category:Plugins]]
== Purpose ==
Manipulate job XML nodes via regular expressions, based on the content of the same or other XML nodes of the job XML.

== Requirements ==
*Seon Enterprise license

== Configuration ==
*Source XPath: the source XPath expression of a XML node which contains the source text information.
*Modification regular expression: the Perl regular expression (preg) rule which defines the result text, based on the source XML node text.
*Target XPath: the target XPath expression, where the target extrapolated information is stored.
*Create non-existing target XPath: if the last node of the target XPath is not-existant, the plugin will create it.

== Behaviour ==
*The exact same amount of source XPath results must exist as the amount of target XPath results
**If you modify files in a job, you can only modify target XPaths of the same amount, which is normally a file target XPath.
*The source XPath must be a XML node containing text. Empty text sources lead to a plugin error which aborts the job.
*If the target text is empty, the plugin exits with an error and the job aborts.
*When dealing with multiple XML results for source and target XPath expressions, the calculated target value is always put in the same XML structure where source source is located (but with calculated values of the corresponding node, see examples below).

== Examples ==
=== Scenario 1: change virtual filename based on real filename ===
Filename example in job:
Yanfeng_DESADV.dat

*Source XPath: /Seon_job/job_information/job_file/real_filename
*Modification regular expression: .*_(.*)..*
*Target XPath: /Seon_job/job_information/job_file/virtual_filename

Plugin output:
<pre>
Source XPath: '/Seon_job/job_information/job_file/real_filename'.
Modifying regular expression: '.*_(.*)\..*'.
Target XPath: '/Seon_job/job_information/job_file/virtual_filename'.

Source information #1: [Yanfeng_DESADV.dat]
Replacement of regular expression #1: [DESADV]
Target XPath expression found with one resultset.
</pre>

=== Scenario 2: change virtual filename based on real filename (multiple files in job) ===
Filename examples in job:
Yanfeng_DESADV.dat
Other_DELIVERY.dat

*Source XPath: /Seon_job/job_information/job_file/real_filename
*Modification regular expression: .*_(.*)..*
*Target XPath: /Seon_job/job_information/job_file/virtual_filename

Plugin output:
<pre>
Source XPath: '/Seon_job/job_information/job_file/real_filename'.
Modifying regular expression: '.*_(.*)\..*'.
Target XPath: '/Seon_job/job_information/job_file/virtual_filename'.
Creating non-existing target XPath has been configured as true.

Source information #1: [Other_DELIVERY.dat]
Replacement of regular expression #1: [DELIVERY]
Target XPath expression found with 2 resultsets.

Source information #2: [Yanfeng_DESADV.dat]
Replacement of regular expression #2: [DESADV]
Target XPath expression found with 2 resultsets.
</pre>

Relevant job XML nodes changed (after plugin exection):
<pre>
<job_file>
<real_filename>Other_DELIVERY.dat</real_filename>
<virtual_filename>DELIVERY</virtual_filename>
</job_file>
<job_file>
<real_filename>Yanfeng_DESADV.dat</real_filename>
<virtual_filename>DESADV</virtual_filename>
</job_file>
</pre>

=== Scenario 3: create new XML node based on real filename ===
Filename examples in job:
Yanfeng_DESADV.dat

*Source XPath: /Seon_job/job_information/job_file/real_filename
*Modification regular expression: .*_(.*)..*
*Target XPath: /Seon_job/job_information/job_file/my_own_node

Plugin output:
<pre>
Source XPath: '/Seon_job/job_information/job_file/real_filename'.
Modifying regular expression: '.*_(.*)\..*'.
Target XPath: '/Seon_job/job_information/job_file/my_own_node'.
Creating non-existing target XPath has been configured as true.

Source information #1: [Yanfeng_DESADV.dat]
Replacement of regular expression #1: [DESADV]
Retrying with XPath [/Seon_job/job_information/job_file]...
Target XPath expression found with one resultset.
Appending XML node: [my_own_node]
</pre>

Relevant job XML nodes changed (after plugin exection):
<pre>
<job_file>
...
<my_own_node>DESADV</my_own_node>
</job_file>
</pre>

Seon Enterprise plugins

2017-07-27T09:59:59Z

Admin:

[[Category:Plugins]]
== Plugin management ==

[[Add new plugins]]

----

The list of available plugins is continously growing. Click on a link below to retrieve the plugin's documentation:

[[Seon plugin mail_to_recipient]]

[[Seon plugin mail_to_sender]]

[[Seon plugin seonplugin_copy]]

[[Seon plugin seonplugin_engdat_light]]

[[Seon plugin seonplugin_engdatv2_encode]]

[[Seon plugin seonplugin_engdatv2_decode]]

[[Seon plugin seonplugin_enqueue]]

[[Seon plugin seonplugin_enqueue_passive]]

[[Seon plugin seonplugin_filetype_recognizer]]

[[Seon plugin seonplugin_gzip]]

[[Seon plugin seonplugin_remove_engdat]]

[[Seon plugin seonplugin_set_absolute_to_real_filename]]

[[Seon plugin seonplugin_set_rec_in_xml_by_db]]

[[Seon plugin seonplugin_set_recipient_by_engdat_light]]

[[Seon plugin seonplugin_set_sender_in_xml_by_db]]

[[Seon plugin seonplugin_filemove]]

[[Seon plugin seonplugin_filecopy]]

[[Seon plugin seonplugin_gtar]]

[[Seon plugin seonplugin_zip]]

[[Seon plugin seonplugin_bzip2]]

[[Seon plugin seonplugin_create_internal_job]]

[[Seon plugin seonplugin_promata_recipient]]

[[Seon plugin seonplugin_promata_recipient2]]

[[Seon plugin seonplugin_promata_sender]]

[[Seon plugin seonplugin_comsecure_decrypt]]

[[Seon plugin seonplugin_comsecure_encrypt]]

[[Seon plugin seonplugin_delete]]

[[Seon plugin seonplugin_bots_edi_translator]]

[[Seon plugin seonplugin_charset_convert]]

[[Seon plugin seonplugin_gzip_decompress]]

[[Seon plugin seonplugin_bzip2_decompress]]

[[Seon plugin seonplugin_zip_decompress]]

[[Seon plugin seonplugin_tar_decompress]]

[[Seon plugin seonplugin_permission]]

[[Seon plugin seonplugin_virt_filename2recipient_mapping]]

[[Seon plugin seonplugin_oftp_rename]]

[[Seon plugin seonplugin_transmission_pdf]]

[[Seon plugin seonplugin_filerename]]

[[Seon plugin seonplugin_set_recipient_by_file]]

[[Seon plugin seonplugin_set_sender_by_file]]

[[Seon plugin seonplugin_recipient_by_sfid]]

[[Seon plugin seonplugin_sender_by_sfid]]

[[Seon plugin seonplugin_ftp_upload]]

[[Seon plugin seonplugin_scp_upload]]

[[Seon plugin seonplugin_hqm_sealcheck]]

[[Seon plugin seonplugin_prowl]]

[[Seon plugin seonplugin_email_files]]

[[Seon plugin seonplugin_edi_add_newline]]

[[Seon plugin seonplugin_manipulate_xml]]

Seon plugin seonplugin edi add newline

2017-07-27T09:37:48Z

Admin: Created page with "Category:Plugins == Purpose == If a file is transfered in a fixed record format via OFTP(2), the file content will be extended by newlines ('<code>\n</code>') or configura..."

[[Category:Plugins]]
== Purpose ==
If a file is transfered in a fixed record format via OFTP(2), the file content will be extended by newlines ('<code>\n</code>') or configurable by cariage-return linefeed ('<code>\r\n</code>') after every record.

== Requirements ==
*Seon Enterprise license

== Configuration ==
*Keep original file: the original file will be copied to file with the appendix "<code>.orig</code>". This backup will not be contained in the job XML description.
*Add 'CRLF' instead of 'LF': add Windows-compatible line endings to the file after each record.

Seon plugin seonplugin email files

2017-07-27T09:37:07Z

Admin: Created page with "Category:Plugins == Purpose == Send all files as attachement of a job to a defined recipient via email. The mail body text content is freely configurable. The email will b..."

[[Category:Plugins]]
== Purpose ==
Send all files as attachement of a job to a defined recipient via email. The mail body text content is freely configurable. The email will be sent to the configured recipient of the job if he has a configured email address. This applies to both outgoing and incoming jobs.

== Requirements ==
*Seon Enterprise license
*configured and working MTA

== Configuration ==
*Alternative mail FROM address: override the default value of "Seon <seon>".
*Email address CC: a list of freely defined CC recipient(s) is configurable. This configuration option supports XPath expressions based on the job's XML.
*Email address CCC: a list of freely defined CCC recipient(s) is configurable. This configuration option supports XPath expressions based on the job's XML.
*Alternative mail subject: The subject of the sent email. This configuration option supports XPath expressions based on the job's XML.
*Send subject UTF-8 encoded: some MTAs need the subject formatted as UTF-8 for special characters.
*Absolute path to mail template: the path of the mail body text template, see below.
*Debug mail execution: when enabled, more information about environmental variables and the mail command itself is being logged.
*Send mail as HTML: if required, the sent mail will be declared as "Content-Type: text/html" instead of "Content-Type: multipart/mixed", which may be required for most mail clients to interpret the attachement correctly.
*MTA (sendmail) command: the MTA program for sending emails (default: sendmail). If "sendmail" is not available in the PATH (i.e. in "/usr/sbin/sendmail"), you can configure the used MTA here.

== Mail templating ==
=== Mail subject ===
The configurative value can include XPath expressions, indicated by a single dollar sign ("<code>$</code>").

A productive example could be:
Seon Transfer-PDF - Auftrag $/Seon_job/job_information/job_number (gesendet an Fa. $/Seon_job/job_information/recipient/partner_longname)

=== Mail content ===
A configurable mail template must be configured. This text file is the body of the mail sent to the corresponding person. The default mail template is as follows:
<pre>
Sehr geehrter Seon-Nutzer,

Ihr Seon-Auftrag $/Seon_job/job_information/job_number wurde erfolgreich transferiert. Anbei die zugehörigen Dateien.

MfG
Seon
</pre>

As you can see, a variable is contained in this template. You can use as many variables as you want, the plugin will replace them with the content of the variables. All variables are indicated by a dollar sign "<code>$</code>" (as in shell scripts). The end of the variable name is a whitespace, tab or end of text. The variable itself is an XPath expression, i.e.:
/Seon_job/job_information/job_number
This XPath information is executed on the configured XML (either actual or initial one, see above).

Seon Enterprise plugins

2017-07-27T09:35:44Z

Admin:

Seon Enterprise plugins

2017-07-27T09:35:14Z

Admin:

Seon Core binaries

2017-07-07T10:55:38Z

Admin: /* input parameters */

== seoneq ==
Add a file to the send queue or enqueue an EERP message to the EERP queue. If the addressed partner is configured for OFTP2, special file handling is available for the following virtual filenames:
*<code>ODETTE_CERTIFICATE_REQUEST</code>: request certificate from remote partner
*<code>ODETTE_CERTIFICATE_DELIVER</code>: send the configured certificate to the partner (also used by updating certificate)
*<code>ODETTE_CERTIFICATE_REPLACE</code>: send the configured certificate to the partner as an instant replacement
The used cipher suite for automatic certificate is "#1: 3des_ede_cbc_3key, RSA, SHA-1'.

When an existing send queue entry already exists (server ID doesn't matter!), then it will be checked if it's blocked. If it's blocked, it will be unblocked, otherwise it will be removed and newly added. If any process is running for that send queue entry (i.e. a process in the status "''taken by send queue''"), it will recognize that its send queue entry was removed and it will cleanly shut down.

The parameter "<code>-m</code>" accepts a relative filename (without path information) for moving or copying the resulting file (which is then added to the send queue) to the [[Seon Core configuration#temporary directory|Seon's temporary directory]] with the given name.

If the destination partner settings use any kind of OFTP2 action (like signing, encryption or compression) and the format is given as "V" (variable record length mode) via parameter "<code>-G</code>", the file will be transcoded to the given structure before any other action will be made. So, as a result of this automatic transformation, you don't have to pre-transform the file on your own.

=== input parameters ===
*-h: printf this help text
*-C <configfile>: use given config file (default: <code>/etc/seon.conf</code>)
*-p <partner shortname>
*-f <filename with absolute path>
*-v <virtual filename>
*-c <comment (max. 255 chars./without special chars.)>
*-q <alternative SSID for this file (originator)>
*-r <alternative SSID for this file (destination)>
*-s <alternative SFID for this file (originator)>
*-t <alternative SFID for this file (destination)>
*-w <alternative password for this file (originator)>
*-x <alternative password for this file (destination)>
*-u <priority, default: 0>
*-i <server ID, default: 0>
*-P: add file passive to send queue (let partner fetch it from remote)
*-d: <optional file description in OFTP2 session>
*-m <filename> move temporarily created OFTP2 file to Seon's temporary directory with the given name
*-V: print out version and exit
*-F <n>: send file in fixed record length mode with n bytes maximum record length; overrides binary data transfer mode
*-G <n>: send file in variable record length mode with n bytes maximum record length; overrides binary data transfer mode
*-H: send file in text mode; overrides binary data transfer mode
*-j <job ID, default: -1>: optional job ID used for reference
*-k <file ID, default: -1>: optional file ID used for reference

In order to enqueue an EERP message, the following parameters are available:
*-E: activate EERP mode (instead of file mode)
*-T <timestamp in format HHMMSSCCCC, i.e. 1435570001>
*-D <datestamp in format YYYYmmdd, i.e. 20081230>
*-z <destination SFID>
*-o <originator SFID>
*[-f <filename with absolute path> needed in OFTP2 sessions only]
*[-S <0|1> OFTP2 sign EERP (1) or not (0)
*[-U <ciphersuite> OFTP2 cipher suite (0, 1, 2...)]

=== examples ===
*enqueue the file '<code>/tmp/testfile</code>' to partner 'c-works', using virtual filename '<code>testfile</code>':
./seoneq -p c-works -f /tmp/testfile -v testfile
*enqueue the file '<code>/tmp/testfile</code>' to partner 'c-works', using ENGDAT light virtual filename '<code>ENG061229153952001001</code>':
./seoneq -p c-works -f /tmp/testfile -v ENG061229153952001001
*enqueue the file same file '<code>/tmp/testfile</code>' to partner 'c-works', using ENGDAT light virtual filename '<code>ENG061229153952001001</code>', but with increased priority (5):
./seoneq -p c-works -f /tmp/testfile -v ENG061229153952001001 -u 5
*enqueue the file '<code>/tmp/testfile</code>' to partner 'c-works', using ENGDAT light virtual filename '<code>ENG061229153952001001</code>', with comment 'this is a testcomment':
./seoneq -p c-works -f /tmp/testfile -v ENG061229153952001001 -c "this is a testcomment"
*enqueue the file '<code>/tmp/testfile</code>' to partner 'c-works', using ENGDAT light virtual filename '<code>ENG061229153952001001</code>', added passively, so partner must fetch the file (no active send):
./seoneq -p c-works -f /tmp/testfile -v ENG061229153952001001 -P

Certificate exchange:
*request certificate from OFTP2 partner 'c-works':
./seoneq -p c-works -f /tmp/testfile -v ODETTE_CERTIFICATE_REQUEST
*send my certificate to OFTP2 partner 'c-works':
./seoneq -p c-works -f /tmp/testfile -v ODETTE_CERTIFICATE_DELIVER

Enqueue an EERP to a given partner:
./seoneq -E -p PARTNER_TESTNAME -v TESTFILE -T 1800652001 -D 20081012 -z DESTSFID -o ORIGSFID

Enqueue a signed OFTP2 EERP to a given OFTP2 partner, providing the received (decrypted, decompressed and verified native plain file), using cipher suite 2 for hashing:
./seoneq -E -p PARTNER_TESTNAME -v TESTFILE -T 1800652001 -D 20081012 -z DESTSFID -o ORIGSFID -f /bin/bash -S 1 -U 2

== seonlic ==
This tool displays the Seon ID, an installation specific hash value, which identifies this copy of Seon.

=== input parameters ===
*-h: help text
*-I: display Seon ID only (without headers)
*-v: display version information and exit

=== examples ===
<pre>
localhost:~/tmp username$ ./seonlic
Seon license tool v2.0

your Seon ID is:
8b6c03222dc17af20d4c022d6cf92d502cb8d51b230467582b8d111a39e7b0bcv2

(all in one line)
</pre>

<pre>
localhost:~/tmp username$ ./seonlic -I
8b6c03222dc17af20d4c022d6cf92d502cb8d51b230467582b8d111a39e7b0bcv2
</pre>

== seon_licinfo ==
Display the information encoded in an Seon license file.

=== input parameters ===
*-h: help text
*-C <code>configfile</code>: use given config file (default: <code>/etc/seon.conf</code>)
*-f <code>license file</code>: use the given license file as input
*-d: display end date of validity
*-I: display licensed Seon ID
*-p: display amount of licensed partners
*-a: display licensed functions
*-A: display licensed functions, as numeric value
*-v: display version information and exit

=== examples ===
<pre>
localhost:~/tmp username$ ./seon_licinfo -I
8b6c03222dc17af20d4c022d6cf92d502cb8d51b230467582b8d111a39e7b0bcv2
</pre>

<pre>
localhost:~/tmp username$ ./seon_licinfo -f /opt/seon/bin/license.key -d
20080331
</pre>

== seonped ==
In order to administrate basic partner information in the Seon database, this command line tool can be used from external programs (i.e. SWAN 2.x, DDX, etc.). The main key is the partner shortname which must be unique. If no partner exists for the given shortname it will be created. If exactly one partner entry exists for the given shortname it will be used for changing configuration entries. If multiple partner entries exist for the given shortname the program aborts.

=== input parameters ===
*-h: help text
*-C <code>configfile</code>: use given config file (default: <code>/etc/seon.conf</code>)
*-s <partner shortname>: shortname of partner
all other parameters are optional:
*-l <partner longname>: long description of partner
*-a <partner SSID>: partner's SSID
*-b <partner SFID>: partner's SFID
*-c <partner password>: partner's password
*-d <my SSID>: my SSID
*-e <my SFID>: my SFID
*-f <my password>: my password
*-g <his hostname/ip address>: his TCP/IP address
*-i <his ISDN number>: his ISDN number
*-p <his tcp/ip port>: his TCP/IP port
*-t <connection type>: 1 - network / 2 - ISDN

=== examples ===
<pre>
localhost:~/tmp username$ ./seonped -s testshortname -l "this is the long description" -c NEWPWD -i 4711 -t 2
Seon partner edit v1.4
company 'testshortname' successfully changed
</pre>

<pre>
localhost:~/tmp username$ ./seonped -s testshortname -a "O001300 NEW SSID" -b "O001300 NEW SFID" -t 1 -g seon.remotedomain.com -p 3317
Seon partner edit v1.4
successfully inserted new company
</pre>

== seonpoll ==
Connect to a given partner and retrieve downloadable files (if any are given by partner) or receive EERP messages. The OFTP direction implemented is "R" (for "receive") only. Sending files is not supported.

=== input parameters ===
*-p <partner shortname>
*-i <partner index (primary database key value)>
*[-a <alternative partner's SFID for authentification>]
*[-n]: no not daemonize
*-h: this help text
*-C <configfile>: use given config file (default: /etc/seon.conf)
*-v: display version

=== examples ===
<pre>
localhost:~/tmp username$ ./seonpoll -v
Seon poll version 2 build 20080513
</pre>

<pre>
localhost:~/tmp username$ ./seonpoll c-works
</pre>

<pre>
localhost:~/tmp username$ ./seonpoll -C /etc/seon.conf -p c-works
</pre>

<pre>
localhost:~/tmp username$ ./seonpoll -i 758
</pre>

In order not to daemonize the process (i.e. to count received files via [[Seon Core - list of returncodes#seonpoll|returncode]]):
<pre>
localhost:~/tmp username$ ./seonpoll -C /etc/seon.conf -p c-works -n
</pre>

== seonrd ==
The main Seon receive daemon which is responsible for accepting OFTP sessions. This daemon starts several processes:
*<code>seonrd</code>: the management process which manages all subsequent child processes
*<code>seonrd_tcpip</code>: main receive process for incoming TCP/IP connections. After having accepted a connection, this processes creates a new child process:
**<code>seonrd_tcpip_active</code>: an active TCP/IP OFTP connection
*<code>seonrd_tcpip_tls</code>: main receive process for incoming TLS secured TCP/IP connections. After having accepted a connection, this processes creates a new child process:
**<code>seonrd_tcpip_active</code>: an active TLS secured TCP/IP OFTP connection
*<code>seonrd_capi_[number]</code>: main receive process for incoming ISDN connections. The number is the index value of the CAPI configuration row. After having accepted a call, this processes creates a new child process:
**<code>seonrd_capi_[number]_active</code>: an active CAPI OFTP connection

''This behaviour in changed process names is not available on HP/UX!''

=== input parameters ===
*-h: help text
*-C <configfile>: use given config file (default: <code>/etc/seon.conf</code>)
*-f start forced
*-v: display version
*-i <serverID>: start as server with ID <serverID> (default: 0)

== seonsqd ==
The send queue daemon checks new entries in the send queue, trying to send them. During processing, the daemon starts the following processes:
*<code>seonsqd</code>: the management process which manages all subsequent child processes:
**<code>seonsqd_tcpip_active</code>: an active OFTP connection process, running a TCP/IP connection
**<code>seonsqd_tcpip_tls_active</code>: an active OFTP connection process, running a TLS secured TCP/IP connection
**<code>seonsqd_capi_active</code>: an active OFTP connection process, running an ISDN connection

''This behaviour in changed process names is not available on HP/UX!''

=== input parameters ===
*-h: help text
*-C <configfile>: use given config file (default: <code>/etc/seon.conf</code>)
*-f start forced
*-v: display version
*-i <serverID>: start as server with ID <serverID> (default: 0)

== seonupdate ==
Check the integrity and signature of an update file and execute it. Optionally run the [[Seon_Core_configuration#Seon_automatic_update_post_event|configurable]] post event after execution.

=== input parameters ===
*-h: printf this help text
*-C <configfile>: use given config file (default: /etc/seon.conf)
*-f <filename with absolute path>
*-V: print out version and exit

=== examples ===
./seonupdate -f /opt/seon/incoming/SEON-UPDATE

./seonupdate -C /usr/local/os4sx/seon.conf -f /tmp/manually_received_update_file

== shox ==
The Seon shell. Start programs with parameters outside Seon as if they were started inside Seon events or other states.

=== input parameters ===
*-h: this help text
*-C <configfile>: use given config file (default: /etc/seon.conf)
*-e <executable>: executable to be started
*-p <parameters>: parameters to give the executable
*-v|V: print out version and exit

=== examples ===
/opt/seon/bin/shox -e set

/opt/seon/bin/shox -C /usr/local/seon/seon.conf -e /bin/ls -p "-l /tmp"

== seon_check_lcapi ==
Check all locally installed CAPI controllers of the underlying Linux CAPI2.0 system. This binary is also used by the web interface in the section "CAPI", when scanning for new devices.

=== input parameters ===
*[-x: output in XML format]

=== examples ===
Human-readable mode:
<pre>
seonbox:~# /opt/seon/bin/seon_check_lcapi
Seon local CAPI check tool v1.0

Available controllers: 1

Checking controller 1:
Available channels per controller: 2
B1 protocol: 0x11F
B2 protocol: 0xB1B
B3 protocol: 0xBF
B3 protocol X.25 available (OFTP ready)
</pre>

XML mode:
<pre>
seonbox:~# /opt/seon/bin/seon_check_lcapi -x
<?xml version="1.0" encoding="UTF-8"?>
<Seon_Brick_config>
<available_controllers>1</available_controllers>
<controller>
<number>1</number>
<index>0</index>
<channels>2</channels>
<b1_protocol>0x11F</b1_protocol>
<b2_protocol>0xB1B</b2_protocol>
<b3_protocol>0xBF</b3_protocol>
<b3_protocol_x25>1</b3_protocol_x25>
</controller>
</Seon_Brick_config>
</pre>

== seonsend ==
Send a single file with a given virtual filename to a defined partner.

=== input parameters ===
*-h: this help text
*-C <configfile>: use given config file (default: /etc/seon.conf)
*-p <partner shortname> (mandatory)
*-f <file to send (absolute path)> (mandatory)
*-v <virtual filename> (mandatory)
*-a <alternative SFID originator>
*-b <alternative SFID destination>
*-s <alternative SSID originator>
*-t <alternative SSID destination>
*-d: daemonize (backgrounding process)
*-D <optional file description in OFTP2 session>
*-o: verbose output
*-V: print out version and exit
* [-F <n>]: send file in fixed record length mode with n bytes maximum record length; overrides binary data transfer mode
* [-G <n>]: send file in variable record length mode with n bytes maximum record length; overrides binary data transfer mode

=== examples ===
Send file "/opt/seon/outgoing/testfile" as "TESTFILE" to partner "c-works":
/opt/seon/bin/seonsend -p c-works -f /opt/seon/outgoing/testfile -v TESTFILE

== seondebugd ==
The Seon debug is an optional daemon which collects data from every running Seon process. It saves the collected data in memory with a maximum size, rotating the log entries automatically (since it's a ring buffer). When an error occurs, it's quite handy to have the debug daemon running, because the debug daemon can produce an encrypted log file which contains information of value for debugging the behaviour. For producing such a log, the debug daemon binary must be started with parameter "d" or "-D":

=== input parameters ===
*-h: this help text
*-C <configfile>: use given config file (default: /etc/seon.conf)
*-f: start forced
*-v: display version
*-d: dump log to Seon temporary directory
*-D: dump log to /tmp (if everything else fails)

=== examples ===
Start the daemon:
/opt/seon/bin/seondebugd
Start the daemon forced (i.e. after system crash or hardware reset):
/opt/seon/bin/seondebugd -f
Start the debug daemon with an alternative configuration file:
/opt/seon/bin/seondebugd -C /opt/seon/seon.conf
Dump a log file to the configured temporary directory:
/opt/seon/bin/seondebugd -d
Dump a log file to /tmp (i.e. when the database is inaccessible and dumping to the configured temporary directory is not possible):
/opt/seon/bin/seondebug -D

=== Configuration parameter ===
A configuration parameter exists to influence the size of the ring buffer. The parameter "<code>seondebugd_max_bufferlength</code>" is the amount of log lines the debug daemon manages. This is just a rough calculation, but a default value of 10000 leads to a memory consumption (and file size) of about 1MB. If this parameter doesn't exist a default of 10000 is assumed.

=== Behaviour ===
Beginning with the debug daemon version 2012-05-12, it reacts on signal 3 (SIGQUIT) in order to write an actual debug dump to Seon's temporary directory.