This is the documentation of an old opsi version. The documentation for the current version 4.3 can be found here.

Start / Log / Exitcodes / Testsyntax

Command Line Options

Since version 4.11.3, the opsi-script program contains at Windows a manifest with the statement:
<requestedExecutionLevel level="highestAvailable" />. This means that if opsi-script is called on an NT6 OS by an Administrator, then it will run as an 'elevated' process. If opsi-script is called with normal user privileges, then it will run with the privileges of this user.

If you start opsi-script without any parameter, it will start in the interactive mode.

opsi-script can be started with different sets of parameters depending on context and purpose of use.

Note

At Linux or macOS the parameter char is not "/" as here described for Windows but "-". So instead of using opsi-script /help as we do on Windows, we use at Linux / macOS opsi-script -help.

Generic Options:

  • /? or /h[elp]
    Show help

  • /silent
    Run opsi-script without GUI

Execute one (or more) scripts:
opsi-script <scriptfile>[;<scriptfile>]* [<logfile>]
where:
<scriptfile> = Name of the script file (incl. path).
<logfile> = Name of the log file (incl. path). Paths to log files see also: Log File and Paths

  • /parameter <parameterstring>
    A string that can be passed to the executed script and can be retrevaled by the command Paramstr.
    Hereby is <parameterstring> a string without whitespaces.

  • /logfile <logfile>
    Define the log file:
    Hereby is:
    <logfile> = Name of the log file (incl. path). Paths to log files see also: Log File and Paths

  • /lang <lang>
    Define the localization:
    Hereby is:
    <lang> = The two char language abbreviation (de,en,fr,es,…​)

  • /batch
    Execute the given script with the batch GUI. The batch GUI has no possibility for user interaction. In combination with the option /silent there will be no GUI at all. If you call opsi-script without the option /batch the interactive GUI ist started, which is designed for development end testing purposes.

  • /testsyntax (since 4.12.7.)
    Execute the given script in 'testsyntax' mode. Normally used in combination with the parameter /batch.
    see also: Check the script syntax: testsyntax

  • /productid <productId>
    For the use together with /servicebatch ; see below.

  • /servicebatch
    Execute the given script with the batch GUI and with a connection to the opsi web service. Thereby the given script will be executed as it would be if the opsi product given by the option /productid had the action request 'setup'.
    The script file has to be the first option.
    The option /opsiservice and its sub options has to be given.
    The option /productid has to be given. This one is used for the communication with the opsi web service to run the given script as it would be the 'setup-script' of the opsi product given with this option.

  • /logproductid <productId>
    While creating the log file the given <productId> should be used to note it as source of the log file.

  • /normalwindow
    Switches off the maximize if of the GUI in the not interactive mode.

  • /usercontext < [domain\]username >
    If the given user is loged in then opsi-script will try to resolve the constants like %CurrentAppdataDir%, %CurrentStartmenuDir%, %CurrentDesktopDir%, %CurrentStartupDir%, %CurrentProgramsDir%, %CurrentSendToDir%, %CurrentProfileDir% from the context of the given user.
    Mostly used together with the’User Profile Management' opsi extension.

  • /opsiservice <opsiserviceurl>
    /clientid <clientname>
    /username <username>
    /password <password>
    [/sessionid <sessionid>]
    [/credentialfile <credentialfile>]
    Give the connection data to connect to the opsi web service:
    Hereby you have to give either /clientid and /username and /password and also optional the /sessionid
    or you have to give this data via a /credentialfile.

Declare what should be done in the context of the connected /opsiservice

  • Default (none of the following parameters):
    Process the action requests as they stored for this client on the opsi-server.

  • /allloginscripts or /loginscripts
    Process the login scripts of the opsi products. Using /allloginscripts all login scripts that are known to the opsi-server will be processed, no matter iftheses products are known to the client or not. Using /loginscripts only these login scripts will be precessed that belong to products that are installed or were installed and then removed (technical: there is an existing productOnClient object).

  • /productlist <productid>[,<productid>]*
    Process the given /productlist in a way as it would normally done if there are the action request 'setup' is stored at the opsi-server.
    Usally used by the event_silent_install.

  • /processproducts <productid>[,<productid>]*
    Process the action requests as they stored for this client on the opsi-server but limited to the list of products given by /processproducts.

Log File and Paths

The default log file name is opsi-script.log. You may find (by default) up to 8 backup copys of old log files: from opsi-script_0.log until opsi-script_8.log.
The default number of backups may be overwritten by using the config: [opsi-script-configs_log_rotation_count]

The log file encoding is UTF-8.

By default log files are written at Windows into the directory c:\opsi.org\log which opsi-script tries to create. If opsi-script has no access to this directory it uses the user-TEMP directory.

At Linux: If running as root (default): /var/log/opsi-script If running as any other user: /tmp

The log file name and location will be overwritten via the specific command line option.

In the case, that opsi-script executes a script in /batch mode and with a specified (and working) usercontext, the default logging path is the opsi/tmp in the appdata directory of the user. This will be overwritten by an explicit given log path.

More possibilities to configure the logging:
see also: [opsi-script-configs_writeProductLogFile]
see also: [opsi-script-configs_default_loglevel]
see also: [opsi-script-configs_force_min_loglevel]
see also: [opsi-script-configs_debug_lib]
see also: [opsi-script-configs_log_rotation_count]

Beside the normal log file there is also a log file named opsi-script.history. This log file contains one line for every run of a product script since the first run. These lines have the pattern:
<timestamp> handled: <productid> Version: <version> Request: <request> Result: <result>
Example:
2022-01-18 00:09 handled : gimp Version: 2.10.30-1 Request: setup Result: success

Exitcodes

opsi-script has (since 4.12.7.0) the following exit codes:

  • 0 :
    The opsi-script program was terminated without any internal errors and all executed scripts ran successfully.

  • 1 :
    The opsi-script program was terminated without any internal errors, but one (or more) executed scripts did not run successfully (failed).

  • >1 :
    An internal error has occurred in the opsi-script program (this should not happen). Script execution probably failed.

Check the script syntax: testsyntax

Available since 4.12.7.0

If opsi-script is started in testsyntax mode, scripts will not be executed but scanned for syntax errors.
Such a testsyntax run has the following characteristic features:

  • While running in testsyntax mode every line of the script will be processed. So for example in case of an if-else-endif statement both branches will be analyzed.

  • Any statement that will modify the system opsi-script is running on, will not be executed.

  • If a syntax error is found, this will be logged. The run will not stop at the first syntax error but run to the end. So you will find every syntax error in the log.

  • Every statement that normally stops the script execution (like isFatalError) will be ignored.

  • In the header of the log file, you will find the warning:
    Running in TestSyntax mode !!.

  • If a syntax error is found, the script will be marked as failed. This means in detail:

    • The log file will end up with script finished: failed.

    • The opsi-script process will return the exit code 1.

    • If opsi-script is started in the context of the opsi web-service (so for example started by the management interface via on_demand), the opsi product will be marked as: State: unknown and Report either ok: testsyntax or failed: testsyntax.

Testsyntax Result in the opsi-configed: 1. line: failed
After you checked a script with testsyntax, you may find additional runtime error messages in the log file. You should ignore these runtime errors. In many cases these runtime errors are side effects of the testsyntax run. The reason is, that while testsyntax many variables have empty (or other unexpected) values.

In order to run opsi-script in testsyntax mode, you have the following possibilities:

Screenshot: opsi-script in interactive mode
Figure 1. opsi-script in interactive mode

  • Interactive :
    If opsi-script is started in the interactive mode, use the button Test Syntax (instead of Start) to run the selected script.

  • In the context of the opsi web-service :
    By using the config ('Hostparameter') opsi-script.global.testsyntax = true, opsi-script will be forced to run all scripts in the 'testsyntax' mode.
    ATTENTION: Switch this config only for selected computers to true. Do not forget to switch it back to false after you have done your syntax check!
    see also: [opsi-script-configs]

  • Command line parameter :
    If you call opsi-script on the command line, use the additional parameter /testsyntax in order to run the given script in testsyntax mode.
    For details see also: Command Line Options