The files and executables used with Trigger Sets reside in a few places on the file system.
All files for specific Actions reside in the subdirectories of the
action directory.
The executable itself must have the same name as the Action directory. On Unix systems, there should be no extension. For Windows users, however, the
Action must be named either
name_of_action.exe or
name_of_action.bat when the
Action has been written as a batch script.
The first section, [setup], describes how the
Action will be called using standard arguments. The options include:
A .conf file may use any combination of these to run the
Action, so long as they are comma-separated. For an example of this, look at the configuration file provided with the
email Action.
The next option inside [setup] is the number of custom arguments that will be set in the configuration file itself. In this case, there are two custom arguments,
arg0 and
arg1.
The next section, [arg0], provides information about the first argument. The description,
label, will appear in the Xinet GUI to the left of the argument. The next two options,
rows and
cols, specify that the argument input area is a text field and describe the size of the input area in the GUI. The final descriptor,
type=path, tells Xinet to protect special characters in this text area because the characters must be used later as a file-system path. There are no other type indicators at this time, so it is only necessary to include this option when your
Action requires user input of a file-system path.
Notice how the final section, [arg1], is slightly different than the description input for
[arg0]. Though both use the label, what follows is very different. In this case,
arg1 is selected by the user using a pull-down menu in the GUI. The
option_count setting tells the GUI how many options will be in the pull-down menu. Each of the options has both a name and a value. The
option_value will be the actual argument passed to the
Action at time of execution. The
option_name is the information the administrator will see in the Xinet GUI when creating settings for the
Action. For example, if a user selects
Append in the administration GUI, the
Action will execute with
-arg1 A.
One might optionally add a boolean option to the example shown on page 465. To do so, increase the
custargcount=2 to
custargcount=3 and, add to the end of the file, something like the following:
which would add the following option to the flags in the xinet ADMINISTRATION view
Adding a boolean option to an
Action configuration file
This file is used by the Xinet Administration GUI to provide instructions and helpful information at the top of the
Action Settings screen. If this file does not exist, the section of the
GUI marked
Description will be blank.
In some cases, the Action configuration file should reflect information that is unique to the specific server running Xinet. For example, the
archive Action should show a list of schedules that is accurate for the current server, and allow the administrator to choose one. In these cases, Xinet uses the
.buildconfig executable to automatically generate the
name_of_action.conf file. The
.buildconfig file may be written in any language that can be executed by the server, but it must generate a properly formatted
.conf file to be useful. On Unix systems, see the
archive.buildconfig file for one example of how this may be implemented. The
.buildconfig file, if it exists, only executes when the settings window for the
Action is viewed via the Xinet Administration GUI.
The Logging, Triggers page of the
xinet ADMINISTRATION view presents information from the
trigger.log file. You can also find this file on the server in the following place:
Most of the interesting logging for Trigger Sets goes to this file. It is a clear-text file (on Unix, you can easily run
tail -f on this while monitoring system activity) and the file to which, by default, all
Actions are logged. When troubleshooting
Trigger Sets, this is the most useful log file. A more detailed discussion of this file follows.
