Novell Home

AppNote: ZENworks for Servers 3.0.2 : Configuring Distributions

Novell Cool Solutions: AppNote
By Ron van Herk

Digg This - Slashdot This

Posted: 20 Aug 2004
 

Ron van Herk
Novell Worldwide Support
RvanHerk@novell.com

Index

Configuration of ZENworks for Servers Distribution
General Properties
Use Digest
Encrypt
Maximum Revisions
Channels
Distribution Type
File Distributions
New Target
Synchronize Directories
Verification Distributions
Desktop Application Type Distribution
Maintain Associations
Load Balancing / Fault Tolerance
Application Requirements
How the Desktop Application Distribution Works
Schedule Properties
Send Distribution Immediately after Building
Schedule Type

Configuration of ZENworks for Servers Distributions

After installing ZENworks for Servers, the next thing to do is configure schedules, channels, distributions, etc. This document describes the different configuration options on the TED Distribution objects and will give some information that will help on configuring the TED Distribution objects.

I hope that this document will provide insight on what ZENworks for Servers can do and how to optimize the use of ZENworks for Servers.

I will go through the different screens and will discuss the important configurable options that are available on these pages.

General Properties

Use Digest

This option is enabled by default. It will generate a checksum that can be used to recognize if the distribution is valid or not. Creating the checksum will take some time and CPU resources on both the Distributor and the Subscriber, however Novell recommends to leave this turned on.

If a distribution for some reason gets corrupted, the digest that is generated will be different then the one that was received from the distributor in the workorder. If this occurs the received DISTFILE.TED will be renamed to CORRUPT.TED so that the distribution will be sent out again the next time the channel schedule is reached. Running with the Digest turned off would disable this feature.

Encrypt

The "Encrypt" option will add encryption to the distributions. This option is only recommended in the following two situations:

  • If a Distributions will be sent over a public network like the Internet. For Distributions that will be sent over a secure WAN environment Novell recommends not to use Encryption.


  • When distributing a NetWare Support Pack. When distributing a NetWare Support Pack an account with administrative rights needs to be entered, these credentials will be in the distribution and encryption of the distribution might be required. For more information see TID 10081510.

Maximum Revisions

This is the most interesting setting on this page, the value that needs to be used for this setting is depending on the content of the distribution.

ZfS will create a distribution file to transfer the files to the Subscribers. The initial distribution that is made is called a Baseline-Distribution. If any files are changed and the Distributor is creating a new build of the distribution, this new distribution will contain all changed files in the source directory. Such a distribution is called a delta-distribution or revision. The Baseline distribution and all following delta distributions is what will be available on the subscriber. After a number of delta distributions, ZfS will start with a new baseline so that all files are stored again within a single distribution, and again, the following distributions will be delta-distributions. The "Maximum Revisions" setting specifies how many delta-distributions will be created before a complete new Baseline is built.

The value that should be used for this setting depends on what is inside the distribution. If the distribution has a large amount of data and only small file changes are made inside the source directory, the baseline distribution will be quite large and the delta files will be small. In this case it will be useful to have "Maximum Revisions" set to a high number to avoid re-sending the baseline too often.

If the distribution contains a limited number of very large files, the best option is to limit the amount of revisions. This will reduce the amount of disk space required to store the complete distribution.

Note: The Maximum Revisions setting will only have affect on sequential distribution types (File and Desktop Application distributions), Other distribution types will always use a baseline distribution.

Channels

There isn't so much to configure on Channels, however there is something that might be useful to know.

With ZfS 3.0.2 we can distribute Applications. To determine if there is anything new to distribute the Distributor will check the eDirectory revision stamps on the Application objects but also on the Distribution object. When adding or removing a channel to a distribution, the NDS revision of the Distribution object will change and it will cause a new delta file to be built on this distribution as soon as the distribution build schedule is reached (as mentioned, only for Desktop Application distributions).

Distribution Type

On this page the distribution type needs to be selected. There are different types of distributions each of these has their own specific configuration page. The following distribution types are available:

  • Desktop Application
  • File
  • FTP
  • HTTP
  • Policy Package
  • RPM
  • Software Package

File Distributions

New Target

The target is a very important setting, since there can be some serious problems if the target isn't set properly.

The first reason why it's important to have the right target defined is because of the "synchronize directories" option. This option will delete everything in the target that isn't part of the distribution. By setting the proper target, the right directory will be used to perform the "synchronize directories" operation.

The second important reason why the target needs to be set properly has to do with performance. The extract of the File Agent will build a hash table that is used to determine what files will need to be updated. Building this hash is quite CPU intensive. The processing time taken to build the hash table can be easily limited by using the right target directory for the distribution.

When specifying the target the default target that will show up if the New target button is clicked is %DEST_VOLUME%. In most cases it's not recommended to keep this as the target directory. In most cases the distributions will be transferred to a subdirectory within the %DEST_VOLUME%. It is possible to create additional directories underneath and specify the files and directory to be within these directories. This would look as follows:

If %DEST_VOLUME% is the root of a large data volume, ZfS will build a hash table with the information on all files on the data volume. This is quite useless as only the files within Dir_3 might change in this distribution. For this reason it is better to modify the target to point to the exact directory used for this distribution. This will look as follows:

Synchronize Directories

As mentioned above, "synchronize directories" will delete everything in the target that isn't part of the distribution. Setting this option with the wrong target specified can be very destructive, this is why there is an additional message showing up as soon as this option is enabled.

Verification Distributions

Enabling this option will force an extract of the distribution every time the extract schedule is reached. If any of the distributed files has been deleted or modified, the original file from the distribution will be restored.

Interesting information on the web:
http://www.novell.com/documentation/lg/zfs302/zfs_admin/data/alqt6nf.html#a8fhl6o
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10074643.htm

Desktop Application Type Distribution

Maintain Associations

As mentioned in the documentation, this option will maintain associations between the distributed application and the trusted groups and containers (within the source root container). ZENworks for Servers will create groups and containers if they do not exist. If a group already exists and has been assigned to the application, ZENworks for Servers won't overwrite the settings that exist on the application.

Load Balancing / Fault Tolerance

These options are used on the subscriber while extracting the application, depending on this option the subscriber will add the source location in the Fault Tolerance or Load Balancing page. These options will only be useful if multiple servers are working with the same working context, in this situation the Load Balancing or Fault Tolerance options will be filled with the file locations on all servers that share this working context.

Application Requirements

ZENworks for servers has specific requirements on the applications that need to be distributed, these requirements are listed in the documentation. Make sure the applications follow the requirements mentioned in the documentation at http://www.novell.com/documentation/zfs302/zfs_admin/data/a86shwb.html

How the Desktop Application Distribution Works

If the eDirectory time stamp on one of the applications(or the distribution object) has changed, a new revision will be build. The Distributor will export the application object details to an AOT file (similar to the export of an application from the wizard in ConsoleOne), this AOT file together with some more configuration files (for example regarding the GUID and associations) and the files that come with this application are added to the distribution.

On the Subscriber this application will be either created or updated based on the information available in the AOT file.

There are a few important things to know about application distributions:

  • If an attribute was deleted it won't be exported into the AOT file (because it doesn't exist anymore) and as such it won't update (delete) the attribute on the subscriber.


  • An association will only be distributed if the association doesn't already exist on the target application, this will prevent changes made on the associations at the target application to be overwritten. Changes to the associations (like adding force-run on an existing association) won't be distributed as this would mean that the existing association needs to be overwritten.


  • If there are multiple subscribers using the same working-context and these subscribers would extract the distribution at the same time, it could be that the subscribers will create the same application object at the same time in two different replica's, this is what is called a eDirectory collision. Make sure that if multiple servers are working in the same working context, one of these servers extracts the applications before the other subscribers start extracting.


  • The Subscriber will add the file location used within the extract as a source location for this application, this functionality makes it possible to have multiple subscribers in the same context updating the same application with their file location, workstations will be able to use these different file locations. There is one limitation due to this functionality, if the file location on the golden application has been changed, the new location will be added and the old location won't be deleted. Make sure you keep the source location for your applications consistent.

Schedule Properties

Send Distribution Immediately after Building

This option can be used to send out an update without waiting for the channel to open. This can be very useful to send things like virus updates to the subscribers. Do not use this option if the channel is set to run immediately as this could cause some timing problems.

Schedule Type

The Schedule type will specify how often a distribution gets built. The setting that should be used is depending on the information that the distribution contains, if the distribution is a daily update of sales information, then the distribution should be built every day and as such the schedule should be set accordingly.

If the distribution contains applications that normally shouldn't change so often, it might be useful to set the schedule to never and manually build the distribution (through iManager). Desktop Application distributions will build a new revision if the revision stamp on one of the application or the distribution object in eDirectory has changed. In eDirectory there are many reasons that can cause the object revision to change, in a large environment with a controlled roll-out of application updates it is often recommended not to use an automatic schedule for the build of application distributions. By setting the schedule to never and manually manage rebuilds through iManager, unwanted revisions can be avoided.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell