A client can receive software updates in one of two ways:
A transaction can be anything from a simple update of a single machine, to a complex scripted interaction for multiple machines.
Transactions can include individual packages or whole channels. For a channel with security updates, including the whole channel makes more sense, as updates can be placed into the channel and deployed without modifying the transaction.
Creating a package-based transaction is useful for tighter control of the shipped software, or when you need to update the same packages frequently, such as when building regular beta versions during software development.
ZENworks Linux Management transactions enables you to perform various tasks on the client machines: simple or repeated updates, installations of new software, pre-installation downloads, script running, and rollback to earlier software installations.
In the Web interface, transactions created in the Groups page are applied to all the members of the group. Transactions created in the Transactions page are applied to the current members of the machine set.
To avoid hitting the server all at once, clients begin transactions at random times within fifteen minutes of the time you specify as the start time.
You can attach scripts to a transaction to be executed before and after a transaction on the client. Typically, they are shell scripts, but you may use other languages if you know they are installed on the client machine. Script creation is beyond the scope of this guide, but the bash man page should provide you with a good starting point.
When you add a script, you will designate it as a pre- or post-transaction script, having it run before or after the actual package transactions.
For example, you could create a post-install script, similar to the following, to restart rcd after a transaction:
'echo "rug restart" |at now + 5 minutes'
WARNING: Transaction scripts run as root on the client, so make sure you test your script thoroughly to prevent undesired results.
Instead of an update or install transaction, you can also revert to a desired software configuration by date.
Transactions must be either rollback or install/update transactions, not both. If you edit a transaction to add rollback, the update and installation actions will be canceled. Rollback does not interfere with transaction scripts, however.
There are several conditions that must be met before you can use rollback:
If you add a rollback action to an existing transaction, it overrides any installations, updates, or other rollback actions you have previously set for that transaction.
To enable rollback, run the following command on the client machine:
rug set rollback true