About the TED Distributor

The TED distributor has the responsibility for transmitting a distribution (collection of files) to subscribers throughout the tree and to external subscribers that are found outside the distributor's tree. The distributor calls TED agents to collect the files and compact them into a distribution file that is then sent to the appropriate subscribers.

The distributor is managed by command-line commands (see Appendix B for more details), by the iManager Web management tool, and by a distributor object that is placed in the tree. The following sections discuss each of the pages that can be administered on the distributor object. Traditionally, because the distributor is associated with the server (a distributor object is expected for each server that is running a distributor), it should be named so that the server is clearly known. The default naming by the installation process is Distributor_<SERVERNAME>, and the distributor object is created in the same container where specified.

NOTE

TheTED distributor and subscriber objects should be created only through the installation program on the product CD. This ensures that the NCF files on the servers authenticate with the correct objects in NDS. If you move or rename a distributor object, you need to update the PATH:\ZENWORKS\TED\DIST\DIST.NCF file with the new DN of the distributor object or it ceases to function. All other TED objects can be moved and renamed, but remember to refresh the distributor after any change to these objects.

The distributor is the only TED component that queries NDS and reads its object. The distributor reads its distribution object, the channel objects, and any policies when it starts on the server, when requested through the console with a refresh command, if you right-click the distributor object in ConsoleOne and choose the Refresh Distributor option, or as scheduled in the distributor object. The distributor also reads any subscriber related to the distribution they are to send and relays any updates in the subscriber object and policies (such as the Tiered Electronic Distribution policy in the Service Location Policy package) to the subscriber when the distribution is sent.

Introducing the Settings Property Page

This page is found under the General tab and represents some general configuration settings that are effective for this distributor. Figure 6.8 displays a capture of this screen.

Figure 6.8. Settings property page of a distributor object.

On this property page you may choose the following settings:

• Input rate. This represents the number of bytes per second that you allow a distributor to consume for all distributions for input (acknowledgments and so forth). The default is for the distributor to send at the maximum rate possible on the server. For example, if you choose to enter 4096, this distributor will not exceed receiving 4KBps for incoming messages. This setting does not affect the rate at which FTP and HTTP distributions are gathered. The distributor will always use as much bandwidth as is available when gathering distributions.

• High Priority. This represents the number of bytes per second that you allow a distributor to consume for all high-priority distributions' output.

• Medium Priority. This represents the number of bytes per second that you allow a distributor to consume for all high-priority distributions' output.

• Low Priority. This represents the number of bytes per second that you allow a distributor to consume for all high-priority distributions' output.

• Maximum concurrent distributions. Each time a distributor is going to perform a distribution, it creates a Java thread that handles the distribution to the subscriber. This value identifies the maximum number of threads that you allow the distributor to create concurrently to service the sending of distributions. The Maximum Number of Concurrent Distributions value is affected by prioritizing because it is subordinate to the priorities set for the distributions. For example, imagine that you have the concurrent distribution number set to 10 and there are 4 high-priority distributions, 5 medium-priority distributions, and 20 low-priority distributions. Initially, the 4 high-priority distributions are to be sent concurrently; the 5 medium-priority distributions must wait until all 4 high-priority distributions are complete. Then the 5 medium-priority distributions are sent concurrently and only after they are complete are 10 of the 20 low-priority distributions sent.

• Connection timeout. The default for this is 300 seconds. You can also enter a timeout value that, when exceeded, causes the distributor to fail the distribution and retry it every two minutes for the next thirty minutes (as long as it is still in its scheduled window). If after the retries the distribution still has not succeeded, the distributor fails the distribution, and at the next scheduled distribution time for the channel the distributor will reattempt to send the distribution.

• Working directory. This identifies the directory where the distributor stores its distribution files. The agents, when they are called to collect the files and compress them into the distribution file, store the files in this working directory. It is not recommended to use the SYS volume because of the potential system problems should that volume become full.

Looking at the Messaging Property Page

The Messaging property page is under the General tab and can be configured by clicking the active tab and selecting the messaging value under the drop-down on the tab (which you find by clicking the small triangle in the tab). Figure 6.9 provides a sample of a Messaging page. Unless you are having some problems and are diagnosing some issues, it is recommended that you use level 4 or lower.

Figure 6.9. Messaging property page of a distributor object.

For each of the appropriate fields, you may enter one of the following message levels:

• Level 0. This level displays no messages. In the Messaging page, you can administer the following items regarding the behavior of the distributor.

• Level 1. This level displays only errors that were encountered in the system.

• Level 2. This level displays the successes that were satisfied by the system and also includes all the level 1 messages.

• Level 3. This level displays any warnings that were encountered in the system, in addition to all the level 2 messages.

• Level 4. This level includes all the level 3 messages, as well as informational messages that identify key points in the system.

• Level 5. This level includes all level 4 messages in addition to trace information, which notifies the observer of the modules that are being executed. This level also captures and displays all Java exceptions.

• Level 6. This level includes all the other levels plus developer trace information.

You can administer the following configuration parameters on the Message property page:

• Server Console. This item identifies the level of messages that are displayed on the distributor server console (not the main server console).

• SNMP Trap. This identifies the level of messages that are sent as an SNMP trap to the SNMP trap target. The SNMP Trap Targets policy must be defined and active in an effective (for the distributor object) Service Location policy for traps to be sent.

• Log file. This identifies the level of message that should be stored in the log file. Additionally, you can configure the following about the log file:

  • Filename. This is the filename of the log file. The default location is SYS:\TED2\DIST\DIST.LOG. You should change the location of the log file, because it can grow as well and may adversely affect the system if it is located on the SYS volume.

  • Delete log entries older than X days. In this parameter you identify the number of days (x) worth of log entries that should remain in the log file. The default is six days. Therefore, any log entries that are older than six days will be cleared from the log file. The process of scanning for and removing old log entries happens once every 24 hours and is not configurable.

• Email. With this option, you may specify the level of messages that will be sent as email to the identified users. The SMTP Host policy in the ZENworks for Servers 3 Service Location policy package must be effective for the distributor object to enable it to discover the address for the SMTP host to send the email. If this is not specified, the email is not sent.

  In addition to identifying the level of messages, you must also specify who should receive these messages. To add users to the list and for them to be sent the message, you must select User, Group, or E-mail and click the Add button and specify the NDS User or Group, or an email address. When you select a user, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all the users in the group are sent the email message and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. Many administrators store user email addresses in the Internet E-mail Address attribute instead of the E-mail Address attribute. It is expected that the attribute you identify contain a valid email address.

  If you choose to enter an explicit email address, rather than selecting a user or a group, you may choose the Email Address choice from the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown in the Username field in the table with an N/A in the Address Attribute field.

Introducing the Distributions Property Page

This page of the distributor object identifies the defined distributions that this particular distributor is responsible for collecting and sending. You cannot add distributions on this page they are added or deleted in this list only when the actual distribution object is created or deleted from NDS. You may look at the distribution object, however, by selecting the distribution in the list and clicking the Details button. This launches the property pages for the selected distribution object.

About the Routing Hierarchy Property Page

The Routing Hierarchy property page is one of the most important pages to administer, especially if you have WANs in your tree and you want to be efficient in your distribution of files. Figure 6.10 shows a sample of this page.

Figure 6.10. Routing Hierarchy property page of a distributor object.

On this property page you can define the hierarchy associating the distributor to subscribers. This is the path that the distributor uses in sending distributions to the subscribers. As discussed in the "TED Configuration in Your Network" section, this page defines the route that you want TED to follow when attempting to transmit a distribution from this distributor to any identified subscriber.

On this page you build a hierarchy tree that describes the routes that the distributor must follow. You place a child in the tree by selecting the parent and clicking the Add button. You are then required to browse the NDS tree and identify the subscriber(s) you want to insert. For example, if you wanted the routes shown in Figure 6.4 placed into this distributor, you would perform the following steps:

1. Select the distributor 1 object in the list (the topmost item). Click the Add button.

2. Browse NDS and select subscriber 3 in the tree.

3. Select subscriber 3 in the list and click the Add button.

4. Browse NDS and select subscriber 4 in the tree.

5. Select the distributor 1 object in the list and click the Add button.

6. Browse NDS and select subscriber 5 in the tree.

7. Select subscriber 5 in the list on this property page and click the Add button.

8. Browse NDS and select subscriber 6 in the tree.

9. Select subscriber 6 in the list and click the Add button.

10. Browse NDS and select subscriber 7 from the tree.

The hierarchy shown in Figure 6.11 should be displayed on the Routing page after you have completed the preceding steps.

Figure 6.11. Routing Hierarchy property page of a distributor object after the route has been entered.

Using the routing algorithm, the distributor now sends any distributions to subscriber 3 that are bound for either subscriber 3 or 4, and sends any distributions to subscriber 5 that are bound for subscriber 5, 6, or 7.

NOTE

The subscriber can be in the routing table and send distributions to other subscribers even if they are not participating in the channel for the end-target subscriber. They simply forward the distribution on and do not extract it on their local systems.

The routing hierarchy must be entered for each distributor object in the tree. If there are no entries in the hierarchy, the distributor relies on only the parent subscriber, which can be defined in the subscriber object to give any type of route other than direct. See the routing hierarchy algorithm described previously to understand how the distributor uses the routing hierarchy and the parent subscribers.

About the Schedule Property Page

The Schedule page (shown in Figure 6.12) enables you to specify how often the distributor software on the server will go to NDS and read the configuration information in its object, the distributions assigned to the distributor, channel information, and subscriber configuration information. The default value is Never, which means that the distributor reads its NDS object only when it first is loaded on the server, or if told to with the console command (refresh), or in ConsoleOne if you right-click the distributor object and choose the Refresh menu option.

Figure 6.12. Schedule property page.

If there is a Tiered Electronic Distribution policy in a Service Location policy package associated with the distributor, the check box for using the policy appears on this page. If there is no policy, the check box is not displayed. When this check box is activated, the schedule described in the policy is used for this distributor. When unchecked, this distributor has its own schedule and the Schedule Type field is available for administration. By default, this check box is checked if you have a TED policy.

This page enables you to select when the configuration should be read and applied: Never, Daily, Monthly, Yearly, Interval, or Time.

After you have selected when you want the configuration applied, you have additional fields to select in the lower portion of the screen. The following sections discuss the various options you have.

Send Distribution Immediately after Building

Selecting this option instructs the TED agent to send the distribution as soon as it is built, regardless of the schedule setting. However, extraction at the subscriber's end is still based on the subscription schedule.

Never

This option loads the distributor with the configuration information only when it is first loaded on the server, after each reboot or restart.

Daily

When you choose to have the configuration applied to the system daily, you also need to select when the changes will be made.

This schedule requires that you select the days when you want the configuration applied. You select the days by clicking the days you want. The selected days appear as depressed buttons.

In addition to the days, you can select the times the configuration is applied. These times the start and stop times provide a range of time when the configuration will be applied.

You can have the configuration also reapplied within the time frame every specified hour/minute/second by clicking the Repeat the Action Every field and specifying the time delay.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Monthly

Under the monthly schedule, you can select which day of the month the configuration should be applied, or you can select Last Day of the Month to handle the last day, because all months obviously do not end on the same calendar date.

After you have selected the day, you can also select the time range when the configuration will be reread and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Yearly

You select a yearly schedule if you want to apply the configuration only once a year.

On this screen you must choose the day that you want the configuration to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box, where you can browse through the calendar to select the date you want. This calendar does not correspond to any particular year and may not take into account leap years in its display because you are choosing a date for each year that will come along in the present and future years.

After you have selected the date, you can also select the time range when the configuration should be read and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Interval

This schedule type enables you to specify how often to repeatedly read and apply the configuration. You can specify the interval with a combination of days, hours, minutes, and seconds. This type waits for the interval to pass first before applying the configuration for the first time and then for each sequence after that.

Time

This enables you to specify a specific calendar date and time when the configuration will be applied. When the current date on the server is beyond the identified date, the configuration will be applied.

Run Immediately

The distributor does not use this schedule type, but it is used by other components. It is described here for the completeness of listing all possible schedulers.

With the Run Immediately schedule type, the schedule causes the activity to occur the first time that the associated object is activated. You may also specify a repeat interval in days, hours, minutes, and seconds. If no repeat interval is specified, the action runs only once until the object is restarted or refreshed.

NDS Rights Property Pages

The NDS Rights property page is made up of three pages. You can get to each of the pages by clicking the small triangle to the right of the page name and then selecting the desired page to be displayed.

These pages enable you to specify the rights that users have to this object in the directory. The following subsections briefly discuss each of these pages. These NDS Rights pages are displayed for every object in the tree.

Trustees of This Object Page

On this page (see Figure 6.13), you can assign objects to have rights as trustees of the distributor object. These trustees have rights to this object or to attributes within this object.

Figure 6.13. Trustees of this Object page.

If the user admin.novell has been added to the trustee list, then this user has some rights to this object. To get into the details of any trustee assignment (in order to modify the assignment), you need to click the Assigned Rights button.

When you click the Assign Rights button, after selecting the user you want to modify you are presented with a dialog box that enables you to select either [All Attribute Rights] (meaning all the attributes of the object) or [Entry Rights] (meaning the object, not implying rights to the attributes).

From within the Assigned Rights dialog box, you may set the rights the user may have on this object. You can set those rights on the object as well as any individual property in the object. The rights that are possible are as follows:

• Browse. Although not in the list, this right shows up from time to time (especially in the effective rights screens). This represents the capability to view this information through public browse capabilities.

• Supervisor. This identifies that the trustee has all rights, including delete, for this object or attribute.

• Compare. This enables the trustee to compare attributes' values.

• Read. This enables the trustee to read the values of the attribute or attributes in the object.

• Write. This enables the trustee to modify an attribute's contents.

• Add Self. This right enables the trustee to add himself or herself as a member of the list of the attribute's objects. For example, if this right were given on an attribute that contained a list of linked objects, the trustee could add himself or herself (a reference to his or her object) into the list.

If you want to add the object as a trustee to an attribute, you need to click the Add Property button to bring up a list of properties or attributes that are available for this object.

From this list, you may select a single attribute. This attribute is then displayed in the Assigned Rights dialog box. From there, you can select the attribute and then set the rights you want the trustee to have for that property. A user does not require object rights to have rights on a single attribute in the object.

Remember that rights flow down in the tree and if you give a user or an object rights at a container level, those rights continue down into that container and any subcontainers until that branch is exhausted or another explicit assignment is given for that user in a subcontainer or on an object. An explicit assignment changes the rights for the user at that point in the tree. Inheritance Rights Filters may also be placed to restrict this flow of rights down into the tree.

Inherited Rights Filters Page

This page (as shown in Figure 6.14) enables you to set the IRF (Inheritance Rights Filter) for this object. This filter restricts the rights of any user that accesses this object, unless that user has an explicit trustee assignment for this object.

Figure 6.14. Inherited Rights Filters page.

You can think of the IRF as a filter that lets only items checked pass through unaltered. Rights that bump up against an IRF filter are blocked and discarded if the item is not checked. For example, if a user who had write privileges inherited at some point above (she was explicitly granted that right at some container at or above the one we're in) were to run into an IRF for an object or attribute that has the write privilege revoked (that is, unchecked), when she got to that object her write privilege would be gone for that object. If the object were a container, she would loose write privileges for all objects in that container or subcontainer.

You can effectively remove supervisor privileges to a portion of the tree by setting an IRF with the supervisor privilege turned off. You must be careful not to ever do this without someone being assigned as the supervisor of that branch of the tree (given an explicit supervisor trustee assignment at the container where the IRF is done) or you will make that part of the tree permanent (that is, you will never be able to delete any objects in that branch of the tree). ConsoleOne helps keep you from performing this action by giving you an Error dialog box that keeps you from putting an IRF on the [Entry Rights] of the object with the supervisor right filtered away without having first given an explicit supervisor assignment on the same container.

Effective Rights Page

The Effective Rights property page (as shown in Figure 6.15) enables you to query the system to discover the rights that selected objects have on the object that you are administering.

Figure 6.15. Effective Rights page.

Within this page you are presented with the distinguished name (DN) of the object whose rights you want to observe. Initially, this is your currently logged in user running ConsoleOne. You can click the Browse button to the right of the Trustee field and browse throughout the tree to select any object.

When the trustee object is selected, you may then move to the Properties table on the lower half of the screen. As you select the property, the Rights box to the right changes its text to reflect the rights that the trustee has on that property. These rights may be via an explicit assignment or through inheritance.

About the Other Property Page

This page may or may not be displayed for you, depending on your rights to the plug-in that now comes with ConsoleOne. This page is particularly powerful and should not be used by those who do not have an intimate knowledge of the schema of the object in question and its relationships with other objects in the directory. The intention of this property page is to give you generic access to properties that you cannot modify or view via the other plugged-in pages. The attributes and their values are displayed in a tree structure, allowing for those attributes that have multiple types (are compound types that consist of, say, an integer and a distinguished name, or postal code that has three separate Address fields).

Every attribute in eDirectory is defined by one of a specified set of syntaxes. These syntaxes identify how the data is stored in eDirectory. For this page, ConsoleOne has developed an editor for each of the different syntaxes that are currently available in eDirectory. When an attribute is displayed on this page, the editor is invoked to display the data and then modify it should the user click a specific attribute.

If the syntax for an attribute were a string or an integer, for example, then an inline editor is launched enabling the administrator to modify the string or the integer value on the screen. More abstract syntaxes, such as octet string, require that an octet editor be launched, giving the administrator access to each of the bytes in the string without interpretation of the data.

The danger with this screen is that some applications require that there be a coordination of attribute values between two attributes within the same object or across multiple objects. Additionally, many applications assume that the data in the attribute is valid because the normal user interface checks for invalid entries and does not allow them to be stored in the attribute. If you should change a data value in the other page, no knowledge of related attributes or objects or valid data values is checked because the generic editors know nothing about the intention of the field. Should you change a value without making all the other appropriate changes or without putting in a valid value, some programs and the system could be affected.

Rights are still in effect in the Other property page, and you are not allowed to change any attribute values that are read-only or that you do not have rights to modify.