NOTE: This examples uses Red Hat* 8.0 as the ZENworks Linux Management server platform, which is no longer supported. However, the commands presented work for other supported platforms with minor modifications.
In this planning scenario, we discuss using ZENworks Linux Management to maintain a network of Linux* systems that includes servers, a number of highly-skilled engineers, and a few non-technical users in administrative and operations roles.
The commands presented are usually based on Red Hat 8.0, and focus on the command line rather than the Web interface. However, these examples can be easily converted to work for other supported systems as well.
Now that your plan is complete, you can begin the deployment. The first step will be to provision and install the server. Our example administrator starts with a fresh install of Red Hat 8.0, with 10GB of disk space. She gets the ZENworks Linux Management license file server.key from her e-mail inbox and saves it to the hard disk. Then, she inserts the CD and enters:
mount /mnt/cdrom cd /mnt/cdrom./rce-install
Note that on SUSE® distributions, the mount point will be /media/cdrom rather than /mnt/cdrom.
After agreeing to the terms of license, she enters the path to the license file and her activation code, so that she can install any necessary updates that were not on the CD. Then, she waits for the install to finish.
Now she initializes the server:
/usr/sbin/rce-init -U username@email -R "Real Name" -P password
With the software installation part complete, she proceeds to configure it and prepare it for clients.
The client install process will end with clients contacting the server, and the server needs to be prepared for that contact, and ready to sort the clients into groups, assigning them group membership and channel access as appropriate. That means we need to create groups, channels, and activation profiles.
To create groups, our administrator enters the following commands:
rcman group-add --desc="Engineering Department" engineers rcman group-add --desc="Server Farm" servers rcman group-add --desc="Office and Operations Team" office-ops
While she is creating groups, she sets notifications for them. A notification allows her to be alerted by email for transaction failures or for all transactions performed by a machine or a group of machines. She chooses to be alerted to all server transactions, and to failed transactions from the office workstations group:
rcman group-addemail servers [my@address] All rcman group-addemail office-ops [my@address] Failure
Another way to check on system performance is to use reports, which are covered in Generating Activity Reports.
Then, she creates channels:
rcman channel-add --desc="Security and OS updates everyone needs" "Security" security rcman channel-add --desc="Optional updates and extra software" "Extra Software" extras rcman channel-add --desc="Software development toolkits" "Developer Tools" devel
With channels and groups in place, she now needs to create activation profiles to put the group and channel privileges onto the right machines as they activate. To create activation profiles, she enters these commands:
rcman act-add --key=server-key rcman act-add --key=office-key rcman act-add --key=engineering-key
She has chosen her own activation keys so that they are easy to remember. Each key is unique and also serves as a name for the profile.
Activation profiles, when first created, are nearly identical: they do not provide access to anything. To change that, our administrator adds groups:
rcman act-addgroup server-key servers rcman act-addgroup office-key office-ops rcman act-addgroup engineering-key engineers
Then, she adds channels. All three profiles get the security channel:
rcman act-addchannel server-key security rcman act-addchannel office-key security rcman act-addchannel engineering-key security
The office and engineering groups get the extras channel:
rcman act-addchannel office-key extras rcman act-addchannel engineering-key extras
Finally, only the engineers get the developer tools channel:
rcman act-addchannel engineering-key devel
The next step is preparing a transaction to ship a package:
First, our administrator adds a package to the security channel. The package file is currently on the NFS shared disk:
rcman channel-addpkg --targets=redhat-80-i386 --importance="suggested" --desc="Testing the Security Update Mechanism" security /mnt/nfs/admin/rce/frobulator-1.0.1-i386.rpm
She has chosen this particular update as the first one because it is non-critical. Most of the software shipped through this channel will be much more important, but for a first transaction, this minor update is ideal.
Then, she creates a transaction. Because it is a test transaction, she adds the --dry-run=1 flag and sets it to start at 4:30 PM. She can watch it happen, then update it when she is ready to run it as a 'live' transaction.
rcman trans-add regular-security-update --dry-run=1 starttime="2004-02-23 16:30"
The next step is to associate the channel with the transaction, and select an action type. Our transaction name is "regular-security-update" and our channel is "security." The action argument for this transaction will be "U," an update transaction.
rcman trans-addchannel regular-security-update security U
Once the server is ready, it's time to install the clients. The process will be:
All of these items can be done at once, with a script, and all the machines will have the same settings, although they will use different activation keys depending upon their group membership.
Our example administrator has already decided to install the packages from an NFS mounted disk, which conveniently happens to be available to all clients as the central network storage device. She copies the files she will need to their own directory there: packages for rcd, rug, and rcd-modules.
For every client machine, she will perform the following steps, either by hand or with a script:
rpm -Uvh /mnt/nfs/admin/rce/*.rpm
/etc/init.d/rcd start
rug set require-verified-certificates false
rug service-add [https://my-server.company.com/data] rug service-delete http://red-carpet.ximian.com
Before she logs out of the machines, she has one more step. The final step varies because the three groups of machines will use three different activation keys.
rug activate server-key [admin@company.com]
rug activate office-key [admin@company.com]
rug activate engineering-key [admin@company.com]
As the machines activate, they acquire the appropriate group memberships and channel access privileges. The client deployment is complete, and all that remains is to associate the clients with the transaction we created earlier.
She can do this using groups:
rcman trans-addgroup regular-security-update engineers rcman trans-addgroup regular-security-update servers rcman trans-addgroup regular-security-update office-ops
Note that the connection made here is between individual machines and the transaction. All the current members of the groups will conduct the transaction, but future additions to the groups will not. If our administrator adds to the groups, she will have to add the individual machines to the transaction, or add the whole group again.
At 4:30 PM, the server will contact individual machines, instructing them to refresh their package lists and update schedules. The machines which have old versions of the "frobulator" package will calculate dependency information and prepare to download the package and any available dependencies. Then, they will stop. The transaction reports will note that the transaction was a dry run, and whether it would have failed due to unavailable dependencies.
Satisfied that the update will work as expected, our administrator updates the transaction. She sets the start time to one which will not interfere with the daily use of the machines, adds a frequency of two days, and sets the dry-run value to 0:
rcman trans-update --starttime="2004-02-23 00:30"--frequency="2 days" --dry-run=0 regular-security-update
The transaction is ready. At 12:30 AM, all client machines will check for updates in the "security" channel, and, if they have an outdated version of "frobulator," install a new one.
In addition, the machines will continue to check for updates every 48 hours, so any packages added to the channel will be updated without additional transaction work.