Difference between revisions of "Os4x oftp2 offlinehandling"
| (4 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
When the configuration flag "[[OS4X Core configuration#Enable_offline_handling_of_OFTP2_transfered_files.3F| Enable offline handling of OFTP2 transfered files?]]" is enabled, all received files via OFTP2 will be added to a special table. This table, filled with all file parameters, will be traversed by the daemon. The main task is to handle (decrypt, decompress and/or check signature) the incoming files asynchronously on another machine, achieving the highest security. | When the configuration flag "[[OS4X Core configuration#Enable_offline_handling_of_OFTP2_transfered_files.3F| Enable offline handling of OFTP2 transfered files?]]" is enabled, all received files via OFTP2 will be added to a special table. This table, filled with all file parameters, will be traversed by the daemon. The main task is to handle (decrypt, decompress and/or check signature) the incoming files asynchronously on another machine, achieving the highest security. | ||
| + | |||
| + | == requirements == | ||
| + | If the daemon is used on a remote machine, it depends on the same paths and filenames as the entries were on the receiving machine. You should therefor assure that the file paths and names during transfer don't change. | ||
== parameters == | == parameters == | ||
| − | There are several ways to customize the behaviour of this daemon. Please have a look at the configuration settings with all subsections | + | There are several ways to customize the behaviour of this daemon. Please have a look at the configuration settings with all subsections [[OS4X Core configuration#Enable offline handling of OFTP2_transfered files.3F|here]]. |
=== scripts === | === scripts === | ||
| Line 19: | Line 22: | ||
The configuration switch [[OS4X Core configuration#remove successfully handled offline OFTP2 file entries|remove successfully handled offline OFTP2 file entries]] influences the daemon how to handle the lines of the database table when the file is handled successfully. | The configuration switch [[OS4X Core configuration#remove successfully handled offline OFTP2 file entries|remove successfully handled offline OFTP2 file entries]] influences the daemon how to handle the lines of the database table when the file is handled successfully. | ||
| + | |||
| + | == Behaviour == | ||
| + | The main behaviour is as follows: | ||
| + | #check database table for new entry ('<code>status=0</code>' and its own server ID, configured in the [[OS4X Core installation#Main configuration|main configuration file]]) | ||
| + | #if entry exists: | ||
| + | ##run pre-script | ||
| + | ###if pre-scripts return with error abort | ||
| + | ###if not, continue | ||
| + | ##handle file | ||
| + | ##run post-script with returncode of handling | ||
| + | #check for next entry | ||
| + | #if no entry exists, sleep for defined timeslice | ||
| + | |||
| + | So, the following return code states are: | ||
| + | |||
| + | === pre-script returncode handling === | ||
| + | If the returncode of the pre-script is not 0, further handling will not occur. The error (command call, returncode & output) will be logged in the receive log. The status of the entry will be set to "<code>2</code>". | ||
| + | |||
| + | If the returncode is zero, handling continues. | ||
| + | |||
| + | === post-script returncode handling === | ||
| + | If the returncode of the post-script is not 0, the error (command call, returncode & output) will be logged in the receive log. The status of the entry will be set to "<code>6</code>". The entry will not be removed from the table. | ||
| + | |||
| + | If the returncode is zero, the configuration flag [[OS4X Core configuration#remove successfully handled offline OFTP2 file entries]] influences the next behaviour. If enabled (non-zero), the entry will be removed, otherwise it will be set to "<code>7</code>". | ||
| + | |||
| + | == security considerations == | ||
| + | *You should not use a mounted filesystem exported from the DMZ machine, because the successfully handled files will be stored on this volume. | ||
| + | *The configured temporary directory is the same as configured in the OS4X basic configuration ([[OS4X Core configuration#temporary directory|temporary directory]]). On the machine running this daemon, it should be a seperate local filesystem, because the files handled by the OFTP2 file handler will be located for a specific time here. | ||
| + | *The database should be the same as the DMZ machine uses. In any case, the same information are used, especially partner configuration, cipher suite definitions etc. | ||
Latest revision as of 09:28, 4 December 2007
What is it?
"os4x_oftp2_offlinehandling" is a daemon which runs on a seperate machine, without needing an OS4X license. It needs an OS4X configuration file (default: "/etc/os4x.conf") in order to access the database, containing the OS4X configuration and parameters.
When the configuration flag " Enable offline handling of OFTP2 transfered files?" is enabled, all received files via OFTP2 will be added to a special table. This table, filled with all file parameters, will be traversed by the daemon. The main task is to handle (decrypt, decompress and/or check signature) the incoming files asynchronously on another machine, achieving the highest security.
requirements
If the daemon is used on a remote machine, it depends on the same paths and filenames as the entries were on the receiving machine. You should therefor assure that the file paths and names during transfer don't change.
parameters
There are several ways to customize the behaviour of this daemon. Please have a look at the configuration settings with all subsections here.
scripts
There are two script, which get executed when accessible. These scripts have the following parameters:
pre-script
- real filename
- server ID
post-script
- real filename
- server ID
- returncode of OFTP2 handling process (0=no error)
The configuration switch remove successfully handled offline OFTP2 file entries influences the daemon how to handle the lines of the database table when the file is handled successfully.
Behaviour
The main behaviour is as follows:
- check database table for new entry ('
status=0' and its own server ID, configured in the main configuration file) - if entry exists:
- run pre-script
- if pre-scripts return with error abort
- if not, continue
- handle file
- run post-script with returncode of handling
- run pre-script
- check for next entry
- if no entry exists, sleep for defined timeslice
So, the following return code states are:
pre-script returncode handling
If the returncode of the pre-script is not 0, further handling will not occur. The error (command call, returncode & output) will be logged in the receive log. The status of the entry will be set to "2".
If the returncode is zero, handling continues.
post-script returncode handling
If the returncode of the post-script is not 0, the error (command call, returncode & output) will be logged in the receive log. The status of the entry will be set to "6". The entry will not be removed from the table.
If the returncode is zero, the configuration flag OS4X Core configuration#remove successfully handled offline OFTP2 file entries influences the next behaviour. If enabled (non-zero), the entry will be removed, otherwise it will be set to "7".
security considerations
- You should not use a mounted filesystem exported from the DMZ machine, because the successfully handled files will be stored on this volume.
- The configured temporary directory is the same as configured in the OS4X basic configuration (temporary directory). On the machine running this daemon, it should be a seperate local filesystem, because the files handled by the OFTP2 file handler will be located for a specific time here.
- The database should be the same as the DMZ machine uses. In any case, the same information are used, especially partner configuration, cipher suite definitions etc.