Difference between revisions of "WPKG flags"

Revision as of 19:06, 8 December 2007

WPKG flags for WPKG-0.9.10

/profile:<profile> - Forces the name of the current profile. If not specified, the profile is looked up using hosts.xml.

/base:<path> - Sets the local or remote path to find the settings files.

/query:<option> - Displays a list of packages matching the specified criteria. Valid options are:

    a - all packages
    i - packages that are currently installed on the system
    x - packages that are not currently installed on the system
    u - packages that can be upgraded

/show:<package> - Displays a summary of the specified package, including its state.

/install:<package> - Installs the specified package on the system.

/remove:<package> - Removes the specified package from the system.

/upgrade:<package> - Upgrades the already installed package on the system.

/synchronize - Synchronizes the current program state with the suggested program state of the specified profile. This is the action that should be called at system boot time for this program to be useful.

/quiet - Uses the event log to record all error/status output. Use this when running unattended.

/nonotify - Logged on users are not notified about impending updates.

/noreboot - System does not reboot regardless of need.

/rebootcmd:<option> - Use the specified boot command, either with full path or relative to location of wpkg.js. Specifying "special" as option uses tools\psshutdown.exe from www.sysinternals.com - if it exists - and a notification loop.

/force - Uses force when performing actions (does not honour wpkg.xml). Handy when you're not sure if your system is "up to date" with the state described in hosts.xml, packages.xml and profiles.xml (i.e., when someone was adding / removing software by other means than WPKG). It will "scan" your system for all possible packages from packages.xml, and then, install and/or uninstall packages, according to profiles.xml / packages.xml / hosts.xml for a given host.

/forceinstall - Forces installation over existing packages. The "install" command will be run, even if "check" conditions are met. This can be useful to "repair" packages etc. Don't use it, unless you really know what you're doing - it will start all your install commands for all packages. A better way is to increase a package revision for a single package (the one you know is broken), and make an "upgrade" of that single package.

/norunningstate - Do not export the running state to the registry (HKLM\Software\WPKG\running set to true when WPKG is running, set to false when it finishes).

/quitonerror - Quits execution if installation of any package was unsuccessful (default: install next package and show the error summary).

/debug or /verbose - Prints some debugging info. Prints everything WPKG does, useful for package installation debugging (and for new users which need to understand how WPKG works).

/dryrun - "Simulates" package installing, without installing anything. Does not execute any action. Assumes /debug on.

/help - Shows these flags with brief description message.

WPKG flags (for WPKG-1.0)

Frequently used parameters

(package operations, you need to chose one)

/install:<package>

Installs the specified package on the system.

/query:<option>

Displays a list of packages matching the specified criteria. Valid options are:

    a - all packages
    i - packages that are currently installed on the system
    x - packages that are not currently installed on the system
    u - packages that can be upgraded 

/remove:<package>

Removes the specified package from the system.

/show:<package>

Displays a summary of the specified package, including it's state.

/upgrade:<package>

Upgrades the already installed package on the system.

/synchronize

Synchronizes the current program state with the suggested program state of the specified profile. This is the action that should be called at system boot time for this program to be useful.

/help

Shows this message.

Optional parameters

(usually defined within config.xml)

/base:<path>

Sets the local or remote path to find the xml input files. Can also be set to a web URL for direct XML retrieval from wpkg_web.

/dryrun

Does not execute any action. Implicites /debug.

/quiet

Uses the event log to record all error/status output. Use this when running unattended.

/nonotify

Logged on users are not notified about impending updates.

/noreboot

System does not reboot regardless of need.

/quitonerror

Quits execution if installation of any package was unsuccessful (default: install next package and show the error summary).

Rarely used parameters

(mainly for testing)

/config:<path>

Path to the configuration file to be used. The path might be absolute or relative but including the XML file name. This parameter is entirely OPTIONAL and should normally not be specified at all. If not specified the configuration will be searched at:

   <script-path>\config.xml 

where <script-path> is the directory from which the script is executed.e.g.

   '\\server\share\directory\config.xml'. 
   'directory\config.xml'. 

/debug or /verbose

Enables debug output. Please note that this parameter only influences notification and event log output. It does not affect the logging level. It is possible to get debug-level output even without using this switch.

/force

Uses force when performing actions (does not honour wpkg.xml).

/forceinstall

Forces installation over existing packages.

/host:<hostname>

Use the specified hostname. This option is for testing puropses to test if a given hostname gets the correct profile assigned.

/ignoreCase

Disable case sensitivity of packages and profiles. Therefore you can assign the package 'myapp' to a profile while only a package 'MyApp' is defined within the packages.

Note that this change requires modifying of the package/profile/host nodes read from the XML files. All IDs are converted to lowercase.

Note: This requires converting all profile/package IDs to lowercase. Therefore you will see only lowercase entries within the log files and also within the local package database.

/logfilePattern:<pattern>

Pattern for log file naming. Recognized patterns:

[HOSTNAME]  replaced by the executing hostname 
[PROFILE]   replaced by the  name 
[YYYY]      replaced by year (4 digits) 
[MM]        replaced by month number (2 digits) 
[DD]        replaced by the day of the month (2 digits) 
[hh]        replaced by hour of the day (24h format, 2 digits) 
[mm]        replaced by minute (2 digits) 
[ss]        replaced by seconds (2 digits) 

Example:

'wpkg-[YYYY]-[MM]-[DD]-[HOSTNAME].log' 

results in a name like 'wpkg-2007-11-04-myhost.log' NOTE: Using [PROFILE] causes all messages before reading or profiles.xml to be temporarily written to local %TEMP% folder. So they might appear on the final log file with some delay.

/logLevel:[0-16]

Level of detail for log file. Log level is defined as a bitmask. Just sum up the values of each log severity you would like to include within the log file and add this value to your config.xml or specify it at /logLevel:<num>.

Specify 0 to disable logging. 1 : log errors only 2 : log warnings 4 : log information 8 : log audit success 16: log audit failure

Examples:

31 log everything (1+2+4+8+16=32) 
13 logs errors, information and audit success (1+4+8=13) 
 3 logs errors and warnings only (1+2=3) 

Default is 0 which will suppress all messages printed before log level is properly initialized by config.xml or by /logLevel:<#> parameter.

/log_file_path:<path>

Path where the log files will be stored. Also allows specifying an UNC path (e.g. '\serversharedirectory'). Make sure the path exists and allows write for the executing user.

NOTE: If you set this parameter within config.xml please note that you need to escape backslashes, e.g.

'\\\\server\\share\\directory'. 

/noforcedremove

Do not remove packages from local package database if remove fails even if the package does not exist in the package database on the server and is not referenced within the profile. By default packages which have been removed from the server package database and the will be uninstalled and then removed from the local package database even if uninstall failed.

This has been introduced to prevent a package whose uninstall script fails to repeat its uninstall procedure on each execution without the possibility to fix the problem since the package (including its uninstall string) is available on the local machine only.

HINT: If you like the package to stay in the local database (including uninstall-retry on next boot) just remove it from the profile but do not completely delete it from the package database.

/norunningstate

Do not export the running state to the registry.

/profile:<profile>

Forces the name of the current profile. If not specified, the profile is looked up using hosts.xml.

/rebootcmd:<option>

Use the specified boot command, either with full path or relative to location of wpkg.js. Specifying 'special' as option uses tools\psshutdown.exe from www.sysinternals.com - if it exists - and a notification loop.