Novell eDirectory Design and Implementation

Chapter 5: Design eDirectory Network Services Strategies

 

Objectives:

This chapter discusses four major network services on a Novell network. The objectives important to this chapter are on page 5-1:

1. Design and Implement an eDirectory DNS/DHCP Strategy
2. Design and Implement an SLP Strategy
3. Explain why time must be synchronized on a network
4. NTP and NetWare Servers
5. NTP and Windows 2000 Servers
6. NTP and Linux Servers
7. Design and Implement a Time Synchronization Strategy
8. Design and Implement an eDirectory Print Services Strategy

Concepts:

Design and Implement an eDirectory DNS/DHCP Strategy

In order for your computer to connect to another computer on the Internet, your computer has to know the IP address to send information to. No one could possibly remember all the addresses that they connect to on an IP network, much less on the Internet, so DNS is needed.

DNS stands for Domain Name Service. DNS is a distributed database system, which means that many servers each hold part of the DNS system. What the system does is provide translation from Domain Names (names of web sites, for instance) to IP addresses. If I tell you to check out the information at server 192.233.80.5 this week, will you remember that address? Thanks to DNS, you don't have to remember the numbers. Its URL (Uniform Resource Locator) name is www.novell.com. You can enter either the address or the name in the address line of a browser. Either will take you to the same web site.

Back to the distributed idea. The Internet is divided into Domains. Baker College, for example, has been assigned a subdomain (called Baker) in the EDU domain, which is for schools. EDU is a top-level domain. A domain name is limited to 255 characters, and each label in it (the parts separated by dots) is limited to 63 characters.

Your corporate intranet can be divided into Domains and Subdomains. Meaningful names can be used for devices instead of IP addresses, thanks to DNS translation of device names to device addresses.

NetWare uses eDirectory to store DNS information. The DNS information is replicated with the rest of the eDirectory data when partition replicas are created.

In an IP network, each device needs a unique IP address. Assignment of these addresses takes some planning. First, there are two major approaches:

• Static assignment - someone has to manually configure the address on each device. Unless your network is small, this is very painful.
• Dynamic assignment - a server on the network can assign an address to workstations as they are signed on. You will still want to manually configure addresses on servers, printers, routers, and other network devices.

Dynamic Host Configuration Protocol (DHCP) service allows us to dynamically assign IP addresses to hosts on an IP network. You need to understand that, as far as IP is concerned, "host" means any device on the network.

eDirectory contains objects for managing both DNS and DHCP services on your network. Your text refers to them in three groups.

Global DNS/DHCP objects:

• DNSDHCP-GROUP group object - This is actually an avenue for access to information about any DNS or DHCP object that will be created in the Tree. Only one such Group object is allowed in a Tree, and all DNS and DHCP objects created become trustees of it, so they can use it to learn information about other objects that are made members of it. Servers that are made DNS or DHCP servers are automatically members of this Group.
• DNS-DHCP locator object - This object contains global defaults, DHCP options,and lists of all DHCP and DNS servers, subnets, and zones in the NDS tree. Only one is allowed in a Tree and it is not configurable, so it does not appear in the Management Console.
• RootServerInfo zone object - This object points to root servers on the Internet. Root servers are servers that maintain listings of assignments in Internet domains (like .COM, .EDU and .NET). It is necessary to refer to root servers for URLs that are not handled by DNS servers on your network.

DNS objects:

• DNS Name Server Object - This represents the physical server that will run the DNS service on your network. It holds information like the IP address and domain name of the server.
• DNS Zone Object - This contains data for an entire zone. By creating more than one, you are effectively creating multiple Domains within your network.
• Resource Record Set Object - These are stored in the Zone objects. Each Domain Name in a Zone needs its own Resource Record Set object.
• Resource Record Object - These are objects inside the Resource Record Set objects. Think of them as holding the values of attributes of these objects.

DHCP objects:

• Subnet Object - defines the subnet (subsection of a network), contains the next two items in this list
• Subnet Address Range Object - Defines one or more ranges of addresses that can be assigned with DHCP. Can also define a range of addresses to exclude from DHCP assignment.
• IP Address Object - Defines one address that is either assigned or excluded from DHCP assignment.
• DHCP Server Object - This represents the physical server running DHCP service on your network. It contains a list of address ranges found in your SAR objects.
• Subnet Pool Object - This will list the various subnets on your network. It allows the same DHCP server to provide service to multiple subnets.

The text discusses strategies for placing the above objects in you eDirectory tree.

• Global objects - Only one of each of these objects will exist in a tree. Since all DNS and DHCP servers will need access to them, they should be placed near the top (root) of the eDirectory tree.
• DNS objects - DNS objects need access to their DNS server object.
• If you have one DNS server in your tree, place the other DNS objects in the same container. This should be at a high level in the tree
• If you have multiple DNS servers, place one in each partition, and place the objects for each DNS server in the container their server is in.
• DHCP objects -DHCP objects need access to their DHCP server object. Avoid passing traffic across WAN links.
• If you have one DHCP server in your tree, place the other DHCP objects in the same container. This should be at a high level in the tree.
• If you have multiple DHCP servers, place one in each partition that represents a location, and place the objects for each DHCP server in the container their server is in.

Design and Implement an SLP Strategy

To understand the following you will need to understand four kinds of network transmissions:

Service Location Protocol,SLP, uses three kinds of software agents. None of these agents have objects in the eDirectory tree:

• User Agent (UA) - this agent runs on every client and server. It sends queries to the other two kinds of agents to learn about available services on the network.
• Service Agent (SA) - every server runs an SA. The SA maintains a list of currently available services on that server. The SA watches for queries from UAs and responds to them. This is more efficient than SAP (Service Advertising Protocol) because UAs generally send multicast requests, not broadcast requests.
• Directory Agent (DA) - DAs are created in large networks to maintain listings of available services in multiple SAs. DAs can receive unicast traffic, reducing the bandwidth usage found in multicast traffic. DAs run on selected servers. If a system uses DAs, then unicast requests flow through them instead of multicasting to SAs.

Small network scenario: UAs send multicast requests for services. SAs on servers that have the requested service available send unicast responses to the UAs. Several servers may respond. The more hosts sending multicast request, the more bandwidth will be consumed.

Large network scenario: UAs are configured to send unicast requests to a DA. The DA checks the information from SAs that have registered with it, and sends a unicast response to the UA. Note that the use of unicast transmissions and the collection of information in the DA cause this scenario to be much more efficient for large networks.

If your network uses Directory Agents, it will also use SLP scopes. A scope is a group of SLP services. Scopes are viewable in the tree by using ConsoleOne. They are the only SLP objects viewable in the tree.

Novell recommends in this text that you use the DA approach regardless of the size of your network. The size of your network, however, has an effect on the placement of your scope object or objects. A question that should be on your mind at this point is "how large does a network have to be to be considered to be large?" There are two diagnostic questions to ask yourself:

• Do you have more than 25 NetWare 5.x servers?
• Do you have a WAN link?

Specific strategies based on the answers to both questions:

• If you answer "no" to both questions, you have a small network. You will only need one scope object, which should be placed next to the server object. However, if the network is expected to grow to the next size soon, place the scope object at the top of the tree.
• If you have more than 25 servers, but no WAN, you have a medium network. You may have more than one scope object. Place them at the top of the tree, or in a custom container.
• If you answer "yes" to both questions, you have a large network. Use scope objects at each location that is separated from other locations by a WAN link.

To load a DA on a NetWare server, you must load SLPDA.NLM on that server. Configuration is done afterward with ConsoleOne.By default, a server's DA object will be called servername_SLPDA. The main SLP organizational unit will be called SLP_SCOPE. The actual scope object will be called UNSCOPED, and the DA will configured to it.

To load a DA on a Windows 2000 server, follow these steps:

1. At the Windows 2000 administrator workstation, insert the eDirectory CD.
2. Select Start | Run | Browse.
3. Select the /NT directory; then select SETUP.EXE.
4. From the installation screen, select SLP Directory Agent | Install.
5. Follow the online instructions for the SLP Directory Agent installation program.
6. For the specified eDirectory tree, extend the schema by selecting a directory type.

Configuration, again, is done with ConsoleOne.

Explain Why Time Must Be Synchronized on a Network

It is very important for devices on a network to agree about the time at which events take place. When two or more people work on the same file, "he who saves last, saves best". Similarly, eDirectory changes that take place in multiple replicas must reconcile with each other, so there must be an indisputable method of determining the actual order of events. Servers determine the time on a network. Page 5-29 lists four services that use server time:

• eDirectory uses it to track changes to the database
• File systems use it to track changes to files and directories
• Messaging applications use it to track when messages are sent, received, and opened
• Network applications also use it to track file changes

Every action on a network involving eDirectory is given a time stamp. The time stamp marks when the event happened, so that eDirectory can reconcile changes to its partition replicas in the proper order. The time system used in NetWare is called Universal Time Coordinated (UTC) which is based on Greenwich Mean Time (GMT). The Prime Meridian (Longitude 0) passes through the Royal Observatory at Greenwich, England. The time at Greenwich has long been a base for determining the time elsewhere in the world, so this is a logical extension of historical precedent.

UTC is calculated by taking the local time, adding or subtracting the number of time zones away from Greenwich (add if you are west of Greenwich, subtract if you are east of it), and subtracting an offset for daylight saving time, if you are using daylight time now. The Eastern Time Zone of the United States, for example, is five hours west of Greenwich, so we would take the local time and add five, then subtract 1 if daylight saving time is in effect, to obtain UTC time. As I am revising these notes, it is January, and I am in the lower peninsula of Michigan, which is in the Eastern US time zone. Daylight time is not in effect, so UTC for me is local time plus five hours. In the spring, daylight time will start again, so I will only need to add four hours. (Did you know that four counties in Michigan are in the Central Time Zone? They all share a border with Wisconsin.)

Set Up Time Synchronization

The text discusses time synchronization methods on three platforms: NetWare, Windows 2000, and Linux. First it explains the generic version of a method all three can use: Network Time Protocol (NTP). NTP is sometimes called SNTP (Simple Network Time Protocol).

NTP uses Internet time sources. Stratum numbers are assigned to reflect how accurate a time source is. An atomic clock might have a stratum number of 0. An authoritative souce, such as the U.S. Naval Observatory, would be assigned a stratum number of 1. A server that takes its time from a stratum 1 source would be called a stratum 2 source. As stratum numbers increase, accuracy is assumed to be less. NTP time source stratum numbers run from 1 to 16.

The NTP protocol has the ability to reject a time source if it is more than 1000 seconds different from the local clock. The protocol labels a source that is more than 1000 seconds different as insane.

NetWare

All NetWare servers are time servers. Of course, it is not that simple: there are several types. Some types adjust their clocks based on time information from other servers, while other types are set in positions of authority in a hierarchy and they do not change their clocks (except when corrected from a more authoritative source). More on that below. To set up time synchronization for your network, you need to understand the time server types on page 5-32. The default configuration uses two types, the time provider group configuration uses three types:

• Single Reference - part of the default configuration. The first server in the tree becomes the Single Reference server which provides time to all other servers, which are Secondaries. The Single Reference server does not adjust its clock for other servers, but it can get its time from the internal DOS clock or an outside source like the Internet.
• Secondary - at the bottom of both kinds of hierarchies, this server receives time from other servers, provides it to other secondaries and clients, never votes, and always adjusts by 100% if it is behind the correct time. As above, time is never adjusted backward. That would lead to inconsistencies with actions already taken on the server.

• Reference - at the top of a hierarchy of a time provider group, the Reference server consults with Primary servers (see below). It can get its time from the Internet (or other external source) or an internal clock. It does not adjust its own clock if the Primary servers (next layer down in the hierarchy) disagree about the time.
• Primary - in the middle of the time provider group hierarchy. These servers poll their Reference server and other Primaries about the time. In cases of disagreement, votes are cast: each Primary server gets 1 vote, and each Reference server gets 16 votes. This results in a calculated weighted average that can be called the network time. The Primary server then adjusts its time by half the difference at each poll, but ONLY if the Reference server is AHEAD of it. Time is never adjusted backward. If the Primary server is fast, it will slow its clock until the network time catches up to it.
• Secondary - at the bottom of both kinds of hierarchies, this server receives time from other servers, provides it to other secondaries and clients, never votes, and always adjusts by 100% if it is behind the correct time. As above, time is never adjusted backward. That would lead to inconsistencies with actions already taken on the server.

TIMESYNC.CFG - This is a text file holding time settings for a server which affect how the TIMESYNC.NLM program runs. (The settings in the configuration file make more sense once you understand the whole chapter.) This file tells the server how often polling takes place, what kind of time server it is, whether to use SAP (Service Advertising Protocol) for time services, whether to use its own hardware clock and so on. The settings in this file can be changed with a text editor, by using SET commands at the console, or by using the MONITOR.NLM program to change server settings. When using MONITOR to make these settings, you fill in fields with the necessary information. When naming an NTP time source, the IP address or server name must be followed by :123. (This means port 123 on that server. e.g 10.20.30.40:123)

Servers can use Service Advertising Protocol (SAP) to request or to provide the network time, or they can be place into configured lists (time provider groups). SAP is the default. It is easy to use, but it generates extra net traffic. Configured lists create less traffic, but the administrator must configure the TIMESYNC.CFG file for each server in a group every time a server is added to or deleted from a time provider group. For fault tolerance, use configured lists and turn SAP on as well. This allows a server to find another time source if all servers in its configured list are down.

NTP and Windows 2000 Servers

A Windows 2000 server uses Windows Time Service, W32TIME. The default time provider hierarchy is similar to the Novell default hierarchy. The first Windows 2000 server in a tree becomes the Primary Domain Controller for that tree, which provides time to other Domain Controllers, which provide time to clients (workstations). This heirarchy can be replaced with time provider groups.

Your book lists four steps for configuring a Windows 2000 server to use NTP based time.

1. At the server command prompt, enter
   net time /setsntp:servername
   This is to configure your new time source. The variable servername can be replaced with an IP address. Additionally, you can enter a series of server names, enclosed in quotes.
2. Enter net stop w32time to stop the current time service.
3. Enter
   w32tm -once
   This manually tells the server to get time from the new source.
4. enter
   net start w32time
   This restarts the server's automatic polling of the new time source.

NTP and Linux Servers

A Linux server can use a program called the NTP Daemon to to perform time synchronization. It is similar to the NetWare process and the Windows process described above. The text offers instructions to install and configure this service on a Linux server.

1. First, download the NTP Daemon program from www.redhat.com, and save it to the Linux server Directory Root.
2. Run the Terminal Emulation Program on the Linux server.
3. Place your focus on the etc directory by entering the command
   cd /etc
4. Use the vi editor program to modify the ntp.conf file by entering the command
   vi ./ntp.conf
   For some notes on using vi, follow this link.
5. Find the line that begins fudge 127. Below it, enter the following:
   server time server IP address
   fudge time server IP address stratum x
6. Save the file and exit vi.
7. At the server console, enter
   ntpdate time server IP address
   This will manually update the server with time from the new source.
8. At the console, enter
   cd /etc/rc.d/init.d
   This will change to the desired directory.
9. At the console, enter
   ./ntpd start
   This will start the NTP Daemon. The text notes that this command is not correct for some versions of the Daemon. The correct command may be ./xntpd start.

Design and Implement a Time Synchronization Strategy

Page 5-40 descbives how to choose which senario, default or time provider groups, you should use. You may accept the default time synchronization strategy if you can answer "no" to these questions:

• Are there multiple sites?
• Are there more than 30 servers?

If you have any of the above characteristics, you need a strategy using one or more time provider groups.

A comparison of the two approaches appears on the following pages. First, benefits of using a Single Reference server:

• It is simple. In fact, it is automatic. The administrator doesn't need to do anything extra to set it up.
• No tweaking of configuration files.
• When new servers are added, no changes are necessary. The Single Reference is still the Single Reference, and everything else is a Secondary.

A list of "considerations" for the Single Reference method:

• All other servers must communicate with the Single Reference server
• If the Single Reference server is bad, it affects every other server
• Secondary servers are not picky: another server could claim to be the Single Reference and change their network time
• Single point of failure
• SAP traffic is not a good idea over WAN links

Recommendations about time provider groups:

• Use a pyramid hierarchy - secondaries synchronize to primaries, primaries synchronize to reference. It is allowed for some secondary servers to synchronize with other secondary servers. It is recommended that you do not do so.
• Use no more than seven reference and primary time servers (total) in a single time provider group
• Time providers should be on reliable network routes

Benefits of using time provider groups:

• Administrator has more control
• Administrator can optimize related traffic
• Provides specific alternative time providers

Some "considerations" for time provider groups:

• Takes careful planning
• Adding or removing a time provider means changing lots of files
• You must designate at least one Reference and at least two Primaries. No more than seven Primaries in s single group.
• Servers that poll each other must have reliable routes to do so
• If using more than one Reference server, all Reference servers must synchronize with the same external time source

If your network has multiple locations (spans WANs), a separate time provider group is recommended for each site.

Primary time servers provide fault tolerance in case the Reference server is not available.

Design and Implement an eDirectory Print Services Strategy

The chapter continues by restating information found in Chapter 9 of the NetWare Administration class.

This chapter begins with the idea that there are two kinds of printers on a network. Public Access printers are those printers that everyone may use, and Restricted Access printers may only be used by people who are granted rights to them through eDirectory.

• Public Access Printer - Features:
  • available to anyone on the network
  • plug-and-print, which means the network will use it easily
  • no eDirectory object exists for these, so you create them in a Manager (see below)
  • low security because of the unlimited access
• Controlled Access Printer - Features:
  • does have an eDirectory object, and is controlled through it
  • many security options
  • many printer configurations are possible
  • access is automatic for users in the same container as the printer object, others can be granted access

The text summarizes the differences between printing in systems that use queues and in systems that use Novell Distributed Print Service (NDPS), which does not use queues. In network printing, as Novell has done it in the past, there was a print queue, which was a holding area for print jobs. A print server monitored the network printer, and pulled the print job from the queue, sending it to the printer when the printer was ready for a job. Each of these entities had to have a Novell Directory Services object to keep track of the relationships between them and users. This changed in NetWare 5. With NDPS, administrators create fewer NDS or eDirectory objects, printers may be added more dynamically, and communication with printers is enhanced.

Using Novell Distributed Print Services (NDPS), we have a new set of printing components:

• Printer Agent - this is assigned to a particular printer; it performs the functions previously done by the Queue, Print Server, and Printer objects. Each printer on the network will have its own Printer Agent. Oddly enough, this component is not an eDirectory object.
• NDPS Manager - a Manager must exist on the system in order to create a Printer Agent. A Manager can control any number of Printer Agents. An NDPS Manager is both an eDirectory object and a program on a server. Although there may be multiple NDPS Managers on a server, each server can only have one Manager running at any given time.
• Gateway - Gateways provide backward compatibility, supporting printers and other printing systems that are not directly compatible with NDPS. (If a printer has a printer agent embedded in its hardware, it does not need a Gateway.) The following Gateways are provided with NetWare 5.1:
  • Hewlett Packard Gateway - to support non-NDPS HP printers, and any printer connected to the network by an HP JetDirect card
  • IBM
  • Ricoh
  • OKIDATA_®
  • Cannon
  • Kyocera
  • EPSON_®
  • Tektronix_®
  • Xerox
  • Lexmark ^TM
  • Novell Gateway - to support all other non-NDPS printers
    You will want to memorize this list for the certification test. I suggest a mnemonic device:
    Hi, Rocket XL -- Novell
    
• NDPS Broker - the Broker provides three services to integrate NDPS with the rest of NetWare. You get one Broker for each network, automatically installed on the first server on which you install NDPS. However, an additional Broker is installed when a server has NDPS installed on it and the server is over three hops from any existing Broker. So, what's a hop? Every time a signal has to pass across a router, that counts as a hop. The Broker's services are:
  
  • Service Registry Services (SRS) - while this sounds redundant, it is actually important. It allows certain types of printers to advertise (or register) their services (availability) to the network.
  • Event Notification Services (ENS) - this service provides notification to users when printers finish tasks or have problems.
  • Resource Management Services (RMS) - this service sends drivers to users from a central location (a NetWare server) when the user logs in. This allows the administrator to change or update drivers centrally instead of having to touch each workstation.\

The text discusses of placement of printing objects. In general, queue related objects should be placed near users who need them or in a container just for them. This simplifies granting rights to them. NDPS printer objects should be placed the same way. NDPS Broker and Manager objects should be placed a level above the printer objects they control.

Creating specific printer containers may make it easier to manage printing services centrally, but may be more confusing than just placing resources near their users.