Installing NNLS

 <  Day Day Up  >  

Test Objective Covered:

1. Perform an NNLS installation.

The first task you must complete to start the NNLS installation process is to obtain a copy of the product. The manner in which NNLS is distributed is a bit different from other software products on the market today. You can't run down to your local computer store and buy a copy off the shelf.

NNLS is distributed only through the Internet. To obtain a copy, you must visit http://www.novell.com or the website of an Authorized Novell Reseller. On these sites you will find a link that allows you to purchase a copy of the product.

When you execute the purchase, you will receive an email containing links where NNLS can be downloaded. There are three separate items you need to make sure you receive:

  • NNLS 1.0 CD ” You should see a link that allows you to download a copy of NNLS version 1.0. The file you will receive is an ISO image. An ISO image is a file that contains a complete image of an ISO 9660 compact disc (CD). Be aware that this ISO image file contains the full contents of the NNLS CD. It will be a very large download ”over 300MB, so don't even think about trying to do it with a modem or you will likely be entering retirement when the download completes. Even with a 256Kbps DSL connection, it will still take the better part of the day to download.

  • NNLS 1.0 Companion CD ” Your email should also contain a link to download a second ISO image for the NNLS 1.0 Companion CD. As with the NNLS ISO image, this file is very large and you should not try to download it with a modem. It contains the Novell GroupWise Collaboration Client for Windows, the Novell NetDrive client for Windows, and DirXML drivers (discussed later in the course).

  • A Novell International Cryptographic Infrastructure (NICI) key file ” Your email message should also contain a link that allows you to download a NICI file ( *.nfk ) required by eDirectory. This file is actually quite small (only a few KB) and is not distributed as an ISO image. Simply copy this file to a floppy disk. During the NNLS installation process, the installation routine will look for this file on the floppy disk mounted in /media/floppy (or in /mnt/floppy on a Red Hat system).

Once you've downloaded your ISO images, you need to decide how you want to use them to install NNLS. You have two options, the first of which is to use a CD burner to burn the ISO image to disc. This is a point of confusion for many. When I say, "burn the ISO image to disc," I'm not referring to putting the ISO image file itself on the CD. Instead, we mean using your CD-burning software to extract all the individual files from the ISO image file and burn them to disc. Most CD-burning software packages are capable of doing this; however, many aren't. Check your package's documentation to see whether it supports burning from ISO images.

Once the CD is burned, insert it in your Linux server's CD drive and mount it. At this point, you're ready to start the pre-installation process.

You also have a second option for installing from the ISO image files. Using the mount command, Linux allows you to mount the image file itself to a mount point in the file system, just as if it were a CD. To do this, first download the ISO image file to your server; then enter the following command:

 

 mount -o loop  /image_path_and_filename /mount_point  

 

In Figure 5.1, the NNLS image file is named nnls.iso and is saved in the /tmp directory. Using the mount command, it is mounted in the /media/iso directory.

Figure 5.1. Mounting an ISO image.

graphics/05fig01.jpg


Once the image is mounted, the files within the ISO image are available for you to use to install NNLS.

Note

In Figure 5.1, I mounted the ISO image into the /media/iso directory. This directory doesn't exist by default. It was created earlier with the mkdir command .


Novell offers an evaluation version that you can download for study purposes. This is available at http://www.novell.com/products/linuxservices/.

The evaluation version doesn't include the Companion CD. This version is only licensed for a 90-day evaluation period, and Novell doesn't offer any support for it. For study purposes, this version will work very nicely .

Once you have downloaded the appropriate files and created a license disk by copying the NICI file to a floppy disk, you're ready to start preparing your SUSE Linux system to install NNLS.

Getting Ready to Install NNLS

If you're like me, your first inclination when you get a new piece of software is to straightway throw the CD in and start installing (who needs documentation, anyway). You can get away with this approach with many software packages.

With NNLS, however, you should avoid this urge at all costs. Unlike other products, you must thoroughly plan and prepare your system before installing. To do this, you need to do the following:

  • Meet system requirements.

  • Make sure NTP is functioning properly.

  • Configure SLP.

  • Enable multicasting.

  • Configure your hosts file.

  • Gather all the required data you will have to provide during the installation program.

Warning

I can't emphasize enough the importance of completing these steps before you begin installing. If you don't, it's likely your installation will fail. Even if it actually completes, it's very likely your NNLS implementation will not function correctly. The information that will be presented here is the result of a lot of painful experience on the part of many early NNLS adopters. Be glad you didn't have to learn these things the hard way!


Let's start by reviewing the system requirements you must meet in order to use NNLS effectively.

Meeting System Requirements

As we go through the next couple chapters, you'll discover that NNLS is composed of a whole suite of products. This makes NNLS a very powerful Linux solution, providing everything from identity management with eDirectory to collaboration services with Virtual Office.

Providing all these services requires a lot of horsepower from your server. You really shouldn't skimp on CPU speed, memory, or hard disk space.

Although you may be able to get NNLS installed on a minimal system, the performance of the product will be poor.

Let's start with the server hardware requirements for running NNLS.

Hardware Requirements

The minimal NNLS hardware requirements include the following:

  • A server-class PC system ” Although it is possible to install NNLS on a Linux system running on desktop hardware, you'll get the best performance from hardware designed specifically to function as a server.

    Real World

    A server-class system is designed to optimize disk and expansion bus I/O operations. For example, a quality server system will usually implement a basic RAID array as well as a 64-bit PCI bus .


  • A Pentium II 233MHz or faster CPU ” This is the minimum CPU specified by Novell. I've actually installed NNLS on a system that used a PII CPU. The system's performance was very poor. To achieve adequate performance, I would strongly recommend a PIII as a minimum. In a production environment, I wouldn't implement NNLS on anything slower than a Pentium 4.

  • 512MB of RAM ” I'm frequently asked if one really needs this much memory, as this seems excessive to many administrators. The answer, however, is a resounding yes . In fact, 512MB is the bare minimum. The NNLS installation script checks the amount of memory in your system, and if you have less than 512MB, it will post a warning. Even with 512MB, the system performance is only adequate at best. If you run iFolder, eDirectory, Virtual Office, NetMail, and DirXML at the same time, your system will slow to a crawl. To achieve better performance, you really should use 1GB or more RAM.

  • 30GB of free hard disk space ” This specification, published by Novell, is a little misleading because it sounds as though this much free space is required to install NNLS. NNLS, however, actually only requires about 1GB of free disk space. Novell recommends this much free disk space to accommodate user storage demands for products such as iFolder. There is an issue regarding disk space, however, that you need to be aware of. NNLS requires a minimum of 100MB for the /opt directory and 310MB for the /usr directory. You need to make sure that the partition (or partitions) where these directories reside on disk has at least this much free space available. In addition to this, NNLS requires a minimum of 350MB for the /var directory to install. NNLS, however, stores iFolder user data in this directory, so you need to make sure you have at least 10GB “20GB of free space available on the partition where /var resides.

These hardware requirements are written with the assumption that you are going to run all the NNLS services on one piece of server hardware. Although this can be done, it may be more practical to consider dedicating separate servers to specific services. Depending on the number of users in your enterprise, you could consider implementing as few as one server per service. Some services, such as iFolder, could even be spread out across several servers.

In addition to these hardware specifications, NNLS also has some stringent software requirements.

Software Requirements

To install NNLS, you must be running one of the following distributions:

  • SLES 8

  • Red Hat AS 2.1

  • Red Hat ES 2.1

That's not to say NNLS won't run on other Linux distributions or versions. I've tried it on a few and had good success. Novell, however, doesn't support NNLS on anything but SLES 8 and Red Hat AS/ES 2.1. Having vendor support is critical for servers in a production environment, so make sure you use a supported distribution.

NNLS also requires that the gettext package be installed in order to run its installation script. Check your system and verify that it is there. Depending on the installation profile you chose when you installed Linux, it may or may not have been installed by default. If it isn't there, you can either download the latest version or install the version that's on your distribution CDs. If you followed the steps in Lab Exercise 2.1, your server has this package installed.

Your server also needs to have a static IP address assigned. Many NNLS products require that the server continue to use the same IP address it was using when they were installed. Using DHCP to assign an address to your server will cause these products to stop functioning when a new address is dynamically assigned. Again, if you followed the steps in Lab Exercise 2.1, your server should have a static IP address installed.

In addition to these software requirements, NNLS has several product dependencies. We'll discuss these next.

Product Dependencies

If you've used Linux for a while, you're aware of the concept of dependencies . Many Linux applications and services are written with the assumption that certain other applications or services are already installed and running on the system.

NNLS has several product dependencies. The NNLS installation script checks your system to verify that the required packages are installed. If a missing dependency is identified, the installation routine will automatically install the missing package. For the CLE certification, however, Novell wants you to know what these dependencies are:

  • The version of Tomcat that comes with NNLS requires JVM 1.4.1_02 be installed on the same server.

  • Linux User Management (LUM) requires eDirectory 8.7.1 or later be installed somewhere in the network. It doesn't have to be installed on the same server as LUM.

  • DirXML requires eDirectory 8.7.1 or later be installed on the same server.

  • eGuide requires that Apache Web Server 2.0.45, JVM 1.4.1_02, and Tomcat 4.1.24 be installed on the same server.

  • The version of Samba that comes with NNLS requires eDirectory 8.7.1 or later be installed somewhere in the network. It doesn't have to be installed on the same server as Samba.

  • iFolder requires that Apache Web Server 2.0.45 be installed on the same server. It also requires that eDirectory 8.7.1 or later be installed on a server in the network. It doesn't have to be installed on the same server as iFolder.

  • NetMail requires that eDirectory 8.7.1 or later be installed somewhere in the network. It doesn't have to be installed on the same server as NetMail.

  • iManager requires that Apache Web Server 2.0.45, JVM 1.4.1_02, and Tomcat 4.1.24 be installed on the same server. It also requires eDirectory 8.7.1 or later be installed on a server in the network. It doesn't have to be installed on the same server as iManager.

  • iPrint requires that Apache Web Server 2.0.45 be installed on the same server. It also requires eDirectory 8.7.1 or later be installed on a server in the network. It doesn't have to be installed on the same server as iPrint.

  • Virtual Office requires that Apache Web Server 2.0.45, JVM 1.4.1_02, Tomcat 4.1.24, and iManager 2.0 be installed on the same server. It also requires eDirectory 8.7.1 or later be installed on a server in the network. It doesn't have to be installed on the same server as Virtual Office.

With these prerequisites met, the next thing you need to do is to verify that the NTP daemon on your server is synchronizing time properly.

Verifying That Time Is Synchronized

Before installing NNLS, you need to verify that time is synchronized on your network. Many who are new to eDirectory underestimate the importance of this operation. It is essential that the NNLS installation program will not let you install into an existing eDirectory tree if time is not synchronized with the other servers in the tree.

Even if you are installing a new tree with your NNLS implementation and your server will be the only server in the tree, it is still good form to configure time synchronization. Your server's time should match up to that supplied by the public NTP time sources mentioned in Chapter 3, "Linux Administration and Configuration," or with a time server on your organization's network.

Imagine what would happen if you didn't and your server's clock is 23 hours behind the correct time. As long as it is the only server in the tree, there would be no problems. If you later tried to install a new server into the tree, however, you would have to set its clock back to match the first server's time before the installation could take place.

This may not sound like a big deal, but be aware that many Linux processes and applications don't like having the system time set to a date in the past. It's likely that you will experience problems with non-NNLS services on the second server. In short, you're much better off synchronizing your server with a reliable time provider, even if it is the only server in the tree.

In Chapter 3, we discussed NTP configuration in detail. You should make sure your ntp.conf file has been configured correctly and that the xntpd daemon is running on your server. You can check your time synchronization status by opening a terminal session on your server and entering

 

 ntpq -p 

 

at the shell prompt.

Remember that NTP uses the concept of insane time . If the time on your local server drifts more than 1000 seconds (about 17 minutes) apart from the time source, the NTP daemon considers the time provider to be unreliable and will not synchronize with it. Because of this, it's a good idea to periodically check your synchronization status and make sure it is still taking place.

If you've lost synchronization, complete the following:

  1. At the shell prompt, stop the NTP daemon by entering /etc/init.d/xntpd stop .

  2. Manually set your system clock to closely match the correct time by entering date MMDDHHmmYYYY at the shell prompt. Replace MM with the current month in two-digit numeric format. Replace DD with the current day. Replace HH with the current hour (using the 24- hour clock). Replace mm with the current minute, and replace YYYY with the current year.

  3. Once the time has been set, manually synchronize with your selected time provider by entering ntpdate provider_IP_address at the shell prompt. Rerun this command several times until the time offset (displayed in milliseconds ) reported is less than 1 second.

  4. Restart the NTP daemon by entering /etc/init.d/xntpd start .

With this done, your next task is to implement and configure the Service Location Protocol (SLP).

Implementing SLP

Before installing NNLS, you need to have SLP configured and running on your Linux servers.

Warning

If you've ever worked with eDirectory on the NetWare platform, you know that the default SLP configuration created during installation works very well. You don't have to do any manual configuration before installation .

However, when running eDirectory on Linux, it is critical that you have your SLP configuration installed and running prior to installing NNLS .


The key goal behind NNLS is to provide a wide variety of network services designed to enhance end-user productivity while reducing help-desk calls. The other hosts on your network, both workstations and servers, need to be able to identify and locate these services. Novell has always been famous for making this an easy-to-administer process.

Advertising Services with SAP

Early on, eDirectory didn't run on Windows or Linux servers. The only platform it ran on was Novell NetWare.

Tip

The first versions of eDirectory were named Novell Directory Services (NDS) .


Back then, NetWare didn't natively support the TCP/IP protocol. You had to use the Internetwork Packet Exchange (IPX) protocol instead. IPX was a very easy-to-use protocol; essentially , all you had to do was plug your server or workstation into the network jack, and the protocol would automatically configure itself. You didn't need DHCP to dynamically assign addresses. You also didn't need a DNS server to resolve hostnames into network addresses. That's because IPX used (and still does) the Service Advertisement Protocol (SAP).

When an IPX server was booted , all the services it provided, such as file, print, and directory services, used the SAP protocol to advertise their availability. Regardless of whether anyone wanted to use them, they would periodically send out broadcasts to the entire network describing the service they had to offer as well as their network address. If a service were to be shut down, it would stop advertising itself.

By way of analogy, imagine that you are sitting in a classroom taking a class. At 60-second intervals, each student in the class stands up and announces his or her name and the desk he or she is currently sitting in and then sits back down. Essentially, this is how SAP works.

This strategy works very well, and if you've ever used Novell's Client software on a Windows workstation to log in to an IPX server, you know that you can browse the network to select the eDirectory tree and server you want to log in to. The Novell Client generates the list of trees and servers by simply listening on the network wire for SAP broadcasts, as shown in Figure 5.2.

Figure 5.2. SAP broadcasts with IPX.

graphics/05fig02.gif


For the most part, SAP was a joy for network administrators because little or no manual configuration was involved. Everything just worked. There are, however, two problems associated with this implementation. First, SAP can become a bandwidth hog. Referring to Figure 5.2, imagine what would happen if there were hundreds of servers and thousands of clients on the network. Every service advertises its availability regardless of whether anyone wants to use it. A large portion of your network bandwidth can be used up by traffic that isn't necessary.

The second problem is that SAP is dependent on IPX. When Novell rewrote eDirectory to run on TCP/IP hosts, it had to come up with a new way for services to be located. Novell could have used static methods such as the hosts file or an option delivered via DHCP. Novell system administrators had become quite used to the automated nature of SAP. Using the hosts file would require a tremendous amount of manual configuration. Using a DHCP option is a little better; however, it doesn't carry any state information. In other words, it delivers the service address regardless of whether the service is up or down.

To keep directory services working the way they had under IPX, Novell worked with several other industry vendors to author RFC 2165 and RFC 2608, which define the Service Location Protocol (SLP).

SLP provides a level of automation on a TCP/IP network similar to that provided by SAP on an IPX network. It also eliminates some of the problems associated with SAP. Because of the way SAP broadcasts service availability, it is usually categorized as a push protocol, whereas SLP is categorized as a pull protocol.

Let's take a closer look at how SLP provides network service discovery without using large amounts of bandwidth the way SAP does.

How SLP Works

SLP uses software agents that run on both the network servers and on the workstations. When an SLP-aware service is brought up, it registers itself with an agent on a server. When a host needs to locate a service, its agent sends out a request with a description of the service. Agents that have the requested information respond to the request with the necessary information. This process is shown in Figure 5.3.

Figure 5.3. Finding services with SLP.

graphics/05fig03.gif


SLP responses are sent in the form of a URL, though. The format of the URL is slightly different from the URLs you use in a web browser. The general format of the URLs is as follows :

service: service_name :/// service_address_or_hostname

Here are sample URLs associated with the eDirectory service:

  • LDAP server ”service:ldap:///192.168.1.100:389

  • eDirectory tree ”service:NDAP.novell:///.CLE-TREE.

SLP doesn't use the networkwide service-announcement broadcasts that SAP uses. Service information is only sent when it is requested. In addition, the requested information is sent only to the host that requested it. By implementing SLP in this way, Novell effectively reduced the high bandwidth usage associated with SAP.

Let's talk about the different types of agents used by SLP.

SLP Agents

The three types of SLP agents are detailed in the following list:

  • User Agent(UA) ” UAs are used by applications or services to locate services on the network. UAs query Service Agents or Directory Agents to retrieve URLs containing information about the requested service. UAs are always implemented and automatically start when the SLP service is started.

  • Service Agent(SA) ” SAs are run on service providers (servers). As with UAs, SAs are always implemented and are automatically run when the SLP service is started. When an SLP-aware application or service is run on the server, it registers itself with the SA. The SA keeps a list of all currently available services on the local server. If a service is shut down, it "deregisters" itself with the SA. By doing this, the SA keeps a dynamic database of services. The SA listens for requests from UAs. If the SA has a record for the service a particular UA is requesting, it responds with the service name and address. SAs can also be configured to register their services with a Directory Agent.

  • Directory Agent (DA) ” DAs are centralized storehouses for service information on a network. By default, DAs are not automatically implemented and run as SAs and UAs are. You must manually implement them. When deployed, SAs register the services they know about with the DA. In this configuration, SAs no longer respond to UA requests. Instead, UAs query the DA directly to locate service information.

SLP can also be configured to use scopes . An SLP scope is a grouping of network services associated with one or more Directory Agents. In essence, scopes are a means for you to organize resources on your network.

Scopes are useful when you are deploying SLP in a very large or geographically dispersed organization. For example, suppose your organization is composed of several divisions that each function as separate business units. You have a paper products division, a light bulb division, and a DVD player division.

You can configure a scope for each business unit, such that users in the paper products division only see, through SLP, network resources in that division. Likewise, users in the light bulb and DVD player divisions have their own scopes that only contain network resources specific to their divisions. If there are network resources used across divisions, you can create a scope that includes those resources as well.

Scopes are also useful if your organization is geographically dispersed. Suppose your organization has three different offices located in different areas of the country. Instead of requiring SLP requests to cross WAN links to access a remote DA, you can set up a DA in each location and configure each of those DAs with a scope that is limited to local network resources.

With this information in mind, you're ready to learn about the different ways SLP can operate on your network.

SA-Only Mode

The default mode for SLP is SA-Only mode. In this mode, there are no DAs configured in the network. Each server runs an SA and a UA. Each client workstation runs a UA. This configuration is shown in Figure 5.4.

Figure 5.4. Using SLP in SA-Only mode.

graphics/05fig04.gif


In this configuration, SLP-aware services on the local server register themselves with the local SA. The SA maintains a list of all services it knows about on the local server. For example, if the eDirectory daemon were to be started on the server, the eDirectory tree and the all the eDirectory partitions on the local server are all registered with the SA.

Tip

When a service is stopped , it deregisters itself from the SA .


The SA doesn't broadcast this service information. Instead, it waits passively for requests from UAs. When an application on a client workstation needs to use a network service, the application sends the request to the local UA. The UA then sends out a multicast to the entire network asking for the location of the specified service.

Before proceeding, we need to discuss the concept of a multicast . Although a multicast sounds similar to a broadcast, it is quite different. A network broadcast is a network transmission that is addressed to all hosts. Every host on the network accepts the broadcast packets and processes them.

A multicast, on the other hand, is a message from a single source host that is sent to multiple recipient hosts. Unlike a broadcast, the transmission isn't sent to all network hosts. Instead, it is sent only to hosts who are configured to listen for multicasts. Hosts configured to listen for multicasts are members of a multicast group . By using multicasting instead of broadcasts, SLP uses considerably less network bandwidth than SAP.

In our SLP configuration, all SAs are members of the multicast group. When the UA sends its multicast requesting information about the specified service, all the SAs receive it and process the query. If an SA recognizes the service and has the information being requested, it responds with a unicast response to the requesting UA.

Tip

A unicast is a network transmission that is sent from a single host to a single recipient host; in this case, the host running the UA making the request .


If the SA doesn't have any information about the requested service, it ignores the request and doesn't respond to the UA. This process is depicted in Figure 5.5.

Figure 5.5. Requesting service locations from Service Agents.

graphics/05fig05.gif


In Figure 5.5, the workstation UA makes a request for the location of the CLE-TREE eDirectory tree. All server SAs in the multicast group receive and process the request. The first two SAs don't know anything about the requested service, so they ignore the request. The third SA, however, has information about CLE-TREE, so it sends the appropriate URL back to the UA using a unicast transmission.

This is how your NNLS system is configured by default. It works acceptably well for small networks that have less than 25 or so servers. For networks larger than this, however, it may not be the best option. Even though SLP uses multicasts instead of broadcasts, the traffic from the multicast requests can still use excessive amounts of your network bandwidth.

If your network is large, you may need to configure one or more DAs.

DA Mode

By implementing one or more DAs on your network, you can significantly reduce SLP traffic on your network. As discussed earlier, a DA acts as a central repository for SLP information. As in SA-Only mode, each server in the network runs a UA and an SA. Each client workstation runs a UA. In DA mode, however, you select one or more servers to run a DA as well as an SA and a UA.

When you do this, the SAs on the network change their behavior. They still register SLP-aware applications and services on their individual servers, but they no longer respond to requests from UAs.

In DA mode, SAs send out a DA discovery multicast packet when the SA is first started. If a DA responds, the SA will register all the services it knows about with the DA using unicast transmissions. After that, the SA will no longer respond to UA requests. If the SA does not discover a DA, they will default to SA-Only mode and will respond to UA requests.

In DA mode, you configure your client workstation UAs with the IP address of the DA (or DAs) you want them to send their requests to. When a UA needs to locate a service, it will send a unicast request directly to the configured DA. The DA will process the query and respond with the requested information ”again using unicast transmissions.

This configuration is shown in Figure 5.6.

Figure 5.6. Requesting services from a Directory Agent.

graphics/05fig06.gif


When a service is shut down, the local SA deregisters the service with the DA.

As you can see from Figure 5.6, using a DA requires more work on the part of the network administrator to configure. The bandwidth savings in larger organizations, however, is usually worth the effort.

DA mode also prevents other problems. Recall that SA-Only mode is heavily dependent on multicast transmissions. Most hardware and software routers, however, are configured by default to not allow multicast traffic to cross between network segments. If the servers in your organization lie on different network segments separated by routers, you must enable multicast routing to use SLP in SA-Only mode.

As a better alternative, Novell recommends that you implement DAs on each side of the router. I mentioned earlier that SAs still rely on multicast transmissions to discover DAs by default. You can, however, manually configure each SA with the IP address of the DAs you want them to register their services with. By doing this, multicast traffic is all but eliminated. We'll discuss how to do this a little later in this chapter when we explore the SLP daemon-configuration files.

Now that you understand the conceptual architecture of SLP, you need to learn how to implement and configure SLP daemons.

SLP Daemons

If you're running eDirectory on NetWare or Windows, your SLP configuration choices and tasks are pretty much straightforward. On Linux, however, you need to take into consideration a couple issues.

The first one is the choice of an SLP daemon. You have two packages to choose from:

  • slpuasa ” This SLP daemon is shipped with NNLS and will be installed by default on your system. This package supplies a UA and an SA. However, it does not include DA functionality. If you are using SLP on a large network and you need to implement a DA, you can't use this package.

  • OpenSLP ” This product offers a full SLP daemon that includes a UA, an SA, and a DA. It is a much more robust and reliable product than the slpuasa daemon that comes with NNLS.

Warning

If you have OpenSLP installed on your system prior to installing NNLS, the installation script will detect it and will not install the slpuasa daemon. I highly recommend that you use OpenSLP instead of the slpuasa daemon. In fact, even Novell recommends that you use OpenSLP instead of its own package .


The CLE certification only requires that you know how to implement the slpuasa daemon. However, I've heard many ill reports as to its reliability. Therefore, we're going to cover both slpuasa and OpenSLP in this chapter.

Before doing so, we need to discuss how to enable multicasting on your Linux server.

Configuring Multicast Routing

Depending on the mode you select, you will need some level of SLP support on your servers. By default, most Linux distributions have multicasting support disabled. To check, open a terminal session and enter netstat -nr at the shell prompt. If you see a route listed with a destination of 224.0.0.0, multicast routing has been enabled. If not, you need to enable it.

Output from the netstat -nr command on a system where the multicast route has not been added is shown in Figure 5.7.

Figure 5.7. Output from netstat -nr with no multicast route.

graphics/05fig07.jpg


Output from netstat -nr on a system where the route has already been added is shown in Figure 5.8.

Figure 5.8. Output from netstat -nr with a multicast route already added.

graphics/05fig08.jpg


If you need to add the multicast route, complete the following steps:

  1. From a shell prompt, change to the root user account by entering su - and entering your root user password.

  2. Enter the following:

     

     route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 

     

  3. Enter netstat -nr again to verify that the multicast route has been added.

Be aware that this route is not persistent. If you restart your server, the route information will be lost. To make this persistent, add an entry to the /etc/sysconfig/network/routes file that reads as follows ( assuming you are using eth0 as your network device):

 

 224.0.0.0 0.0.0.0 240.0.0.0 eth0 

 

Once you have added the multicast route, you're ready to start configuring an SLP daemon on your server. As mentioned earlier, you need to choose whether you want to use the slpuasa daemon that comes with NNLS or the OpenSLP daemon. Configuration tasks for both will be covered next.

Configuring the slpuasa Daemon

If you don't have OpenSLP installed, the NNLS installation script will automatically install the slpuasa daemon on your server. By default, it is configured to load an SA and a UA on your server.

Once the slpuasa daemon is installed during the NNLS installation, you can configure it by editing the slpuasa.conf file located in the /etc directory on your server. The default slpuasa.conf file is shown in Figure 5.9.

Figure 5.9. The slpuasa.conf file.

graphics/05fig09.jpg


You can configure the following parameters in the slpuasa.conf file:

  • net.slp.MTU ” This parameter specifies the maximum path unit used by the SA to service requests. The default value is 1400 .

  • net.slp.isBroadcastOnly ” This parameter specifies whether requests are sent as multicasts or as broadcasts. When set to the value of (the default), this parameter configures the daemon to use multicasts only. When set to the value of 1 , it configures the daemon to use broadcasts instead of multicasts.

  • net.slp.isMulticastOnly ” This parameter is used to prevent the local SA from operating in DA mode. When this parameter is set to a value of 1 , the SA will not try to discover DAs on the network when it is started. It will not register its services with DAs it finds. The default value of configures the DA to operate in normal mode.

  • net.slp.MulticastRadius ” This parameter specifies the time to live (TTL) value for the SA multicast packets. The default value is 32 .

  • net.slp.useScopes ” This parameter specifies a list of scopes that the local SA is allowed to use when registering or querying for services.

  • DA_ADDR ” This parameter is used to statically configure the local SA with the IP address of the DA or DAs it is to register its services with.

Tip

Recall earlier that I said SAs, by default, send out a DA discover multicast message when they are started. If they find a DA, they register their services with it. If not, they default to SA-Only mode. If you list an IP address for the DA_ADDR parameter, however, the SA will not do this. Instead, it will contact the specified DAs and register its services with them only .

This is a very useful parameter if your network routers aren't configured to forward multicast traffic. By you specifying a DA in this parameter, your SA will contact it using unicast transmissions .

The syntax is as follows:

 

 DA_ADDR = DA_IP_address, scope_name 

 


Once you have configured your slpuasa.conf file, you next need to restart the slpuasa daemon. This is done using the slpuasa script located in /etc/init.d .

Tip

On other distributions, such as Red Hat, the script is located in /etc/rc.d/init.d .


To stop the daemon, open a terminal session and enter /etc/init.d/slpuasa stop . To start the daemon, open a terminal session and enter /etc/init.d/slpuasa start . Because SLP is so critical to the operation of eDirectory and other NNLS components , you should use the chkconfig command to make the service start automatically each time the system starts. To do this, enter chkconfig slpuasa 345 at the shell prompt.

Configuring OpenSLP

As discussed earlier, Novell actually recommends that you don't use the slpuasa daemon on any implementation where there are more than a handful of servers or where the eDirectory tree has many partitions and replicas. If you want to implement a DA on a Linux server, this is even more applicable because the slpuasa daemon doesn't include DA functionality.

Warning

Novell's SLP implementations on NetWare and Windows do include DA functionality. Many administrators are tempted to implement a DA on one of these platforms in their network and configure the slpuasa daemon on their Linux servers to register its SA with those DAs. I've done this before and had reasonably good success. However, I've also talked with administrators who have done this and had terrible problems. I side with Novell and say don't even bother with the slpuasa daemon. Use OpenSLP instead .


In these cases, it is recommended that you install and configure the OpenSLP Open Source SLP package prior to installing NNLS.

The NNLS installation program will automatically detect the presence of the OpenSLP package on your system and will not install the slpuasa daemon. OpenSLP is freely available from http://www.openslp.org as both a tarball and an RPM package. In this book, we're going to work only with the RPM version.

Once downloaded, the package is very easy to install. Open a terminal session and switch to the directory where the OpenSLP RPM package is located. Then enter

 

 rpm -i ./  OpenSLP_package_filename  

 

When the installation is complete, the OpenSLP daemon, slpd, is copied to /usr/sbin and its configuration file, slp.conf , is copied to /etc .

After the initial installation, the slpd daemon is configured to run in SA-Only mode, much like the slpuasa daemon discussed earlier. To create a DA, you must edit the slp.conf file, shown in Figure 5.10.

Figure 5.10. A portion of the slp.conf file.

graphics/05fig10.jpg


The following is a list of parameters you can configure in the slp.conf file:

  • net.slp.useScopes ” This parameter has two functions. If the slpd daemon is running in SA-Only mode, this parameter specifies which scopes the local SA is allowed to register its services with. If the slpd daemon is running in DA mode, this parameter specifies the name of the scope associated with the local DA. The default value is DEFAULT .

  • net.slp.DAAddresses ” This parameter forces the local SA to not multicast at startup for DAs. Instead, it forces the SA to register its services, using a unicast, with the specific DAs listed here. This feature is disabled by default.

  • net.slp.isBroadcastOnly ” Like the parameter used with the slpuasa daemon, this parameter forces the local UA and SA to use broadcasts instead of multicasts when locating services. This feature is disabled by default. Under normal circumstances, you probably will never need to enable this parameter. Doing so would greatly increase the traffic on your network.

  • net.slp.passiveDADetection ” This parameter configures the local SA to discover Directory Agents passively. The default value is set to TRUE .

  • net.slp.DAActiveDiscoveryInterval ” If the passive DA detection parameter is set to FALSE , this parameter specifies the number of seconds between active DA discovery transmissions. The default value is 900 seconds. If you set it to , it will be disabled.

  • net.slp.interfaces ” If you have multiple network interfaces in your Linux server, this parameter can be used to specify the network interfaces the local DA and SA should listen on. By default, they listen on all interfaces.

  • net.slp.isDA ” This is the parameter you need to use if you want to enable a local DA. Remember that the UA and SA always run when the daemon is running. To run a DA, you must set this parameter to TRUE . The default value is FALSE .

  • net.slp.DAHeartBeat ” This parameter configures the number of seconds between Directory Agent heartbeat packets. The default value is 10800 seconds (3 hours).

To configure your slpd daemon, simply edit the /etc/slp.conf file, making the changes you need for your network. Once done, you're ready to start the service.

Tip

In the lab for this chapter, you will create a DA and configure it with a scope .


Like the slpuasa daemon, the slpd daemon places an init script file in the /etc/init.d directory named slpd . On other distributions, such as Red Hat, this will be located in the /etc/rc.d/init.d directory.

To run the slpd daemon, open terminal session and enter /etc/init.d/slpd start . As we discussed earlier with the slpuasa daemon, it is absolutely critical that SLP be running on your Linux server for the proper functioning of NNLS components. You should use the chkconfig command to configure the slpd daemon to automatically start on runlevels 3, 4 (optional), and 5. To do this, enter chkconfig slpd 345 at your shell prompt.

Once the daemon is running, you can use the slptool utility, which is installed as a part of the OpenSLP package, to verify that your configuration is working properly.

The syntax for using slptool is as follows:

 

 slptool  options commands  

 

You can use the following options with slptool:

  • -v ” Displays version information.

  • -s scope_name ” Specifies a list of scopes to limit queries to.

You can use the following commands with slptool:

  • findsrvs service-type ” Displays registered services of the type specified.

  • findattrs URL Displays registered services with the specified URL.

  • findsrvtypes URL Lists the services that are available, but not their URLs.

  • findscopes ” Displays all scopes known to the DAs that your local UA and SA know about.

It's important that you remember that your system's SLP configuration is absolutely critical to the proper functioning of your NNLS installation. I highly recommend that you install and configure OpenSLP on your system before you start the NNLS installation process. To do this, we're going to perform Lab Exercise 5.1.

 <  Day Day Up  >  


Novell Certified Linux Engineer (CLE) Study Guide
Novell Certified Linux Engineer (Novell CLE) Study Guide (Novell Press)
ISBN: 0789732033
EAN: 2147483647
Year: 2004
Pages: 128
Authors: Robb H. Tracy

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net