main

• | Table of Contents
• | Index
Novell® Certified Linux Engineer (Novell CLE) Study Guide
By Robb H. Tracy
Publisher | : Que
Pub Date | : October 13, 2004
ISBN | : 0-7897-3203-3
Pages | : 576

The Novell CLE Study Guide, the official study guide to Novell's Certified Linux Engineer (CLE) exam, meets the needs of those seeking to pass the Novell Certified Linux Engineer exam. The Novell CLE Study Guide provides deeper coverage of Nterprise Services for Linux components than any other documentation and the knowledge needed to pass the practical exam with coverage of the Novell Nterprise Linux Services (NNLS) using hands-on labs and scenarios. The accompanying CD includes practice questions to prepare the reader for the exam.


Table of Contents

• | Table of Contents
• | Index
Novell® Certified Linux Engineer (Novell CLE) Study Guide
By Robb H. Tracy
Publisher | : Que
Pub Date | : October 13, 2004
ISBN | : 0-7897-3203-3
Pages | : 576

Copyright
About the Author
Acknowledgments
We Want to Hear from You
Introduction
Chapter 1. Introduction to the CLE Practical Exam
 | Introduction to the CLE
 | Introduction to the CLE Test Environment
 | Summary
Chapter 2. Introduction to SUSE Linux
 | An Overview of Linux
 | Lab Exercise 2.1: Installing a New SUSE Linux Server
 | Working with the Linux Command Line
 | Lab Exercise 2.2: Using the Linux Command Line
 | Working with the Linux File System
 | Lab Exercise 2.3: Managing Linux Files and Directories
 | Answers to Exercises
 | Summary
Chapter 3. Linux Administration and Configuration
 | Managing Linux Users and Groups
 | Managing File Ownership and Permissions
 | Lab Exercise 3.1: Managing Linux Security
 | Managing the Linux Networking Configuration
 | Managing Linux Applications and Services
 | Lab Exercise 3.2: Installing Linux Products and Managing Processes
 | Implementing and Configuring NTP
 | Lab Exercise 3.3: Implementing NTP
 | Summary
Chapter 4. Introduction to Novell Nterprise Linux Services (NNLS)
 | Introduction to NNLS
 | NNLS Components
 | Novell and Open Source
 | Summary
Chapter 5. NNLS Installation and Administration
 | Installing NNLS
 | Lab Exercise 5.1: Installing and Configuring SLP
 | Lab Exercise 5.2: Preparing to Install NNLS
 | Lab Exercise 5.3: Installing NNLS
 | Updating NNLS with Red Carpet
 | Lab Exercise 5.4: Updating NNLS with rcd
 | Managing eDirectory
 | Lab Exercise 5.5: Managing eDirectory
 | eDirectory and LDAP
 | Lab Exercise 5.6: Importing an LDIF File
 | Administering eDirectory on Linux
 | Summary
Chapter 6. Managing User Accounts with eGuide and Linux User Management
 | Working with eGuide
 | Lab Exercise 6.1: Working with eGuide
 | Working with Linux User Management
 | Lab Exercise 6.2: Implementing LUM
 | Summary
Chapter 7. Synchronizing User Identities with DirXML
 | An Introduction to DirXML
 | How DirXML Works
 | Changes Made to the System After DirXML Is Installed
 | Installing and Configuring the DirXML Delimited Text Driver
 | Lab Exercise 7.1: Working with the DirXML Delimited Text Driver
 | Lab Exercise 7.2: Testing the DirXML Delimited Text Driver
 | Installing and Configuring the DirXML eDirectory Driver
 | Lab Exercise 7.3: Working with the DirXML eDirectory Driver
 | Summary
Chapter 8. Implementing File Services with iFolder, Samba, and NetStorage
 | An Introduction to iFolder
 | Installing and Configuring iFolder
 | Lab Exercise 8.1: Implementing iFolder
 | An Introduction to Samba
 | Installing and Configuring Samba
 | Lab Exercise 8.2: Implementing Samba
 | An Introduction to NetStorage
 | Configuring NetStorage
 | Lab Exercise 8.3: Working with NetStorage
 | Summary
Chapter 9. Implementing Print Services with iPrint
 | An Introduction to iPrint
 | iPrint Components and Functionality
 | Installing and Configuring iPrint
 | Configuring iPrint Printers on Windows Workstations
 | Lab Exercise 9.1: Implementing iPrint
 | Lab Exercise 9.2: Implementing Location-Based Printing
 | Summary
Chapter 10. Implementing Email Services with NetMail
 | An Introduction to NetMail
 | NetMail Message Processing
 | Designing, Installing, and Configuring NetMail
 | Lab Exercise 10.1: Implementing NetMail
 | Summary
Chapter 11. Tying It All Together with Virtual Office
 | An Introduction to Virtual Office
 | Installing Virtual Office
 | Configuring Virtual Office Parameters
 | Configuring Virtual Teams
 | Lab Exercise 11.1: Configuring Virtual Office
 | Summary
Chapter 12. CLE Practice Scenario
 | CLE Exam Objectives
 | Business Requirements Document for InfoTec, Inc.
 | Summary
Index


Copyright

Copyright © 2005 by Novell, Inc.

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

Acquisitions Editor Jenny Watson

Development Editor Emmett Dulaney

Managing Editor Charlotte Clapp

Project Editor Matt Purcell

Copy Editor Bart Reed

Indexer Chris Barrick

Proofreader Kathy Bidwell

Technical Editor David Coughanour

Publishing Coordinator Vanessa Evans

Designer Gary Adair

Page Layout Juli Cook

International Standard Book Number: 0-7897-3203-3

Library of Congress Catalog Card Number: 2004101536

Printed in the United States of America

First Printing: October 2004

07 06 05 04 4 3 2 1

Trademarks

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Novell Press cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Novell is a registered trademark; and Novell Press and the Novell Press logo are trademarks of Novell, Inc. in the United States and other countries. All brand names and product names used in this book are trade names, service marks, trademarks, or registered trademarks of their respective owners.

Linux is a registered trademark of Linus Torvalds.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.

Bulk Sales

Pearson Education offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information, please contact

U.S.Corporate and Government Sales
1-800-382-3419
corpsales@pearsontechgroup.com

For sales outside of the U.S., please contact

International Sales
international@pearsoned.com

Dedication

This book is dedicated to all the individuals who have made a difference in my life. To my Dad, for instilling in me a love of teaching and all things mechanical. To my Mom, for teaching me the value of hard work and devotion.


About the Author

With 10 years of teaching experience, Robb H. Tracy is an expert in the information technology training industry. He has a Master of Science degree in Instructional Technology from Utah State University. There he learned the principles of teaching and learning from some of the finest minds in the field.

Since leaving the university, Tracy has designed and implemented technical training curriculums for major industry hardware and software vendors since 1994. He spent some time working for Novell, Inc. in the 1990s, developing courseware for all CNE training programs since NetWare 4.11. He has also served on the CompTIA Network+ certification committee.

In 2002, Tracy co-founded Nebo Technical Institute, Inc., a leading provider of technical training development services. When not rushing to finish yet another project, He can be found relaxing in a boat on a high-mountain lake with a fishing pole in hand.


Acknowledgments

The title page of this book lists Robb H. Tracy as its author. However, this attribution is deceiving. By no means was this a one-man job. Behind every book is a team of people who rarely get the credit they deserve. They are the unsung heroes who make sure the job gets done.

First, I would like to acknowledge the efforts of my beautiful wife, Kimberly. She's kept the bills paid, got the kids to school on time, and kept me sane as I endeavored to hit my deadlines. Without her support, this title would never have happened. Next, I would like to acknowledge the patience shown by Jessica, Joshua, Brittany, and Natasha while Dad tapped away at the keyboard most nights and weekends. It's time to spend some time at the lake kids!

I would also like to acknowledge the efforts of the production team behind this book. These folks were the glue that kept everything together. Thanks to Jenny Watson for giving me the opportunity to write this book. I appreciate your confidence in me! Thanks to Emmett Dulaney as well for managing the development process. I've been in his shoes before, and you don't get a lot of sleep. Thanks, Emmett!

Thanks also go out to Bart Reed for his copyediting efforts. You have to have eyes like a hawk to do his job. Thanks for catching my typos! Speaking of editors, thanks also to Matt Purcell, the project editor behind this book. His positive attitude was contagious!

Finally, a huge thank you to Dave Coughanour at Novell. Dave reviewed each and every word and exercise step in this book for technical accuracy. His efforts kept me honest and were absolutely invaluable, dramatically increasing the overall quality of this title. Dave spent many late nights testing the lab exercises in this book, ensuring you have a successful experience. Thanks, Dave!


We Want to Hear from You

As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass our way.

You can email or write me directly to let me know what you did or didn't like about this book—as well as what we can do to make our books better.

Please note that I cannot help you with technical problems related to the topic of this book and that due to the high volume of mail I receive, I may not be able to reply to every message.

When you write, please be sure to include this book's title and author as well as your name and email address, or phone number. I will carefully review your comments and share them with the author and editors who worked on the book.

Email: | feedback@novellpress.com
Mail: | Mark Taber Associate Publisher Novell Press/Pearson Education 800 East 96th Street Indianapolis, IN 46240 USA


Introduction

Welcome to the world of Novell Nterprise Linux Services! As you will see in later chapters of this book, Novell has yet again revolutionized the Information Technology industry by migrating its world-famous network services from the traditional NetWare platform to the up-and-coming Linux operating system.

By giving organizations the opportunity to provide Novell's productivity-enhancing services on a very inexpensive yet highly stable operating system, Novell has raised a standard that other vendors will be hard-pressed to match. In accordance, Novell Training Services has rolled out a certification program for NNLS: the Certified Linux Engineer (CLE).

Due to the complexity of the CLE certification, Novell wants to make sure candidates really know their stuff with NNLS. To do this, Novell has implemented a practical test for the certification. To pass, you must be able to walk the walk, not just talk the talk.

By gaining your CLE certification, you tell the world that you can actually manage an NNLS deployment, not just answer a bunch of questions about the product in a multiple-choice exam. This gives you a strong competitive edge in a tight job market.

However, this hands-on approach to testing means the CLE exam is much more difficult than most other certification exams you may have taken. The CLE practical exam has a higher failure rate than most written IT certification exams. To pass, you must thoroughly prepare yourself.

That's where this book comes in! By reading this book, completing the lab exercises, and working through the practice scenario at the end, you will be much better prepared than your average CLE candidate.

In Chapter 1, "Introduction to the CLE Practical Exam," I introduce you to the NNLS product and the CLE certification program. I also provide you with some important exam tips and strategies that will increase your chances of passing.

In Chapter 2, "Introduction to SUSE Linux," you will learn some basic Linux skills that you will need to know in order to deploy and manage an NNLS implementation. You will also learn how to install a Linux server in preparation for deploying NNLS. In Chapter 3, "Linux Administration and Configuration," you will learn some intermediate-level Linux skills that will also be required to manage NNLS.

In Chapter 4, "Introduction to Novell Nterprise Linux Services (NNLS)," you will be introduced in depth to the NNLS product, including its component parts, features, and benefits. In Chapter 5, "NNLS Installation and Administration," you will get your hands dirty by installing NNLS on your Linux server. You will also learn how to implement and manage your server's eDirectory tree. You further learn how to keep your NNLS implementation up to date using the Red Carpet daemon.

In Chapter 6, "Managing User Accounts with eGuide and Linux User Management," you will learn how to provide a company address book portal using eDirectory and eGuide. You will also learn how to redirect Linux user authentication to your eDirectory tree using the Linux User Management component of NNLS.

In Chapter 7, "Synchronizing User Identities with DirXML," you learn the basics about one of the most powerful and complex components of NNLS: DirXML. You will learn how to configure a basic delimited-text driver and a more advanced eDirectory driver.

In Chapter 8, "Implementing File Services with iFolder, Samba, and NetStorage," you learn how to increase file accessibility while protecting data integrity using iFolder. You also learn how to implement Samba shares using eDirectory authentication as well as how to provide users with web-based access to the server file system with NetStorage.

In Chapter 9, "Implementing Print Services with iPrint," you learn how to deploy a location-based, automated printing system using iPrint. In Chapter 10, "Implementing Email Services with NetMail," you learn how to deploy a web-based, modular email server: NetMail.

In Chapter 11, "Tying It All Together with Virtual Office," you learn how to tie all the various NNLS components together into a unified, web-based interface using Virtual Office. Finally, in Chapter 12, "CLE Practice Scenario," you will be presented with an NNLS deployment scenario for a hypothetical company to give you an opportunity to practice for your CLE practical exam.

As you progress through this book, my goal is to provide you with a quality learning experience. I hope you find this book well written and easy to understand. I also hope you find it to be adequate preparation for your CLE exam. However, no text is perfect. If you have suggestions for improvement, features you would like to see added, or corrections you feel need to be made, please feel free to email me at support@nebo-tech.com.

Best of luck to you in your CLE certification pursuits!


Chapter 1. Introduction to the CLE Practical Exam

Congratulations on your choice to become a Certified Linux Engineer! By purchasing this book, you are on your way to earning one of the hottest new certifications around.

By gaining your CLE certification, you prove to your employer and your coworkers that you truly know your stuff with Novell services on Linux. That's because Novell's practical testing strategies ensure that anyone certified as a CLE really can do the job. No paper certifications allowed here! We'll go into more depth on the CLE in just a moment. For now, let's take a look at what will be covered in this book.

This chapter provides an overview of Novell's newest certification program—the Novell Certified Linux Engineer (CLE). The following topics will be covered:

  • Introduction to the CLE

  • Introduction to the CLE Test Environment

  • CLE Test-taking Strategies


Introduction to the CLE

For years, Novell certifications have represented the pinnacle of Information Technology industry training. Novell pioneered the certification industry with the Certified Novell Engineer (CNE) and Certified Novell Administrator (CNA) programs.

Novell continues this venerable tradition with the Certified Linux Engineer program. Why a whole new certification? The nature of the product CLE certifies you on is dramatically different from prior Novell products. Let's take a look at the nature of the product you must know in order to become a CLE: Novell Nterprise Linux Services.

Novell Nterprise Linux Services

In 2003, Novell fused together two very powerful worlds. In one world, there is Linux, one of the most robust, stable, and affordable network operating systems available today. These factors contribute to the popularity of Linux.

Each year Linux is finding its way into more and more organizations. According to IDC, an IT industry organization, "Linux servers have demonstrated six consecutive quarters of year-on-year revenue growth, proving that they are not a flash-in-the-pan technology." (Source: IDC Worldwide Quarterly Server Tracker, November 2003)

Residing in the other world are Novell's time-proven network services. Historically, these services were provided only on Novell's high-end NetWare server operating system. Although Novell did eventually port some of these services to the Windows Server platform, very few were made available on Linux.

In 2003, Novell changed all that with the introduction of Novell Nterprise Linux Services (NNLS). In this product, Novell ported its famous services such as iPrint, iFolder, NetStorage, Virtual Office, and DirXML to run on the Linux platform. For the first time, these time-tested services are available on an operating system other than NetWare.

The benefits of this fusion are noteworthy for several reasons. System administrators can implement a reliable, inexpensive, and fully supported open-source network operating system. Embracing Linux allows them to dramatically lower the all-important total cost of ownership (TCO) of the system.

Using eDirectory, administrators can configure the NNLS implementation as a standalone system or integrate it into an existing Novell eDirectory environment. eDirectory also provides administrators with a broad range of user identify management tools and options, depending on which networking platforms are present.

NNLS doesn't require a "rip and replace" approach to deployment. Using NNLS components, administrators can synchronize existing NetWare, Windows Domain, or Active Directory user accounts with eDirectory on the NNLS system.

In addition, end users receive the benefits of Novell's productivity-enhancement services. These services provide users the tools they need to complete their daily tasks, whether they are in the office, at home, or on the road.

For example, suppose a user is at home one evening and receives a call informing her that a report she has been working on is needed first thing in the morning. In the past, she would probably have to drive back to the office to complete the report, expending valuable time on travel.

With NNLS, however, she can use iFolder within a browser interface to access her files from her home computer. When she's finished with the report, all changes made at home are applied to her files on the Linux server at work. Because iFolder only synchronizes the changes she's made, her dialup connection bandwidth can easily handle the task.

With iPrint, she can securely print the document from home to a color laser printer at the office so it is ready as soon as she arrives in the morning. Using NetMail, she can reserve a conference room and send out an appointment—from home—for a morning meeting with co-workers to review the report before turning it in.

Why CLE?

As you can probably see, implementing and managing NNLS require that system administrators really know their stuff with both Linux and Novell services. In accordance with the CLE, certification is very difficult to achieve. This is so for two reasons.

First, you have to know the Linux operating system and the technology behind Novell's NNLS services in depth. You need to know the following:

  • How to manage a SUSE Linux Enterprise Server 8 system, including managing users, groups, permissions, ownership, processes, and services.

  • How to install NNLS.

  • How to manage eDirectory on Linux.

  • How to configure and manage eGuide.

  • How to manage Linux user accounts in eDirectory with Linux User Management (LUM).

  • How to implement DirXML (no small task, I assure you).

  • How to manage iFolder and NetStorage.

  • How to deploy iPrint.

  • How to implement NetMail.

  • How to configure Virtual Office to pull all these services together into a single interface.

Second, Novell has implemented a practical exam, discussed in detail later, to ensure you really have the skills required. You have to be able to deploy an NNLS system, not just fill in a bubble sheet with a No. 2 pencil.

When researching the need for a new certification, Novell discovered that there are many administrators with strong Linux skills and, likewise, many administrators with strong Novell skills. However, there are relatively few administrators in the industry with both Novell and Linux skill sets.

In light of this, Novell designed and implemented the CLE certification program. The CLE program is composed of two elements:

  • NNLS courseware— This Study Guide or Novell's Course 3015 provides you with the skills and knowledge you need to pass the CLE exam.

  • CLE Practicum— Instead of a written exam, the CLE uses a hands-on, live exam that certifies you are sufficiently skilled in both the Linux and Novell realms.

I can't emphasize enough the importance of thorough preparation for the Practicum. With a multiple-choice test, many network administrators have discovered over the years that you can get away without studying. After all, you have a one in four chance of getting the right answer without any knowledge at all. With a little bit of networking background, many candidates can discern the correct response.

Not so with the Practicum. You must be able to "walk the walk and talk the talk," or you will fail miserably. And a large number of candidates have done just that.

With that, let's discuss the target audience of the CLE certification.

Who Is the CLE For?

When designing the CLE, Novell encountered a quandary of sorts. Should the CLE be aimed at existing Novell system administrators who need Linux training, or should it be aimed at existing Linux administrators who need to learn how to use Novell services?

After a great deal of debate, Novell decided to proceed with both candidates in mind. The question then becomes one of where to start. Do you teach Linux and eDirectory in depth, or do you assume a certain level of proficiency on the part of the student? Novell opted for the latter option.

Therefore, the CLE exam and courseware (including this Study Guide) assume that you already have a pretty good grasp of basic Linux concepts and commands. Novell recommends that you complete LPI (Linux Professional Institute's) Level I certification (or have an equivalent level of experience) before completing course materials or taking the CLE exam.

With this said, Novell also realizes that not all CLE candidates have the prerequisite Linux knowledge. Novell also realizes that many candidates may have Linux skills that are out of date.

To accommodate students in these categories, the first portion of the CLE objectives covers very basic Linux skills and tasks. These skills represent about 10% of the CLE exam.

The Novell staff reviewed the various tasks required to implement and manage NNLS services to determine which Linux skills to include in the CLE objectives. From these, it identified the basic Linux skills required and added those to the objectives list for the certification.

In accordance, the first portion of this Study Guide will present a brief introduction to Linux. Be aware, however, that this will not be an exhaustive review. If you have little or no Linux experience, you should spend some time getting to know the product before completing this Study Guide or taking the CLE exam. To do this, you should purchase or borrow three items:

  • An easy-to-read Linux study guide— Unfortunately, many of the Linux guides on the market today are not well written and tend to assume a lot more knowledge than the average new user has. Look for a title that is geared toward the new-user audience.

  • A copy of SUSE Linux Enterprise Server 8— You can download an evaluation copy from http://www.novell.com. That's the good news. The bad news is that SLES 8 comes on four CDs. Each CD download is almost 650MB in size. Unless you have a really fast Internet connection, you will probably need to purchase a copy from your local computer store or from http://www.suse.com. You may be asking, "Why can't I use Red Hat or some other Linux distribution?" The CLE objectives are written to SLES 8. This is the distribution you will be expected to use in the CLE exam and the distribution we will be using in this Study Guide.

  • A Pentium II or later PC to use as a lab machine— Although it is possible to make Linux and Windows coexist on the same PC hardware using the grub or lilo bootloaders, it's a good idea for you, as a new learner, to use dedicated hardware until you have developed a degree of experience with the operating system.

With these items in hand, go through the Linux study guide and familiarize yourself with the operating system. You will then be prepared to complete this Study Guide and the CLE exam.

Novell also assumes you have a certain degree of experience with eDirectory. You need to know concepts such as trees, objects, attributes, rights, containers, leafs, and inheritance. If these terms leave you bewildered, you will need additional training.

Chapter 5, "NNLS Installation and Administration," presents a detailed, yet concise, overview of eDirectory concepts. Try using the content of this chapter first. If it still isn't enough to bring you up to speed, Novell offers an eDirectory fundamentals course (Course 3017) that you may want to consider.

In addition to Linux and eDirectory, you should also have a solid background in computer networking before attempting to complete this Study Guide. The CLE certification assumes that you already have your Network+ certification from CompTIA or have equivalent experience.

If you can answer the question, "What's the default subnet mask for a Class B IP address?" without hesitation, you are probably prepared to begin study for the CLE. If not, you should probably purchase Network+ study materials and review them before completing this Study Guide.

CLE Objectives

With this information in mind, we're ready to move on to a review of the CLE objectives. Be aware that you will be expected to know the concepts and do the tasks specified in each objective.

With many certifications, it's possible to pass the associated exam even if you lack proficiency with a few objectives, as long as you have a good understanding of the other remaining objectives.

With the CLE, however, you must have a strong working knowledge of all the objectives. To be blunt, the CLE Practicum is an unforgiving pass/fail exam. More candidates fail it than pass it. This is due to the way Novell structured the CLE exam, which will be covered in more depth later in this chapter.

Novell's CLE exam incorporates multiple objectives into a given testing scenario. If you lack proficiency with one of the objectives, you could potentially fail the entire scenario, thus failing the exam.

The objectives in the CLE certification are as follows:

  • Describe the characteristics of Linux.

  • Use the Linux command-line interface.

  • Manage the Linux file system.

  • Manage Linux applications.

  • Manage Linux network interfaces.

  • Describe Novell Nterprise Linux Services (NNLS).

  • Perform an NNLS installation.

  • Manage NNLS with Red Carpet.

  • Describe the purpose of eDirectory.

  • Describe how eDirectory works.

  • Perform eDirectory administration tasks.

  • Manage user objects with iManager.

  • View user information with eGuide.

  • Access a Linux server with Linux User Management (LUM).

  • Describe the purpose of DirXML.

  • Describe how DirXML works.

  • Install the DirXML Starter Pack on Linux.

  • Implement the Delimited Text driver for DirXML.

  • Implement the eDirectory driver for DirXML.

  • Describe the purpose and architecture of iFolder.

  • Install and configure iFolder.

  • Describe the purpose and architecture of Samba.

  • Install and configure Samba.

  • Describe the role and function of NetStorage.

  • Install and configure NetStorage.

  • Identify the benefits of iPrint.

  • Describe how iPrint works.

  • Install and configure iPrint.

  • Print with iPrint.

  • Identify NetMail features.

  • Describe NetMail components.

  • Describe how NetMail works.

  • Install NetMail.

  • Configure and use NetMail.

  • Describe Virtual Office.

  • Install Virtual Office.

  • Configure Virtual Office.

Using This Study Guide

To pass the CLE exam, you must have both the theoretical knowledge and the technical skills reflected in the objectives. This Study Guide is designed to provide you with both of these elements.

First, each chapter in this Study Guide presents conceptual information related to each CLE objective. For chapters that are heavy with conceptual information, you will find a "Check for Understanding" exercise at the end that you can use to verify that you have mastered the information presented.

It is critical that you take time to complete these activities. Use the results to identify information you may need to review. Doing so will greatly increase the likelihood that you will pass the CLE exam.

Second, each chapter in this study, with the exception of this one, includes one or more hands-on exercises to help you gain the Linux and NNLS skills required to pass the CLE exam. As you progress through this guide, you will build a complete NNLS implementation, piece by piece, from the ground up.

Again, it is absolutely critical that you complete these exercises. The CLE exam requires that you be able to complete these tasks in a live NNLS environment.

This is a departure from most certification exams in the IT industry today. They generally require you to complete an exam that tests your mastery of only the conceptual subject matter. The CLE, on the other hand, tests your ability to do the tasks specified in the objectives.

To complete these exercises, you will need the following equipment:

  • A lab PC—This computer must meet the following specifications:

    • CPU— Pentium III 800MHz or later

    • Memory— 512MB minimum

    • Hard disk— 4GB or more

    • Peripherals— Printer, monitor, mouse, and keyboard

  • A copy of NNLS 1.0— An evaluation copy of NNLS is available from Novell at http://www.novell.com.

  • A copy of SLES 8— An evaluation copy of SLES 8 is available from Novell at http://www.novell.com. It's important to note that NNLS will run on other Linux distributions. However, the only supported distributions are SUSE Linux Enterprise Server 8 and Red Hat Enterprise Server 2.1. Because SLES 8 is specified in the CLE objectives, this is the distribution used in this Study Guide. If you choose to use a different distribution, some of the steps in the hands-on exercises may not work.


Introduction to the CLE Test Environment

Let's discuss the CLE exam in a little more detail. As mentioned earlier, the CLE exam is called a "practical" exam, and you may hear it referred to as "The CLE Practicum." They mean one and the same thing.

Why Practical Exams Are Used

Traditional certification exams in the IT industry usually provide the student with a series of multiple-choice, fill-in-the-blank, and matching questions, as shown in Figure 1.1.

Figure 1.1. Traditional testing method.

The strength of these types of exams is the fact that they are very effective at evaluating your mastery of theoretical concepts. They are also easier to create and deliver.

Their weakness is the fact that they don't test your ability to actually perform the tasks specified in the objectives. In other words, they tend to evaluate what you know instead of what you can do. You may have heard the term paper certified before. This term refers to network administrators who have passed the multiple-choice exam for their certification, but who can't actually perform on the job. Novell wanted to make sure this situation didn't happen with the CLE certification.

Novell has been a pioneer in the field of practical testing since its Certified Directory Engineer (CDE) certification was introduced in 1999. Novell has implemented exams that present you with a scenario and then require you, without guidance, to determine the proper resolution and to implement that resolution correctly.

The strength of this strategy is that it truly verifies whether you have mastered the skills specified in the objectives.

Students who pass a practical test are much more likely to be able to perform better on the job than those who pass traditional exams only. To a job applicant, this is of high value. It gives you bargaining power with an employer, allowing you to provide a higher degree of verification of your skill set.

Unfortunately, "certified" IT job applicants have burned many employers over the years. Because their skills were only verified at the conceptual level, their ability to actually do the job was sometimes less than what was necessary.

Practical certification testing helps employers filter out less qualified job applicants. When you apply for a job, employers can have a higher degree of confidence in your abilities if you have successfully completed a practical exam.

You should, however, be aware that the pass rate on practical exams tends to be much lower than traditional exams. To pass the CLE practical exam, you will probably have to spend twice as much time preparing as you would for a traditional certification exam. Interestingly, Novell reports that even though the pass rate on the CLE exam is lower than a traditional exam, most candidates feel the test was a fair one—even those that fail. Some exam-preparation tips are presented later in this chapter.

How the CLE Practicum Works

The CLE Practicum is composed of the components shown in Figure 1.2.

Figure 1.2. The CLE Practicum.

The role of each of these components is as follows.

The Testing Center Computer

The first component in the CLE Practicum is the testing center computer. In order to complete the Practicum, you must schedule a test with a Novell education partner center. This can be done by visiting http://practicum.novell.com/partner_search.php. At the testing center, you will use a Web browser on the testing center computer to access the virtual servers running on the Novell server. The CLE exam interface is shown in Figure 1.3.

Figure 1.3. The CLE Practicum interface.

The Novell Server

The second component in the Practicum is the Novell server. This server is maintained at Novell's Provo campus and is used to run VMWare, a product that allows multiple operating systems to be run simultaneously on a single computer. More information about VMWare can be found at http://www.vmware.com.

Virtual Servers

The final Practicum component is the group of virtual server sessions running on the Novell server. Each session represents a SUSE Linux server. These servers have been preconfigured using a specific scenario.

Depending on what scenario you are required to complete, you may find that these servers have been deliberately configured incorrectly. To pass the exam, you must correct any errors and implement the requirements of the scenario in these virtual servers.

CLE Practicum Tips and Strategies

When you are in the testing center taking your CLE Practicum, you should keep the following tips in mind. They will save you a lot of trouble!

  • Follow all the instructions to the letter! When you begin your exam, you will be presented with detailed instructions on how to complete the exam. Don't skip reading these.

  • You are accessing the virtual servers using a TCP/IP connection. You should never change the IP address, subnet mask, router address, or DNS server address of your virtual servers. Doing so will disrupt your ability to access them.

  • You will be automatically logged in to the virtual server as a non-root user. If you need root-level access, you should open a terminal session and use the su- command. Under no circumstances should you log out. You won't be able to log back in.

  • Remember that the virtual Linux server has several key processes running on it that provide you with remote access at the testing center. Don't kill a running process unless you are absolutely sure you know what it is first. If you accidentally kill a process that provides remote access, your session will be closed.

  • You should never exit the X Windows System. If you need access to a shell prompt, open a terminal session.

  • If you need to restart your server, use the reboot command. You should never use the halt or logout command.

  • On occasion, your mouse cursor may disappear when using Mozilla within the virtual server desktop. It may or may not come back. (Sometimes wiggling the mouse quickly will cause it to reappear.) If you can't get your cursor back, you must exit Mozilla by pressing Ctrl+Q and then restart it.

  • It can take some time to load iManager on your server for the first time. Be patient. After it is loaded into memory on your virtual server, it should run at a reasonable speed thereafter.

  • Remember that you are completing the exam on a virtual server being accessed through a remote-access Web connection. It's going to run much slower than a real server. Exercise patience and don't get "click happy."

As mentioned previously, passing the CLE Practicum will require considerably more effort than traditional certification exams. Before you start studying the CLE objectives, we need to spend some time in this chapter discussing some test-taking strategies that will help you be successful in your Practicum experience.

Read the Scenario

Remember that the CLE Practicum is scenario based. Novell has a number of different CLE scenarios. Each one is slightly different from the others. When you sign on at the testing center, you will be randomly assigned one of these scenarios to complete.

When you receive your scenario, keep the following points in mind:

  • Read the scenario thoroughly. Due to the time constraints imposed on the Practicum, your first impulse will be to get working right away on your virtual Linux server. Avoid this impulse at all costs. It is imperative that you read through your scenario line by line. The time spent will be time well invested.

  • As you read, carefully analyze the details of your scenario. Your testing center should provide you with scratch paper or a whiteboard for making notes. Use these materials to record the following information:

    • What is the problem or error condition identified in the scenario?

    • Are there any special or unusual conditions identified in the scenario?

    • What criteria must be met in order for the scenario to be considered resolved? (It is critical that you list each item!)

    • What tests can you run to verify that each success criteria has been met?

  • Don't assume that your server has been configured properly as you read the scenario. Depending on your scenario, you may have to isolate and resolve various misconfigured parameters.

  • After you have read through and analyzed your scenario, read it again! Chances are you will find one or more items that you missed. Add these to your scenario analysis.

Plan Your Strategy

After you have thoroughly read and analyzed your scenario, you will be, once again, tempted to immediately dive in and start working on your virtual server. Avoid this impulse at all costs!

Before working on your server, it is imperative that you use your scenario analysis to create a plan of action. Again, using your testing center scratch paper or whiteboard, identify each of the tasks you must complete in order to resolve the condition in the scenario. List them in the order that they must be completed.

Implement Your Plan

When you have thoroughly analyzed your scenario and have planned your strategy, you can now give in to your impulse and actually start working on your virtual server. If you've organized yourself properly, you should be able to complete the scenario quickly and methodically.

As you do, it is important that you keep your eyes open for hidden issues that may not have been overtly described in the scenario. Be prepared to reevaluate your plan at any time.

Test the Resolution

As a part of your overall plan, you should have identified how you would test your resolution to ensure that you have completed each criterion in the scenario. (It's interesting to note that many CLE candidates fail to complete this simple task.)

When you have completed each task in your plan, implement your evaluation plan and verify that the scenario has been truly completed.

There's a better than average chance that you will find one or more problems remain unresolved. Identify each of these and, again, develop a plan for how you will work them out.

If you study the materials in this book, practice with the lab exercises, follow the exam instructions, plan your strategy, and test your implementation, you will greatly increase your chances of passing the CLE practicum. Let's review what you learned in this chapter.


Summary

In this chapter, you were introduced to the CLE certification from Novell. You learned about its purpose, its audience, and how it is delivered.

You then learned about the nature of the CLE practical testing environment. You learned about the various components that comprise the practical exam.

Finally, you were presented with some test-taking tips and strategies for increasing your chances of passing the CLE practical exam.

In the next two chapters, you will learn the basics of Linux. After that, we will dig into the various components of NNLS as we progress through the rest of the book.


Chapter 2. Introduction to SUSE Linux

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Describe the characteristics of Linux.

  2. Use the Linux command-line interface.

  3. Manage the Linux file system.

In this chapter, we'll walk through a general overview of Linux concepts and skills you will need to install and administer an Novell Nterprise Linux Services (NNLS) implementation. If you already have a solid background with Linux, you can probably skip ahead to Chapter 3, "Linux Administration and Configuration."


An Overview of Linux

Test Objective Covered:

1. Describe the characteristics of Linux.

As mentioned in Chapter 1, "Introduction to the CLE Practical Exam," Novell had a tough decision to make when designing the Certified Linux Engineer (CLE) certification. Should it be directed toward existing Novell Certified Novell Engineers (CNEs) who need to learn how to manage the products and services they are already familiar with on the Linux platform, or should it be directed at Linux professionals who need to learn how to use Novell products and services?

After a great deal of discussion and debate, Novell decided to aim for both audiences with this certification. To accommodate those who might not have a background in Linux, Novell included a series of objectives in the CLE that covers some basic Linux concepts.

This chapter and Chapter 3 of this study guide present a quick introduction to Linux and provide a review of some common Linux administrative tasks. Be aware that Novell assumes you have some degree of Linux experience prior to taking this course.

The content in this chapter and Chapter 3 are not intended to make you a Linux expert. Instead, they are intended to help you study the key tasks you will need to know in order to complete the exercises that appear later in the study guide. As mentioned in Chapter 1, you might want to obtain additional Linux study materials if you are new to Linux.

If you are already experienced with the Linux operating system, you may want to jump ahead to Chapter 4, "Introduction to Novell Nterprise Linux Services (NNLS)," using this chapter and Chapter 3 as a reference.

A Historical Review of Linux

Linux is somewhat of an anomaly in the computer software world. Most software products, whether they are applications or operating systems, are developed as a part of a planned and well-organized effort. Usually, a software company first identifies a customer need. It then assembles a design team that hashes out a product requirements document (PRD).

The tasks in the PRD are allocated to teams of software developers who write their assigned portions of the code. The developed code is checked and the product is tested through a series of alpha- and beta-stage testing cycles. If it measures up to expectations (or is at least reasonably close), the finished product is shipped to the customer.

After the customer has used the product for a period of time, the software company notes its deficiencies and a revision process starts the cycle all over again.

The advent of Linux didn't conform to this corporate product development cycle. Instead, one person—Linus Torvalds—initially developed it while he was a graduate student at the University of Helsinki in Finland.

During his studies in the early 1990s, Torvalds developed an interest in a freeware product called Minix, an educational version of the commercially developed Unix operating system. Andrew S. Tanenbaum, a university professor in the Netherlands, developed Minix, which looked and behaved like Unix, but was written completely from scratch. At the time, there were three main operating systems available:

  • MS-DOS (and other variants such as PC-DOS and DR-DOS)

  • Mac OS

  • Unix

The source code for each of these operating systems was carefully protected by patent and copyright. At an earlier point in time, the source code to Unix had been made available to universities for teaching purposes. This practice had been stopped, however, leaving Tanenbaum without an effective means for teaching his students about the inner workings of an operating system. To provide this, he developed a small educational version of the Unix kernel that he called Minix. Its purpose was to provide students with a real operating system with source code access. Heralding things yet to come, Tanenbaum included the source code to Minix in his textbook Operating Systems: Design and Implementation.

Inspired by Tanenbaum and his Minix operating system, Torvalds developed his own Unix clone in 1991, which he dubbed Linux. It's important to note that Torvalds didn't initially develop a full-blown operating system complete with a full suite of applications and utilities. Instead, Linux version 0.02, released on October 5, 1991, provided only the Linux kernel and three utilities: bash (a command-line interface), update (a utility for flushing file system buffers), and gcc (a C++ compiler).

Note

Interestingly, Tanenbaum and Torvalds didn't always get along. They reportedly had many heated email discussions.

In an unprecedented move, Torvalds made the Linux source code freely available over the Internet to anyone who wanted to download it. Torvalds even went so far as to invite other programmers to refine and enhance his code. At that point, Linux became a worldwide collaborative project. Version 1.0 of the Linux kernel was released in 1994. The results since have been nothing short of amazing.

About GNU

A discussion of the history of Linux would be incomplete without introducing GNU's Not Unix (GNU). The GNU movement exerted a significant influence on Torvald's development of Linux.

In the early 1980s, a programmer from the Massachusetts Institute of Technology named Richard Stallman objected to the proprietary nature of software development, so in 1983 he launched the GNU project. This project was dedicated to the advancement of freely distributable source code. Stallman felt that source code should be free from restrictions against copying, modification, and redistribution. He believed that allowing programmers to modify an application's source code would result in better software.

Powerful applications, such as the GNU C Compiler (gcc) were subsequently developed, and many of them were written to run on Linux. The availability of an array of powerful GNU applications on Linux was a key factor in taking the Linux kernel from a hobbyist's project to a robust tool capable of doing real work.

Linux itself is licensed under the GNU General Public License (GPL), which ensures that the operating system's source code will remain freely available to anyone who wants it. Anyone is free to download the Linux kernel's source code, modify it to meet their own requirements, and then recompile and run it.

This is a very significant aspect of Linux, as most software vendors do not make their products' source code available. To even further protect themselves, most have a section in their End User License Agreement (EULA) that forbids the user from reverse-compiling the software.

Note

Reverse-compiling is a process in which a special application is run against a binary file to reproduce the file as code in a text file. The resulting code isn't an exact duplicate of the original source code, but it can be very close.

Linux Distributions

You're probably aware that there are many different Linux distributions available. Among the choices, there's SUSE Linux, Red Hat Linux, Slackware Linux, and many others. This is yet another unique characteristic of Linux—nearly every other operating system is developed and marketed by a single vendor. For example, the only vendor who develops and sells OS X is Apple, Inc. You can't go to Novell or Microsoft for their versions of the Mac OS.

With Linux, however, there are many different, independent companies that each sell their own distribution.

The GPL also allows developers to bundle their own utilities and applications with the kernel and create what is known as a distribution.

To draw a comparison, imagine that you want to purchase a copy of the latest version of Windows. If Windows were licensed under the GPL, you would notice at your local computer store that there are hundreds of different "flavors" of the operating system available from many different software vendors—only one of which is Microsoft.

Each flavor is slightly different from the others; although they're still based on the same operating system kernel. One might be optimized to provide web-based services, and another might be optimized for video editing. Imagine being able to sort through the different flavors and find the one that is best geared toward what you want to do.

Sounds far-fetched—but with Linux, that's exactly what is available to you. Many different software vendors have taken the basic Linux kernel, modified and recompiled it according to their specifications, bundled some value-add applications with it, and redistributed it as their own Linux distribution.

Today there are, quite literally, more than 100 different distributions available. This course will use SUSE Linux from Novell as the distribution for running NNLS. Most of the concepts and skills taught in Chapters 2 and 3, however, can be transferred to almost any other distribution. You can learn more about these Linux distributions by visiting http://www.linuxiso.org.

The Function of Linux in a Computer System

Let's turn now to a discussion of the part Linux plays in a computer system. Believe it or not, this is actually a point of confusion for many. Because most of the PC systems sold over the past two decades have had a version of either MS-DOS or Windows installed on them, many end users don't understand the modular role of an operating system.

Many tend to see the operating system as an integral, inseparable part of the PC. I've encountered many users who are under the impression that Linux is some kind of application that runs on top of DOS or Windows. I kindly explain to them that Linux is an operating system, not an application, and that it is used instead of DOS or Windows. In other words, it is a substitute for Windows, not a complementary application.

Even with this explanation, it is inconceivable to many that you can pull Windows or DOS off a system and use Linux as the operating system. To avoid this kind of confusion, let's discuss the generic role of an operating system.

All operating systems, whether they be DOS, Windows, Mac OS, Unix, NetWare, or Linux, provide four key functions in the computer system:

  • Application platform— Applications generally don't access the system hardware directly. Operating systems provide a platform where applications can be run. Operating systems manage and prioritize application access to the system.

  • File storage— Operating systems provide a means for writing, organizing, and retrieving data from system storage devices.

  • Security— Most modern operating systems are multiuser systems. They use rules configured by the system administrator to identify who the authorized users of the system are and what they can do within the system.

  • Hardware moderator— A key role of an operating system is providing applications with easy access to system resources. It provides a means for applications to address the CPU, place information in RAM, read and write information to the hard disk drive, and communicate with peripherals such as printers, COM ports, or network boards. Instead of having to write code from scratch to do these tasks, most operating systems contain prewritten, reusable routines that the application programmer can use to interact with system hardware. It also provides methods for managing system input and output devices such as the keyboard.

The difference between operating systems is how they are designed and how they fill these roles. As you might guess, some fill these roles better than others.

Introduction to the Linux User Interface

For an operating system to be useful, it must provide an interface that allows the end user to easily communicate with it. Linux provides two user interfaces:

  • The command-line interface— The basic Linux interface is the command-line interface. The user communicates with the operating system by entering commands at a shell prompt. A common Linux shell prompt is shown in Figure 2.1.

    Figure 2.1. A Linux command-line interface.

  • The X Window System graphical interface— In a world dominated by graphical user interfaces, a command-line only operating system may face some resistance. There are many computer users in the world today, both end users and system administrators, who have never had to use a command-line interface. To make it easier to use, the XFree86 project developed an X Window system that runs on Linux. Using the base XFree86 system along with a window manager (such as GNOME or KDE), users can interact with the Linux kernel in a graphical environment. The GNOME graphical interface on SUSE Linux is shown in Figure 2.2.

    Figure 2.2. A Linux graphical interface.

An Introduction to the Linux File System

As mentioned earlier in this chapter, one of the key roles filled by an operating system is managing a storage system that allows files to be written and retrieved from storage devices such as floppy disk drives and hard drives.

Linux uses a hierarchical file system much like other operating systems you might be familiar with. Consider the Windows file system shown in Figure 2.3.

Figure 2.3. The Windows file system.

At the top of the Windows file system is the root directory. In this example it is C:\.

Real World

Technically, C: identifies the drive letter assigned to the NTFS partition. The \ indicates the root directory of the file system on that partition.

Files or other directories can exist within the root directory. Sometimes these are called subdirectories. Subdirectories can contain other subdirectories or files. In this example, there is a file named MyStuff.txt. It is located in the MyStuff directory. MyStuff is a subdirectory of the Temp directory; which is, itself, a subdirectory of the root directory \.

To describe the location of the MyStuff.txt file, you prepend the path to the file to its name. In this example, you would use C:\Temp\MyStuff\MyStuff.txt.

Linux works in a very similar manner. However, there are some differences you should be aware of. Consider Figure 2.4 as an example.

Figure 2.4. The Linux file system.

Just as with the Windows file system, there is a root directory. Instead of being referenced as \, the Linux root directory is referenced as /. The root directory contains subdirectories and files. In this example, there is a file named MyStuff.txt located in the MyStuff directory. This directory is a subdirectory of the Temp directory—which is itself a subdirectory of the root directory /.

Notice that the only apparent differences, so far, are the absence of a drive letter and the direction of the slash. Windows (and DOS, for that matter) use the back slash character (\) in the directory structure. Linux, on the other hand, uses the forward slash (/).

There are, however, more significant differences between the Windows file system and the Linux file system. Let's investigate, in the sections that follow, some of the most critical aspects of the Linux file system you need to understand to succeed in this course.

Case Sensitivity

Recall our Windows example: You can reference the file specified as C:\Temp\MyStuff\MyStuff.txt by C:\TEMP\MYSTUFF\MYSTUFF.TXT, C:\TEMP\MYSTUFF\MyStuff.txt, C:\Temp\MyStuff\MYSTUFF.TXT, or any other combination of upper- and lower-case characters. File and directory names under Windows (or DOS) are not case sensitive.

Under Linux, however, file and directory names are very case sensitive. In the example presented here, the correct path and file name is /Temp/MyStuff/MyStuff.txt. If you try to reference this file as /TEMP/MYSTUFF/MYSTUFF.TXT or as /temp/mystuff/mystuff.txt, it will fail. According to the standards used to define the Linux file system, these two names point to completely different files and directories.

Mount Points

The Windows file system uses a drive letter—in the example given, the drive letter is C:. Drive letters are used by NTFS and FAT file systems to uniquely identify a partition on the hard drive. There could be multiple partitions on the drive (each with its own drive letter assigned), or there could be one partition that encompasses the entire drive. Each drive letter has its own hierarchical structure underneath it.

Linux, on the other hand, doesn't use drive letters. Like Windows, the Linux file system can use multiple partitions, but instead of assigning a new drive letter to each partition, the Linux file system incorporates each partition within the same hierarchical structure using mount points.

A mount point is simply a directory in the file system that points to a different Linux partition. This partition could be on the same hard drive in the same system, a partition on a different hard drive in the same system, or even a remote file system on a hard drive in a different PC.

Note

To mount remote file systems, you must use the Network File System (NFS) service.

When you change to the directory where the mount point is set, the Linux file system takes you to the different partition or file system.

For example, suppose you use your Linux system to edit video footage. The raw files you work on take tremendous amounts of space and you need to add a new 200GB hard drive to your system.

To do this, you would first partition and format the drive. Then you can create a directory in the existing file system where you want to mount the new partition—say, in /home/rtracy/rawfootage. You can then use the mount command to mount the new hard disk in the file system.

Real World

To automatically mount the partition every time the system boots, you can place an entry in the /etc/fstab file—a file system table. We'll cover the fstab file later in the book.

To save a file on the new hard drive, you simply save it to /home/rtracy/rawfootage and it will be automatically redirected to the new disk.

This metaphor applies to removable devices such as CDs, DVDs, or floppy disks as well. Recall that in the Windows file system, floppy disk drives and CD/DVD drives are assigned their own drive letter.

Under Linux, these devices are mounted and incorporated into the Linux file system's single unified hierarchical structure. On a SUSE system, CDs or DVDs are mounted, by default, in the /media/cdrom directory. Floppy disks are mounted, by default, in the /media/floppy directory. SUSE uses the /mnt directory for mounting local hard disks or remote NFS file systems.

Note

Using the mount command, you can actually mount a CD or a floppy disk in any directory in the file system you want.

On other Linux distributions, such as Red Hat, the default mount directory for CD/DVDs is /mnt/cdrom. The default mount directory for floppy disks is /mnt/floppy.

Another difference is the fact that, on a Windows system, a floppy diskette or a CD/DVD is immediately available as soon as you insert it in the system. Depending on the Linux distribution you are using, this may or may not be the case. On some systems, when you insert a CD, DVD, or floppy disk, you must manually mount it before you can access it.

Other systems might be running a process that detects the insertion of a disc or diskette and automatically mounts it in the default mount directory specified in the /etc/fstab file.

Linux Partitions

A key difference between the Windows and Linux file systems is the types of partitions used. Windows 95, 98, and Me provide FAT16 and FAT32 partition types. Windows NT, 2000, and XP provide FAT32 and NTFS partition types.

Although Linux can actually mount these types of partitions into its hierarchical tree, the Linux file system itself uses very different types of partitions. Older Linux distributions use EXT2 partitions. Newer distributions use the EXT3 (Red Hat and others) or ReiserFS (SUSE) partition types.

EXT3 and ReiserFS partitions use a process called journaling. To understand journaling, you need to understand that one of the key responsibilities of the system is to protect data integrity.

One of the ways this is done is by recording information about each file in the file system such as its size, the time and date of the last modification, and its path.

In an EXT2 partition, an improper system shutdown could cause some of this cached data to not be written properly to disk.

When the system was subsequently restarted, this issue would be detected and a repair would be automatically attempted by the fsck (file system check) utility. The problem with this process is that fsck could take a great deal of time, depending on the size of the file system, to repair all the problems.

EXT3 and ReiserFS compensate for this using a process called journaling. Simply speaking, the journaling process records every action that is going to take place on all file system files before the actions actually occur. If an improper shutdown occurs, the system simply checks the journal and compares it against the actual state of the files. Any actions that were missed as a result of the improper shutdown can be quickly identified and subsequently completed. This allows an improperly shut down system to come back up much more quickly than a system that uses EXT2 partitions.

Another difference is the number of partitions used. On most Windows systems, a single disk system generally only uses a single partition, as shown in Figure 2.5.

Figure 2.5. Default Windows partitions.

On most Linux systems, however, there are three partitions by default, as shown in Figure 2.6.

Figure 2.6. Default Linux partitions.

  • /boot— This partition is an EXT2, EXT3, or ReiserFS partition, and it is usually 50MB to 100MB in size. This partition is represented by the first entry in the list of partitions shown in Figure 2.6. Notice that it is the only partition marked as bootable. It contains the Linux startup files. Because it is a bootable partition, it must reside within the first 1,024 cylinders of the hard disk drive, although this usually isn't a problem. Most Linux install programs can automatically partition your hard disk for you, and they will ensure that this partition resides where it should on the disk. This becomes an issue if you decide to manually partition the drive, or if you are creating a dual-boot system.

  • /— This partition is an EXT2, EXT3, or ReiserFS partition and is mounted at the root directory of the hierarchical file system. It contains the Linux system files, utilities, and user files. It is represented by the third partition displayed in Figure 2.6.

  • Swap— If you're familiar with Windows, you know that every version since Windows 3.0 creates a swap file on the hard drive. Linux does things a little bit differently. Instead of a file in the file system, Linux uses a dedicated swap partition. This is the second partition shown in Figure 2.6. Again, if you let your Linux install program partition your drive for you, it should automatically determine the proper size for you. If you manually partition your hard drive, the general rule of thumb is that the swap partition should be at least as big as the amount of RAM in the system.

Linux Bootloaders

A bootloader is a small piece of software that resides in the boot sector of the first hard disk in the PC system. When a PC boots, the system BIOS on the motherboard first takes control of the system. It runs various tests to verify that critical pieces of hardware, such as the system memory, hard disks, and so on, are available and responding. When it's done, the BIOS searches for a bootloader. If it finds it in the prescribed location, the BIOS relinquishes control of the system to the bootloader.

The bootloader software is configured with the location of the startup files of the operating system on the hard disk drive. If multiple operating systems have been installed, the bootloader can be configured to present the user with a simple menu that allows him to choose the operating system to load.

All operating systems come with some kind of bootloader. There are two commonly used bootloaders in Linux systems:

  • Linux Loader (LILO)— The LILO bootloader was used on earlier Linux systems. Because it was very popular at one time, most modern distributions still provide LILO as an optional bootloader that can be installed. The configuration parameters for LILO are stored in the /etc/lilo.conf file shown in Figure 2.7. If you make any changes to this file, you need to enter lilo at the shell prompt before rebooting your system, or else the changes won't take effect.

    Figure 2.7. The LILO bootloader configuration file.

  • Grand Unified Boot Loader (GRUB)— GRUB is the default bootloader used on most newer Linux distributions. As with LILO, you can customize the way GRUB works by editing its configuration file. There are actually two files you need to be concerned with: /etc/grub.conf and /boot/grub/menu.lst. The menu.lst file is shown in Figure 2.8.

    Figure 2.8. The GRUB bootloader configuration file.

Introduction to Linux Users

The last topic we will address before actually installing a new SUSE Linux server will be that of Linux user accounts. Most modern operating systems are multiuser systems; this means that more than one person can use the same operating system on the same PC. When the system is first booted, you must authenticate using a valid username and password before you are allowed to do anything further with the system.

Note

Linux actually takes this concept one step further. Using various utilities and configurations not covered in this guide, multiple users can use the same operating system at the same time.

Most Linux install programs create two users by default when you first create the system. The first is the root user. This account is the superuser account. It is comparable to the Administrator account in a Windows system or the Admin account in a NetWare system. The root account has, by default, all rights to all files, services, and user accounts in the system.

The second account created during most installation routines is a generic user account that you name, which has limited access to the system. Because the root account is so powerful, most system administrators don't actually use it unless they have to. For day-to-day tasks, they will authenticate as a generic user that has limited access to the system. When they need to perform root-level tasks, they will change to the root account using the su - command at a shell prompt.

The concern is that if an administrator authenticates as root and stays logged in throughout the day, it creates a small security breach that unauthorized users can breach. For example, consider what could happen if the system administrator, logged in as root, steps away from her desk to pick up several documents she sent to the printer. While she's gone, an unscrupulous individual could potentially have enough time to exploit the root-level access and compromise the system.

To avoid this, you should log in to your system as a regular user and only switch to the superuser account when absolutely necessary.

Note

If you routinely use the root account, your fellow Linux system administrators will probably tease you mercilessly!

Whenever you create a new user account, a home directory is automatically created for that user in the /home directory, as shown for the student user in Figure 2.9.

Figure 2.9. The home directory for users.

The exception to this rule is the root user. This user account has its own exclusive home directory called /root.


Lab Exercise 2.1: Installing a New SUSE Linux Server

Up to this point, this study guide has focused on giving you a general overview of Linux. The goal is to give you just enough knowledge to get your own SUSE Linux server installed. After this, most of our work will be done on the server itself. We can't proceed until this is done.

To complete this exercise, you will need the following items:

  • A lab PC— This PC must meet the specifications listed in Chapter 1.

    Note

    Be sure to make a backup of any data on this server that you want to preserve! The installation we are going to perform in this lab will overwrite ALL data on the drive. As an alternative, you might want to consider using VMWare Workstation from VMWare, Inc. Once installed on a Windows 2000 or XP workstation, it allows you to install multiple guest operating systems that run in a window on top of the Windows host operating system. See http://www.vmware.com for more information.

  • Your copy of SLES 8— This is included with this study guide.

Be sure your system is configured to boot from the CD drive first. Use your BIOS' CMOS Setup program to configure it to do this.

To complete this exercise, do the following:

  1. Boot your system from the SUSE Linux Enterprise Server 8 CD.

  2. In the Installation screen, press the function key that corresponds to your highest possible screen resolution. For example, if you want to select 1024x768, press F5. If you encounter resolution problems, try a lower resolution setting or try Text mode.

  3. Select Installation.

  4. In the License Agreement screen, select Accept.

  5. In the Language Selection screen, select your language and then select Accept.

  6. In the Installation Settings screen, make sure the keyboard layout and the mouse settings are correct for your hardware.

  7. Select Partitioning and then select Create Custom Partition Setup.

  8. Select Next.

  9. Mark your hard disk drive and then select Next.

  10. If you receive a message asking you to use the remaining free space on your hard disk, select No.

  11. Select Use Entire Hard Disk and then select Next.

  12. Scroll down and select Software.

  13. Select Detailed Selection.

  14. Make sure only the following product groups are selected (deselect any items that are not in this list):

    1. Gnome System

    2. KDE Desktop Environment

    3. Simple Webserver

    4. LSB Runtime Environment

    5. Help & Support Documentation

    6. Graphical Base System

    7. YaST2 Config Modules

    8. Analyzing Tools

    9. DHCP and DNS Server

    10. SLES Administration Tools

  15. In the Filter drop-down list, select Search.

  16. In the Search field, enter gettext and then select Search.

  17. In the right frame, mark the gettext package.

  18. In the Search field, enter locate and then select Search.

  19. In the right frame, mark the findutils-locate package.

  20. Select Accept.

  21. Scroll down to and select Time Zone.

  22. From the list presented, select your time zone and then select Accept.

  23. Select Accept to continue.

  24. When prompted to start the installation, select Yes, Install.

  25. When prompted, insert the UnitedLinux CD 1 in your system's CD drive and select OK. Wait while the files are copied.

  26. When prompted, insert the UnitedLinux CD 2 in your system's CD drive and select OK. Wait while the files are copied.

  27. When prompted, insert the SUSE Enterprise Linux 8 CD 1 in your system's CD drive and select OK. Wait while the system initializes.

  28. When the root user configuration screen appears, enter a password of novell, then select Next.

  29. In the Add a New User screen, create a user account using the following information:

    • First name—Student

    • Last name—Student

    • User login—student

    • Password—novell

  30. Select Next.

  31. In the Desktop Settings screen, verify that the correct video board and monitor have been detected.

    Note

    It's recommended that you use a minimum screen resolution of 1024x768.

  32. Mark Graphic Desktop Environment and then select Accept.

  33. If a printer warning appears, select Skip Detection.

  34. Configure your network board as follows:

    1. Select Network Interfaces.

    2. Select Change.

    3. Make sure eth0 is selected, and then select Edit.

    4. Select Static Address Setup.

    5. In the IP Address field, enter an appropriate IP address for your network.

    6. In the Subnet Mask field, enter an appropriate subnet mask for your network.

      Note

      If your server will reside on a network at your place of employment, be sure to get permission from your organization's network administrator to put this server up. Also, consult with the administrator to secure a static IP address assignment. They tend to get a bit testy if you arbitrarily grab one and start using it without their knowledge.

    7. Select Host Name and Name Server.

    8. In the Host Name field, enter CLE1.

    9. In the Domain field, enter CLE.com.

    10. Select Next.

    11. Select Routing.

    12. In the Default Gateway field, enter the IP address of your default gateway (if you have one).

    13. Select Next.

    14. Select Next again.

    15. Select Finish.

  35. Review your installation settings and then select Next. The system will now reboot.

  36. When the system has rebooted, select gnome from the Session Type drop-down list.

  37. Authenticate as root with a password of novell.

  38. If you see an error message related to the image for the terminal icon, select OK. Then complete the following to correct the error:

    1. Right-click the terminal icon (it looks like a bare foot) and then select Properties.

    2. Select the No Icon button.

    3. Scroll down and select gnome-term-linux.png (it looks like a seated penguin) and then click OK.

    4. Click Close.

    5. Select Actions, Logout.

    6. Select Save Current Setup and then click OK.

    7. After the system has rebooted, log in as student with a password of novell.

Congratulations! You now have a fully functional SUSE Linux implementation. In the rest of this chapter as well as in Chapter 3, we will spend some time learning how to use the system.


Working with the Linux Command Line

Test Objective Covered:

2. Use the Linux command-line interface.

There are two types of interfaces Linux provides for communicating with the operating systems: a graphical interface and a command-line interface.

Although graphical interfaces tend to be easier to use, many of the tasks you must perform later in this course are best done from the command line. In accordance with this, Novell has included an objective in the CLE certification that requires you to demonstrate that you know how to use the command line.

To allow users to interact with the kernel using the command line, Linux uses command-line interpreters called shells.

Linux Shells

If you've ever used MS-DOS or Novell's NetWare, you are already familiar with the concept of a command-line shell. The shell is simply a command interpreter that allows you to type commands from the keyboard to interact with the operating system kernel. A typical command-line interface is shown in Figure 2.10.

Figure 2.10. The Linux command-line interface.

In MS-DOS, COMMAND.COM provided this functionality. As with many other aspects of Linux, you have several different shells to choose from. You can try out several of them and then settle on one that you like the best. Some of the more popular shells include the following:

  • sh (Bourne Shell)

  • bash (Bourne-Again Shell)

  • csh (C Shell)

  • tcsh (Tom's C Shell)

  • zsh (Z Shell)

Which shell you choose is really a matter of preference. If you try each one, you'll probably find that they each work pretty much in the same way.

When you boot to a command prompt or open a terminal session on your Linux system, a default shell is used. Most distributions use the bash shell by default.

To determine which shell you're using, enter the env command at the shell prompt. This command lists all the environment variables for the currently logged in user. One of the variables is the shell currently in use, as shown in Figure 2.11.

Figure 2.11. Checking the shell currently in use.

In this example, you can see that the bash shell is currently in use, as shown by the SHELL variable. If you want to change the shell you're using, simply enter the shell command at the current shell prompt. For example, if you are running bash and want to use zsh, simply enter zsh at the shell prompt. To stop using the new shell and revert back to the original shell, enter exit.

Linux is fully capable of running the 80x86 CPU in Real mode, which allows you to run multiple command-line sessions at once, even if you're not using the XFree86 graphical interface. Each session can run its own programs, all simultaneously.

This can be very useful if you have one program running and then need access to the command prompt. For example, suppose you are installing NNLS and you reach the point where the installation program needs to access the license diskette. You realize that you forgot to insert and mount it. You can simply open another session, mount the diskette in the second session, change back to the first session, and continue the installation.

Before going any further, I need to point out that this can be done in two ways. First, from a text-based shell prompt, you can open alternate command-line screens, each capable of running its own programs independently of the others.

Second, from within X Window System, using multiple command-line interfaces can be done in two different ways. The first, and easiest, is to simply open multiple terminal sessions. Each terminal session can run its own set of programs independent of the others, as shown in Figure 2.12.

Figure 2.12. Running multiple terminal sessions.

The second method is to press Ctrl+Alt+function_key. This will switch you to a text-based shell prompt. This is very useful because some tasks, such as creating eDirectory users in NNLS, can only be done from a text-based shell prompt. Using Ctrl+Alt+F1 switches you to the first text-based console screen, Ctrl+Alt+F2 switches you to the second one, and so on up to F6. To switch back, press Alt+F7 and you will return to your X Window System session.

If you're running your Linux system without X Window System running, you can switch between shell prompts by simply pressing Alt+function_key. For example, to switch to the third alternate console screen, simply press Alt+F3.

Using Linux Commands from the Command Line

To enter commands at the Linux command line, all you have to do is type the name of the command at the shell prompt.

If you are experienced with using a command prompt under Windows or DOS, there are some important differences you must be aware of. First, although Linux implements a PATH variable similar to the one used in DOS, it is used differently. The Windows or DOS command interpreter will check the current directory for a file specified at the command prompt as well as the directories specified in the PATH variable.

Note

The PATH variable is an environment variable that contains a list of directories.

Linux works in a similar manner; however, it doesn't check the local directory for the specified file. This represents an enormous stumbling block to those who are new to Linux. Because of their prior experience with DOS and Windows, they expect to be able to switch to the directory where an executable resides and run it from the command line.

Instead, Linux searches all the directories in its PATH variable. A typical Linux PATH environment variable is shown in Figure 2.13.

Figure 2.13. The PATH variable.

There are three ways to get around this:

  • You can provide the full path to the executable file. For example, if you wanted to run an executable named helloworld located in /usr/myfiles, you could enter /usr/myfiles/helloworld at the shell prompt.

  • You can switch to the directory where the executable file resides. Then prepend ./ to the command. In the previous example, I would switch to the /usr/myfiles directory and then enter ./helloworld at the shell prompt. The ./ characters refer to the current directory. By prepending them to a command, you tell the shell program to look for the file in the command in the current directory.

  • You can add ./ to the PATH variable. This will direct the command interpreter to check the local directory regardless of the current directory.

Another issue you need to be aware of is one we briefly discussed earlier in this chapter. Linux file names and directory names are case sensitive. Hence, Linux commands are also case sensitive. If the executable file you are going to run is HelloWorld, you must use HelloWorld at the command prompt. Helloworld, HELLOWORLD, or helloWorld won't work. Linux sees each of these as different files.

This applies to directory names as well. If you're calling /usr/myfiles/helloworld, you must enter the command using the exact case. /Usr/Myfiles/helloworld will point the command interpreter to a completely different directory structure.

A final issue to be aware if is the fact that each user has his or her own PATH variable. If you log in as root, you will have directories in your PATH variable that won't exist if you log in as a different user.

Commonly Used Linux Commands

As you get to know the Linux operating system, you'll find that there are some very powerful commands that you use over and over. The following is a list of some commonly used commands:

Note

There are many other Linux commands. Unfortunately, covering all of them is beyond the scope of this study guide. If you want to learn more about Linux commands, see a Linux reference text.

  • halt— This command shuts down the operating system, and can only be run by root.

  • init0— This command also shuts down the operating system, and can only be run by root.

  • reboot— This command shuts down and restarts the operating system. It can only be run by root.

  • init6— This command shuts down and restarts the operating system. It can only be run by root.

  • man— This command displays the manual (man) page for the specified command. This is a very useful learning tool. If you are unsure how to use any command, use man to display its manual page. You can exit a man page by pressing q.

  • info— This command displays a help page for the specified command. The information displayed tends to be more in-depth than that displayed in the man page for the same command.

  • su— This command switches the current user. For example, if you're logged in as fred and need to change to user account mary, you can enter su mary. This command is most frequently used to switch to the superuser account. If you don't supply a username (in other words, you simply enter su), this utility assumes you want to change to the root account. If you enter su -, you switch to the root (superuser) user account and have all of its environment variables applied.

    Real World

    Because of this, the su command is frequently misconstrued to stand for "super user." In fact, it stands for "switch user."

  • env— This command displays the environment variables for the currently logged in user. The output of env was shown in Figure 2.11. Notice that this includes items such as the user's name, default shell, and system host name.

  • echo— This command is used to display a line of text on the screen. It's very useful for displaying environment variables. For example, if you want to see the current value of the HOSTNAME variable, you can enter echo $HOSTNAME. If you want to see the user name of the currently logged-in user, you can enter echo $USER.

    Real World

    The $ used in this command tells the echo utility that the string of text that comes after it is a variable, not a literal string of text. If you omitted the $, the echo command would simply display the text HOSTNAME on the screen.

  • top— This command is a very useful command that displays a list of all processes currently running on the system. You can sort them by several criteria, including CPU usage, memory usage, process ID, and so on. You can also use top to kill a process that is hung. To exit the top utility, press q.

  • which— This command is used to display the full path to a shell command. For example, if you want to know the full path to the top command, you would enter which top.

  • whoami— This command is used to display the username of the currently logged-in user.

  • netstat— This command is used to display the status of the network, including current connections, routing tables, multicast memberships, and statistics.

  • route— This command is used to manage the operating system's routing table. You can add, remove, and modify routing information.

  • ifconfig— This command is used to manage network interfaces in the system. If you've spent much time working with Windows NT, 2000, or XP, you're probably familiar with the IPCONFIG command. With it you can release and renew DHCP connections, assign IP addresses, and so on. The ifconfig command is used in much the same way. If you enter ifconfig without any parameters, it will display the current configuration parameters for your network interfaces. The ifconfig utility is located in /sbin. This directory is included, by default, in the root user's PATH variable. You can still run it as a non-root user, but you will have to call it explicitly from the /sbin directory.

  • yast2— This command is used on a SUSE Linux system to provide a menu-driven interface to configure the system. It is available in text-only form from a text-based shell prompt and as a GUI utility under X Window System. This is a very useful tool. With it, you can do the following:

    • Install or remove software.

    • Run online updates.

    • Configure peripherals such as printers, sound boards, mouse devices, graphic cards, and monitors.

    • Configure network interfaces.

    • Manage user accounts.

    • Partition hard disk drives.

    • Run a system backup.

    Real World

    The equivalent utility on a Red Hat system is setup.

  • startx— If your Linux system is configured to boot to a shell prompt, you can start the XFree86 graphical interface by entering this command at the prompt.

Real World

In Linux circles, booting to a shell prompt is referred to as runlevel 3. Booting to a XFree86 graphical environment is referred to as runlevel 5. Runlevels will be discussed in more detail in Chapter 3.

As you implement NNLS, you'll find that you will need to use these tools on a frequent basis. To make sure you understand these tools, let's run though a lab to practice using them.


Lab Exercise 2.2: Using the Linux Command Line

In this exercise, you will use your newly installed SLES 8 server to practice using commonly-used Linux commands, as well answer some tricky questions. Check the "Answers to Exercises" section at the end of this chapter for the answers.

Complete the following:

  1. Boot your server and log in as student with a password of novell and a session type of gnome.

  2. Complete the following:

    1. In the top bar, select the Terminal icon.

    2. How can you determine who the currently logged on user is? (Hint: There are three ways.)

    3. At the shell prompt, enter su – to change to the root account.

    4. When prompted for a password, enter novell.

    5. At the shell prompt, enter reboot.

  3. When the server has restarted, log in as the student user with a password of novell and a session type of gnome.

  4. Open a terminal session again. How can you determine which shell you are using? (Hint: There are two ways.)

  5. What is the full path to the top utility?

  6. What is the full path to your home directory?

  7. Determine which currently running process is using the most CPU time by completing the following:

    1. At the shell prompt, enter top.

    2. Enter P (be sure to use an uppercase P).

    3. Which process uses the most CPU time?

    4. Open a second terminal session.

    5. Enter xclock.

    6. Does the order of the processes change?

  8. Determine which interrupt your network board is using by completing the following:

    1. Open a new terminal session.

    2. Change to the root account by entering su - and providing a password of novell.

    3. Enter ifconfig.

    4. What interrupt is eth0 using?

  9. Suppose you need to use the route command to enable multicasting on your server. How can you determine the necessary switches and parameters?

  10. Close all your terminal sessions.

Check your answers at the end of this chapter. If you got them right, you're ready to move on and learn how to work with the Linux file system.


Working with the Linux File System

Test Objective Covered:

3. Manage the Linux file system.

To effectively manage a Linux server, it's imperative that you have a sound understanding of the Linux file system. We've already introduced this topic earlier in this chapter, but now we're going to dive in a little deeper in the sections that follow.

Default Linux File System Structure

If you're familiar with Windows or DOS, you will probably be completely lost when you first encounter the default Linux directory structure. There's little in the way of similarity between them.

That's because they are based on completely different standards. The Linux directory structure is based on the Linux Standards Base (LSB). The goal behind the LSB project is to encourage all the various Linux distributions to conform to a set of operating system standards, including how the file system is organized. The purpose is to ensure compatibility between distributions.

Within the LSB is the File Systems Hierarchy (FSH) standard. This defines directory structures, naming standards, and usage. For more details on the LSB, visit http://www.linuxbase.org.

A full review of all the default Linux directories is beyond the scope of this study guide. The folks at Novell, however, felt it important enough that they included this objective in the CLE. Here are the common Linux directories you need to be familiar with to be successful in the CLE Practicum:

  • /bin— This directory contains most of the useful command-line programs and shells you learned about earlier in this chapter. These include echo, bash, zsh, su, and netstat, among others.

  • /dev— This directory has a special purpose in the Linux file system—it contains files that represent special links to system hardware. For example, in /dev is a file named sda. This file points to the first SCSI hard disk drive, if it exists, in the system. If you have two SCSI hard disk drives, the sdb file would reference the second drive. The hda file points to the first IDE hard disk drive in the system. The fd0 file is a link to the floppy drive A.

  • /etc— This directory contains configuration files for the various applications and utilities on the system. For example, the fstab file, mentioned earlier in this chapter, is located in this directory. Your hosts file is also located in this directory. If you needed to configure your web server, you would use the httpd.conf file located in the httpd subdirectory of /etc. Because the files in this directory are used to configure the local system, the files in the /etc directory on one Linux system will be different from those on other Linux systems.

  • /home— This directory contains home directories for every user in the system except for root.

  • /mnt— This directory is used as a mount point for remote NFS file systems. It is also used to mount a Samba share on a remote server. On some distributions, such as Red Hat, it is used to mount removable media such as floppy disks and CDs.

  • /media— This directory is unique to SUSE Linux. It is used as a mount point for removable media.

  • /root— This directory is the root user's home directory. By default, only root can see this directory.

  • /tmp— This directory is used for storage of temporary files created by applications.

  • /usr— This directory is used to store binary program files. For example, gcalc, an X Window System calculator program, is stored in the /usr/bin directory.

    Real World

    Many people think that usr stands for "user." That isn't true. The acronym usr stands for Unix System Resources.

  • /var— This directory has a variety of uses. Manual pages are stored here, as are log files. Data files for services such as named and dhcpd are stored here. You will also see that NNLS stores many of its data files here, as well.

Warning

Because the data stored in /var can grow very large (especially with NNLS installed), you should make sure the partition where /var is located has lots of free space. Some NNLS administrators will actually add an additional disk to the system, partition it, and mount it at /var to ensure they don't run out of space.

As you will be working a great deal with these directories in this course, it would be a good idea to commit their names and uses to memory.

Keep in mind that these are the default system-created directory structures. There's nothing to stop you from modifying the structure or creating your own additional structures. If you do, however, be sure to document your changes. An administrator down the road might inherit your system from you and will need to know what you have put where.

Command-Line File System Utilities

Just as with other operating systems, Linux provides a suite of utilities you can use to manage the file system. These include tools to make directories, copy files, move files, delete files, remove directories, view the contents of files, and so on.

It's been my experience that system administrators who learned their trade in a graphical environment tend to become a little nervous when presented with command-line file system utilities. I've heard arguments from them to the effect that, if graphical utilities are available, in this case X Window System, why bother learning how to use the command-line version of these utilities?

In a Windows world, there is some validity to their argument. Windows command-line utilities generally aren't as powerful as their graphical counterparts.

The same can't be said for Linux. There are two good reasons for leaning how to use command-line Linux tools. First and foremost, many Linux system administrators and implementers actually install their systems without X Window System. They want their server systems to run as fast as possible. They don't want to "waste" CPU cycles redrawing graphical screens. Second, the Linux command-line file system utilities tend to be much more powerful than their graphical counterparts. Most experienced administrators share this opinion, preferring command-line utilities over their graphical equivalent.

In short, to be a good Linux system administrator, you simply must know how to effectively use the command line. With that said, let's review some of the most commonly used command-line file system management utilities. Note that this study guide doesn't go into great depth on the syntax required to use these commands. You can use the man command to learn the specifics of how to use each of those utilities.

Real World

Remember that these commands are case sensitive!

  • cat— This command is used to display the contents of a text file on the screen. The DOS equivalent would be the TYPE command. The syntax is cat file_name. For example, to print the contents of the system log to screen, you would enter cat /var/log/messages.

  • cp— This command is used to copy files. The syntax used is very similar to that used with the COPY command used by MS-DOS. You simply type cp source_file destination_file.

  • cd— This command is very similar to its DOS counterpart command: CD. It is used to change directories within a file system. The syntax is cd directory_name.

  • dir— This command is very similar to the DOS command DIR. It is used to display a listing of the contents of a directory. The syntax is dir directory_name. If no directory name is supplied, it displays the contents of the current directory. If you add an –o switch, the file owners and permission assignments, discussed in the next chapter, are displayed as well.

  • find— This command is used to search for a directory or file. For example, you could enter find /tmp to find all the files in the /tmp directory and its subdirectories.

  • grep— This command is very powerful. It is used to search for an expression within a file. The syntax is grep expression file_name. If you use the –i switch, grep will ignore case as it searches the file. This utility is very useful for searching for specific text within large log files.

  • less— This command is related to the more command. It is usually used in conjunction with another command, such as dir, ls, or cat, to pause long displays one screen at a time. For example, if you were to execute dir –o for a large directory, such as /usr/bin, the output quickly scrolls off the screen before you can read it. If, instead, you were to enter dir /usr/bin –o |less, the output will pause at each screen, allowing you to read the text. This command also allows you to page forward or backward through the display (which the more command can't do).

  • locate— This command is similar to the find command. It is used to search for files in the file system. It uses a special search database that speeds up the search process. The updatedb command is used to initially build the database. To locate a file, enter locate file_name. For example, you could enter locate gnome-term-linux.png to locate the graphic file you used for your terminal icon in GNOME.

  • ls— This command is similar to the dir command. It is used to display the contents of a directory. The syntax is ls directory_name. If no directory name is provided, it will display the contents of the current directory. If you append the –l switch, the owners and permissions assigned to the files in the directory will also be displayed.

  • mkdir— This command is used to create a directory in the file system. It is similar to the MD command in DOS. The syntax is mkdir path/directory_name. If you omit the path, the directory will be created in the current directory.

  • more— This command is similar to the less command. It is used in conjunction with another command, such as dir, ls, or cat, to pause long displays one screen at a time. For example, if you were to enter dir /usr/bin –o |more, the output will pause at each screen, allowing you to read the text.

  • mv— The mv command is similar the MOVE command under DOS. It is used to move files within the file system. It can also be used to rename a file in place. The syntax for this command is mv source_path/file destination_path.

  • pwd— This command displays the current directory.

  • rm— This command is similar to the DEL command under DOS. It is used to delete a file in the file system. The syntax is rm file_name.

  • rmdir— This command is similar to the RD command under DOS. It's used to delete a directory from the file system. The syntax is rmdir directory_name.

  • tail— This is a very useful command for viewing entries in text files, such as a log file. Log files can become quite large over time. There will be many times when you will actually only need to view the last few entries in the file. The tail command is used in these circumstances—it displays the last 10 lines of a text file (although you can configure it to display more). The syntax is tail file_name. When troubleshooting a Linux system, one of the most useful tools I've found is to use tail on the /var/log/messages file. By using the –f parameter, you can continuously monitor the file.

The preceding commands are very useful when you're maintaining a Linux system, especially one with NNSL installed. At this point, we need to discuss in depth several utilities that you must know how to use in order to install and configure NNLS on your Linux system. These include mount, tar, gunzip, and vi.

Using the mount Command

In order to install NNLS on your Linux system, you must know how to use the mount command. This command wasn't included in the preceding list because you need to know how to use it in depth. You will probably need to use the mount command whenever you insert a floppy diskette or a CD/DVD disc in your Linux server's drives.

Tip

Some Linux distributions use an automount daemon that detects a new diskette or disc in the system and will automatically mount it.

The syntax for the mount command is as follows:

mount -t filesystem_type device mount_point

The mount command supports many different file system types. There are really only two that you need to be concerned with for the CLE certification. The first is the ISO9660 file system. This is used by most data CDs. The other is the VFAT file system. This used by most floppy diskettes.

Tip

Technically, a floppy diskette can be formatted using any file system that supports the media type. However, in this book, all the floppy diskettes we will work with will be formatted using the FAT file system. This allows them to be readable in both Windows and Linux systems.

Check the man page for mount to see a complete list of supported file systems.

To mount a floppy diskette on a SUSE Linux system, you would insert the disk and then enter mount -t vfat /dev/fd0/media/floppy.

Note

Remember that you don't have to use the /media/floppy direcrory. You can mount the disk anywhere in the file system. However, many applications are hard-coded to look in /media/floppy when they are looking for a floppy diskette.

On a Red Hat system, you would use the same command, but you would mount the diskette in the /mnt/floppy directory.

If you have the correct entry in the fstab file, you don't have to specify the file system type or the mount point. Consider the fstab file shown in Figure 2.14.

Figure 2.14. The fstab file.

Notice that /dev/fd0 is configured to automatically mount to /media/floppy. Because of this, you can enter the following command to mount a floppy diskette:

mount /dev/fd0

You can customize your fstab file to make the mount process even easier. To do this, use the following command:

ln -s /dev/fd0 /dev/floppy

Note

To learn more about how ln is used to create links, check out its man page by entering man ln.

When executed on your system, this command creates a file in /dev called floppy and creates a symbolic link between it and the /dev/fd0 file. After it's executed, you can mount a floppy diskette on your system by simply entering the following:

mount /dev/floppy

CDs are mounted in a similar fashion as floppies. On a SUSE Linux system, insert the CD in the CD drive and then enter the following command:

mount -t iso9660 /dev/cdrom /media/cdrom

A Red Hat system is mounted in the same way except that the default mount point is /mnt/cdrom.

Notice in Figure 2.14 that there is an entry in the fstab file for /dev/cdrom that configures it to automatically mount to the /media/cdrom directory. Because of this, you can mount a CD using a simplified mount command as shown here:

mount /dev/cdrom

If your system doesn't have an entry for /dev/cdrom in the fstab file, you can create your own symbolic link, as we did for the floppy diskette drive. Check the fstab file and entry for the CD drive. If your CD drive is the master drive on the secondary IDE channel (which is how most PC manufacturers configure them), its corresponding link in /dev will be hdc. You can create a symbolic link for /dev/cdrom by entering the following command:

ln -s /dev/hdc /dev/cdrom

Once this link has been created, the preceding mount command will work properly. To access a mounted floppy diskette or CD, simply change directories to the mount point. The files on the media will be accessible in that directory.

It is critical that you remember that mounted media must not be removed unless you first dismount it. You'll notice that, once mounted, you can't open the CD drive door until it is dismounted. There is nothing to stop you, however, from removing a mounted floppy diskette from its drive.

This can be a serious issue. Changes made to the files on the diskette may not be immediately written to the disk. Dismounting the media immediately writes all changes to disk. If you remove it without dismounting, files may become corrupted.

To dismount a mounted floppy diskette, enter the following command:

umount /dev/floppy

or

umount /dev/fd0

To dismount a mounted CD, enter the following command:

umount /dev/cdrom

Tip

You can also use the mount point directory with the umount command. For example, you could dismount a floppy diskette by entering umount /media/floppy.

Managing Archive Files

With the concept of mounting removable media behind us, we still need to cover a few more topics in this chapter. Novell wants you to understand how to work with Linux archive files in preparation for your CLE practical exam.

Most operating systems have programs written for them that can compress multiple files into a single zip file. You've probably downloaded a zip file before from the Internet, or had one emailed to you.

Linux also has utilities for working with compressed files. It's a little bit different, however, than those you've probably worked with on the Windows or Macintosh platforms. Linux uses two separate utilities: tar and gzip. The tar utility, which stands for tape archive, is used to take multiple files from the Linux file system and combine them into a single file. Tape archive files usually end with a .tar extension. This archive file is not compressed.

The gzip utility is used to compress files. It can be used to compress any file in the file system, but it is most frequently used to compress archive files. The gunzip file is used to decompress a compressed file. Files compressed with gzip usually have a .gz extension.

If you see a Linux file that has a .tar.gz extension, you know that this is an archive file that has been compressed with gzip.

Note

Compressed archive files are sometimes called tarballs.

There are two ways to decompress and extract a tarball file. The first way is to use the gunzip command to decompress the file, and the syntax is gunzip file_name. After the file has been decompressed, you'll notice that it automatically loses its .gz extension. For example, if you were decompressing mystuff.tar.gz, the resulting file from the gunzip process would be mystuff.tar.

After decompression, the archive is extracted using the tar command, and the syntax is tar -xvf file_name. The x switch tells the tar utility to extract an existing archive file. The v switch tells the tar utility to display the progress of the extraction process on the screen. The f switch tells the tar utility that the string of text that follows is the name of the file to be processed.

Warning

The v switch is optional, but the x and f switches are not.

The tar utility can also be used to both decompress and extract, and this is the second method for managing tarball files. To do this, simply add a –z switch to the tar command and run it against the .tar.gz file. This will automatically decompress and then extract the archive. For example, if you have a tarball named mystuff.tar.gz, you could decompress and unarchive it by entering tar -zxvf mystuff.tar.gz.

Editing Text Files

The last topic we will address in this chapter is that of editing text files. Another way that Linux is unique from Windows is the fact that most Linux configuration changes are made by editing text files.

If you're familiar with Windows, you know that most of its configuration parameters are stored in the Registry. Data in the Registry is stored in a series of binary files that can only be edited with a binary file editor such as REGEDIT or REGEDT32.

Linux configuration parameters, on the other hand, are stored in a series of text files that are located, for the most part, in the /etc directory.

Which is the better method? I suspect this question is very subjective. Personally, I much prefer editing a text file. For me, they are much more intuitive. Too many times have I opened up Registry keys in Windows and had to do a lot of head scratching to understand them. With a text file, programmers can (and usually do) include documentation for the various parameters as comments within the file.

Most Linux distributions include a number of text editors, both graphical and command-line, that you can use to edit these configuration files.

Using vi from the Command Line

One of the most commonly used editors is vi—a command-line text editor. Depending upon your distribution, you might have vi or vim (which stands for vi improved) installed. To open a file for editing in vi, enter the following command:

vi /path_to_file/file_name

When you do, vi is executed, and the specified file is loaded. For example, if you need to edit the smb.conf file (which is used to configure the Samba service), you could enter vi /etc/samba/smb.conf. When you do, the following appears, as shown in Figure 2.15.

Figure 2.15. The vi command mode.

If you're used to text editors such as Notepad under Windows, you might find vi a little confusing at first. You need to understand that vi operates in two different modes: Insert mode and Command mode.

Insert mode is used for actually editing the file. When the file is first opened in vi, however, it is opened in Command mode. This mode is what is shown in Figure 2.15. To edit the file, you must enter Insert mode by pressing Ins or by pressing i, as shown in Figure 2.16.

Figure 2.16. Editing in vi Insert mode.

Notice in Figure 2.16 that the text –INSERT- appears at the bottom of the screen when you are in Insert mode. When you are in Command mode, this text is absent, as shown in Figure 2.15 In Insert mode, you can edit the file just as you would with any other text editor. To return to command mode, press the Esc key.

In Command mode, you can enter commands to work with the file. To enter a command in Command mode, you must first type:. This brings up a command prompt of sorts where you enter vi commands (see Figure 2.17).

Figure 2.17. Entering vi commands.

Notice that you now see a colon (:) and a cursor at the bottom of the screen, as shown in Figure 2.17. This cursor is used to issue commands to vi. For example, to exit vi and save all changes made to the currently open file, you would enter exit or q at the command prompt. To exit vi without saving changes to the file, you would enter quit! or q!.

A full review of all vi commands is beyond the scope of this book. Fortunately, there is an extensive help system available for vi. At the shell prompt, enter vimtutor to learn more.

Editing Text Files Using Graphical Utilities

If text-based editors make you uncomfortable, you can also use one of several graphical text editors from the X Window System environment to edit Linux configuration files.

On a Red Hat system, you can use the gedit utility. Open a terminal session and enter gedit from the shell prompt. You can also select Main Menu, Programs, Applications, gedit. When you do, the screen looks like Figure 2.18.

Figure 2.18. Editing text files with gedit.

You'll find that gedit works in a manner very similar to the Notepad utility on a Windows system.

On a SUSE Linux system, you can use the KWrite utility to edit text files in a graphical environment. You can run KWrite by selecting Applications, KDE Menu, Editors, KWrite. When you do, the screen shown in Figure 2.19 appears.

Figure 2.19. Editing text files with KWrite.

When you understand how to use mount, tar, gunzip, and vi, you've got the skills you need to complete an initial NNLS installation. Before continuing, make sure you can use these utilities in Lab Exercise 2-3.


Lab Exercise 2.3: Managing Linux Files and Directories

In this exercise, you will work with the various utilities we have introduced in this chapter to complete common file system tasks. The answers are located at the end of this chapter. Complete the following:

Note

In this exercise, you will be presented with several hypothetical situations that will direct you to check several log files for error messages. If your system is running properly, you might not see any error messages at all. That's all right. (In fact, that's good!) The point of the exercise is to give you some experience using the utilities themselves, not troubleshooting actual problems.

  1. Boot your Linux server and authenticate as your student user with a password of novell.

  2. Open a terminal session.

  3. Change to the root user account by entering su - and providing a password of novell.

  4. Suppose you've been having trouble with your Linux server and you want to check the messages file for any entries with the term "error" in it. Complete the following:

    1. At the shell prompt, enter grep -i error /var/log/messages.

      Tip

      Using the –i switch tells the grep utility to ignore case and find any instance of the search string in the specified file.

    2. What error entries were you able to locate?

  5. Suppose an error just occurred again on your system. You need to check the end of the messages file to see what happened.

    1. At the shell prompt, enter tail /var/log/messages.

    2. What are the last 10 messages recorded in the file?

  6. You decide to capture messages as they are written to the messages file in an attempt to catch the error as it occurs. Complete the following:

    1. At the shell prompt, enter tail -f /var/log/messages.

      Note

      The –f switch tells the tail utility to monitor the specified file for changes and display them onscreen as they occur.

    2. Open a new terminal session.

    3. At the shell prompt, enter su -.

    4. Authenticate with a password of novell.

    5. Log out of your superuser session by entering exit.

    6. Check to see the messages displayed by the tail utility.

    7. Exit tail by switching to the terminal session where it is running and pressing Ctrl+C.

  7. Practice mounting and dismounting removable media by completing the following:

    1. Make sure you have root access by entering whoami at the shell prompt. If you aren't logged in as root, use the su command to switch to this user.

    2. Insert your SUSE Linux CD in the server's CD drive.

    3. If it doesn't automount, enter mount -t iso9660 /dev/cdrom/media/cdrom.

    4. Access the files on the CD by entering cd /media/cdrom.

    5. Generate a listing of files on the CD by entering ls.

    6. Generate a detailed listing of the files on the CD by entering ls -l.

  8. Practice managing files and directories by completing the following:

    1. At the shell prompt, create a new directory named files in /tmp by entering mkdir /tmp/files.

    2. Using either the ls or dir command, pick a file on the mounted CD to copy.

    3. Copy this file to /tmp/files by entering cp ./file_name/tmp/files.

    4. Change to the /tmp/files directory by entering cd/tmp/files.

    5. Verify the file was copied by entering ls -l.

    6. Delete the file you just copied by entering rm ./file_name.

    7. Change to the root directory of the file system by entering cd /.

    8. Delete the directory you created by entering rmdir /tmp/files.

    9. If asked to confirm, enter y.

    10. Dismount the CD by entering umount /dev/cdrom.

    11. Remove the CD from the CD drive.

  9. Practice editing files.

    Warning

    It's important that you complete this step of this exercise. The file created will be used in a lab exercise in the next chapter.

    1. Change to the /tmp directory by entering cd/tmp.

    2. Use vi to create a new text file by entering vi ./scriptfile.txt.

    3. Enter Insert mode by pressing the Ins key.

    4. Enter the following text in the file:

echo "Changing to the /var/log directory."

cd /var/log

echo "Running grep to check for errors."

grep -i error messages

cd /tmp

echo "The script is now finished."

    5. Exit Insert mode and return to Command mode by pressing Esc.

    6. Save the changes to the file by entering :exit.

    7. Verify that the text of the file has been entered correctly by entering cat ./scriptfile.txt.

    Real World

    If you try to execute the script at this point, you will find that it won't run. You must configure permissions on the file to make it executable. This will be done in the next chapter.

  10. Close the root session by entering exit.

  11. Close your terminal session.

That's it for this exercise. You should now know how to use the su, grep, tail, whoami, mount, ls, mkdir, cp, rm, rmdir, and umount commands. In the next chapter, you'll learn about users, groups, and permissions. After that, you'll be ready to install your own NNLS implementation.


Answers to Exercises

Compare the following with the results you came up with in the exercises.

Lab Exercise 2.2

2b. You can determine the currently logged-in user by checking the shell prompt text, by entering env, or by entering echo $USER.

4. You can determine the shell program being used by entering env or by entering echo $SHELL.

5. The full path to top is /usr/bin. You can find this by entering which top.

6. If you're logged in as student, your home directory is /home/student. You can determine this by entering env or by entering echo $HOME.

7c. Answers vary.

7f. Answers vary.

8d. Answers vary.

9. You can learn how to use any Linux command by entering man command_name. In this case, you could enter man route.

Lab Exercise 2.3

4b. Answers vary.

5b. Answers vary.


Summary

In this chapter, you were introduced to the Linux system. The following topics were discussed:

  • You learned about the evolution of Linux from Unix and Minix.

  • You also learned that Linux is distributed under the GPL license, which allows developers to modify the Linux source code and recompile the operating system. We discussed the function of an operating system and how Linux fills those roles.

  • You were introduced to the Linux command-line interface and the X Window System graphical interface. You were introduced to Linux file system concepts such as mount points, partitions, and bootloaders.

  • You were introduced to Linux users, including the default root user account.

  • You learned about Linux shells, such as sh, bash, and tcsh. You also learned about commonly used Linux commands such as ifconfig, halt, reboot, and whoami.

  • You learned about the default Linux file system structure and the files that are housed in directories such as /usr, /bin/, and /etc.

  • You also learned about commonly used Linux command-line utilities such as grep, tail, cp, mv, mkdir, rm, and rmdir. We also discussed how to use the mount command in depth. You learned how to mount CDs and floppies. You also learned how to create symbolic link files with ln and how to edit your fstab file to make mounting easier.

  • We discussed how to manage Linux tarball files with the tar and gunzip utilities. You also learned how to edit text files with vi and with KWrite.

In the next chapter, we will go into depth on Linux users, groups, and permissions. We will also discuss how to manage Linux applications and processes. After that, you'll learn how to configure and manage Linux network interfaces.


Chapter 3. Linux Administration and Configuration

This chapter covers the following testing objectives for Novell Course 3015:Novell Nterprise Linux Services:

  1. Manage the Linux file system.

  2. Manage Linux network interfaces.

  3. Manage Linux applications.


Managing Linux Users and Groups

Test Objective Covered:

1. Manage the Linux file system.

In the previous chapter, you were introduced to the Linux file system. In this chapter, we will explore that file system in more depth and specifically focus on how Linux keeps information in the file system secure.

Linux File System Security

Recall from earlier discussions that Linux is a multiuser operating system. When you installed your SUSE Linux server, you created two users: root and student. You could also create many other users. Depending on how the system is utilized, you could even have dozens or even hundreds of users.

This is a very powerful aspect of Linux, but it also presents some problems. Suppose you have four users on your system—root, Kimberly, Josh, and Jessica—and each user had full access to all the files on the system. Kimberly uses the Linux system to edit digital video, which involves using very large files. Josh uses the system to prepare reports and spreadsheets—very small files in comparison to Kimberly's.

When Josh logs in, he notices that the system is low on disk space and decides to clean off some files. Of course, he doesn't want to delete any of his own files, so he probes through the file system looking for entries owned by other users and notices that that some of Kimberly's files are over 12GB in size. Josh feels that these files are obviously wasting space and decides to delete them.

Josh also probes into the /usr/bin directory and decides to delete some of the files found there as well. Who needs files with funny names such as "grep" and "dig" anyway?

Imagine how Kimberly feels when she logs back in, only to find her video files gone. Imagine how root feels when it is discovered that some administration files are missing. This is definitely not good.

Real World

WINDOWS AND MULTIPLE USERS

If you use an older version of Microsoft Windows, such as Windows 95 or 98, this is exactly the situation you could encounter. These operating systems allow you to create individual user accounts. Each user, however, has full access to every file in the file system, including the operating system files. This presents a challenge for many system administrators.

To reduce expenses, many companies with multiple employee shifts assign users in different shifts to use the same workstation. All too often, the day-shift employee arrives to find that the swing- or night-shift employee had deleted his or her files.

Later versions of Windows, such as Windows 2000 and XP, rectified this problem by allowing the administrator to create user accounts that don't have access to system files and that can't access other users' files.

To prevent this situation, Linux implements a file system security system that uses the following components:

  • Users

  • Groups

  • Permissions

  • Ownership

Each of these components are explored in the following sections.

Linux Users

As with other multiuser operating systems, Linux uses user accounts. During the installation of a Linux system, one user account is always created by default: root.

The root user account has full access to the entire system. Anyone logged in as root can open, modify, copy, or delete any file in the file system. This user account has a great deal of power and must always be used with discretion.

As mentioned earlier in this book, you should never log in as root to perform routine, day-to-day work. This rule prevents two problems. First, it eliminates the possibility of someone using your root account to wreak havoc on your system while you're away from your desk. Second, it keeps you from accidentally wreaking havoc on your own system. I'll explain why later in this chapter.

For these reasons, you should always log in as a regular system user to conduct your normal tasks on the system. When you need root-level access, use the su - command at the shell prompt to switch to the root account. When you're done, be sure to switch back to your regular account with the exit command at the shell prompt.

Most Linux installation routines provide you with the ability to create one or more regular user accounts during installation.

Tip

Some Linux distributions will require that you create at least one regular user account during installation.

After installation, you can use YaST2 on a SUSE system to create new user accounts. If you're working from within GNOME or KDE, just select Applications, SUSE Menu, System, YaST2.

When you do, the YaST Control Center appears. Select Security and Users and then select Edit and Create Users. The User and group administration screen appears, as shown in Figure 3.1.

Figure 3.1. Creating new users in YaST.

Tip

If you are working within a nongraphical session, you can enter yast2 at the shell prompt.

To create a new user, select Add. To modify an existing user, select Edit. To delete an existing user, select Delete.

In a Linux system, user account information is saved in the passwd file located in /etc. A typical passwd file is shown in Figure 3.2.

Figure 3.2. User accounts in the passwd file.

Notice that the passwd file is composed of lines of information. Each line represents a single user account record. Seven individual pieces of information appear on each line (or record). These are called fields and are delimited by a colon (:) character. The fields, in order, are as follows:

  • User name— This is the name the user enters to log in to the system.

  • Password— Notice that each account appears to have a password of "x"." That's because the passwd file doesn't actually contain the user's passwords. This will be explained in more detail later.

  • User ID— This is a number assigned by the system to each user account. Each User ID is unique on the system. No two users can have the same ID.

  • Group ID— This is the ID number of the group the user is a member of. Multiple users can be members of the same group and, hence, have the identical Group ID numbers.

  • Full name— This is the user's full name. This parameter is optional.

  • Home directory— This is the path to the user's home directory in the file system.

  • Shell— This is the default type of shell that will be presented to the user.

If you look closely at Figure 3.2, you'll notice that each user account appears to be assigned a password of x. That's because user passwords aren't actually stored in the passwd file.

To prevent this, user passwords are stored in encrypted format in the shadow file located in the /etc directory. A typical shadow file is shown in Figure 3.3.

Figure 3.3. User passwords in the shadow file.

Warning

It is possible to install your Linux system such that passwords are stored in the passwd file. Depending on the Linux distribution you are using, you should be presented with a screen during installation that asks if you want to shadow your passwords (or text to that effect). You should always use shadow passwords. If you don't, they'll appear in the passwd file.

Notice in Figure 3.3 that, like the passwd file, each line in the shadow file represents a user record. Each user record has nine fields delimited by colons:

  • User name— This is the same name as is used in the passwd file.

  • Password— This field contains the user's encrypted password.

  • Last change— This field lists the date when the password was last changed.

  • Minimum days— This field lists the minimum number of days the user can have the same password.

  • Maximum days— This field lists the maximum number of days the user can have the same password.

  • Warning— You can configure the system such that users are prompted a couple days before their password expires. This field lists the number of days prior to expiration that the warning is displayed.

  • Allow inactive— You can configure the system such that users can still log in for a couple days after their password has expired. This field contains the number of days this is allowed.

  • Expires— This field lists the date that the user's password will expire.

  • (Unused field)

To change these values on a SUSE system, you can use YaST. Access the Edit and Create Users option and select the user you want to modify. Then select Edit, Password settings. The screen shown in Figure 3.4 appears.

Figure 3.4. Modifying user password settings.

Look closely at the record for the root user account. Notice that the password appears to be a complex string of characters. This is actually the password in encrypted form. The root password on this system is actually novell. Because of this, you shouldn't directly edit the shadow file with a text editor. You should use a system utility such as YaST to change a user's password.

Linux Groups

Not only does Linux differentiate accounts by user, but it also uses groups. A group is simply a collection of user accounts. At first glance, groups and users may seem somewhat redundant. Groups are very powerful management entities, especially when you're working with a large number of user accounts.

To illustrate, imagine that you have 40 user accounts on a Linux system. All these users need the same permissions to a given set of directories in the file system. Without groups, you would have to manually assign permissions to each user.

Tip

Permissions will be introduced later in this chapter.

With groups, however, you can make all 40 user accounts members of a single group. Then you can assign permissions just once to the group. Each of the members of the group automatically receive the permissions that have been assigned to the group.

As a general rule, you should create groups and assign permissions to them first and add users to those groups. After that, assign individual permissions to specific users who require access differing from that required by other members of the group. The goal is to minimize the number of permissions assigned directly to individual user accounts.

For example, suppose you have 40 users who all need the same level of system access. You can create a group for these users, assign permissions to the group, and make the 40 users members of the group. Further, suppose that one of the 40 users needs additional access beyond that provided by the group. You can then assign additional permissions to that individual user.

Managing your system in this manner can greatly decrease your administrative workload. Suppose you have the 40-user system mentioned previously and you install a new application on the system. Each user needs access to the files for that application. If you use groups to manage access, you simply need to make one permission change. If, on the other hand, you chose to assign permissions to each individual user instead of using groups, you need to make 35 changes.

On a 40-user system, that may not sound overwhelming. Instead of 40, however, suppose you administer a Linux system that has several hundred users. The difference in work required to manage permissions becomes much more apparent.

When working with groups, you should keep in mind a couple important points. First, only two users can change groups assigned to a file or a directory and the associated permissions: root and the file/directory owner.

Second, you can't have a user account that isn't assigned to a group. Each and every user must be a member of at least one group. On a SUSE Linux system, every user is made a member of the users group, by default, when the user account is created.

In Figure 3.5, user rtracy has just been created. You can see that rtracy was made a member of the users group along with the student account we created during the installation of the system.

Figure 3.5. New users automatically added to the users group.

It's important to note that users can be members of more than one group. Users can switch to a different group (and receive the permissions of the new group) by entering newgrp new_group_name at the shell prompt. When they do, they'll be prompted to supply the new group's password, discussed next.

Group information is stored in the group file located in the /etc directory. This file is shown in Figure 3.6.

Figure 3.6. Groups in the group file.

Just like the passwd and shadow files, each line in the group file represents a record for an individual group. The fields within the record are delimited by colons. The fields in the group file include the following:

  • Group name— This field contains the name of the group.

  • Password— You can, optionally, require that members of this group supply a password when switching to the new group.

  • Group ID (GID)— The GID is a unique number assigned to the group.

  • Group members— This field lists users who are assigned as members of the group.

You probably noticed that, like in the passwd file, an x represents passwords in the group file. If you configured your system to use shadow passwords during installation (and you should), group passwords are saved in the gshadow file in the /etc directory. A typical gshadow file is shown in Figure 3.7.

Figure 3.7. Group passwords in the gshadow file.

In Figure 3.7, a sample group named test was created and assigned a password of novell. You'll notice, however, that the text of the password in the file appears to be random characters.

Just as with the shadow file, passwords in the gshadow file are encrypted. Because of this, you shouldn't try to use a text editor to edit the gshadow file to change or add a group password.

If you need to manage the groups on your SUSE Linux system, you can use the YaST utility. Select Applications, SUSE Menu, System, YaST2.

When you do, the YaST Control Center appears. Select Security and Users, Groups Administration, Edit and Create Groups. The screen shown in Figure 3.8 appears.

Figure 3.8. Managing groups in YaST.

If you want to add a new group, select Add. If you need to modify an existing group, select the group and then select Edit. If you need to delete a group, select it and then select Delete.


Managing File Ownership and Permissions

Test Objective Covered:

1. Manage the Linux file system.

To this point, we have discussed two elements of the Linux security system: users and groups. Now you'll be introduced to two more elements: file ownership and file permissions.

File Ownership

In a Linux system, every file and directory has an owner. By default, the user who initially creates a file or directory is automatically assigned as its owner.

To see who owns a particular file or directory, you can browse to and right-click it in the GNOME file management utility. Then select Properties, Permissions. The screen shown in Figure 3.9 appears.

Figure 3.9. Viewing ownership.

In this figure, you can see that the owner of Documents is the rtracy user. The owner of a file or directory can be changed, but only the root user has the ability to do this.

This can be done in the GNOME file management interface shown in Figure 3.9 or from the shell prompt using the chown command.

Tip

To learn how to use chown, enter man chown at the shell prompt.

File Permissions

I've already alluded to the concept of permissions earlier in this chapter. Simply speaking, permissions determine the level of access a user or group has to a file or directory. Linux uses three different basic permissions:

  • Read

  • Write

  • Execute

You need to remember that these permissions can be assigned to a directory or file. The functionality provided by a particular permission varies depending on whether it is assigned to an individual file or to a directory.

The Read permission allows a user to see a file in the file system, open it, and view its contents. For a directory, it allows the user to see the directory in the file system, open it, and view the files or subdirectories it contains.

The Write permission allows the user to modify the contents of a file and save the changes. For a directory, it allows the user to create, delete, or modify a file or subdirectory within the directory.

The Execute permission allows a user to run a file. This is particularly useful when creating script files, which you will do in this chapter's lab exercises.

Permissions to a file or directory are assigned to three different entities:

  • To the file or directory owner

  • To the group assigned to the file or directory

  • To other users

The permissions assigned to the file or directory owner define the level of access the file owner has. The permissions assigned to the group define the level of access granted to users who are members of the group assigned to the file or directory.

Permissions assigned to Others define the level of access granted to users who have successfully authenticated to the system, but who are not the owner of the file or directory and are not members of the group assigned to the file or directory.

You'll see these three permissions referred to simply as Owner, Group, and Other.

Consider the permissions assigned to the example.txt file in Figure 3.10.

Figure 3.10. Permissions.

The user rtracy created this file and, therefore, is its owner. Notice that Owner is assigned Read and Write permissions to the file. Because of this, user rtracy can open this file, read its contents, modify its contents, and save the changes. The rtracy user can also delete this file.

Notice that the users group has been assigned to the file. This assignment was made because the file owner, rtracy, is a member of the users group. Users who are members of the users group are granted the Read permission to the file. That allows them to open the file and read its contents. However, they can't save any changes to the file. They also aren't allowed to delete the file.

Notice that Others has also been assigned the Read permission. That means any user who logs in to the system but is not a member of the users group also can open the file and read its contents. Likewise, the user is not allowed to save any modifications to the file, nor can he or she delete it.

Let's examine Figure 3.10 a little more closely. Notice underneath the permission assignments the two lines Text view and Number view.

In our graphical computing world, we're a little spoiled with easy-to-read dialogs such as that shown in Figure 3.10. Prior to the X Windows System and GNOME, Linux administrators still had to manage permissions. They did it (and you still can) with Linux command-line utilities. Key among these is the chmod utility.

Every file or directory in the Linux file system has a number assigned to it that represents its permissions.

The chmod utility doesn't accept arguments such as "Read"," "Write"," or "Execute"." Instead, it expects to receive permission assignments in numeric form. In Figure 3.10, you'll notice that the permission assignments made to example.txt are shown as 644. The number 644 is a summary of all permission assignments made.

If you're new to Linux, this may be a little confusing. How does 644 equate to Read and Write to Owner, Read to Group, and Read to Others?

Each digit represents the permissions assigned to each entity. The first digit represents the permissions assigned to the file or directory's owner. The second digit represents the permissions assigned to Group. The last digit represents the permissions assigned to Others. This relationship is shown in Figure 3.11.

Figure 3.11. Permissions in numeric form.

Now that we've identified what the individual digits represent, we need to discuss what the value of each digit represents. You need to understand that each digit is the sum of three values for each permission assigned:

  • Read permission: 4

  • Write permission: 2

  • Execute permission: 1

  • No permissions assigned: 0

Real World

If you've ever used jumpers on the back of a SCSI device to configure its SCSI ID number, this will be familiar to you. With a SCSI device, such as a CD-ROM drive, the ID is the sum of the values assigned to three or four jumpers on the device. Jumper 1 is assigned the value 1, jumper 2 is assigned the value 2, and jumper 3 is assigned the value 4. If you put a shunt on jumpers 2 and 3, the SCSI ID is set to 6. If you put a shunt only on jumper 1, the SCSI ID is set to 1. If you don't put shunts on any jumpers, the SCSI ID is set to 0. Representing permissions in Linux numerically works in the same way.

If a permission is assigned, its value is added to the value of the respective digit. If it isn't assigned, a null value (0) is added to the value of the digit.

This can be a hard concept to understand for many Linux users. Let's look at a few examples.

Notice in Figure 3.11 that Owner has been assigned Read and Write permissions. Execute has not been assigned. The first digit in 644 represents Owner's permissions. The first digit is the sum of the values for the Read and Write permissions:

 | Read: | 4
+ | Write: | 2
+ | Execute: | 0
 |  | _____
= | Permission | 6

Also, notice that Group has been assigned only the Read permission. Therefore, the value of the second digit is

 | Read: | 4
+ | Write: | 0
+ | Execute: | 0
 |  | _____
= | Permission | 4

The same applies to the value of the Others digit:

 | Read: | 4
+ | Write: | 0
+ | Execute: | 0
 |  | _____
= | Permission | 4

The result is the permission 644. Let's work through another example. Suppose a file has a permission of 750. What permission has been assigned to each entity?

Let's look at the first permission, 7. The only way to get the value 7 is to assign all permissions, as shown here:

 | Read: | 4
+ | Write: | 2
+ | Execute: | 1
 |  | _____
= | Permission | 7

We know that the file owner has been granted all permissions to the file in question. The second digit has the value 5. The only way to arrive at 5 is to assign Read and Execute permissions, as shown here:

 | Read: | 4
+ | Write: | 0
+ | Execute: | 1
 |  | ______
= | Permission | 5

Any user who is a member of the group assigned to the file has Read and Execute permissions to the file. The last digit has the value 0. The only way to arrive at this value is to assign no permissions:

 | Read: | 0
+ | Write: | 0
+ | Execute: | 0
 |  | ______
= | Permission | 0

Any authenticated user who is not the file owner and who is not a member of the group assigned to the file has no rights at all to the file.

If you were to use the chmod command, you could assign permissions to a file or directory using this numeric permission representation.

For example, if you wanted to assign the owner of example.txt full permissions to the file, but deny everyone else any permissions, you would change to the directory where the file resides and enter chmod 700 ./example.txt.

Earlier, I mentioned that there were two extra lines shown in Figure 3.10. We've examined the Number view line. We now need to turn our attention to the Text view line.

If you're working in a text-based Linux environment, you won't have a fancy tool such as the GNOME file manager to view file and directory permissions. Instead, you can use the ls or dir command.

Real World

Many organizations don't use the X Windows system on their Linux servers. Using a graphical user interface (GUI) on any operating system requires taking time from the CPU. The graphical screen must be periodically refreshed (redrawn). Each time this happens, the CPU's attention is diverted from its current work to service the GUI's requests.

If you enter ls, the contents of the current directory are displayed, as shown in Figure 3.12.

Figure 3.12. Output from ls.

However, if you use the dir command or the ls -1 command, you will be presented with the current directory contents and the permissions assigned to them, as shown in Figure 3.13.

Figure 3.13. Output from the ls -l command.

The first column displays the permissions assigned to the particular file or directory. The second column lists the file or directory owner. The third column displays the group assigned to the file or directory.

For example, locate the Documents directory in Figure 3.13. Notice that its permissions are drwxr-xr-x. The owner of Documents is the rtracy user. The group assigned to Documents is users.

Let's focus on the first column. The first character is either d or -. The first character simply identifies whether the item is a directory (d) or a file (-).

The second, third, and fourth characters list the permissions assigned to Owner, as shown in Figure 3.14.

Figure 3.14. Interpreting output from the ls -l command.

In this example, the owner of the public_html directory has Read (r), Write (w), and Execute (x) permissions.

The fifth, sixth, and seventh characters identify the permissions assigned to Group. In this example, Group is assigned the Read (r) and Execute (x) permissions. Permissions not assigned are identified by the - character.

Tip

If you want to change the group assigned to a file or directory, you can use the chgrp command. To learn how to use this command, enter man chgrp at your Linux shell prompt. You can also do this with the GNOME file management utility in the X Windows system interface.

Finally, the eighth, ninth, and tenth characters specify the rights assigned to Others. In Figure 3.14, Other has been assigned the Read (r) and Execute (x) permissions.


Lab Exercise 3.1: Managing Linux Security

In this exercise, you will work with Linux users, groups, ownership, and permissions. Complete the following steps:

  1. Boot your Linux server and authenticate as your student user with a password of novell.

  2. Open a terminal session.

  3. Change to the root user account by entering su - and providing a password of novell.

  4. Create a new text file by completing the following:

    1. At the shell prompt, enter cd/tmp.

    2. Create a new text file called example.txt by entering vim ./example.txt at the shell prompt.

    3. Press Ins.

    4. For the contents of the file, enter This is a text file.

    5. Press Esc and then enter :exit.

  5. Check the properties of example.txt by entering ls -l example.txt at the shell prompt.

Who owns the example.txt file? What group is it assigned to?

If you completed these steps correctly, root should be the owner of example.txt and the root group should be assigned to the file.

What permissions have been automatically assigned to example.txt?

Owner should be assigned Read and Write permissions. Group should be assigned the Read permission. Other should be assigned the Read permission.

Test the permissions by completing the following:

  1. At the shell prompt, enter exit.

  2. At the shell prompt, enter cd/tmp.

  3. Select Applications, KDE Menu, Editors, KWrite.

  4. Select File, Open.

  5. Browse to and select /tmp/example.txt and then click OK.

  6. Add a line after the first line that reads "This is the second line."

  7. Select File, Save.

Were you able to save the file? Why or why not?

You should see a warning indicating that you don't have the Write permission. Recall that you are now authenticated as the student user. This user isn't the file owner and isn't a member of the root group. That makes the permissions assigned to Other applicable. Other was assigned only Read permissions.

Continue with these steps:

  1. In the warning dialog, click OK.

  2. Select File > Quit.

  3. When prompted to save changes, select No.

Change the permissions assigned to example.txt by completing the following:

  1. In your terminal session, enter su - and supply a password of novell.

  2. Enter cd/tmp.

  3. Remove the Read permission from Others by entering chmod 640./example.txt at the shell prompt.

  4. Verify the permissions assigned to example.txt by entering ls -l example.txt. It should have -rw-r----- permissions assigned to it.

  5. Enter exit at the shell prompt.

Now try to access example.txt as the student user:

  1. Select Applications, KDE Menu, Editors, KWrite.

  2. Select File, Open.

  3. Browse to and select /tmp/example.txt and then click OK.

Can you see the contents of example.txt? Why or why not?

If you assigned permissions correctly, you should not be able to see the contents of the file. As the student user, you have no permissions to the file.

Create a restricted folder by completing the following steps:

  1. In your terminal session, enter su - and provide a password of novell.

  2. At the session prompt, enter cd/tmp.

  3. Create a directory named HideMe by entering mkdir HideMe at the session prompt.

  4. Make the HideMe directory restricted from anyone but root or the root group by entering chmod 640 ./HideMe.

  5. Enter exit.

Try to access the HideMe directory as the student user by completing the following steps:

  1. At the session prompt, enter cd/tmp.

  2. Generate a listing of the contents of /tmp by entering ls |more.

Do you see the HideMe directory displayed?

You should be able to view the directory.

Now try changing to the HideMe directory by entering cd/tmp/HideMe.

Were you able to change to the HideMe directory? Why or why not?

You should receive a message indicating that you don't have the appropriate permissions to access the directory.

Execute a script file by completing the following steps:

  1. Change back to the root user account by entering su - and entering a password of novell.

  2. Change to the /tmp directory by entering cd/tmp.

  3. At the shell prompt, enter ls scriptfile.txt.

  4. You should see the scriptfile.txt file you created in the previous chapter. This file contains a series of commands that can be executed from within the file. If you skipped that exercise, go back now and create the text file according to the lab instructions.

  5. Verify that scriptfile.txt contains the correct commands by entering cat ./scriptfile.txt. You should see the commands you entered in the previous exercise.

  6. Try to execute the file by entering ./scriptfile.txt.

What happens? Why?

You should see a message indicating that permission to run the file is denied. This happens because the Execute permission has not been granted.

Continue by following these steps:

  1. Grant the Execute permission to all users by entering chmod 777./scriptfile.txt at the shell prompt.

  2. Execute the script by entering ./scriptfile.txt.

What happens this time?

The file should execute the commands.

To finish this lab exercise, enter exit at the shell prompt.

That's it for this lab exercise. You now know how to manage basic Linux file system privileges. You'll now learn how to manage your system's network configuration.


Managing the Linux Networking Configuration

Test Objective Covered:

2. Manage Linux network interfaces.

With Linux file system security behind us, we're ready to move on to a discussion of basic Linux network configuration tasks. To pass the CLE certification, Novell expects you to know what the term eth0 means and how to do some simple tasks, such as assigning an IP address or subnet mask.

Linux Network Interfaces

If you're coming into the Linux arena from the Windows world, you're probably used to managing Windows network interfaces using the Control Panel, as shown in Figure 3.15.

Figure 3.15. Managing network interfaces in Windows XP.

Notice that each interface is assigned a name, such as Local Area Connection 1, Local Area Connection 2, and so on.

Managing Linux network interfaces is a little bit different. Linux Ethernet interfaces are labeled eth0, eth1, eth2, and so on. Each network board installed in the system is assigned one of these labels.

Most modern PC systems use the Peripheral Component Interconnect (PCI) expansion bus to implement modular expansion boards. PCI slots are assigned a number beginning with 1, as shown in Figure 3.16.

Figure 3.16. PCI slots.

By default, if you have only one network board in the system, it is assigned to eth0. If you have more than one network interface in the system, the board installed in the lowest numbered PCI slot is assigned to eth0. The board installed in the next lowest-numbered PCI slot is assigned to eth1, and so on.

This seems simple on the surface. It gets tricky, however, when your motherboard uses an integrated network board.

Tip

An integrated network board is one that is built into the motherboard hardware itself. There is no network board installed in an expansion slot. The motherboard provides an RJ-45 jack to plug in an Ethernet cable.

If you are using only one network interface and it is the integrated interface, it will be automatically assigned to eth0. If you use the integrated interface and a network board installed in an expansion slot, however, either one could be assigned to eth0.

Some motherboard manufacturers build their boards such that an integrated device, such as a network board, will be assigned a lower slot number than one installed in a PCI expansion slot. I've encountered many systems where the built-in network adapter was assigned a very high number, whereas the first PCI expansion slot was assigned the number 1.

If you encounter this situation, you can manually swap eth0 and eth1 between interfaces. I've found it much easier (and faster), however, to simply swap the cables plugged into the RJ-45 jacks on the two interfaces.

Real World

ABOUT NETWORK BOARDS

Not too long ago, administering a network server required that you be familiar with a number of different varieties of network boards in a variety of expansion bus types. In the mid-1990s, some of the more popular network standards included Ethernet, Token Ring, and Arcnet. You also had to know how to configure network boards in 8- and 16-bit ISA, 16- and 32-bit MCA, EISA, and VLB expansion busses.

Today, the choices are much less confusing. Nearly all network boards are 32-bit PCI boards. On a high-end server system, you may encounter a 64-bit PCI board. Nearly all the systems you use will probably use one of these two types of boards.

Occasionally, you may run into a Communications Networking Riser (CNR) network board. These are tiny little network boards. They are rarely implemented in server systems.

The good news is that most of the systems you work with will probably only have a single network interface. Most of the administration tasks you will need to perform will be with eth0.

There's also one other interface to be aware of that is present in all Linux systems, even those that don't have a network board installed: lo. The lo interface is the localhost loopback interface. It is usually assigned an IP address of 127.0.0.1.

This interface always points back to the host system. Many Linux applications and services require lo to be present to function.

Managing Linux Network Interfaces with ifconfig

When you install your Linux system, you are given the opportunity to configure various parameters for your network interfaces, such as IP address, subnet mask, and default gateway. At some point, you will probably need to modify this configuration.

This can be done with the ifconfig command. ifconfig is a very powerful command. It can be used to assign IP addresses, modify subnet masks, and perform many other tasks.

It can also be used to view the current networking configuration. If you enter ifconfig at a shell prompt on a Linux system, it displays detailed information about each network interface installed in the system. This output is displayed in Figure 3.17.

Figure 3.17. Output from the ifconfig command.

Tip

The ifconfig command can only be run by the root user.

Notice in Figure 3.17 that this particular SUSE Linux system has two interfaces installed: eth0 and lo. The eth0 interface is an Ethernet interface with the parameters listed in Table 3.1.

Table 3.1. Network Parameters

PARAMETER

VALUE

Board MAC Address

00:0C:29:E0:02:D5

IP Address

192.168.1.26

Subnet Mask

255.255.255.0

Ethernet Collisions Detected

0

Board Interrupt

10

Board I/O Address

0x10e0

The ifconfig utility can also be used to configure a Linux network interface. The general syntax is as follows:

ifconfig Linux_interface parameter

For example, if you wanted to see only the current settings for the eth0 interface, you could enter ifconfig eth0. Some of the more useful parameters (and the ones you need to know for the CLE certification) include the ones shown in Table 3.2.

Table 3.2. ifconfig Parameters

PARAMETER

FUNCTION

EXAMPLE

ip_address

Assigns an IP address to the specified interface. (You don't need to include the text "ip_address" in the command, as shown in the example to the right.)

ifconfig eth0 10.0.1.30

netmask mask

Assigns a subnet mask to the specified interface.

ifconfig eth0 netmask 255.0.0.0

down

Disables the specified interface.

ifconfig eth1 down

up

Enables the specified interface (if it was previously disabled).

ifconfig eth1 up

Configuring Linux Network Interfaces in YaST

If using the command line gives you a case of the hives, never fear. You can also configure your Linux network interfaces in a graphical X Windows system environment using YaST.

To run YaST, select Applications, SUSE Menu, System, YaST2 from within GNOME. You can also run the program by opening a terminal session, changing to the root user using the su - command, and then entering yast2 at the shell prompt.

Warning

If you aren't authenticated as root, you will be asked to provide the root user's password before YaST will start.

If you run YaST from within GNOME, the screen shown in Figure 3.18 appears.

Figure 3.18. The YaST Control Center.

From within YaST, select Network/Basic and then select Network Card Configuration. The screen shown in Figure 3.19 is displayed.

Figure 3.19. The YaST Network cards configuration screen.

If you've just installed a new network board in the system, the unconfigured device will be displayed in the Network cards to configure field under Available are. To configure it, select Configure, and you will be presented with a series of screens that guide you through the process of assigning an IP address, subnet mask, default gateway address, and DNS server address to the interface.

If you need to modify the parameters assigned to an existing interface, select Change under the Already configured devices field. When you do, the screen shown in Figure 3.20 is displayed.

Figure 3.20. Modifying an existing interface in YaST.

Notice that each of your interfaces is listed. The system shown in Figure 3.20 has only one network board, so only eth0 is listed.

Identify the interface you want to modify and select it. Then select Edit. When you do, the screen shown in Figure 3.21 appears.

Figure 3.21. Modifying the network address in YaST.

If you want your system to be assigned an IP address dynamically from a DHCP server, mark Automatic address setup (via DHCP).

Warning

If you intend to install Novell Nterprise Linux Services on your Linux server, you should not use a dynamic IP address. Many of the NNLS components require that you use a static IP address assignment.

If you intend to use a static IP address assignment, mark Static address setup. Then enter an IP address and subnet mask in the respective fields.

At this point, you must decide if you need to configure a DNS server address and a default router. If you are using a static IP address assignment, you should configure these parameters.

Sometimes, the default router is also referred to as the default gateway, gateway router, or just router.

If you are using a dynamic address assignment obtained from a DHCP server, you may or may not need to configure these addresses. Check to see if your DHCP server is configured with the appropriate DHCP options to deliver these parameters automatically. If so, you don't need to configure these parameters.

However, sometimes a given DHCP server isn't configured to deliver these addresses. If your DHCP server is in this category, you will need to manually configure these parameters.

Tip

Most network administrators will configure their DHCP servers to deliver the DNS server and default router addresses automatically. It doesn't make much sense to deliver an IP address without these other two critical parameters.

To configure the host name of the system and the DNS server address, click Host name and name server. When you do, the screen shown in Figure 3.22 appears.

Figure 3.22. Modifying the DNS server address in YaST.

In the Host Name field, enter the host name for your Linux system. In the Domain Name field, enter your organization's domain.

In the Name server fields, enter the IP addresses of your organization's primary, secondary (optional), and tertiary (optional) DNS servers; then click Next.

To configure the default router instead, click Routing. When you do, the screen shown in Figure 3.23 appears.

Figure 3.23. Modifying the default gateway address in YaST.

In the Default gateway field, enter the default gateway IP address for your network and then click Next.

Note

You'll notice that there are several other parameters in this screen. A full discussion of these is beyond the scope of this book. For more information, see the Linux Network Administrator's Guide at http://www.tldp.org/LDP/nag2/index.html.

When you're satisfied with the configuration settings you've configured for the network interface, click Next and then click Finish. At this point, the interface will be disabled and the changes you configured applied. As this happens, the screen shown in Figure 3.24 is displayed.

Figure 3.24. Implementing configuration changes in YaST.

When the changes have been applied, the interface will be brought back up. A nice feature of Linux is the fact that you don't need to reboot the system after making these types of changes. If you've ever used an older version of Windows, you know that these operating systems require a full reboot for even a minor change to the networking configuration.

Note

Later versions of Windows, such as Windows 2000 and XP, don't require you to reboot the system after making changes to the networking configuration.

You can now close the YaST Control Center by selecting Close.


Managing Linux Applications and Services

Test Objective Covered:

3. Manage Linux applications.

As we discussed in Chapter 2, "Introduction to SUSE Linux," one of the key functions of an operating system is to provide a platform where applications and services can run. To effectively manage a Linux system, you need to know how to install and uninstall packages, start and stop services, and manage running processes.

Installing Linux Packages

You're probably already familiar with installing an application on a Windows system. Typically, you insert an installation CD in the system's CD drive. An AUTORUN.INF file automatically starts the installation program, usually named SETUP.EXE.

Installing an application on a Linux system is a little bit different. There are three different ways applications are typically distributed and installed on SUSE Linux:

  • By extracting files from a tarball archive and running an installation script

  • By using the rpm command

  • By using the YaST Control Center

Many applications are installed using tarball distribution files. As we discussed in the previous chapter, Linux uses the tar and gzip utilities to combine multiple files into a single tape archive file (the tar file) and then compress them into a gzip file (the tarball file). Six sample tarball files are shown in Figure 3.25.

Figure 3.25. Typical tarball files.

Using the tar -zxvf command, you can extract these archives into their component files. At this point, the distribution should contain an install script that you can run to install the application.

In Figure 3.26, the vmware-linux-tools.tar.gz tarball from Figure 3.25 has been extracted to the vmware-tools-distrib directory. Within this directory is a file named vmware-install.pl. Running this file will install the vmware-tools application.

Figure 3.26. A tarball install script.

Linux applications are also frequently distributed as Red Hat Package Manager (RPM) files. These files require that you use the rpm utility, included in many Linux distributions.

Note

Not all Linux distributions include the rpm utility. Distributions based on Debian Linux use the Debian Package Manager instead. Red Hat and SUSE use rpm.

The advantage of using RPM packages instead of tarballs is the fact that many applications are dependent on other applications or services being installed on the system. The rpm utility can query the RPM package to be installed to identify its dependencies. It can then check the host system and make sure these dependencies have been installed prior to installing the new package.

If they aren't installed, rpm will warn you of the missing dependencies, giving you the opportunity to install them before proceeding. This can save you a great deal of trouble. Many years ago when I was first learning Linux, I installed an application from a tarball file. The readme file that accompanied the application didn't list any dependencies. However, when I tried to run it for the first time, it reported a missing application it was dependent on and halted execution.

I downloaded and installed the missing application and tried to run the application a second time. It again reported another missing dependency and exited. I installed this application. Guess what happened when I tried to run the application for the third time? It did it again. There was yet another dependency missing. After a great deal of work, I finally got the application running.

You won't experience this type of problem with RPM packages. All missing dependencies will be reported right up front so you can take care of them all at once.

To install an RPM package, do the following:

  1. Open a terminal session and change to the root user account using the su - command.

  2. Navigate to the directory where the RPM package is stored.

  3. At the session prompt, enter

 rpm -i package_filename

In this mode, the application will be installed with no progress indicator on the screen. If you would like to see a progress indicator as the package is installed, use rpm with the -ihv switch.

Another advantage of RPM packages is the fact that they are quite easy to uninstall. To do this, enter rpm -e package_name. Notice that installing requires that you use the package filename, whereas uninstalling requires that you use the package name. For example, if I were installing an NTP package on my system, I would use the package file name, ntp-4.1.1-1.i386.rpm, with the rpm utility.

However, if I were to uninstall this package at a later date, I would use the package name, ntp, with the rpm utility.

You can also use the YaST Control Center to install RPM packages. The left column holds the Software option, as shown in Figure 3.27.

Figure 3.27. The Software option in the YaST Control Center.

To install a package in YaST, complete the following steps:

  1. Double-click Install or remove software. The screen shown in Figure 3.28 appears.

    Figure 3.28. Selecting a package to install.

  2. Select the package you want to install.

  3. Click Accept.

If you want to install a package other than the one that came with your SUSE distribution, you will need to use the Change source of installation option under Software in the YaST Control Center (shown in Figure 3.27) to point to the directory where the RPM package is stored.

Managing Linux Services

A key skill you will need when managing a Linux system (and when taking your CLE exam) is starting and stopping Linux services. Before covering this topic, we need to discuss the difference between a service and an application. The distinction is rather thin between these two concepts. Generally speaking, an application is a program that the end user interacts with in some way. The Mozilla web browser, for example, is an application. The YaST Control Center is also an application.

A Linux service, on the other hand, is a program that runs continuously in the background. Users generally don't see an interface, nor do they generally interact with the program. For example, the Apache web server is a Linux service. The Network Time Protocol (NTP) is also a service. Linux services are usually referred to as daemons.

Services are usually installed in the same way as regular applications. They may be distributed as tarballs or as rpm files.

With that said, you need to know how to start and stop services on your Linux system.

In the /etc/init.d directory on your SUSE server, you will find scripts that are used to start and stop services, as shown in Figure 3.29.

Figure 3.29. Script files in the init.d directory.

Tip

On a Red Hat Linux system, these scripts are found in /etc/rc.d/init.d.

To start a service on your SUSE Linux system, open a terminal session, change to the root user account, and change to the /etc/init.d directory. Then enter ./service_name start at the shell prompt.

For example, if you wanted to start the Tomcat applet server on your system, you would enter ./tomcat start.

You can stop a service by entering ./service_name stop. For example, to stop the tomcat server, you would enter ./tomcat stop.

If you need to bring the service down and restart it, you can enter ./service_name restart.

Note

Not all Linux distributions and not all services support the restart option.

You can also perform these same tasks without first changing to the /etc/init.d directory. On a SUSE Linux system, you can prepend rc before the service name. For example, if your current directory is /var and you need to stop the Tomcat service, you can enter rctomcat stop. The start and restart options work with this shortcut as well.

Tip

On a Red Hat Linux system, you can do the same thing by entering service service_name start|stop|restart. For example, to stop the Tomcat service on a Red Hat system without changing to /etc/rc.d/init.d, you would enter service tomcat stop.

As you administer your Linux system, you will discover that there are some services you want started every time the system boots. Others you will want to only start when you need them. Configuring the default state for services is done with the chkconfig command. This command specifies at which runlevels a given Linux service will be automatically started.

A runlevel is a Linux mode of operation. There are six Linux runlevels:

  • 0—System shutdown.

  • 1—System started with only a single user allowed and networking enabled.

  • 2—System started with multiple users enabled and most services disabled.

  • 3—System started, multiple users enabled, and most services enabled except for the X Window System. If you boot your system to a non-graphical shell prompt, you are in runlevel 3.

  • 4—Unassigned. This runlevel can be custom-configured by the system administrator.

  • 5—System started, multiple users enabled, and most services enabled, including the X Window System. If your system boots to a graphical login, you are in runlevel 5.

  • 6—System restart.

Using chkconfig utility, you configure the default state for a service at a specific runlevel. The syntax for this utility is chkconfig service_name levels.

For example, to configure the Tomcat service to automatically start on run-levels 3 and 5, you would open a terminal session, change the root user, and enter chkconfig tomcat 35.

Tip

On a Red Hat system, the syntax for chkconfig is slightly different. To configure Tomcat to automatically start at runlevels 3 and 5 on this system, you would enter chkconfig -35 tomcat on.

You can also configure the default system runlevel and services that are automatically started by editing the /etc/inittab file.

Managing Linux Processes

When a Linux service or application is currently running, it is said to be a process. Each Linux process is assigned a unique process ID (PID). Most Linux distributions include a utility to let you view processes that are currently running. On a SUSE system, you can use the top utility. Simply open a terminal session and enter top at the shell prompt.

When you do, the screen shown in Figure 3.30 is displayed.

Figure 3.30. Running processes displayed in the top utility.

Notice in the top display that the running service or application is displayed in the COMMAND column. In the PID column, you can view the PID assigned to the process. You can also view assorted information about the process, such as how long it has been running, how much memory is it consuming, and how much CPU time is it consuming.

You can use the commands in Table 3.3 to format the way the information in top is displayed and to manage the running processes.

Table 3.3. Managing Processes in the top Utility

COMMAND

RESULT

c

Displays the full path in the COMMAND column.

P

Sorts the display by CPU usage.

M

Sorts the display by memory usage.

N

Sorts the display by PID.

T

Sorts by time running.

A

Sorts by age.

k

Kills a running task. (This is very useful if you encounter a process that is hung.)

q

Exits the top utility.

You can also kill a running process from the command line using the kill command. To use this utility, you need to know the PID of the process you want to kill. You also need to know the signal you want to send. To see a list of valid signals, enter kill -l. There are 63 different possible signals, but two of the most useful are #15 (TERM) and #9 (KILL). If you don't supply a signal number, TERM is used by default.

The syntax for the kill command is kill -s signal pid. If you're trying to stop a hung process, you should try using kill with the TERM signal first. If that doesn't work, you should next try the KILL signal.

For example, let's suppose I'm running xclock on my GNOME desktop and for some reason it has hung. The PID for xclock is 9541. To kill it using the TERM signal, I could enter kill 9541 or kill -s 15 9541.

You can also use the killall command to stop a hung process. This utility is a little more brutal than the kill command. It sends a signal to any process that is using the specified name.

As with the kill command, you can send a specific signal or just use the default of TERM. Instead of a PID, you need to supply killall with the name of the process you want to kill. To send a simple killall with the TERM signal, you would enter killall service_name at the shell prompt. For example, if the Tomcat service were to hang, you could enter killall tomcat at the shell prompt.


Lab Exercise 3.2: Installing Linux Products and Managing Processes

In this exercise, you will install the Mozilla web browser on your server. Then you will practice managing Linux processes. Complete the following steps:

Warning

This lab assumes you have Internet access from your Linux server.

  1. Boot your Linux server and authenticate as your student user with a password of novell. Change to your root user account entering sux - at a shell prompt.

  2. Your SUSE Linux distribution comes with an older version of Mozilla, which was installed when the system was installed. You need to use a newer version in order to access Novell's NNLS web-based management utilities. To do this, you need to complete these steps:

    1. Select Applications, Internet, WWW, Mozilla.

    2. In your Mozilla window, browse to http://www.mozilla.org.

    3. Download the latest version of Mozilla to /tmp. You must use version 1.5 or later.

    4. When the download is complete, close your browser window.

    5. Open a terminal session.

    6. Change to the root user account by entering su - and supplying a password of novell.

    7. Change to the /tmp directory by entering cd/tmp.

    8. At the shell prompt, enter ls. Notice that the file you downloaded from Mozilla.org is a tarball file. For example, if you downloaded Mozilla 1.6, you will see a file named mozilla-i686-pc-linux-gnu-1.6-installer.tar.gz.

    9. Extract the tarball by entering tar -zxvf ./mo; then press the Tab key. Notice that the rest of the filename is automatically completed for you. The tab-complete feature of Linux makes typing long filenames much easier.

    10. At the shell prompt, enter ls. You should now see a new directory named mozilla-installer where the files from the archive were extracted.

    11. Enter cd mozilla-installer.

    12. Start the installation script by entering ./mozilla-installer.

    13. At this point, you will be presented with a graphical installation wizard that varies depending on the version of Mozilla you've downloaded. Follow the prompts presented to complete a typical installation to the /usr/local/mozilla directory.

Create an icon on your Desktop for the new version of Mozilla by completing the following steps:

  1. Right-click anywhere on your Desktop.

  2. Select New Launcher.

  3. In the Name field, enter Mozilla.

  4. In the Generic Name field, enter Mozilla.

  5. In the Command field, enter /usr/local/mozilla/mozilla.

  6. Select the No Icon button.

  7. Select an icon of your choosing for the Mozilla browser icon.

  8. Click OK.

  9. Close any open browser windows; then test your new launcher by double-clicking the Mozilla icon on the Desktop.

  10. The Mozilla browser should be displayed as shown in Figure 3.31.

    Figure 3.31. Mozilla running on SUSE Linux.

Install the Pure-FTP service on your server by completing the following steps:

  1. Start YaST on your server by selecting Applications, SUSE Menu, System, YaST2.

  2. When prompted, supply your root user's password (novell).

    Note

    When you do this, you'll notice that YaST returns a password error but runs anyway. You can safely disregard the error message.

  3. Select Install or Remove Software.

  4. In the Filter drop-down list, select Package Groups.

  5. Select zzz All.

  6. In the top-right frame, scroll down to and select pure-ftpd.

  7. Click Accept.

  8. When prompted, insert UnitedLinux 1.0 CD #2 and then click OK.

  9. Wait while the package is installed.

  10. When the installation is complete, click Close.

Follow these steps to manage the pure-ftpd service on your server:

  1. Open a terminal session and change to your root user account by entering su - and supplying a password of novell.

  2. At the shell prompt, enter cd /etc/init.d.

  3. Enter ls. You should see a script for the pure-ftpd daemon, as shown in Figure 3.32.

    Figure 3.32. The pure-ftpd script.

  4. Check to see the runlevels pure-ftpd is configured to automatically start at by entering chkconfig -l pure-ftpd at the shell prompt.

  5. You should see that pure-ftpd is not configured to automatically start at any runlevel. Start the pure-ftpd service by entering ./pure-ftpd start.

  6. Configure pure-ftpd to automatically start at runlevels 3 and 5 by entering chkconfig pure-ftpd 35.

  7. Verify this change by entering chkconfig -l pure-ftpd.

Now you can practice managing Linux processes by completing the following steps:

  1. At your shell prompt, enter top.

  2. Sort the display by CPU usage by entering P.

Which process is using the most CPU cycles on your system?

  1. Open a new terminal session.

  2. Change to the root user with the su - command.

  3. Kill the top process by entering killall top. Notice that the top process in the first terminal session is terminated, as shown in Figure 3.33.

    Figure 3.33. Killing the top process.

    Previous Section < Day Day Up > Next Section


Implementing and Configuring NTP

Before ending this chapter, we need to discuss one more topic—time synchronization. Before implementing Novell Nterprise Linux Services, it is critical that you configure all the servers that will be installed into the same eDirectory tree to synchronize their internal clocks.

Why Time Must Be Synchronized

Many new eDirectory administrators fail to understand the absolute importance of time synchronization in their network. With many other network operating systems, having your server clocks in sync is nice, but not really necessary.

With eDirectory, however, it is absolutely critical. The reason for this is the nature of the eDirectory database itself. eDirectory is a distributed database. It can be configured to reside on a single server in your network (a very bad idea) or it can be configured to reside on multiple servers in the network.

eDirectory implements two concepts: partitioning and replication. Partitioning allows you to divide the database into logical chunks. This can be very useful if you have a large, geographically dispersed organization.

For example, suppose your organization has offices in Salt Lake City, Santaquin, and Idaho Falls. In your eDirectory tree, you may have containers for each location. You can create a partition for each container and for the root of the tree, as shown in Figure 3.34.

Figure 3.34. Partitioning the eDirectory tree.

By partitioning the tree, you have created three logical divisions in your eDirectory database. One of the key features of eDirectory is the fact that you can create multiple copies (called replicas) of each partition and store them on multiple servers in the tree.

In the example in Figure 3.34, the Salt Lake City server could hold replicas of the tree root partition, the SLC partition, the SAN partition, and the IDA partition. The other servers can also hold replicas of all the partitions.

Information in all the replicas is synchronized at regular intervals. eDirectory ensures that all the data in all the replicas remains consistent.

If a disaster were to happen and a server were to go down, the eDirectory tree would continue to function normally because the loss of the server would be detected and a replica stored on a different server would be promoted and used to replace the information lost.

This high degree of fault tolerance is one of the key value propositions behind eDirectory. However, this database design is highly dependent on each server being set to the same date and time.

eDirectory uses time stamps to keep track of operations. For example, in Figure 3.34, suppose an administrator in Santaquin changes a user's password. Then, an hour later, an administrator in Idaho Falls changes the same user's password again. If time is synchronized on all the servers, there is no problem. The sequence of events is preserved and implemented.

If time is not synchronized, however, continuity in the database can be lost. eDirectory may lose track of which operation occurred first and which occurred second.

Tip

If eDirectory detects operations in the database that have time stamps ahead of the current time, it tries to keep data consistent by issuing what is called synthetic time.

It is very important that you keep the system clocks on all your servers synchronized. In the "old days" when eDirectory (back then it was called NDS) ran only on NetWare, time synchronization was relatively easy. NetWare implemented the Timesync protocol, which automatically detected whether the server was the first server installed in the tree or if it was a later server.

If your server were the first server in the tree, it would be automatically configured as a Single Reference time provider. Subsequent servers were automatically configured as Secondary time consumers. The Secondary servers would query the Single Reference server and adjust their date and time to match it.

Today, you have to do a little more work to synchronize time when you are working with servers that use operating systems other than NetWare. eDirectory now runs on a variety of platforms. The Timesync protocol only runs on NetWare. To synchronize time between NetWare, Linux, and Windows servers, you have to use a time-synchronization protocol that can be run on all three.

In this book we will use the Network Time Protocol (NTP) to synchronize time. NTP is an Open Source product that can synchronize time on a variety of platforms. You can learn more about NTP at http://www.ntp.org.

Before configuring NTP, you need to plan your NTP deployment. You need to determine which servers will provide time and which servers consume time.

One of the very useful features of NTP is the fact that you can use it to synchronize time with time providers over the Internet. There are many publicly accessible NTP time providers on the Internet that get their time directly from the United States Navy atomic clock.

Tip

A list of NTP time servers you can use is available at http://www.eecis.udel.edu/~mills/ntp/servers.html.

A commonly used NTP time-synchronization strategy is depicted in Figure 3.35.

Figure 3.35. A commonly used NTP time-synchronization

In this configuration, one server in the organization is used to get its time from an NTP time provider on the Internet. This is the Organizational Time Provider. Other servers in the organization are then configured to get their time from the Organizational Time Provider.

Tip

The NTP service can be both a time provider and a time consumer at the same time. In Figure 3.35, the Organizational Time Provider fills both of these roles simultaneously.

There are, of course, many other ways to configure your NTP strategy. Some organizations configure all their servers to get their time directly from a public NTP time provider on the Internet. Others aren't concerned with synchronizing with a time provider on the Internet. Instead, they designate one server in the organization as an NTP time provider and configure their other servers to get their time from it.

Very large organizations may implement a hierarchy of time providers. This is possible because NTP uses the concept of strata. A detailed discussion of NTP is beyond the scope of this book. If you would like to learn more about NTP, check out the Time Precision HOWTO document available at http://www.tldp.org/HOWTO/TimePrecision-HOWTO/index.html.

For our purposes, we simply need to ensure that each server in our network that will be installed into the eDirectory tree is configured to synchronize time with the other servers.

On a Linux server, this is done with the xntpd daemon. When you installed your SUSE Linux server, the xntp package should have been installed by default, as shown in Figure 3.36.

Figure 3.36. Installing the xntp package.

If this package wasn't installed for some reason, you should install it using the steps we covered in the previous section in this chapter.

Warning

If you are going to use NTP to synchronize time among Linux servers, you can use version 4.x of the NTP daemon. However, this version is not compatible with the NTP service on a NetWare server. If you need to synchronize your Linux server with a NetWare server, you need to uninstall the 4.x version and then download and install version 3.x of the NTP daemon on your Linux server.

Once the package is installed, you need to configure the service and start it. The NTP daemon is configured using the ntp.conf file located in /etc, shown in Figure 3.37.

Figure 3.37. Configuring the xntpd daemon with the ntp.conf file.

Notice that the first entry in the file is a parameter that reads server 127.127.1.0. This parameter provides a fallback strategy. If the xntpd daemon can't contact the NTP time provider it has been configured to use, it will query the system BIOS clock to get its time. This parameter is added to your ntp.conf file by default.

To configure the xntpd daemon to get time from an NTP time provider, enter the following parameter in the ntp.conf file:

server time_provider_IP_address

For example, if you wanted your server to get its time from a time provider with an IP address of 10.0.0.1, you would enter server 10.0.0.1.

Once this is done, you should save the changes to your ntp.conf file and exit your text editor.

Now, before you start your xntpd daemon, there are a few steps you need to complete. The NTP protocol is a little bit fussy. If the time on your server is more than 17 minutes out of synchronization with the time on the NTP time provider, the NTP protocol considers the time source "insane" and will refuse to synchronize.

Therefore, you need to set your system time as closely as possible to the time provider's time before you start the xntpd daemon. This involves three steps:

  1. Configure your server's time zone by entering tzselect at a shell prompt. Follow the time zone wizard prompts to set your time zone, as shown in Figure 3.38.

    Figure 3.38. Setting your server's time zone.

  2. Manually set your server's system time using the date command. The date command expects you to provide the current date and time in the format mmddhhmmyyyy. For example, if the current date and time is August 30, 2004, 8:30 p.m., you would enter date 083020302004. Note that the hour is specified using the 24-hour clock.

  3. Perform a one-time synchronization with the NTP time provider by entering ntpdate time_provider_IP_address. For example, if your time provider's IP address is 10.0.0.1, you would enter ntpdate 10.0.0.1. You may have to run this command several times. As a general rule of thumb, you should rerun the command until the offset reported by this command is less than 1 second.

Note

If the xntpd daemon is running, you can't run the ntpdate command.

At this point, your server's clock should be in sync with your time provider's clock. However, if you leave it in this state, the time on your server will quickly drift away from the time on the time provider.

To keep this from happening, edit your ntp.conf file as discussed earlier and add a server entry for your time provider. Once this is done, start the xntpd service on your server by entering /etc/init.d/xntpd start at a shell prompt.

By default, the xntpd service is not configured to automatically start. You need to make sure the xntpd service is started every time the server is booted by entering chkconfig xntpd 35 at a shell prompt.

Once the xntpd daemon is running, you can use the ntpq command to see the time providers it is configured to use. Open a terminal session and enter ntpq -p.


Lab Exercise 3.3: Implementing NTP

In this exercise, you will configure and run the NTP daemon on your server. Complete the following steps:

Warning

This lab assumes you have Internet access from your Linux server.

  1. The NTP package should have been installed by default when you installed your system. Verify that this is the case by doing the following:

    1. Open a terminal session.

    2. Change to your root user account by entering su - and supplying a password of novell.

    3. At the shell prompt, enter ls /etc/xntpd. If the xntpd init script is there, then the package has been installed. If not, use the skills you gained in this chapter to install the xntpd daemon using YaST.

  2. Configure NTP to synchronize time with a publicly available NTP server on the Internet by completing the following:

    1. At the shell prompt, enter vi /etc/ntp.conf.

    2. Scroll down to the line that reads "server 127.127.1.0 # local clock.

    3. Add a new line beneath this line.

    4. Open a browser window and navigate to http://www.eecis.udel.edu/~mills/ntp/servers.html.

    5. Scroll to the bottom of the browser window and select the Public NTP Secondary (stratum 2) Time Servers link.

    6. From the list provided, identify the IP address of a time server that is located reasonably close to you.

    7. Switch back to your terminal session.

    8. On the new line you just created, enter server IP_address_of_time_server. For example, if you selected the time server at the University of Nevada, you would enter server 131.216.1.101.

    9. Comment out the local clock line and the fudge line by placing an asterisk (#) character at the beginning of each line.

    10. Press Esc and then enter :exit.

  3. Configure your server's time zone by entering tzselect at a shell prompt. Follow the Time Zone Wizard prompts to set your time zone.

  4. Manually set your server's system time by entering date mmddhhmmyyyy. For example, if the current date and time is August 30, 2004, 8:30 p.m., you would enter date 083020302004.

  5. Perform a one-time synchronization with the NTP time provider by entering ntpdate time_server_IP_address. For example, if you selected the NTP time server at the University of Nevada, you would enter ntpdate 131.216.1.101.

  6. Run this command several times until the offset reported by this command is less than 1 second.

  7. Start the xntpd daemon by entering /etc/init.d/xntpd start. You should see success messages displayed.

  8. Verify that the time is synchronized by entering ntpq -p. The offset parameter should be less than 1 second.

Congratulations! You now know how to synchronize time on your SLES 8 system using NTP.


Summary

That's it for this chapter. In this chapter we covered the last of our Linux overview topics. We discussed

  • How to manage Linux users and groups.

  • How to manage Linux permissions.

  • How to manage the Linux networking configuration.

  • How to manage Linux applications and services.

  • How to implement and configure the Network Time Protocol (NTP).

In the next chapter, you'll be introduced to NNLS and the various components that comprise the system. Then, in Chapter 5, "NNLS Installation and Administration," you will have the opportunity to actually install NNLS on your system!


Chapter 4. Introduction to Novell Nterprise Linux Services (NNLS)

This chapter covers the following testing objective for Novell Course 3015: Novell Nterprise Linux Services:

  1. Describe Novell Nterprise Linux Services (NNLS)


Introduction to NNLS

Test Objective Covered:

1. Describe Novell Nterprise Linux Services (NNLS).

In the preceding chapters, you spent some time learning the basic Linux tasks you will need to know in order to manage a Novell Nterprise Linux Services (NNLS) implementation on a Linux server. If you're already familiar with Linux, you've probably noticed that we barely scratched the surface in Chapter 2, "Introduction to SUSE Linux," and Chapter 3, "Linux Administration and Configuration." As stated earlier, the goal of these chapters (and the associated CLE objectives) is not to make you an overnight Linux expert.

Note

The proper name for NNLS is Novell Nterprise Linux Services. However, in this book we're going to use the abbreviation from here on out. Just remember that when you see NNLS, we're talking about the Novell Nterprise Linux Services product.

Instead, the experts at Novell analyzed the remaining Certified Linux Engineer (CLE) objectives, identified the Linux skills you will need to know to be successful when installing and managing NNLS, and grouped them together into the objectives covered in Chapters 2 and 3.

If you're comfortable with these skills, we're ready to move on with an introduction to the NNLS product. If not, you should spend some additional time learning the basics of Linux.

What Is NNLS?

Since the 1980s, Novell has been the leader in the network operating system (NOS) industry. In the early days, this leadership was established with the NetWare OS, which provided mainly file and print services on local area networks (LANs). Prior to this time, these types of services were provided mostly by expensive Unix systems.

Novell took the innovative approach of creating an NOS that ran on the x86 Intel CPU. This allowed businesses to provide file and print services using relatively inexpensive server hardware. In fact, you didn't even need to buy server hardware; you could grab any desktop system with a network board and install NetWare on it. NetWare was such an efficient operating system that you could get reasonable performance from off-the-shelf desktop systems. Even today, you may run into an organization, from time to time, that still has a NetWare server running on an old 80486 system.

There was, however, one glaring problem in the early days of NetWare. User accounts were local to each server. If your organization only implemented one server, this wasn't a problem. It was, however, a serious impediment for larger institutions that may have hundreds of servers. To use the services provided by a particular server, you had to have a user account on that server.

That doesn't sound too bad on a small scale, but imagine the administrative nightmare associated with a company that has thousands of users and hundreds of servers. In that world, you had to manage duplicate user accounts, passwords, and rights on multiple servers.

Believe me, it could become very cumbersome. The first network administration job I had back in the early 1990s involved this very situation. My organization had four LANs connected by routers; each was serviced by its own NetWare 3.1 server. That doesn't sound too bad, but I also had over a thousand users who needed access to each server. Maintaining consistent user accounts and passwords was difficult.

It was also difficult for the end users. If they were logged in to one particular server, but then needed to access files they had saved in their home directory on a different server or print to a printer serviced by a different server, they had to reauthenticate to each one.

Note

Linux/Unix systems still face a similar quandary today. Many administrators use the Linux Network Information Service (NIS) to eliminate the need to maintain duplicate user accounts. For more information on NIS, visit http://www.linux-nis.org/.

Novell revolutionized the industry in the mid 1990s when it introduced Novell Directory Services (now called eDirectory) for the NetWare platform. Directory Services provided a directory tree that contained all user accounts, servers, printers, and other network resources.

Each user had only one user account in the tree and was granted rights to other network resources. With Directory Services, administrators only had to worry about a single user account for each user. In addition, users only had to authenticate once to use network resources.

In the late 1990s and early 2000s, Novell enhanced NetWare by providing a number of directory-enabled products and services that significantly enhanced end users' productivity. These included products such as iFolder, iPrint, Native File Access Protocol (NFAP), NetDrive, NetStorage, eGuide, GroupWise, ZENworks, Virtual Office, and NetMail.

If you've ever used any of these services, you know how powerful they are. Users can access their work files from home using only a dial-up connection and a web browser. They can use a web-based interface to select the printer they want to print to and have it automatically download the correct drivers to their workstation.

Users can also use eGuide to view company contact information in a web browser and send email messages.

In 2003, Novell once again made an innovative move and began porting these services to run on the Linux platform as well as its venerable NetWare operating system. This is all part of Novell's oneNet strategy, announced in 1999.

Note

Ever since oneNet was announced, everyone keeps asking, "Does this mean Novell is getting rid of NetWare?" According to the latest Novell press releases posted at the time this book was written, Novell plans to continue to develop NetWare. This only makes sense because Novell has a very large installed NetWare base. Porting its most popular services over to Linux serves to broaden the potential installed base. As you will see later in this book, a Linux server with NNLS installed can be configured to work with NetWare servers in the same eDirectory tree.

One of the main goals of the oneNet strategy is to make network services available to users no matter where they are. If an executive is preparing a presentation in a remote city, she should be able to access her company's network resources from her hotel room as if she were back at her desk.

If a user is at home in the evening and receives an emergency request for information, he shouldn't have to drive back to work. He should be able to access network resources from home and complete the assignment from there.

The oneNet strategy is composed of the following services and products:

  • Novell Nterprise— A key component of the oneNet strategy is the Nterprise product line. These products, of which NNLS is a part, provide the services discussed earlier that supply "anywhere" access to an organization's network resources.

  • Novell Nsure— The Nsure family is composed of products that provide identity security management services.

  • Novell exteNd— Novell's exteNd product line provides a development platform for web-based applications.

  • Novell Ngage— Novell also provides Ngage consulting and training services to deploy oneNet products.

As we work through the remaining chapters in this book, you will see how NNLS on Linux fits the goals of Novell's oneNet strategy.


NNLS Components

Test Objective Covered:

1. Describe Novell Nterprise Linux Services (NNLS).

Let's now turn to a discussion of the individual components included in NNLS to provide these services. Before doing so, you need to know that NNLS 1.0 isn't currently supported on all Linux distributions. The distributions that are supported include the following:

  • Red Hat Enterprise Linux AS 2.1

  • Red Hat Enterprise Linux ES 2.1

  • SUSE Linux Enterprise Server 8

Tip

The fact that NNLS isn't supported for a particular distribution doesn't necessarily mean that it isn't compatible. I've found that it runs very well on Red Hat 7.3, Red Hat 9, and SUSE 8.2. I have experienced problems, however, when installing on Red Hat 8.

If you have a particular distribution you are partial to, feel free to give NNLS a try on it. Be aware, however, that if you experience a problem and try to call Novell's Technical Support number, you will be told to install NNLS only on a supported distribution.

The individual components that comprise NNLS are discussed in the following sections.

Identity Management

To manage your network and keep it secure, NNLS provides eDirectory 8.7.3 for your Linux server. As mentioned earlier, eDirectory is the latest version of Novell Directory Services (NDS). With eDirectory, you can assign rights that control the level of access individual users have to network resources.

Note

Unlike many other network operating systems, eDirectory is extremely difficult to hack into. If you read the various hacker websites, you'll see that to hack eDirectory, you have to get an actual copy of the eDirectory database files. This is not any easy thing to do without having physical access to the server hardware.

NNLS also includes eGuide 2.12. eGuide is a web-based application that allows you to query any LDAP-compliant database and display the resulting information. eGuide is most frequently implemented with eDirectory to create a web-based organization directory of users and resources.

In addition to these two products, NNLS includes the Starter Pack version of the powerful Novell DirXML product. DirXML can synchronize your eDirectory database with other directory services and databases, such as Windows NT Domains and Active Directory. It can even be used to synchronize your eDirectory database with another eDirectory database.

DirXML is frequently implemented such that eDirectory is configured as the central, authoritative source for network information. When you make a change in eDirectory, such as creating a new user, DirXML replicates the change in the synchronized application.

NNLS also includes the Linux User Management 2.1 (LUM) product. LUM is a powerful service that allows you to redirect authentication from the standard Linux authentication mechanisms to eDirectory.

Each of these products will be covered in more depth in later chapters of this book.

File Management

In addition to identity management, NNLS also provides file management services. The key goal behind this suite of products is to allow end users to have the same level of access to their files regardless of where they are physically located.

For example, a traveling salesperson for your company should be able to access her presentation files on your server from her hotel room as easily as she does back at the home office.

One of the components that makes this possible is Novell's iFolder 2.1.2 product. iFolder is a file-synchronization tool. User files are stored centrally on the iFolder server. These files are synchronized out to user workstations using the iFolder client or the iFolder browser interface.

This allows users to work on their files locally. When a user makes a change to one of these files, the iFolder client synchronizes the changes automatically back to the iFolder server.

Tip

Because iFolder only synchronizes the changes made to a file instead of the whole file, it works very well across slow Internet connections.

If the user uses a different workstation to access her files, the most current copy is automatically synchronized down from the iFolder server.

One of the key benefits of iFolder is that it can eliminate a lot of document version problems. In the "old days," users would frequently email themselves documents. If a user needed to work on a document from home, he might email it to himself from work. Then, at home, he would access his email and download the attachment. When he was done, he would email the latest version back to himself again. Finally, back at work, he would open the email and download the attachment.

Doing this creates three separate versions of the same document. This can easily result in the wrong version being deleted. iFolder eliminates this problem. Because the files are automatically synchronized, there is always only one version of the file.

Note

Another benefit of iFolder is the fact that, if the network administrator is worth his or her salt, the central iFolder server is usually backed up on a regular basis. If the server goes down, its data can be easily restored from a tape backup. User files are, therefore, protected with a backup.

NNLS also provides the NetStorage 3.0 product. NetStorage is a simple, yet powerful product. It allows you to access your files on the server using a web browser. Although it doesn't synchronize your files the way iFolder does, it does allow you to get at your work files over the Internet. This can be a real lifesaver in an emergency. NetStorage also supports shared directories, enabling collaboration within a workgroup team.

NNLS also includes Samba 2.2.8a. If you haven't used Samba before, you're in for a real treat. Samba, when run on Linux, allows a Linux server to process Server Message Block (SMB) messages. In short, this allows your Linux server to emulate a Windows NT file and print server.

This is especially valuable in an organization that uses a Linux server with Windows workstations. By implementing Samba, users can map drives and printers to, what appear to be, shares on a Windows server. The shares, however, actually point to directories or printers on your Linux server. The NetStorage product also leverages Samba to provide much of its functionality.

Print Management

As with the file management services included in NNLS, the print management component's goal is to provide users with the ability to seamlessly print from any location. Imagine editing a document on a workstation at home and being able to print it on a printer in your company's Sydney office.

This can be done with NNLS using iPrint 5.0. iPrint is a powerful product that turns your Linux server into an Internet print server using the Internet Printing Protocol (IPP). Users can open web-based office floor plans and click the printer they want to send a document to. If they don't have the correct driver for that printer installed, iPrint will automatically download it to the workstation before sending the document.

Messaging Services

In today's business world, email is a must-have element of any network implementation. To meet this need, NNLS includes the NetMail 3.5 product. NetMail provides a very powerful messaging and calendaring solution that is also very easy to configure and manage. With it, users can send and read email messages, schedule meetings, and reserve organizational resources such as conference rooms.

Collaboration Services

One of the most useful components of NNLS is its collaboration product: Virtual Office 1.0.1. Virtual Office is a web portal that allows users to create virtual teams. These virtual teams can collaborate with a chat applet, send email messages, share uploaded files, and schedule meetings.

Virtual Office also presents users with a unified browser-based interface for accessing NNLS services such as email, iPrint, and eGuide.

Version Management Services

Ask any Linux administrator and he will tell you that one of the tasks that consumes a lot of his time is managing updates to the network operating system files.

NNLS includes the Red Carpet 1.4 daemon, which you can use to manage products installed on your Linux server, including downloading and installing updates of NNLS components.

Web-based Administration

True to Novell's oneNet strategy, NNLS can be managed using web-based administration utilities. The advantages of web-based administration are significant.

Image that you are responsible for administering a Linux server running NNLS. You get a telephone call at 3:00 a.m. from your company's night-shift manager indicating that one of his employees has been promoted to the position of Team Lead and needs rights to a particular printer in the managers office area. (And by the way, it's urgent and absolutely can't wait until you come in tomorrow morning.)

Without web-based management utilities, you would have to roust yourself out of bed, drive to work, make a rights assignment to a user object in the eDirectory tree, and then drive back home. Overall, this is a very poor use of time.

With the web-based administration component of NNLS, such a call (although irritating) could be taken care of in a matter of minutes from a web browser on your home computer. Because NNLS uses encryption, you don't have to worry about sensitive network information being intercepted by hackers.

NNLS includes three web-based administration utilities:

  • iManager 2.0.2—iManager is the primary administration tool for Novell eDirectory. It's used to manage users, manage eDirectory services such as DirXML, and back up the tree. iManager uses role-based administration. This allows you to create a management role, assign tasks to it, and then associate it with specific users. This automatically grants them the rights they need in the tree to complete the tasks you've assigned to them.

  • iMonitor—iMonitor is an advanced eDirectory troubleshooting and maintenance tool. You can use it to check the overall health of your eDirectory database and repair any problems you may discover.

  • NetMail WebAdmin 4.0— WebAdmin is a web-based utility used to implement and manage the NetMail 3.5 service in NNLS.

These tools make NNLS relatively easy to manage. Let's now turn our attention to the relationship between Novell and the Open Source movement.


Novell and Open Source

Test Objective Covered:

1. Describe Novell Nterprise Linux Services (NNLS).

Before we end this chapter and start installing NNLS on your server, we need to briefly discuss Novell's relationship with the Open Source movement. As part of its oneNet strategy, Novell has begun to embrace Open Source software. We talked briefly about Open Source back in Chapter 2. If you will recall, the source code for products developed under the GPL license is freely available for anyone to download.

Once you've downloaded it, you can legally alter the code to fit your needs and then compile it. The stipulation behind this agreement is that your changes have to be openly shared. You can license and redistribute your application as long as this condition is met.

You might be wondering why Novell chose to embrace the Open Source community. I'm sure there are many reasons behind this decision (most of which I'm not privy to, of course). One clear advantage stands out, though: One of the key drawbacks to Novell's product line was the fact that it didn't have a lot of applications written for it by third-party developers. NetWare Loadable Modules (NLMs) were very difficult to write.

Many industry analysts in the late 1990s identified this issue as an important advantage for Microsoft Windows NT and 2000 Servers over NetWare. By moving to an Open Source strategy, Novell has opened up its systems to a wide array of existing Open Source applications. Because Open Source products are freely distributed, the total cost of ownership (TCO) of Novell products can be significantly lowered for an organization.

Novell has also contributed back to the Open Source community by opening up the source code to some of its most popular products, such as iFolder.


Summary

In this chapter, we covered the following topics:

  • Introduction to NNLS

  • NNLS components

  • Novell and Open Source

That's it for this chapter. It's time to stop talking about NNLS and start implementing it. In the next chapter, you will learn how to install NNLS as well as how to manage eDirectory.


Chapter 5. NNLS Installation and Administration

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Perform an NNLS installation.

  2. Manage NNLS with Red Carpet.

  3. Describe the purpose of eDirectory.

  4. Describe how eDirectory works.

  5. Perform eDirectory administration tasks.

  6. Manage user objects with iManager.

Up to this point in the book, we have reviewed the basic Linux skills you need to implement and manage NNLS. You've also been introduced to the various components that make up the NNLS products.

In this chapter, we're going to get down to business and install NNLS on the SUSE Linux server implemented in Chapter 2, "Introduction to SUSE Linux." After installing NNLS, we'll discuss how to keep the implementation up to date using Red Carpet. After that, we'll dive into eDirectory and cover some basic administration concepts.


Installing NNLS

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 0 (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 0 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.

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 0, 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.


Lab Exercise 5.1: Installing and Configuring SLP

In this exercise, you will install OpenSLP on the Linux server you installed and configured in earlier chapters of this book. You will then modify the slp.conf file to create a DA.

Warning

A word of warning before beginning: This exercise requires you to access a website on the Internet and download a file. In previous chapters, we practiced configuring network interfaces on your SLES 8 server. If your system is connected to a company network that has Internet access, this shouldn't present a problem.

If your company network doesn't provide access to the Internet or if you've set up your system at home and you only have dial-up access, this may cause difficulties. Configuring a modem on a Linux server is outside the scope of the CLE certification and this book. If you need to do this, visit the Linux Documentation project at http://www.tldp.org, where you will find several how-to's that explain how to configure a modem in your system and create a PPP connection.

Another issue to be aware of is the fact that you'll be directed to download a package from the Internet. The URLS and links specified in this exercise were correct at the time this was written.

Complete the following:

  1. Boot your Linux server and authenticate as your student user with a password of novell.

  2. Open a browser window and navigate to http://www.openslp.org.

  3. Scroll down to the Downloads section, shown in Figure 5.11, and click the Take me to the download page link.

    Figure 5.11. The OpenSLP download page.

  4. Under the latest stable release heading, select the latest OpenSLP binary package file, and download it to /tmp on your server.

    Note

    At the time this book was written, the latest stable release was 1.0.10.

  5. Open a terminal session.

  6. At the shell prompt, change to the root user account by entering su - and supplying a password of novell.

  7. At the shell prompt, change to the /tmp directory by entering cd/tmp.

  8. Install the OpenSLP package by entering rpm -i ./OpenSLP_file_name. For example, at the time this book was written, the current stable release is 1.0.10. The command to install this package would be rpm -i ./ openslp-1.0.11-1.i386.rpm.

  9. Wait while the package is installed.

  10. When the installation is complete, you're ready to configure the slp.conf file to create a DA. At your shell prompt, enter vi/etc/slp.conf.

  11. Press Ins to enter Insert mode.

  12. Scroll down to and locate the net.slp.useScopes line.

  13. Remove the comment character (;) from the beginning of the line.

  14. Delete the text string that reads

myScope1, myScope2, myScope3

    from the end of the line.

  15. After net.slp.useScopes = text, enter CLEScope. When you're done, the line should appear as follows:

net.slp.useScopes = CLEScope

    This configures your DA to service a scope named CLEScope.

  16. Scroll down to and locate the line net.slp.isDA.

  17. Remove the comment character (;) from the beginning of the line. The line should now read as follows:

net.slp.isDA = TRUE

    This enables the local DA on your server. Remember that the SA and UA are run automatically when the service is started.

  18. Scroll to the net.slp.DAAddresses line. Remove the comment character (;) from the beginning of the line and set the value of this parameter to your server's IP address.

  19. The remaining parameters' functions can remain at their default values for your implementation. Press Esc to enter Command mode.

  20. Save the changes to the file and exit vi by entering :exit.

  21. Start the slpd daemon by entering /etc/init.d/slpd start at the shell prompt.

  22. At the shell prompt, enter chkconfig—list slpd. Verify that the slpd daemon is configured to automatically start at runlevels 3, 4, and 5. If it's not, enter chkconfig slpd 345.

  23. Verify that SLP has been configured correctly using the slptool utility. At the shell prompt, enter slptool findscopes.

    The slptool utility should find the CLEScope you configured your DA to service, as shown in Figure 5.12.

    Figure 5.12. Checking your SLP configuration with slptool.

If slptool located the CLEScope, your SLP implementation is configured properly, and you're ready to continue preparing your system for an installation of NNLS.

Configuring the hosts File

The next task you need to complete is configuring your system's hosts file. Depending on the distribution and version, sometimes the hosts file is written during installation of the operating system in such a way that NNLS is unable to resolve the hostname correctly.

Basically what happens is that an alias for the server hostname is added to the loopback address. For example, it may read something to the effect of

127.0.0.1 CLE-1 localhost.localdomain localhost

or

127.0.0.1 localhost.localdomain localhost CLE-1

Check your hosts file, located in /etc, and verify that the hostname of the server doesn't appear in the loopback address line. If you identify this problem in your hosts file, use vi to edit out the server hostname in the loopback address line.

When you're done, it should read as follows:

127.0.0.1 locahost.localdomain localhost

You should also make sure there is a record in your hosts file that reads as follows:

Server_IP_Address  Server_DNS_Name  Server_Hostname (alias)

Here's an example:

192.168.1.35  CLE1.CLE.com  CLE1

When you're done, you hosts file should appear similar to that shown in Figure 5.13.

Figure 5.13. Checking your hosts file.

Once this is done, the next thing you need to do is establish a connection to the Internet.

Establishing an Active Internet Connection

To install NNLS, you need to have an active Internet connection established prior to starting the installation process. NNLS includes a component called Red Carpet that automatically updates NNLS products (we'll talk a little more about Red Carpet later in this chapter). The Red Carpet daemon must detect an active Internet connection during installation in order for it to configure its network settings.

If you don't have an active connection, Red Carpet will still install, but its configuration will not be accurate. Unfortunately, you can't manually edit the configuration. If you install without an active Internet connection, you'll have to uninstall and then reinstall the Red Carpet component of NNLS at a later time when an Internet connection is available.

Once your Internet connection is established, the next thing you need to do is gather information required for installing NNLS.

Gathering Data Required for Installation

During the installation of NNLS, you will be prompted to provide many pieces of data that will be used to configure the NNLS components; these include usernames and passwords, IP addresses, and various other configuration parameters. Before you start the installation process, it is wise to gather all this information beforehand.

If you do not do this, your installation may have to wait patiently for you while you search for the value of a requested parameter. You should prepare the information shown in Table 5.1.

Table 5.1. NNLS Installation Data

NNLS COMPONENT

DATA REQUIRED

DESCRIPTION

eDirectory

NICI file location and filename

This is the path and filename of the NICI file you downloaded. You should insert the floppy disk containing this file in your server's floppy drive and mount it to the /media/floppy directory before beginning installation. The NNLS installation script is coded to look in this directory for the file.

Install a new tree or into an existing tree?

You must specify whether you are installing a new eDirectory tree or into an existing tree.

Tree name

The data you provide here is dependent on whether you are installing a new tree or into an existing tree. If you're installing a new eDirectory tree, you must determine a unique name. If you're installing into an existing tree, you must supply its name at this prompt.

Existing server IP address

If you're installing into an existing tree, you need to know the IP address of the server (NetWare, Linux, or Windows) that already resides in the tree. If you're installing into a new tree, you won't be prompted to provide this information.

Admin name with context

Again, the value you supply here is dependent on whether you are installing into a new or an existing eDirectory tree. If you're installing into an existing eDirectory tree, you must provide the typeful name of the tree's admin user (for example, cn=admin.o=CLE).

If you're installing a new tree, you must also provide this information. This information will be used to create the tree's admin user account.

Admin password

This is the password for your admin user. If you are installing into a new tree, the value you provide will be assigned as the admin's password.

If you're installing into an existing tree, you must provide the pass word of the existing admin user.

Server context

This parameter specifies where you want your server to reside in the eDirectory tree. If you're installing into a new tree, the context will be automatically created for you. If you're installing into an existing tree, you should use iManager from another server to create the context beforehand. The installation script won't create the context in the tree for you.

LDAP port

This parameter represents the TCP/IP port your LDAP server will use. The default value is 389. Unless you have a conflict, you should stick with the default.

Secure LDAP port

This parameter represents the secure port the LDAP server will use. The default value is 636. Again, you should stick with the default value.

HTTP port

This parameter represents the port used by iMonitor. The default is 81.

Secure HTTP port

This parameter represents the secure port used by iMonitor. The default is 444.

Linux User Management

LDAP server IP address

This is the IP address of the eDirectory server running LDAP that LUM will use to authenticate. This could be any server in your tree. In this book, we're going to use the LDAP service on the same server where LUM and eDirectory will be installed.

Admin name and context

This parameter is the admin user for your tree. It's the same user as you specified during the eDirectory portion of the installation.

You must provide the typeful name of your admin user (for example, cn=admin.o=CLE).

Admin password

This parameter is the password assigned to your admin user object.

LDAP port

This parameter specifies which TCP/IP port will be used by LUM to communicate with the LDAP server. The default value is 389. If you configured your LDAP server to use a different port number, be sure you enter it here.

Secure LDAP port

This parameter specifies the secure TCP/IP port to be used to communicate with the LDAP server in your eDirectory tree. The default value is 636. If you've configured your LDAP server to use a different secure port number, be sure you enter it here.

Partition root

This parameter specifies the top most context where the LDAP server will begin searching for eDirectory objects.

You must supply the typeful name of the container, such as o=CLE.

Workstation context

During the installation of LUM, a LUM Workstation object will be created in your tree. This parameter specifies where you want this object created.

You must use a typeful name, such as o=CLE.

This context must be the same as or within the partition root context you specified previously.

PAM services that will use eDirectory

You must decide which services you want to use eDirectory for authentication. You can choose from ftp, su, sshd, rsh, login, rlogin, and passwd.

DirXML

Tree name

This parameter specifies the name of the tree where DirXML will be installed. In this book, we will use the eDirectory tree we specified previously.

Admin name and context

This parameter specifies the admin user for the tree specified earlier. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

eGuide

LDAP server IP address

This parameter is the IP address of the LDAP server that will be used to authenticate users to eDirectory.

LDAP port

This parameter specifies which TCP/IP port will be used by eGuide to communicate with the LDAP server. The default value is 389. If you configured your LDAP server to use a different port number, be sure you enter it here.

Secure LDAP port

This parameter specifies the secure TCP/IP port to be used by eGuide to communicate with the LDAP server in your eDirectory tree. The default value is 636. If you've configured your LDAP server to use a different secure port number, be sure you enter it here.

Admin name and context

This parameter specifies the admin user for the tree. You must use a typeful name such as cn=admin.o=CLE.

Samba

eDirectory server IP address

For this parameter, you need to provide the IP address of a server in the eDirectory tree. This server must host a Master or a Read/Write replica of at least one eDirectory partition.

Admin name and context

This parameter specifies the admin user for the eDirectory tree. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

LDAP server IP address

This parameter is the IP address of the LDAP server that will be used to authenticate users to eDirectory.

Samba Proxy user

eDirectory uses a proxy user account to assign rights to the Samba service. This allows the service to perform certain actions in the eDirectory tree. During installation, this user is automatically created and assigned the appropriate rights.

At this prompt, you specify the name you want used for the proxy user. You can use any valid user name as long as it hasn't already been used in the tree.

Samba Proxy user password

This parameter is used to create a password for the Samba Proxy user. You can use any valid password.

LDAP port

This parameter specifies which TCP/IP port will be used by Samba to communicate with the LDAP server. The default value is 389. If you configured your LDAP server to use a different port number, be sure you enter it here.

Secure LDAP port

This parameter specifies the secure TCP/IP port to be used by Samba to communicate with the LDAP server in your eDirectory tree. The default value is 636. If you've configured your LDAP server to use a different secure port number, be sure you enter it here.

iFolder

LDAP server IP address

This parameter is the IP address of the LDAP server that will be used to authenticate users to eDirectory.

LDAP port

This parameter specifies which TCP/IP port will be used by iFolder to communicate with the LDAP server. The default value is 389. If you configured your LDAP server to use a different port number, be sure you enter it here.

LDAP admin name and context

For this parameter, you should use the admin user for the eDirectory tree. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

iFolder server IP address

This parameter specifies the IP address of the server you want to install iFolder on.

iFolder admin username

This parameter allows you to delegate iFolder administrative tasks. You can specify names of users who you want to grant iFolder administrative access.

The users must reside in the same eDirectory context as the admin username you specified earlier. The usernames must be separated with a semicolon.

iFolder user data path

This parameter specifies where you want user files stored in the Linux server's file system. The default path is /var/opt/novell/ifolderdata.

NetMail

Admin name and context

This parameter specifies the admin user for the eDirectory tree. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

NetMail primary DNS server

This parameter specifies the IP address of your organization's DNS server.

NetMail secondary DNS server

This parameter specifies the IP address of your organization's secondary DNS server. This parameter is optional.

Domain name for NetMail server

This parameter specifies your organization's domain name.

NetMail WebAccess HTTP port

This parameter specifies the TCP/IP port that will provide insecure access to the WebAccess email interface. The default is port 52080.

Unless you have a port or firewall filtering conflict, you should use the default value.

NetMail WebAccess secure HTTP port

This parameter specifies the TCP/IP port that will provide secure access to the WebAccess email interface. The default is port 52443.

Unless you have a port or firewall filtering conflict, you should use the default value.

NetMail LDAP port

This parameter specifies the port that will be used to populate the NetMail address book. The default port is 52389.

Unless you have a port or firewall filtering conflict, you should use the default value.

iManager

iManager server IP address

This parameter specifies the IP address of the server where iManager is to be installed.

In this book, we will install iManager on the same server where eDirectory is installed.

Admin name and context

This parameter specifies the admin user for the eDirectory tree. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

iManager PCO password

This parameter specifies the password iManager uses to authenticate to eDirectory via LDAP as the Portal Container Object (PCO).

If you install iManager on other servers in the tree, each instance must use the same PCO password.

LDAP server IP address

This parameter specifies the IP address of the LDAP server that will be used to authenticate to eDirectory.

LDAP port

This parameter specifies which TCP/IP port will be used by iManager to communicate with the LDAP server. The default value is 389.

If you configured your LDAP server to use a different port number, be sure you enter it here.

Secure LDAP port

This parameter specifies the secure TCP/IP port to be used by iManager to communicate with the LDAP server in your eDirectory tree.

The default value is 636. If you've configured your LDAP server to use a different secure port number, be sure you enter it here.

WebAdmin HTTP port

This parameter specifies the insecure HTTP port WebAdmin will run on. The default value is 8018.

Unless you have port conflict or firewall filter issues, you should stick with the default value.

WebAdmin HTTP Port

This parameter specifies the secure HTTP port WebAdmin will run on. The default value is 8020.

Unless you have a port conflict or firewall filter issues, you should stick with the default value.

iPrint

Admin name and context

This parameter specifies the admin user for the eDirectory tree. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

iPrint server IP address or hostname

This parameter specifies the IP address of the server where iPrint will be installed.

The server must be in the eDirectory tree and must host a Master or a Read/Write replica of a partition.

Virtual Office

eDirectory server IP address or hostname

This parameter specifies the IP address of the server where Virtual Office is to be installed.

The server must be in the eDirectory tree and must host a Master or a Read/Write replica of a partition.

Admin name and context

This parameter specifies the admin user for the eDirectory tree. You must use a typeful name such as cn=admin.o=CLE.

Admin password

This parameter is the password for the admin user object you specified earlier.

NetStorage authentication server

This parameter specifies the IP address of the server that will be used to authenticate NetStorage users.

This server must reside in the eDirectory tree and have LDAP installed.

NetStorage proxy user

At this prompt, you must supply the name of a user in the eDirectory tree that will be used to provide proxy access to the NetStorage service. In this book, we will simply use the tree admin.

You must use a typeful name.

NetStorage proxy user password

This parameter supplies the password for the user specified earlier.

NetStorage users context

This parameter specifies the topmost context in the eDirectory tree that will be searched for NetStorage users. All contexts below this specified context will be included in search operations.

iFolder server IP address or hostname

As you'll learn later in this book, NetStorage and iFolder are tied closely together.

This optional parameter specifies the IP address of the iFolder server you want to use as a NetStorage storage location.

Red Carpet Client

Admin email address

This optional parameter specifies the email address that you want NNLS update messages sent to.

Proxy server

If you want the Red Carpet Client to connect to the Internet though a proxy server, select yes. Otherwise, select no.

Proxy server contact URL

If you selected yes for the preceding parameter, you need to use this parameter to specify the URL of the proxy server.

Proxy username

If you selected yes for the proxy server parameter earlier, you need to use this parameter to supply a username for the proxy server.

Proxy user password

If you selected yes for the proxy server parameter earlier, you need to use this parameter to supply the password for your proxy server username.

As you can see, this is an extensive list of information you need to gather. Before beginning the NNLS installation, you should create a list of the required information and keep it handy as you proceed.

With this information in hand, you're almost ready to start installing NNLS. However, you need to be aware of some important issues you may encounter during the installation process.

Gotchas to Avoid During Installation

There are several idiosyncrasies with the NNLS installation routine that can cause you a great deal of anguish. If you're aware of them, however, they are pretty easy to deal with. In this section, we'll cover the issues other administrators have discovered (so you don't have to!). When installing NNLS, keep the following points in mind:

  • Don't include your server's domain when prompted for a hostname. Many administrators have mistakenly thought the installation script was asking for the server's hostname and domain name (such as CLE1.CLE.com). If you include the domain name with the hostname, eDirectory won't install correctly and you will be left scratching your head wondering why all your NNLS components don't work.

  • Watch out for port conflicts, especially with Apache Web Server. NNLS automatically installs a new version of Apache on your server. If Apache is already running on your system, the NNLS installation routine will shut it down and change its runlevel configuration to not automatically start.

    The new Apache Server's configuration files are located in /etc/opt/novell/httpd and the default document root directory is set to /var/opt/novell/httpd/htdocs. The important point to remember is that both the old and the new versions of Apache are configured to run on ports 80 and 443.

    Table 5.2 lists all the default port assignments used by the various NNLS components. Note that, if two ports are listed, the first port is the insecure port and the second port listed is the secure port.

    Table 5.2. Default NNLS Ports

    NNLS COMPONENT

    DEFAULT PORTS

    Apache Web Server

    80, 443

    eDirectory

    524

    iMonitor

    8008, 8010

    iPrint

    631, 443

    LDAP

    389, 636

    Tomcat

    8080

    Samba

    137, 138, 139

    NetMail WebAdmin

    8018, 8020

    NetMail LDAP

    52389

    NetMail WebAccess

    52080, 52443

    NetMail Calendar Access Protocol

    1026

    NetMail SMTP Agent

    25

    NetMail POP Agent

    110, 995

    NetMail IMAP Agent

    143, 993

    NetMail NMAP Agent

    689

  • During installation, NNLS places some of its man pages in the /opt/novell/man directory, which is not in the MANPATH variable. To add this path to the MANPATH variable, open a terminal session when the NNLS installation is complete. At the shell prompt, enter MANPATH=$MANPATH:/opt/novell/man. This command adds the new path to the existing directories already in the MANPATH variable.

    Warning

    Be sure to remember to include $ in front of MANPATH, as shown the example. This designates the text that follows as a variable. If you forget $, MANPATH will be treated as a literal text string, overwriting the directories currently stored in the MANPATH variable. Although your NNLS man pages will work, all your system man pages won't.

    Then enter export MANPATH at the shell prompt. At this point, your system man pages and your NNLS man pages will be available.

  • Make sure your system DNS server is up and running. The NetMail installation process will attempt to contact it to verify domain and host information. If it can't contact the server, the NetMail product won't work properly.

  • If you interrupt the installation script after it has started installing packages, you must uninstall eDirectory before attempting to reinstall NNLS. To do this, open a terminal session and enter /usr/bin/nds-uninstall at the shell prompt.

  • Sometimes the new NNLS Apache Web Server won't start up after installation. This presents a serious problem because most of your NNLS administration utilities are dependent on it.

    Essentially what happens is, the process ID (PID) file for the new Apache Server doesn't get updated with the correct status of the service. It specifies that the service is already running.

    When the novell-httpd daemon tries to start, it checks its associated PID file. When it reads that the process is supposedly already running, it automatically shuts down.

    If you suspect this is happening, check your /var/log/boot.log file for a message to this effect. If you find it, simply delete the /var/opt/novell/httpd/run/httpd.pid file and then start the novell-httpd daemon.

Believe it or not, it is actually time to start installing NNLS on your system! Let's take a look at how this is done.

Installing NNLS

With your downloaded ISO image mounted (or burned on a CD and mounted), time synchronization established, OpenSLP configured, and your pre-installation data gathered, you're finally ready to start the installation process.

To do this, open a terminal session on your server and switch to the directory where your ISO file or CD is mounted. Start the installation by entering ./install.sh.

One of the first decisions you will have to make is whether you want to perform an express or a custom installation. Let's review how each of these options work.

Express NNLS Installation

As the name suggests, an express installation is designed to require the administrator to supply only minimal input. To perform an express installation, you need to supply only the following data:

  • The path to the NICI file you downloaded

  • The name for the new eDirectory tree

  • The context and password for the tree admin user object

This option sounds very easy. Be aware, however, that it is not for everyone. To make it easy, the express installation option makes many assumptions for you without your input.

For example, this option assumes you want to install a new eDirectory tree. If you want to install your NNLS server into an existing eDirectory tree, you must use the custom option.

In addition, the express option installs all the NNLS components on the same server. For a small organization or for lab testing, this scenario may be quite appropriate. If you are deploying NNLS in a production environment for a large organization, however, putting all the components on the same server may not yield the level of performance you need. If you need to distribute the NNLS components among several servers (to provide a degree of load balancing), you need to use the custom option.

The express option also assigns services to use the default NNLS TCP/IP ports mentioned earlier. If this will create port conflict issues on your server, you need to use the custom installation to customize the port number assignments.

Be aware, as well, that the express option also uses the context you specify for the admin user as the context for all other components. If you need to customize your tree, then, likewise, you need to use the custom installation option.

If, however, the constraints of the express option match your requirements, by all means use it. I've installed and configured many times and the express option really is a lot easier on the administrator. You start it up, provide the few parameters it needs, and then you can leave while it completes the installation.

One other key benefit to the express option that I have observed is the fact that it tends to produce more successful installations of NNLS. This has less to do with the way the script is written as it does with the fact that there is less input required from the administrator and, hence, there are fewer opportunities for mistakes.

The custom installation option requires so much information that it's easy for the administrator to enter typos, provide wrong information, or misunderstand what information is being requested.

The express option also provides you with the ability to use a response file to automate the installation process. Essentially, what you do is download the response file from Novell's website, edit the text of the file for your organization and network, and then point the installation script to this file.

When you do this, the install script reads the data it needs from the file instead of displaying prompts on the screen for you to respond to. The user input portion of the express installation response file is shown in Figure 5.14.

Figure 5.14. Express installation response file.

Notice in Figure 5.14 that you simply enter the information you would have been prompted for onscreen in the appropriate fields. Using a response file isn't of much benefit if you're only installing one or two NNLS servers. If you're installing many servers, however, it can be a real timesaver.

The express installation response file can be downloaded from http://www.novell.com/documentation/lg/nnls/answers/express.txt.

Warning

I strongly recommend that you use KWrite, vi, or another Linux text editor to edit this file. Some Windows text editors mess up the CRLF characters in Linux text files. If this happens, the file won't work with the NNLS install script.

Once you've edited the file, create a directory named /etc/opt/novell on your server and save the response file there as nterprise_linux_services_install.conf. Then, run the install script with the -s option (for example, ./install.sh -s).

If you need more flexibility in your installation than the express option has to offer, you should use the custom installation option.

Custom NNLS Installation

The custom installation option takes a lot longer to complete and increases the risk of administrator error, but it also provides you with a high degree of flexibility. With a custom installation, you can do the following:

  • Distribute NNLS components among several different servers.

    As stated earlier, this is strongly recommended for large organizations. The horsepower required from your server to run all the NNLS components on the same system is considerable.

    If you have thousands of users requesting services at the same time, the system could slow to a crawl. The custom option allows you to specify which server each component is to be placed on. By dividing the load among servers, NNLS can provide stellar high-load performance.

    A nice feature of NNLS is the fact that it will check each server you select for the appropriate dependencies and install missing packages for you (if it has them).

  • Install into an existing eDirectory tree or create a new one.

  • Customize where various objects used by NNLS components are stored in the tree.

Because of the sheer amount of data you must provide, it's a good idea to fill out Table 5.1 from earlier in this section.

As with the express option, you can automate the installation process using a response file. Because the custom installation requires a lot more information from the administrator, you must use a different response file. The file for a custom installation is available for download from http://www.novell.com/documentation/lg/nnls/answers/custom.txt.

As with the express response file, you must edit the file with a Linux text editor to provide the requested information. Then you must save the file as /etc/opt/novell/nterprise_linux_services_install.conf and run the install script with the -s option.

Once you have selected the type of install you want to use, you're ready to begin! In the next lab exercise, we will perform a complete custom installation using detailed steps. At a high-level, the steps you need to follow to install NNLS are as follows:

  1. Mount your NNLS 1.0 CD or ISO image on your Linux server.

  2. Mount the floppy disk containing your NICI file on your Linux server.

  3. Open a terminal session and change to the root user account by entering su - and supplying your root user password.

  4. Change to the directory where the NNLS 1.0 CD or ISO image is mounted.

  5. Start the installation by entering ./install.sh.

  6. When prompted, specify that you want to install NNLS by entering i.

  7. At this point, you must decide whether you want to perform an express or a custom install. If you want to do an express installation, enter y when prompted; otherwise, use the default value of [no] by pressing Enter.

  8. Identify the NNLS components you want to install.

  9. When prompted, accept the license agreement.

  10. When prompted for the location of the NICI Foundation Key file, enter the path and filename of the NICI file.

  11. Enter the parameters requested at each prompt (see Table 5.1 for details).

  12. When prompted, view the installation summary by entering y.

  13. If you need to change any parameter, enter y and follow the instructions present on the screen.

  14. When you are satisfied with the configuration, begin the installation by entering f.

  15. Wait while all the packages are installed and the services are configured.

  16. When prompted, view the readme file by entering y.

  17. Save the installation settings in a log file by entering y. This log file can be used as a response file. By editing this file, you can use it to perform automated installations of subsequent NNLS servers.

  18. Unmount your CD or ISO image and floppy disk.

That's all there is to it! Let's do it for real in Lab Exercise 5.2.


Lab Exercise 5.2: Preparing to Install NNLS

The moment is finally here! You're sufficiently prepared to install NNLS. In this exercise, you will install NNLS on the Linux server you installed and configured in earlier chapters of this book.

In this lab, you're going to install all the NNLS components on the same server. For a lab exercise, this is an acceptable practice. For a production server, however, you should distribute the various components among several servers.

Warning

A word of warning before beginning: As with the previous exercise in this chapter, this exercise requires you to access a website on the Internet and download the evaluation version of NNLS.

You need to have reliable Internet access to do this. When writing this exercise, I've assumed that you have set up your system in a work environment that has Internet access through your LAN. In this situation, the NNLS download should take less than an hour or so.

If you are going to try this from a system at home using a modem, be sure you allow enough time for the NNLS download.

Because it is more than 300MB in size, you should start the download the night before and let it run overnight. Be aware, however, that many dial-up ISPs periodically check their current PPP connections for activity. They then terminate connections that appear to be inactive.

Even though you're in the midst of a heavy download, they may deem your connection to be inactive and disconnect you. (I've had that happen many times myself.)

As with the previous exercise, the URLS and links specified in the lab were correct at the time this was written.

In this lab, I'm assuming that you have already configured the xntpd daemon on your system and that SLP has been implemented.

To install NNLS, complete the following steps:

  1. Boot your Linux server and authenticate as your student user with a password of novell.

  2. Open a terminal session.

  3. Change to the root user account by entering su - and supplying a password of novell.

  4. Verify that you have a multicast route added to your routing table by entering netstat -nr. You should see a route for the 224.0.0.0 destination. If not, enter route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 to add the multicast route. If you do this, you will need to stop and restart your slpd daemon.

  5. Verify that NTP is working properly by entering ntpq -p at the shell prompt. If time isn't synchronized properly, follow the steps presented earlier in this chapter to resync.

  6. Verify that SLP is working properly by entering slptool findscopes at the shell prompt. The utility should display the CLEScope scope. If you don't see it, make sure your slp.conf file is configured according to the instructions in Lab Exercise 5.1 and that the slpd daemon is running.

  7. Download the NNLS 1.0 Evaluation ISO image by completing the following steps:

    1. On your Linux server, open Mozilla and browse to http://www.novell.com/products/linuxservices/.

    2. In the Nterprise Linux Services home page, click the Download the Eval link.

    3. Under Nterprise Linux Services, click the Click Here to Download link.

    4. In the NNLS Download page, click the Download Now link.

    5. If you already have a Novell.com profile, enter your username and password and then click Login.

    6. If you don't have a Novell.com profile, select Create a Profile and then follow the prompts to create your own personal profile.

    7. Next to Novell_Nterprise_Linux_Services_1.0.iso select Download.

    8. Save the file to /tmp.

    9. Wait while the download completes.

  8. When the first download set is complete, download your NICI file by completing the following:

    1. In your browser window, navigate to http://www.novell.com/products/edirectory/customer_license.htm.

    2. In the Customer License screen, read the license agreement and then click I Accept.

    3. Click the Request a Novell eDirectory 8.7.x 250,000 User (128 Bit) Encryption License link.

    4. Fill out the Contact Information, Questionnaire, and Privacy/Permission forms and then click Submit. Your evaluation license will be sent to your email address.

    5. Open the email message and save the .nfk and the .nlf files you were sent to a floppy disk. Record the names of your files for use during installation.

  9. Check your hosts file by completing the following:

    1. At your shell prompt, enter vi /etc/hosts.

    2. Verify that the hostname of your server (CLE1) is not included anywhere in the localhost record.

    3. Verify that a record exists for your server that includes its IP address, its fully qualified hostname (domain name), and its short hostname (alias).

    Compare your hosts file with the hosts file displayed in Figure 5.13.

  10. Verify that your server has an active connection to the Internet.

  11. Configure DNS on your server by completing the following steps:

    Warning

    To complete later lab exercises with NetMail, you must have a DNS server configured to service the CLE.com zone with an A record for CLE1.CLE.com that resolves to your server's IP address.

    If you have a very kind DNS administrator in your organization, you could have him or her configure this zone for you and skip this step. If not, you'll need to set up your own DNS server. Configuring the named daemon, which was automatically installed on your server, does this.

    1. Open a terminal session.

    2. Change to your root user account by entering su - and supplying a password of novell.

    3. On your server, enter vi /etc/named.conf.

    4. Scroll to the bottom of the file. You should see a line that reads # You can insert further zone records.... Place your cursor at the beginning of the line following this line of text.

    5. Press Ins.

    6. Enter the following text:

zone "cle.com" in {

    type master;

    file "named.hosts";

};

    7. Press Esc.

    8. Enter :exit.

    9. Enter vi /var/named/named.hosts. This will create a new text file called named.hosts in the /var/named directory.

    10. Press Ins.

    11. Enter the following text:

; Zone file for CLE zone

;

; The full zone file

;

$TTL 3D

@    IN  SOA     CLE1.CLE.com. admin.CLE.com. (

                  200302151       ; serial  #

                  8H               ; refresh, seconds

                  2H               ; retry, seconds

                  4W               ; expire, seconds

                  1D )             ; minimum, seconds

;

             NS  CLE1              ; name server

localhost   A   127.0.0.1

CLE1          A  your_server's_IP_address

;

      Warning

      Be sure to press Enter and leave a blank line after the last line in the file!

    12. Press Esc.

    13. Enter :exit.

    14. Start the named daemon by entering /etc/init.d/named start.

    15. Configure the named daemon to automatically start by entering chkconfig named 345 at the shell prompt.

    16. Check your messages file for named startup errors by entering tail /var/log/messages. Ensure there were no errors encountered during startup. Resolve any errors reported.

    17. Run YaST.

    18. Select Network/Basic, Network Card Configuration.

    19. Under Already Configured Devices, select Change.

    20. Click Edit.

    21. Select Host Name and Name Server.

    22. If presented with a resolver configuration file error, click Modify.

    23. In the Name Server 1 field, enter your server's IP address.

    24. In the Domain Search 1 field, enter cle.com.

    25. Select Next, Next, Finish.

    26. Click Close.

      aa. Test your DNS server by entering nslookup.

      bb. At the prompt, enter cle1.cle.com. Your DNS server should resolve this name to your server's IP address.

      cc. At the prompt, enter www.novell.com. Your DNS server should resolve this name to Novell's web server IP address.

      dd. Enter exit.

  12. Mount your ISO image and your floppy disk by completing the following steps:

    1. At the shell prompt, make a directory for mounting ISO images by entering mkdir /media/iso.

    2. At the shell prompt, enter the following command:

 mount -o loop /tmp/

Novell_Nterprise_Linux_Services_1.0.iso /media/iso

    3. Verify that the image mounted properly by entering cd /media/iso; then enter ls. You should see the NNLS installation files, as shown in Figure 5.1.

    4. Insert your NICI disk in the server's floppy disk drive.

    5. At the shell prompt, enter mount -t vfat /dev/fd0/media/floppy.

With that, your system is now ready for an NNLS installation. Let's do that in Lab Exercise 5.3.


Lab Exercise 5.3: Installing NNLS

In this exercise, you will install NNLS. If you haven't completed Exercises 5.1 and 5.2, complete those before attempting this exercise.

To install NNLS, complete the following:

  1. Install NNLS using a custom install by completing the following steps:

    1. Verify that the current directory is /media/iso.

    2. At the shell prompt, enter ./install.sh.

    3. When prompted, enter i to install.

    4. When prompted to use an Express install, type no.

    5. You are now prompted to select the NNLS components you want to install. In this book, we're going to install everything up front. Then, as you progress through the remaining chapters, you will configure each product. Enter a to select all products.

    6. Enter f to finish making selections.

    7. In the License Agreement screen, press the spacebar until you are prompted to agree to the license agreement.

    8. When prompted to agree to the license, enter y.

  2. Provide eDirectory NNLS installation parameters by completing the following:

    1. When prompted for the location of the NICI file, enter /media/floppy/file_name.nfk.

    2. When prompted, enter 1 to create a new eDirectory tree.

    3. When prompted for the tree name, enter CLE-TREE.

    4. When prompted for the eDirectory port, press Enter.

    5. When prompted for the admin name and context, enter cn=admin.ou=IF.o=CLE.

    6. When prompted to enter the admin user's password, enter novell.

      Warning

      Be sure to use a different password for your admin user when you deploy NNLS in a production environment. You would be surprised how many eDirectory admin user objects are out there in corporate environments that have a password of novell.

    7. When prompted for a server context, press Enter.

    8. When prompted for the LDAP port number, press Enter.

    9. When prompted for the secure LDAP port number, press Enter.

    10. When prompted for the iMonitor HTTP port, press Enter.

    11. When prompted for the iMonitor secure HTTP port, press Enter.

  3. Configure the LUM component of NNLS by completing the following:

    1. When prompted for the LDAP server IP address, enter your server's IP address.

    2. When prompted for the admin name and context, press Enter.

      Tip

      Notice that the NNLS installation script remembers previously entered values for other components and automatically uses them for the default values for other NNLS components. You can use these defaults by simply pressing Enter.

    3. When prompted for the admin user's password, press Enter.

    4. When prompted for the LDAP port, press Enter.

    5. When prompted for the secure LDAP port, press Enter.

    6. When prompted for the partition root, press Enter.

    7. When prompted for the workstation context, press Enter.

    8. When prompted to select services that will use eDirectory for authentication, enter a to select all of them; then enter f.

  4. Configure DirXML parameters by completing the following:

    1. When prompted to supply the eDirectory server's IP address, press Enter.

    2. When prompted for the admin user's name and context, press Enter.

    3. When prompted for the admin user's password, enter novell.

    4. When prompted for the secure LDAP port, press Enter.

  5. Configure eGuide by completing the following:

    1. When prompted for the LDAP server's IP address, enter your server's IP address.

    2. When prompted for the LDAP server's port, press Enter.

    3. When prompted for the secure LDAP port, press Enter.

    4. When prompted for the LDAP admin username and context, press Enter.

    5. When prompted for the admin user's password, enter novell.

  6. Configure Samba by completing the following:

    1. When prompted to supply the eDirectory server's IP address, press Enter.

    2. When prompted for the admin user's name and context, press Enter.

    3. When prompted for the admin user's password, enter novell.

    4. When prompted for the LDAP server's IP address, press Enter.

    5. When prompted for the Samba Proxy username, press Enter.

    6. When prompted for the Samba Proxy user's password, enter novell.

    7. When prompted for the LDAP server's port, press Enter.

    8. When prompted for the secure LDAP port, press Enter.

    9. If prompted to remove existing Samba packages, press Enter.

  7. Configure iFolder by completing the following:

    1. When prompted for the LDAP server's IP address, press Enter.

    2. When prompted for the LDAP server's port, press Enter.

    3. When prompted for the LDAP admin username and context, press Enter.

    4. When prompted for the admin user's password, enter novell.

    5. When prompted for the IP address of the iFolder server, enter your server's IP address.

    6. When prompted to enter iFolder admin usernames, press Enter.

    7. When prompted to supply the iFolder user data path, press Enter.

  8. Configure NetMail by completing the following:

    1. When prompted to supply the admin username and context, press Enter.

    2. When prompted to supply the admin user's password, enter novell.

    3. When prompted to supply the NetMail DNS server address, enter your server's IP address.

    4. When prompted to supply the NetMail secondary DNS server address, enter your organization's secondary DNS server address, if it exists. This parameter is optional.

    5. When prompted for your NetMail domain, press Enter.

    6. When prompted for your WebAccess HTTP port, press Enter.

    7. When prompted for your WebAccess secure HTTP port, press Enter.

    8. When prompted for your NetMail LDAP port, press Enter.

    9. When prompted for the IP address of the server where iManager will be installed, enter your server's IP address.

    10. When prompted for the admin user's name and context, press Enter.

    11. When prompted for the admin user's password, enter novell.

    12. When prompted to supply the eDirectory server's IP address, enter your server's IP address.

    13. When prompted for the LDAP server's port, press Enter.

    14. When prompted for the iManager WebAdmin HTTP port, press Enter.

    15. When prompted for the iManager WebAdmin secure HTTP port, press Enter.

  9. Configure iPrint by completing the following:

    1. When prompted for your eDirectory tree name, press Enter.

    2. When prompted for the admin user's name and context, press Enter.

    3. When prompted for the admin user's password, enter novell.

    4. When prompted to supply the eDirectory server's IP address, enter your server's IP address.

  10. Configure Virtual Office by completing the following:

    1. When prompted to supply the eDirectory server's IP address, enter your server's IP address.

    2. When prompted for the admin user's name and context, press Enter.

    3. When prompted for the admin user's password, enter novell.

    4. When prompted for the NetStorage authentication domain host, press Enter.

    5. When prompted for the NetStorage proxy username and context, press Enter.

    6. When prompted for the NetStorage proxy user's password, enter novell.

    7. When prompted for the users context, enter o=CLE.

      Warning

      Be careful on the preceding step. You've been pressing Enter for so many parameters, it's easy to accidentally press it on this step.

    8. When prompted for the iFolder server's IP address, press Enter.

  11. Configure Red Carpet by completing the following:

    1. When prompted for the Red Carpet administrator's email address, enter your email address. If you want to use the NetMail account for your admin user object, you could enter admin@cle.com.

    2. When prompted, specify whether or not your server uses a proxy server.

  12. Finish the installation by completing the following:

    1. When prompted to view the installation summary information, press Enter.

    2. If you need to make any changes, enter yes and make the necessary changes. If you're satisfied with the current settings, enter no.

  13. Wait while NNLS is installed. This can take up to 15 minutes.

  14. When the installation is complete, you are prompted to view the readme file. Enter y to view it.

  15. When prompted to save the installation settings to a file, enter y.

  16. Unmount your ISO image and your floppy disk using the umount command.

  17. Verify your installation by completing the following:

    1. Run Mozilla by selecting the Mozilla icon on your desktop and open http://your_server_IP_address. You should see your NNLS home page displayed. Links for the various NNLS components should be shown on the left side of the page.

    2. Open iMonitor in Mozilla by browsing to https://your_server_IP_address:8010. If prompted, select Remember this certificate permanently; then select Continue. If you're presented with a Security window, click OK.

    3. Click the NDS iMonitor link.

    4. Authenticate as admin with a password of novell.

    5. Click the Known Servers link. You should see your server listed.

    6. Close your web browser.

  18. Update the $MANPATH variable by completing the following:

    1. Open a terminal session.

    2. At the shell prompt, enter

MANPATH=$MANPATH:/opt/novell/man.

    3. Enter export MANPATH.

    4. Close the terminal session.

Congratulations! You now have a fully functioning NNLS deployment on your server. You're probably wondering where all those files ended up on your system. Let's discuss the NNLS file locations.

NNLS File Locations

After installation, the NNLS files are placed in the /opt/novell directory and its subdirectories. In /opt/novell/lib are shared library files used by the various NNLS components. In /opt/novell/bin are NNLS executables and utilities. In /opt/novell/product_name/bin are product-specific binary files. In /opt/novell/include are product-specific header files.

User data for iFolder users is saved in /var/opt/novell. Log files for the various NNLS components are saved in /var/opt/novell/log.

NNLS configuration files are placed in /etc/opt/novell. Within this directory are subdirectories for each NNLS product. Within these subdirectories you will find conf files for the respective products.

The /var/novell/nici directory stores your server's Novell International Cryptographic Infrastructure (NICI) files.

The /var/nds directory stores your eDirectory database (DIB files) and log files.

Now let's discuss how to install NNLS components after the initial installation has taken place.

Post-Installing NNLS Components

You probably noticed during your NNLS installation that you don't have to install every NNLS component. You can pick and choose those products you need. When you do, you'll notice that the NNLS installation script automatically identifies dependencies that must be installed to support the products you have specified.

From time to time, however, you may find that you want to add an NNLS component after the initial installation has taken place. This can be done by simply mounting your NNLS ISO image or CD and running the install script again. When you reach the component selection screen, you'll notice that the products you previously installed are flagged as "already installed."

Select the additional products you want to install and proceed with the installation as you did when you performed the initial installation.

When you have finished installing the additional components, you need to restart Apache and Tomcat. You do this by opening a terminal session and entering /etc/init.d/novell-httpd restart and then /etc/init.d/novell-tomcat4 restart.

With the initial system configuration and NNLS installation complete, we're ready to move on and start working with the various individual components that comprise NNLS. In the remaining pages of this chapter, we will investigate Red Carpet and eDirectory.


Updating NNLS with Red Carpet

Test Objective Covered:

2. Manage NNLS with Red Carpet.

If you've ever been responsible for managing software updates—whether for operating systems or for applications—for a large organization, you know what a difficult task this can be. Fortunately, NNLS includes a component that can make this process much easier.

As you saw when you installed your server, NNLS includes the Red Carpet component. Red Carpet is a technology Novell gained when it acquired Ximian. The Red Carpet daemon (rcd) is used to automatically download software updates to your NNLS implementation.

Red Carpet allows you to group together multiple NNLS servers and update them concurrently. A very useful feature of Red Carpet is its ability to check for and apply dependencies before applying updates.

If you've ever worked with Linux updates, you know how helpful that can be. Consider the following typical scenario: You receive word of an update to your Linux distribution. You download it and start to apply it. The installation stops because the update has a dependency that is missing on your system.

You browse the web to locate the dependency and you download it. When you try to install it, however, it reports that it has a dependency as well that is missing on your system. You download and install it. Then you install the first missing dependency and then restart the installation of the update.

As you do, however, the update reports that it has another missing dependency and the whole cycle starts all over again.

Red Carpet eliminates this frustration. Red Carpet is always installed with NNLS. The rcd daemon is automatically configured during installation to Novell's Red Carpet server.

Let's take a look at the various pieces that comprise the Red Carpet product and how they work together to provide automated updates.

Components That Comprise Red Carpet

The Red Carpet component of NNLS is composed of the following elements:

  • Update files in the form of RPM packages.

  • Red Carpet channels. A channel is a group of software packages. Channels are usually defined according to criteria such as Linux distribution or product. For example, Novell offers an NNLS channel. You can also subscribe to channels for Red Hat Linux or SUSE Linux.

  • The Red Carpet daemon (rcd). The rcd daemon is responsible for installing updates on your local Linux system. The rcd daemon is configured and managed using the rug utility. Red Carpet also includes a plug-in that allows you to manage the rcd daemon in a web-based interface using iManager.

Let's discuss how to configure and use Red Carpet.

Configuring Red Carpet

As mentioned earlier, there are two ways to configure the rcd daemon that is installed by NNLS: the rug command-line utility and iManager.

If you choose to use rug, be aware that it operates on a per-server basis. If you want to manage rcd updates on multiple servers, you need to use iManager.

Tip

For the CLE certification, you don't need to know how to use rug.

There's a great deal of power in being able to manage updates on groups of servers. For this reason, the CLE designers chose to focus on iManager instead of rug. That's the focus we're going to take in this book. The first task we're going to discuss is creating RCD Groups.

Creating RCD Groups

When you create an RCD Group, you first create a special group object in eDirectory and then create the NNLS server you want to update members of the group. To do this, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Under Resource Management, select Create RCD Group. The screen shown in Figure 5.15 appears.

    Figure 5.15. Creating an RCD Group object.

  4. In the RCD Group Name field, enter a name for your group object.

  5. In the Context field, enter the context in the eDirectory tree where you want the group object to reside. This can be any location you wish in the tree.

    Warning

    If you're new to eDirectory and are confused by the terms object and context, just hold tight. In the last part of this chapter we're going to discuss eDirectory concepts in depth.

  6. Click OK to create the object.

  7. When prompted that the object was created, click OK.

With the object created, now you need to populate the group with NNLS server objects that currently exist in the tree. To do this, you have to do the following:

  1. In iManager, select the Modify RCD Group link under Resource Management.

  2. When prompted, browse to and select the RCD Group object you just created and then click OK. The screen shown in Figure 5.16 appears.

    Figure 5.16. Modifying an RCD Group object.

  3. Select New under the Device List heading.

  4. Select NCP Server. An NCP server is any server that has eDirectory installed and is in your tree. You could also select a standalone Linux server in your network that has Red Carpet installed, but doesn't have eDirectory installed, by selecting Red Carpet Daemon instead of NCP Server.

  5. Click OK.

  6. When prompted, browse to and select the NNLS server you want to make a member of the RCD Group; then click OK. In Figure 5.17, the CLE1 server has been added to the RCD Group. You can repeat this step as many times as necessary to populate the group object with servers.

    Figure 5.17. Populated RCD Group object.

  7. When you've finished adding servers to the group, click Done.

Remember that you can create multiple RCD Group objects and populate them with servers according to function, distribution, geography, or any other criteria. For example, you could create an RCD Group for all your Red Hat servers and another RCD Group for all your SLES 8 servers.

With your RCD Group object created and populated, you next need to configure product updates.

Managing NNLS Product Updates

As with creating the RCD Group object, you manage rcd product updates with iManager. This is done by completing the following steps:

  1. In iManager, select Manage RCD Group under Resource Management.

  2. Browse to and select the group you just created.

  3. Select Get Devices. The NNLS servers in the group are displayed in the Device List field, as shown in Figure 5.18.

    Figure 5.18. Managing an RCD Group object.

  4. Click OK. The screen in Figure 5.19 is displayed.

    Figure 5.19. Managing updates.

Notice the three tabs shown in Figure 5.19: Software, Channels, and Preferences. Let's quickly review the function of each tab.

The Software Tab

The Software tab allows you to view the following options:

  • Updates— This option, shown in Figure 5.19, displays the updates that are currently available. Notice that an Importance option is available that helps you determine how critical the update displayed is. If you scroll to the right, you'll notice that the New Version and Current Version columns are displayed. These allow you to compare the version number of the update with the version number of the currently installed package. You can deploy an update from this screen by marking the desired packages and then selecting Update.

  • Installed— This option, shown in Figure 5.20, displays packages that have already been installed on the servers in the group. If you wish to remove a package, simply mark it and then click Remove.

    Figure 5.20. Installed packages.

  • Available— This option, shown in Figure 5.21, displays packages that are available for installation on the servers in the RCD Group. To install a package, mark it in the list displayed and click Install.

    Figure 5.21. Available packages.

  • Search— This option, shown in Figure 5.22, allows you to locate a specific package in any rcd channel.

    Figure 5.22. Searching for packages.

  • History— This option displays a list of packages that have been installed or removed.

Now lets look at the Channels tab.

The Channels Tab

The Channels tab, shown in Figure 5.23, allows you to subscribe to the channels you need to keep your software up to date.

Figure 5.23. The Channels tab.

To subscribe to a channel, mark it and then click OK. Let's now turn our attention to the Preferences tab.

The Preferences Tab

The Preferences tab allows you to manage and configure your rcd settings. The changes you make in these screens apply to all NNLS servers that are members of the RCD Group. The following options are available:

  • General— This option, shown in Figure 5.24, allows you to configure the URL of the Red Carpet server from which the rcd daemons on your servers will download their updates. For NNLS servers, you should use the URL currently configured.

    Figure 5.24. General options.

  • Cache— The rcd daemon, by default, keeps the updates it downloads in a cache. This allows you to easily restart or resume a failed or interrupted installation without having to re-download the entire package. The cache options page, shown in Figure 5.25, allows you to configure where these updates are stored as well as an interval for emptying the cache.

    Figure 5.25. Caching options.

  • Advanced— The advanced options page, shown in Figure 5.26, allows you to configure various rcd parameters, such as the refresh interval, logging level, and notice messages. It also provides you with the ability to remotely shut down or restart the NNLS servers that are members of the RCD Group.

    Figure 5.26. Advanced options.

  • Activate— The activate options page is used to activate your premium Red Carpet Express service, if you choose to purchase it.

Let's practice using rcd by completing Lab Exercise 5.4.


Lab Exercise 5.4: Updating NNLS with rcd

In this lab, you're going to install an update using rcd on your server.

Warning

As with the previous exercises in this chapter, this exercise requires that your server have access to the Internet. If you installed NNLS without an Internet connection established, you will need to use the NNLS installation script to uninstall the Red Carpet component. Then establish your Internet connection and reinstall Red Carpet.

To install an NNLS update, complete the following steps:

  1. If necessary, authenticate to your Linux server as your student user with a password of novell.

  2. Launch a web browser by selecting the Mozilla icon on your desktop and open https://your_server's_IP_address/nps/iManager.html.

    Tip

    You can do this from either your server desktop or from a remote workstation.

  3. In the Username field, enter admin.

  4. In the password field, enter novell; then click Login.

  5. If prompted, accept the security certificates issued by your server.

  6. Under Roles and Tasks, scroll down to Resource Management.

  7. Create an RCD Group by completing the following steps:

    1. Select Create RCD Group.

    2. In the RCD Group Name field, enter NNLSUpdates.

    3. In the Context field, browse to and select IF.CLE; then click OK.

    4. When prompted that the group was created, click OK.

  8. Populate the RCD Group with your NNLS server by completing the following steps:

    1. Under Resource Management, select Modify RCD Group.

    2. In the RCD Group Name field, browse to and select the NNLSUpdates.IF.CLE RCD group, if it isn't already specified.

    3. Click OK.

    4. Under Device List, select New.

    5. In the New Device dialog, mark NCP Server; then click OK.

    6. In the Name field, browse to and select CLE1.IF.CLE; then click OK.

    7. Click Done.

  9. Download an update for the NNLS Tomcat service on your server by completing the following steps:

    Warning

    The packages specified in this exercise were available at the time this book was written. If you find that availability has changed when you perform these steps, feel free to select a different update. If you do, however, there's a chance that exercise steps in later labs in this book may not match up with the screens you see on your server.

    1. Under Resource Management, select Manage RCD Group.

    2. In the Manage RCD Group screen, make sure your NNLSUpdates.IF.CLE RCD Group is in the RCD Group Name field; then click OK.

    3. In the Software-Updates tab, scroll down to and mark the novell-tomcat4 update.

    4. Click Update.

    5. In the Packages to be Installed screen, click OK.

    6. Wait while the package is downloaded.

    7. When prompted that the update has been installed, select the History link.

    8. Verify that the update was installed. You should see an entry similar to that shown in Figure 5.27.

      Figure 5.27. Successful Red Carpet update.

That's it! You now have a fully functioning NNLS system and you know how to use Red Carpet to download and apply updates to your system. You'll spend the rest of this chapter learning how to administer the eDirectory service that was installed on your system.


Managing eDirectory

Test Objectives Covered:

3. Describe the purpose of eDirectory.

4. Describe how eDirectory works.

5. Perform eDirectory administration tasks.

6. Manage User objects with iManager.

Up to this point, we've briefly brushed up against the topic of eDirectory several times. Each time I've said, "Don't worry, we'll discuss this in detail later." Fortunately, later is finally here. It's time to talk eDirectory.

It is absolutely critical that you master the concepts and skills presented in this part of this chapter. As we will discuss in a minute, eDirectory is the backbone of NNLS. If you don't understand eDirectory, you won't be able to manage an NNLS system effectively.

Even if you are already familiar with eDirectory, I would strongly suggest that you read this content anyway. Chances are you learned eDirectory (or its predecessor Novell Directory Services) on the NetWare platform. Most of the concepts are the same with eDirectory on Linux. There are, however, some key differences that can trip you up if you're not aware of them.

Without any more delay, let's dig into the world of eDirectory.

What Is a Directory Anyway?

If you're new to eDirectory, you may be asking, "What's this directory thing all about, anyway?" If you learned to manage user accounts using Windows NT domains or Linux passwd files, you'll be surprised at what you can do with directory services.

Essentially, a directory service is a hierarchical database that is used to store information about network resources.

Note

The directory services we are discussing here are those that are based on the X.500 directory service standard. You may hear these types of directories referred to as full-service directories. Many software vendors over the years have tried to pass off their flat-file user databases as "directories."

The first time I heard the term directory back in the mid-1990s, the image of a phone book came to my mind. That analogy isn't far off. A full-service directory, however, can store more than just user information.

Let's take a few steps back into history. Recall that in an earlier chapter I related a story about my first networking job where I was responsible for an organization's NetWare 3 network.

NetWare 3 (and earlier versions of NetWare as well) used a flat-file database called the bindery to store user accounts and groups. Each server in my network had its own bindery. My organization had about 1200 users, each with his or her own account. Each needed access to resources hosted by each of the NetWare servers I was responsible for.

That required me to keep the user accounts and passwords synchronized on all servers in the organization. Needless to say, for the first couple of months on the job, that's about all I did. My users simply expected to have a single password to access all network resources.

If they changed their password in one bindery user account, they expected that password to work when accessing other servers in the network. Eventually, that would be so, but only after I fielded their complaint and manually changed the account information on the other servers.

After a couple of months, I became very annoyed with the situation and wrote some nifty little programs that could be used to synchronize accounts between servers; but it was still a manual process. If I forgot to run them, the accounts would quickly go out of sync and the help desk calls would start rolling in.

This situation also presented a problem when a new individual would join or leave the organization. I had to either create multiple accounts or delete multiple accounts on all the servers.

In addition, each version of the user's account had different trustee assignments and login scripts. Talk about job security.

If you've ever managed a Linux network that employed multiple servers, you've faced a similar issue. Remember that Linux users and groups are local to the server. To get around this, many Linux administrators employ the NIS+ service, which synchronizes user accounts among Linux servers.

eDirectory changes all that. With this service, all the servers on your network are installed into the eDirectory tree. User accounts are also created in the tree. Users have one single account that gives them access to network resources.

Instead of logging in to a specific server, users authenticate to the eDirectory tree. From there, they can access any network data or resource they have been granted access to, regardless of what server is hosting the resource.

In addition, applications can be easily written that access directory information. As you will see later in this book, all NNLS components do just that. They use eDirectory information to control access, display information, and provide services.

eDirectory fills the following primary roles:

  • Storing network data in a central repository

  • Organizing network data into a logical structure

  • Providing standardized methods for accessing network data

  • Controlling access to network data

  • Securing network data

Let's now discuss how eDirectory works.

How eDirectory Works

When discussing how eDirectory works, we're going to stay at the conceptual level. Recently, I had the opportunity to spend time with the software developers at Novell who actually wrote the eDirectory code, learning about the inner workings of the product. My head was swimming after only a few minutes (and I had considered myself an eDirectory veteran!). We will discuss the following topics:

  • The structure of the eDirectory tree

  • How eDirectory naming conventions work

  • How eDirectory rights work

  • How eDirectory embraces the Lightweight Directory Access Protocol(LDAP) standard

The Structure of the eDirectory Tree

Recall that I mentioned earlier that eDirectory is a hierarchical database. Before discussing what this is, let's talk about what it is not.

Windows NT domains, the Linux passwd file, and NetWare binderies are all considered flat-file databases (that is, nonhierarchical). This is because entries in these databases can't contain other database entries.

Many new to directory services contend that this isn't entirely true because, they argue, groups in these databases are composed of user accounts. This isn't correct. A group in one of these databases has users who are members of the group. The actual user account itself resides outside the group; user accounts aren't actually contained within the group.

The hierarchical eDirectory database, on the other hand, handles things in a very different manner. You must first understand that entries in the eDirectory database are called objects. There are two general categories of objects within the database:

  • Container objects— Container objects can contain other database objects. To draw a simple comparison, container objects are similar to directories within a file system. File system directories can contain files or other directories.

    Likewise, an eDirectory container object can contain other container objects, or leaf objects. Container objects are used to organize directory data. Container objects can be used to organize data by geographical location, business unit, or organizational function.

  • Leaf objects— Leaf objects represent network resources in the eDirectory database. These can be physical resources, such as users, printers, and servers. Or, they can be logical network resources such as groups, profiles, and templates.

    Carrying on the analogy started earlier, leaf objects are similar to files within the file system. In the file system, files contain real data. Files can't contain directories or other files.

    Likewise, leaf objects in the eDirectory database can't contain any other objects.

All eDirectory objects, both container and leaf, are contained within the eDirectory tree. Each eDirectory tree has a set of rules that defines the types of objects that can exist in the tree and where they can reside. This set of rules is called the schema. A very simple eDirectory tree is shown in Figure 5.28.

Figure 5.28. eDirectory tree.

Figure 5.28 depicts the eDirectory tree you installed in an earlier lab exercise. Notice that the name of the eDirectory tree is CLE-TREE. The tree is the topmost container in the hierarchy. Within the tree is a container object called CLE. Inside of CLE is another container object named IF. Within IF are several leaf objects, including the admin user object and the RCD Group object you created.

This brings up an issue that I've observed over the years. Because many network administrators who move to eDirectory come from a Windows NT, NetWare bindery, or Linux/Unix passwd file background, they make a key error when installing eDirectory.

Generally speaking, an organization should have one eDirectory tree. Because of their previous experience with these other flat-file databases, however, administrators install each eDirectory server in their organization into its own tree.

A Novell technical support engineer once related to me an instance when she received a support call from an individual who had made this very mistake. After asking several exploratory questions trying to discern the customer's problem, she discovered that the administrator had more than 50 eDirectory servers in his network and had installed each one into its own tree.

If you do this, you're stuck with a system that isn't much better than the flat-file database systems you migrated from. Each tree operates completely independent of the other trees in your network. Remember that you can (and should) install all your servers into the same eDirectory tree.

You've probably noticed in Figure 5.28 that the icons representing the CLE and the IF containers are different. That's because they represent different types of container objects. In eDirectory, there are three types of containers within the tree container:

  • Country object— Country objects can only reside at the top of the tree, directly within the tree object itself. Country objects can only contain Organization objects or alias objects. Country objects can only be named using standardized two-character country abbreviations, such as US, FR, and UK.

    Use of Country objects is optional. Notice that we didn't use a Country object in the eDirectory tree we configured when we installed NNLS.

  • Organization object— Organization objects can reside only within tree objects or within Country objects. Organization objects can contain any other eDirectory objects, except for Country objects and other Organization objects. They can contain Organizational Unit objects and any leaf objects defined in the tree's schema.

    Notice in the tree you installed that the CLE container is an Organization object.

  • Organizational Unit object— Organizational Unit objects are container objects that can reside only with Organization objects or other Organizational Unit objects. Organizational Unit objects can contain any other objects defined in the eDirectory schema, except for Country and Organization objects. They can even contain other Organizational Unit objects.

Given the rules associated with these objects, a couple of standard tree designs are frequently used by eDirectory implementers. The first, and most common, is the one you used to create your eDirectory tree. Beneath the tree are one or more Organization objects.

Within each Organization object are one or more Organizational Unit objects, each containing the various leaf objects that comprise the tree as well as other Organizational Unit objects.

You could also design your tree such that you have one or more Country objects directly beneath the tree object. Within each Country object are Organization objects that each contain Organizational Unit objects.

You could also design your tree such that you have one or more Organization objects at the root of the tree that each contain leaf objects.

Which is the best design? That's a very subjective question. The design that works best for your organization may not work well at all for a different organization. There are some general rules you should adhere to when designing your eDirectory tree.

First, you should organize the upper layers of the tree by geography, business unit, division, or some other organizational criteria. For example, if your organization has offices in Denver, Boise, and Annapolis, you could create Organization objects at the top of your tree for each location.

If your organization has offices in several countries, you could create Country objects at the top of your eDirectory tree that represents each one.

You don't have to use geography to design the top layer of your tree. You could also use logical criteria, such as a business unit or function. For example, if your company resides in a single location, but has five different business units, you could create five Organizational Units at the top of your tree.

This is the metaphor we used when we installed our tree. Notice that our topmost container is an Organization named CLE. Our topmost layer is organized by certification type. Using this standard, we could expand our tree to include Organizations for CNE, CNA, and LPI, for example.

Once you have the top layers of your tree designed, you need to design the lower layers of your tree. As with the upper layers of the tree, you should use some organizational criteria to design the lower layers of the tree. These criteria could be business function, geographic location, or business unit.

In our eDirectory tree, we chose to organize the lower layers of our tree by geography. Our only Organizational Unit is IF, which represents the city of Idaho Falls, Idaho. As we go through this book, we will add more Organizational Units representing geographical locations.

A full review of all the eDirectory design rules and guidelines is beyond the scope of this book. If you follow the basic rules presented here, though, you'll be in good shape.

As mentioned earlier, eDirectory also uses leaf objects in addition to container objects. There are a multitude of different types of leaf objects in a typical eDirectory tree. We don't have the time or space to review them all here. We will, however, discuss some of the most commonly used types:

  • User objects— User objects are perhaps the most commonly used type of eDirectory object. A user object represents a user in the tree. Users use these objects to authenticate to the tree. Access to network resources is controlled by the rights you grant to these objects.

  • Group objects— Group objects are special objects you can populate with user objects. Group objects help make the administration of your tree much easier. Suppose you have 150 users who all need exactly the same access to the same network resources. Without group objects, you would have to manually configure rights assignments for each and every user object.

    By making these 150 users members of a single group object, however, you can assign rights to the group object. The users who are members of the group automatically receive the rights that have been assigned. Managing one set of assignments is much easier than managing 150.

  • Template objects— The standard eDirectory schema includes a template object. Template objects make the process of adding new users more efficient. You add information that is common to all users to the template object.

    This could include information such as business address and fax number. Then, when you create a new user, you associate it with the template object, which automatically populates the new user object with this information, which saves you a lot of typing.

  • Organizational role objects— Organizational role objects are very useful. To understand how these objects work, consider the following: Suppose you need to delegate some administrative authority to a user in your eDirectory tree. You want this individual to be able to add new users to the tree when they are hired.

    One option you have would be to assign the necessary rights to the user you want to delegate this authority to. But suppose this user were to move somewhere else within the organization. You would have to remember to unassign the rights you gave him or her and reassign them to someone else.

    Organizational role objects make this much easier. Instead of assigning rights to the user object, you assign the necessary rights to an organizational role object. Then you make the user you want to delegate authority to an occupant of that role.

    When you do this, the user automatically receives the rights assigned to the organizational role object. If you need to change the delegation to a different employee, you simply remove the previous occupant from the role and add the new user.

  • Alias objects— Alias objects are similar to shortcut files on a Windows system or link files on a Linux system. Both of these files serve as pointers to a resource somewhere else in the file system. The pointer files themselves contain very little information.

    Alias objects in the eDirectory tree work in much the same manner. They are placeholders that point to an object somewhere else in the tree. They are frequently used for user objects.

    Suppose you have a user named LMorgan. Her user object resides in .IF.CLE. She has recently been promoted and has moved to an office in Salt Lake City, Utah. You moved her user object to .SLC.CLE. However, she keeps trying to authenticate to the tree as LMorgan.IF.CLE. If you were to create an alias object for LMorgan in the IF.CLE container that pointed to her user object in its new location, she would be able to log in.

  • Server objects— Server objects represent eDirectory servers that have been installed into the tree. Notice in Figure 5.28 that the CLE1 server we installed has an object in the tree.

  • Printer objects— Printer objects represent a physical printer in the network.

There are a multitude of other types of eDirectory objects, such as LDAP objects, SAS object, KMO objects, SSL objects, license objects, and so on. We're not going to cover them here. If you happen upon an object that you're just dying to learn more about, check out the eDirectory 8.7.3 documentation available at http://www.novell.com.

eDirectory Naming Conventions

If you're new to eDirectory, you're probably scratching your head over the way we're referencing eDirectory objects. For example, we used the object names LMorgan.IF.CLE and CN=admin.OU=IF.O=CLE. Let's review what all this means. We'll start with the concept of context.

eDirectory Contexts

The term context simply refers to the object's location in the tree. It is the list of container objects that contain the object in question.

Context is very similar to the concept of full path in the Linux file system. For example, the full path to the slpd init script in your Linux file system is /etc/init.d/. The full path is simply the list of directories in order, starting at the root directory, that contains the particular file. In this example, slpd exists in the init.d directory, which exists within the etc directory. The etc directory itself resides in the root directory (/).

eDirectory objects are referenced in the same way. The difference is in the direction of the path. In the Linux file system, you start with the root directory on the left side and drill down to the file moving to the right. eDirectory object context moves in the opposite direction.

Let's look at the admin.IF.CLE object (refer to Figure 5.28). The LMorgan object resides in the IF container, which resides in the CLE container. Containers are separated by a period (.).

One nice feature of eDirectory is the fact that object names and contexts aren't case-sensitive. The name lmorgan.if.cle is considered to be exactly the same as LMORGAN.IF.CLE.

Now let's look at typeful and typeless naming.

Typeful and Typeless Naming

There are two ways to refer to eDirectory objects. One is referred to as typeful and the other as typeless.

Remember when you were installing NNLS and were asked to provide the name of your tree's admin user? You were directed to enter CN=admin.OU=IF.O=CLE. This is an example of typeful naming.

Typeful naming requires you to specify the type of object in the name. All leaf objects have a typeful designator of CN=. Organizational Unit objects have a typeful designator of OU=. Organization objects have a typeful designator of O=. Country objects (which aren't used very often) have a typeful designator of C=.

Suppose you created a group object named Engineers in the SLC.CLE context. It's typeful name would be CN=Engineers.OU=SLC.O=CLE.

If you were to use typeless naming, you would refer to this object simply as Engineers.SLC.CLE. This is pretty easy stuff so far. Now it's time to confuse you with relative and distinguished names.

Relative vs. Distinguished Names

I've been teaching eDirectory since the mid-1990s (back then it was called NDS), and one of the hardest concepts for new eDirectory administrators to grasp is the concepts of relative and distinguished names.

To understand these concepts, you must first understand the notion of current context. The easiest way to understand this idea is to compare it to current context as implemented in the Linux file system. If you were to use the cd command to change to the /etc directory, your file system current context is /etc. It's where you are currently "at" in the hierarchical directory structure.

It works the same way in the eDirectory tree. Your current context is where you are "at" in the tree.

With that in mind, let's talk about distinguished names in the tree. A distinguished name lists the object name and its context all the way back to the root of the tree. Distinguished names always begin with a period (.).

For example, the distinguished name of the admin user in the eDirectory tree you just installed is .admin.IF.CLE. This name begins with a period, then it lists the name of the object itself (admin) and then provides the context of the object up to the root of the tree (.IF.CLE).

This is what constitutes a distinguished name. A typeful distinguished name adds the type designations to the distinguished name. For example, .CN=admin.OU=IF.O=CLE is the typeful distinguished name for your admin user object.

A relative name, on the other hand, is the name of the object concatenated with the containers it resides in up to the current context instead of the root of the tree. Relative names do not begin with a period.

For example, if your current eDirectory context is .IF.CLE, the relative name of your admin user is simply admin. That's because it resides within the current context.

Suppose, however, that the current eDirectory context is now .CLE. The relative name for your admin object is the name of the object (admin) plus the containers the object resides in up to the current context (.IF). Therefore, if your current context is CLE, your admin user object's relative name is admin.IF.

As with distinguished names, relative names can be typeful or typeless. The relative name admin.IF is an example of a typeless relative name. The typeful version of this relative name is CN=admin.OU=IF. Remember that relative names do not begin with a period, whereas distinguished names do.

With that we're ready to move on to a discussion of eDirectory rights.

Working with eDirectory Rights

Earlier I mentioned that one of the key roles of eDirectory was to control access to network resources. Assigning eDirectory rights does this.

eDirectory rights are similar in some ways to Linux file and directory permissions. Permissions specify what specific users and groups can do with a file or directory in the file system.

eDirectory rights specify what one object in the tree can do to another. When one object is granted rights to another object, the first object is said to be a trustee of the second. For example, if you were to grant LMorgan rights to the Engineers group object, the LMorgan user object becomes a trustee of the Engineers object. eDirectory rights include the following:

  • Supervisor— The supervisor right grants all rights to the trustee. The trustee can create, delete, or modify the object. This is a very powerful right and is assigned only on very rare occasions.

  • Browse— The browse right allows the trustee to see the object in the tree.

  • Create— When a trustee of a container object is assigned the create right, the trustee can create new objects in the container. You can't assign the create right to a trustee of a leaf object.

  • Rename— This right allows a trustee to modify the name of an object.

  • Delete— This right allows a trustee to delete an object.

Tip

Object rights are also referred to as entry rights. Older versions of eDirectory use the former term; later versions use the latter.

There's also a second set of rights you can manage in eDirectory. These are called property rights.

Tip

Property rights are also referred to as attribute rights.

To understand property rights, you need to understand that every eDirectory object has properties. Each property, in turn, has at least one value. For example, a user object has properties such as First Name, Last Name, Title, Location, Phone Number, Fax Number, Address, and so on.

Object rights specify how a trustee can manipulate the actual objects. Property rights specify what the trustee can do with the values of the object's properties.

For example, you could grant your organization's administrative assistant rights to modify user objects' Phone Number, Fax Number, and Address properties.

The following are the property rights that can be assigned to trustees:

  • Supervisor— The supervisor property right allows the trustee full access to the specified property.

  • Compare— The compare property right allows the trustee to query the value of the specified property using a Boolean expression. For example, you could query the object to see if its phone number value is equal to 555-555-5555. The compare right only returns a TRUE or FALSE response. The compare right doesn't allow you to see the actual value of the property.

  • Read— The read property right allows the trustee to view the value of the specified property. It doesn't allow the trustee to modify the property in any way.

  • Write— The write property right allows the trustee to modify the value of the specified property.

  • Add Self— The add self property right is an interesting one. It allows the trustee limited access to the value of a property. It only allows the trustee to set the value of the specified property to the name of the trustee object (hence the term add self).

There's one more key aspect of eDirectory rights that you need to understand: inheritance.

Managing Inheritance

It is vital that you understand that eDirectory rights, by default, flow down the tree in what is called inheritance. The best way to understand inheritance is through an example.

Suppose your organization has grown very large and you need help managing the eDirectory tree. You decide to grant user LMorgan.IF.CLE the browse, create, and rename rights to the CLE container in your tree so she can create, delete, and modify objects in the tree.

The rights assignment you made to the CLE container flow down the tree to objects beneath CLE in the hierarchy. In other words, LMorgan.IF.CLE receives rights to all other objects below CLE through inheritance. For example, if there is a user object named VHammer in the SLC.CLE context, LMorgan.IF.CLE has browse, create, and rename rights to the VHammer.SLC.CLE object, even though she hasn't been explicitly granted rights to it.

Rights that a trustee receives to an object through inheritance and not through an explicit rights assignment are called effective rights.

This is how your admin object receives rights to the entire eDirectory tree. Consider Figure 5.29.

Figure 5.29. Admin as a trustee of the tree object.

During installation of NNLS, your admin user object was made a trustee of the tree object and granted supervisor rights. This assignment flows down the tree to all subcontainers and leaf objects within those containers.

This allows the admin user object to have supervisor effective rights to the entire eDirectory tree.

This concept of inheritance is also used with the [Public] account. [Public] is not a user object. It's an account that provides guest access to the eDirectory tree. Notice in Figure 5.30 that [Public] has been granted the browse right to the tree object.

Figure 5.30. [Public] rights to the tree.

Because [Public] is a guest user account that doesn't require authentication, this rights assignment allows unauthenticated users to browse the tree. It doesn't allow them to log in or to modify data in the tree any way. This feature is used by eDirectory client workstations during login. Users can browse the tree to find their context and their server objects so they can log in.

The concept of inheritance in an eDirectory tree makes managing the tree much easier. Imagine how much work it would take if you had to make explicit rights assignments to every object every time you wanted to make a trustee assignment.

There may be times, however, when you don't want these rights to flow down the tree. Going back to the previous example, remember that we granted LMorgan.IF.CLE browse, create, and rename rights to the CLE container in our tree. Suppose that within the IF container is a container named Finance, where your organization's financial officers' user objects reside. For security reasons, you don't want LMorgan.IF.CLE to have rights other than the browse right to this container.

With eDirectory, you can block inheritance. This is done in two ways, the first of which is to make an explicit rights assignment at the level where you want the inheritance to end. Consider Figure 5.31.

Figure 5.31. Blocking rights with an explicit rights assignment.

Here, LMorgan.IF.CLE has been made a trustee of the Finance Organizational Unit object and has been granted only the browse right to it. This explicit assignment overwrites and blocks the rights LMorgan.IF.CLE received to the container through inheritance.

Inherited rights can also be blocked using an Inherited Rights Filter (IRF). IRFs are used to block specific rights from being inherited by a given object. Consider Figure 5.32.

Figure 5.32. Implementing IRFs.

In Figure 5.32, an IRF has been placed on the Finance container object. Rights that have a check mark next to them are allowed to flow through and be inherited. Rights that are not marked are blocked and are not inherited. IRFs have no impact on rights that are explicitly granted to a trustee.

For example, if you were to grant a different user object browse, create, and rename rights to the Finance container, he or she would have received those rights in spite of the IRF. IRFs only affect rights that are inherited from somewhere above in the tree hierarchy.

IRFs must be used with caution. Imagine what would happen if you were to block all the rights to the given container and there wasn't anyone else in the tree who had explicit assignment to the container: all access for everyone, including admin, would be cut off.

In the "old days" of NDS, the administrative tools in use at the time would allow you to do just that. Every now and then, you would hear horror stories about someone cutting off an entire branch of the eDirectory with an IRF, and he or she couldn't get it back.

Today, if you try to do this with a utility such as iManager, you will get a nasty warning indicating that if you implement the IRF, there's no one else in the tree who will be able to access the container.

You've just been given a crash course into the basics of eDirectory. As with Chapters 2 and 3, you've been given just enough to get you going.

Now, we're now going to change course and discuss two deeper eDirectory concepts: partitioning and replication.

Managing eDirectory Partitioning and Replication

To understand eDirectory partitioning and replication, you must first realize that eDirectory is a distributed and replicated database. This is probably very different from other types of databases you have used in the past. It's definitely different from the way Linux and Windows NT user accounts are managed.

The eDirectory database can be run on a single server, but it doesn't necessarily have to be. It can be distributed among several servers. This is what happens when a server is installed into the eDirectory tree.

The eDirectory tree can also be partitioned. Like the concept of relative naming mentioned earlier, partitioning is one of the hardest concepts for new eDirectory administrators to understand.

Essentially, partitioning allows you to divide the database into several parts, each called a partition. The partitions are created logically in the tree at the container level. The topmost container in a partition is called the partition root.

Consider the tree we installed when we implemented NNLS. We could potentially create a partition at three different levels in the tree—one at the tree root, one at the CLE Organization object level, and one at the IF Organizational Unit level.

Each partition can be placed on a different server in the eDirectory tree. The reason for doing this is performance. Imagine what would happen if you had a huge network with users all around the world. If eDirectory ran on a single server, every user would have to access that server every time he or she wanted to log in or use a network resource. Remote users would have to consume expensive WAN bandwidth to do this.

With partitioning, you can divide the eDirectory database into several parts and place those parts on different servers. This distributes the load among those servers, improving performance. It also allows you to place partitions on local servers containing the data that the users in a given location need.

For example, if your organization has offices in Denver, Boise, and Annapolis, you could place partitions of your eDirectory tree containing Boise-specific users and data on a server in Boise (and likewise for Denver and Annapolis). Then, when users need to log in or use a network resource, they don't have to cross WAN links. The information they need is local to them.

You also need to understand parent and child relationships in partitioning. Referring to our previous example, we could potentially create three partitions in the tree we configured earlier. Notice that the partitions exist in a hierarchical fashion; the tree root partition, at the top of the eDirectory tree, has two partitions below it—one at the CLE container level and one at the IF container level.

In this situation, the tree root partition is said to be a "parent" of the CLE partition because it resides higher in the tree hierarchy. The CLE partition is said to be a "child partition" of the root partition. Likewise, the CLE partition is the parent of the IF partition and the IF partition is a child of the CLE partition.

In eDirectory, parent/child relationships only go up or down one level, so the IF partition is not a child, or grandchild, of the tree root partition.

The first time I learned about partitioning back in the early 1990s, it scared me to death. I had some experience with hardware crashes, and the thought of taking a database and dividing it up among several servers made me cringe. What if one of the servers went down? The whole database could end up getting corrupted because a chunk of it would disappear.

Novell wisely accommodates for this reality. In addition to dividing up the eDirectory database into partitions, you can also place multiple copies of each partition on different servers. Each copy is called a replica.

eDirectory is designed such that changes made by an administrator (changing a password, for example) to one replica are quickly replicated to all the other replicas of that partition. All the servers that host a replica of a given partition are said to be members of the replica ring. Each replica has an attribute called Replica. This attribute contains a list of all the other servers in the replica ring for the given partition.

eDirectory uses this to make sure the data in all replicas of a given partition is always synchronized so that no matter what replica is used for a given network action, the data is always up to date.

For any given partition, four different types of replicas can be placed on servers in the tree:

  • Master replica— The Master replica is created when a partition is defined. There can be only one Master replica per partition. As you can see in Figure 5.33, one partition was automatically created when you installed eDirectory that encompasses the whole tree. By default, your CLE1 server had a Master replica of the partition placed on it.

    Figure 5.33. Default partitioning and replication.

    Because CLE1 is the only server in the tree, there is only one replica of the partition. All major partition operations, such as moves, merges, and creates, must be initiated from the Master replica.

  • Read/Write replica— Read/Write replicas are exact copies of the Master replica. Read/Write replicas can be used to authenticate to the tree and make changes to objects in the tree. The changes made are synchronized around to the other replicas of the partition, including the Master replica.

    You can create as many Read/Write replicas of a partition as you wish. Novell recommends, however, that you don't create more than about 10 in order to keep the synchronization traffic on your network to a minimum.

    Read/Write partitions can be configured as Filtered replicas. In a regular Read/Write partition, all data from the Master replica is synchronized. In a Filtered replica, you configure replication such that only specific data is replicated from the Master. For example, you may want a partition to only contain user objects. You can configure a filter on the replica that prevents anything, except for user objects, from being copied to the Filtered replica.

  • Read-Only replica— Read-Only replicas are just like Read/Write replicas, except for the fact that they can't be used to make changes to the objects in the tree. That's because they can only receive updates from the Master replica; they can't send them. Read-Only replicas aren't used very often. As with Read/Write replicas, you can create Filtered Read-Only replicas. They aren't all that useful, however—I've never actually seen anyone use one.

  • Subordinate Reference— The Subordinate Reference (SR) is a tricky entity to understand. SRs aren't really replicas. They contain no partition data. They are really more of a shortcut or a pointer that provides a reference to the location where the real data can be found.

    SRs are automatically created. You can't create them yourself. They are only created when a replica of a partition exists on a given server and that partition has one or more child partitions, but the server does not have a replica of those child partitions. The SR simply points to the servers where a real replica of the child partitions are placed.

The advantages to this partitioning and replication scheme are considerable. The partition aspect distributes the load among several servers, dramatically improving network performance. Replication ensures that multiple copies of each partition are placed on multiple servers in the network.

If one server goes down, the other servers holding replicas of the partition it contains automatically step in and service any network requests. The end user is able to keep working as though nothing happened.

Let's practice working with basic eDirectory concepts in Lab Exercise 5.5.


Lab Exercise 5.5: Managing eDirectory

In this lab, you're going to practice creating, deleting, and modifying eDirectory objects as well as working with eDirectory partitions. Complete the following:

  1. Start iManager by opening a web browser (using the Mozilla icon on your desktop) and navigating to https://your_server's_IP_address/nps/iManager.html.

  2. If prompted to accept a security certificate from your server, click OK.

  3. In the Username field, enter admin.

  4. In the password field, enter novell and then click Login.

  5. Create a new Organizational Unit in the CLE container by completing the following steps:

    1. Scroll down to eDirectory Administration and select Create Object.

    2. In the Available Object Classes field, scroll down to and select Organizational Unit and then click OK.

    3. In the Organizational Unit name field, enter SLC.

    4. In the Context field, enter CLE and then click OK.

    5. When prompted that the operation was successful, click OK.

    6. Verify that the object was created by selecting Modify Object.

    7. Next to the Object Name field, click the Browse button.

    8. Select Browse.

    9. Next to CLE, select the blue down arrow. You should see two containers listed: IF and SLC.

    10. Select Cancel, Cancel.

  6. Create a new user in the IF and SLC containers by completing the following steps:

    1. Select Create Object.

    2. In the Available Object Classes field, scroll down to and select User and then click OK.

    3. Enter the following information in the respective fields:

      • Username: CGrayson

      • First Name: Christopher

      • Last Name: Grayson

      • Context: IF.CLE

      • Password: novell

      • Title: Director

      • Location: Idaho Falls, Idaho Office

      • Department: Training

      • Telephone: 555-555-5555

      • Fax Number: 555-555-4444

      • E-mail Address: cgrayson@cle.com

    4. Select OK, OK.

    5. When prompted to convert the user to a LUM object, click Cancel.

    6. Repeat this process to create the following user:

      • Username: DCoughanour

      • First Name: Dave

      • Last Name: Coughanour

      • Context: SLC.CLE

      • Password: novell

      • Title: President

      • Location: Salt Lake City, Utah Office

      • Department: Executive Management

      • Telephone: 555-555-5555

      • Fax Number: 555-555-4444

      • E-mail Address: dcoughanour@cle.com

  7. Give CGrayson management rights to the IF container by completing the following steps:

    1. In iManager, scroll down to Rights and select Modify Trustees.

    2. In the Object Name field, enter IF.CLE and then click OK.

    3. Select Add Trustee.

    4. Select Browse.

    5. Browse to and select CGrayson.IF.CLE.

    6. Next to CGrayson.IF.CLE, select Assigned Rights.

    7. On the Entry Rights line, mark Browse, Create, Rename, Delete.

    8. Select Done, OK, OK.

  8. Verify that CGrayson.IF.CLE has the rights you assigned by completing the following steps:

    1. In iManager, select View Effective Rights.

    2. In the Trustee Name field, enter CGrayson.IF.CLE and then click OK.

    3. In the Object Name field, browse to and select IF.CLE.

    4. In the Property Name field, select Entry Rights. You should see Browse, Create, Rename, and Delete rights listed.

    5. In the Object Name field, browse to and select CLE.

    6. Select Entry Rights. CGrayson.IF.CLE should only have Browse rights to the CLE container.

    7. Click Done.

    Real World

    CGrayson.IF.CLE has the Browse right because every user in the tree is security equivalent to [Public]. Remember that [Public] has the Browse right to the root of the tree.

  9. Create an Organizational role and make Dcoughanour.SLC.CLE the role's occupant by completing the following steps:

    1. In iManager, select Create Object under eDirectory Administration.

    2. In the Available Object Classes field, select Organizational Role and then click OK.

    3. In the Organizational Role Name field, enter Manager.

    4. In the Context field, enter CLE and then select OK, OK.

    5. Select Modify Object.

    6. In the Object Name field, enter Manager.CLE and then click OK.

    7. In the drop-down list, select Role Occupant.

    8. In the Role Occupant field, browse to and select DCoughanour.SLC.CLE.

    9. Click OK.

  10. Grant Manager.CLE administrative rights to the CLE container by completing the following steps:

    1. In iManager, scroll down to Rights and select Modify Trustees.

    2. In the Object Name field, enter CLE and then click OK.

    3. Select Add Trustee.

    4. Select Browse.

    5. Browse to and select Manager.CLE.

    6. Next to Manager.CLE, select Assigned Rights.

    7. On the Entry Rights line, mark Browse, Create, Rename, Delete.

    8. Select Done, OK, OK.

  11. Verify that DCoughanour.SLC.CLE has the rights you assigned to Manager.CLE by completing the following steps:

    1. In iManager, select View Effective Rights.

    2. In the Trustee Name field, enter DCoughanour.SLC.CLE and then click OK.

    3. In the Object Name field, browse to and select CLE.

    4. Select Entry Rights. You should see Browse, Create, Rename, and Delete rights listed.

    5. In the Object Name field, browse to and select .CLE-TREE.

    6. Select Entry Rights. DCoughanour.SLC.CLE should only have Browse rights to the tree root.

    7. Repeat this process to check the effective rights DCoughanour has to the IF and SLC containers. He should have Browse, Create, Rename, and Delete rights to each.

    8. Click Done.

  12. Partition the eDirectory tree at the CLE, IF, and SLC levels by completing the following steps:

    1. Under Partitions and Replica Management, select Create Partition.

    2. In the Container field, enter CLE and then click OK.

    3. Wait while the process is completed.

    4. When prompted that the partition has been completed, select Repeat Task.

    5. Using the preceding steps, create a partition at the IF.CLE and SLC.CLE container levels.

  13. Verify that your partitions were made and that your server holds a Master replica of each by completing the following steps:

    1. In iManager, select View Partition Information.

    2. In the Partition field, select the Browse icon.

    3. Select Browse.

    4. Browse to and select the CLE partition.

    5. Click OK.

    6. Verify that the partition exists and that your server holds the Master replica.

    7. Repeat the preceding steps to check the IF.CLE and the SLC.CLE partitions.

    8. When you're done, click Close.

    9. Check your replica status by selecting Replica View.

    10. In the Partition or Server object, enter CLE1.IF.CLE and then click OK.

    11. You should see that your server has a Master replica of the four partitions in your tree: The tree root, CLE, IF.CLE, and SLC.CLE partitions. This is shown in Figure 5.34.

      Figure 5.34. Replica view.

      Warning

      If we had multiple servers in our tree, we could place additional replicas of each partition on them. However, because we only have a single-server tree, we must use the replication shown in Figure 5.34.

    12. Click Done.

That's it for this exercise. You learned how to create eDirectory objects, modify their properties, assign eDirectory rights, and partition the tree. Let's move on and discuss how eDirectory works with the Lightweight Directory Access Protocol (LDAP).


eDirectory and LDAP

Test Objectives Covered:

4. Describe how eDirectory works.

5. Perform eDirectory administration tasks.

The version of eDirectory that is installed with NNLS includes a very powerful LDAP server. LDAP is a set of standards that provides controlled access to the information stored in a directory such as eDirectory.

Before we go any further, we need to make some clarifications about the nature of LDAP. The concept of LDAP tends to confuse a lot of people, even those who have a lot of experience with directory services.

LDAP, as stated earlier, is a protocol that allows programmers to write applications that can read and write information to a directory service that complies with the X.500 directory standard (hence the name Lightweight Directory Access Protocol).

LDAP is not, as many think, a directory service in and of itself. The confusion comes because we use the term LDAP server frequently in the industry. A more correct term would be LDAP service. The LDAP server doesn't contain any information, such as containers or objects. It simply allows you to access information in an LDAP-compliant directory service, such an eDirectory. This is shown in Figure 5.35.

Figure 5.35. LDAP and the directory.

The goal behind the LDAP protocol is to provide a common way to access directory information. As shown in Figure 5.35, programmers can access system information in a directory with either the native directory access protocols established by the vendor with LDAP calls.

Without LDAP, programmers would have to learn a whole new API set for each directory service they needed to write applications for. With LDAP, they can learn a single set of protocols and use it with many different directory services.

Equating eDirectory and LDAP Terms

Another point of confusion for eDirectory administrators is the difference in terminology and naming conventions between eDirectory and LDAP. Let's review some of the most common:

  • In LDAP terms, an object is referred to as an entry or as a record.

  • Object properties are referred to as attributes.

  • eDirectory contexts are referred to as naming contexts.

  • eDirectory client connections are referred to as LDAP binds.

You also need to be aware of the differences in naming standards. Recall that eDirectory object names can be typeful or typeless, relative or distinguished. Using LDAP syntax, objects in the tree are always referenced using typeful distinguished names.

Another difference is the delimiter. With eDirectory standards, a period (.) is used to separate objects. When using LDAP syntax, you use a comma (,) instead.

For example, if you have an eDirectory object named CGrayson located in the IF.CLE container, it is referred to (typefully) as .CN=CGrayson.OU=IF.O=CLE. When referring to the same object using LDAP syntax, you would use cn=CGrayson,ou=IF,o=CLE.

LDAP syntax is not case-sensitive. Common usage, however, is to actually use all lowercase letters.

With these points in mind, let's look at how LDAP is integrated with eDirectory.

eDirectory LDAP Integration

The LDAP service installed on your server during the NNLS implementation is tightly integrated with eDirectory. The LDAP service binary (nldap) is located in /usr/sbin. Within the eDirectory tree, you will see two objects that are used to configure and manage the LDAP service:

  • LDAP Server object— The LDAP Server object is automatically created in the same context as your server object. It is named LDAP Server – your_server_name, as shown in Figure 5.36. This object stores the configuration information for your LDAP service. When the service starts, it reads this object to retrieve its configuration parameters.

    Figure 5.36. eDirectory LDAP objects.

  • LDAP Group object— The LDAP Group object also stores LDAP configuration parameters. It is also automatically created during installation and is placed in the same context as the server object, as shown in Figure 5.36. It is named LDAP Group – your_server_name. A single LDAP Group object can be associated with multiple LDAP servers in the tree, allowing them to share a common configuration. This can be very beneficial if your network and tree are very large.

LDAP Binds to eDirectory

When a client binds to eDirectory through the LDAP service, eDirectory rules and rights, discussed earlier, apply just as if the client had accessed the directory using native eDirectory calls.

If an LDAP client accesses the directory without supplying a username or password (anonymously), it is authenticated as [Public] and is granted browse rights (unless you've changed [Public]'s default rights assignment) to the root of the tree.

Using the LDAP Group object, you can change the default anonymous user. You can create a user in the tree, assign the rights you need anonymous LDAP users to have, and associate the new user with the LDAP Group. Modifying the properties of the LDAP Group object, as shown in Figure 5.37, does this. Remember that the proxy user can't have a password or any password restrictions.

Figure 5.37. Configuring the LDAP proxy user.

Unless you have an outstanding reason for doing this, you should stick with the default [Public] level of access. The rights you give this proxy are automatically granted to unauthenticated LDAP clients. You should err on the side of caution.

If an LDAP client accesses the directory and supplies a valid username and password, it is authenticated using those credentials. The effective rights associated with the authenticated user object are granted to the LDAP client.

With that, let's briefly discuss how to import objects into your tree using LDAP and a text file.

LDAP Data Interchange Format (LDIF)

One very useful feature of LDAP is the LDAP Data Interchange Format (LDIF) specification. This allows you to define directory objects in a simple text file (using standardized formatting) and import the file into the directory tree.

You can complete add, delete, and modify operations in the file. You can complete multiple operations within the same file. A detailed discussion of the full LDIF specification is beyond the scope of this book. We will, however, explore a couple sample entries in an LDIF-compliant text file:

Note

If you want to learn more about creating LDIF files, visit http://developer.netscape.com/docs/manuals/directory/admin30/ldif.htm.

version: 1

dn: cn=mhuffman,ou=IF,o=CLE

changetype: add

objectclass: inetorgperson

sn: Huffmann

title: Manager

dn: cn=jcorry,ou=SLC,o=CLE

changetype: delete

dn: cn=cgrayson,ou=IF,o=CLE

changetype: modify

replace: title

title: Vice President

If saved in a text file, this information can be imported into your eDirectory tree. This file creates a new user object named mhuffman in the IF.CLE container.

The second operation in this file deletes a user named jcorry from the SLC.CLE container (assuming this user already existed there). The last operation modifies the cgrayson object in IF.CLE and changes the value of its title attribute.

eDirectory includes a utility named Import Convert Export utility (ice) that can be used to import LDIF files into the tree as well as export objects from the tree into an LDIF file. iManager includes a graphical interface that can be used to configure ice jobs and run the ice engine to import the file.

Let's practice importing an LDIF file in Lab Exercise 5.6.


Lab Exercise 5.6: Importing an LDIF File

In this lab, you're going to create an LDIF file that imports a new user into the tree and also modifies an existing user. Complete the following steps:

  1. If necessary, boot your server and authenticate as your student user with a password of novell.

  2. Open a terminal session.

  3. Change to your root user account by entering su - and supplying a password of novell.

  4. At your shell prompt, enter vi /tmp/newuser.ldif.

  5. Press Ins.

  6. Enter the following text into the file:

version: 1

dn: cn=mhuffman,ou=IF,o=CLE

changetype: add

objectclass: inetorgperson

sn: Huffman

title: Manager

dn: cn=cgrayson,ou=IF,o=CLE

changetype: modify

replace: title

title: Vice President

  7. Press Esc.

  8. Enter :exit.

  9. Start iManager by opening a web browser and navigating to https://your_server's_IP_address/nps/iManager.html.

  10. Under eDirectory Maintenance Utilities, select Import Convert Export Wizard.

  11. In the Welcome screen, mark Import Data from File on Disk and then click Next.

  12. In the File Type drop-down list, select LDIF.

  13. In the File to Import field, browse to and select /tmp/newuser.ldif.

  14. Under Advanced Settings, deselect Exit on Error.

  15. Mark Run in Verbose Mode and Add Records Without a Change Type and then click Next.

  16. In the Server Name/IP Address field, enter the IP address of your server.

  17. In the Port field, enter 636.

  18. In the DER File field, enter /etc/opt/novell/SSCert.der.

  19. Mark Authenticated Login.

  20. In the User DN field, enter cn=admin,ou=IF,o=CLE.

  21. In the password field, enter novell.

  22. Under Advanced Settings, deselect Use LBURP.

  23. Mark Allow Forward References and then click Next.

  24. Select Finish.

  25. Wait while the file is imported.

  26. When prompted that the process is complete, click Close.

  27. Under eDirectory Administration, use the Modify Object task to verify that the mhuffman.IF.CLE object was created and that the title of cgrayson.IF.CLE object was modified.

We've finished our introduction to LDAP. It's critical that you understand the LDAP basics presented here. Recall that earlier I said that eDirectory is the backbone of NNLS because all the components rely on it. These components, however, also rely on LDAP to access eDirectory information.

Let's now turn to a discussion of how to administer eDirectory on Linux.


Administering eDirectory on Linux

Test Objectives Covered:

5. Perform eDirectory administration tasks.

There are three main tools you will use to administer eDirectory on Linux:

  • Command-line utilities

  • iManager

  • iMonitor

In this section, we will discuss the basics of each. We will also relate how to perform an eDirectory health check.

Command-line Utilities

On the Linux platform, eDirectory includes several utilities that can be used from the command line to manage your eDirectory database. A detailed discussion of each utility is beyond the scope of this book. We will use iManager and iMonitor as the primary administration tools, wherever possible.

The command-line eDirectory utilities included in NNLS are listed in Table 5.3.

Table 5.3. eDirectory Command-Line Utilities

UTILITY

DESCRIPTION

/etc/init.d/ndsd

The ndsd init script is used to start and stop the eDirectory service on your server.

It is used like other init scripts, with start or stop modifiers. For example, to stop the service, you would enter /etc/init.d/ndsd stop.

To start the service, you would enter: /etc/init.d/ndsd start.

Ldapconfig

The ldapconfig utility can be used to configure your LDAP Server and LDAP Group objects in your tree.

Enter man ldapconfig at your shell prompt to see the various parameters used with this utility.

Ndsbackup

The ndsbackup utility is used to save the logical structure of the eDirectory tree to a file. If something should happen to the objects in the tree, you can use this utility to restore them from the backup file previously created.

Ndsconfig

The ndsconfig utility is used to configure the eDirectory tree itself.

It can be used to create a new tree, modify an existing tree, add a server to an existing tree, or remove a server from the tree.

Enter man ndsconfig at your shell prompt to see the various parameters used with this utility.

Ndslogin

The ndslogin utility is used to check whether eDirectory authentication is working correctly.

When it's run, you provide a username as a modifier (for example, ndslogin cgrayson.if.cle). The utility then prompts you for the user's password. The utility then tests, authenticates, and reports the results.

Ndsmerge

This utility can be used to combine two separate eDirectory trees into a single tree.

This can be a delicate operation. Before attempting this, enter man ndsmerge at the shell prompt and read the instructions for preparing the trees and servers.

Ndsrepair

Because of the replicated, distributed nature of eDirectory, it's possible for errors to creep into the database due to failed communication links and other issues.

The ndsrepair utility can be used to check the local eDirectory database for errors and repair them.

To run a full, unattended repair, enter ndsrepair -U at the shell prompt.

To see all the options available with this utility, enter man nds repair at the shell prompt.

Ndsstat

The ndsstat utility is used to display information about the local eDirectory server.

It displays the tree name, the server distinguished name, and the version of eDirectory installed.

To use this utility, simply enter ndsstat at the shell prompt.

Ndstrace

This utility can be used to trace internal eDirectory activity. This utility has many options and parameters.

View the ndstrace man page for more information about how to use this utility.

One thing you need to keep in mind when using these utilities is that they are server centric. That is, they only configure the eDirectory service on the local server.

If your eDirectory tree is large and has many servers, this may prove to be cumbersome. In this case, you should use iManager and iMonitor. In fact, on your CLE exam, you should do everything you can with iMonitor and iManager first. Only if you can't perform a task with these two utilities should you consider using the command-line utilities.

Using iManager

Novell's iManager is a web-based utility that is used to manage your eDirectory tree. We've already used iManager several times in the exercises in this book. iManager is accessed by opening a web browser and accessing http://your_server_address/nps/iManager.html.

When you do, the iManager authentication page is displayed, as shown in Figure 5.38.

Figure 5.38. The iManager authentication page.

iManager uses eDirectory to control access. The tasks you can perform in iManager are dependent upon the credentials you supply in this page.

You should be aware that the iManager uses LDAP to authenticate. If the user you are authenticating as exists in the same context as your server object and your LDAP Server and LDAP group objects, you can simply provide the typeless username.

In the preceding exercises, you simply entered admin and were able to authenticate. If you want to use a different user, you must supply the typeful distinguished name of the user using LDAP syntax. For example, if I were Christopher Grayson and wanted to authenticate to the CLE-TREE we just installed, I would enter cn=cgrayson,ou=IF,o=CLE in the Username field.

After authenticating, the iManager home page appears, shown in Figure 5.39.

Figure 5.39. The iManager home page.

Notice that a frame labeled Roles and Tasks is displayed on the left side of the screen. By default, iManager displays all the roles and tasks it has been configured with.

The roles are superordinate headings displayed in black text. These are groupings of individual tasks.

The tasks are specific jobs you can perform with iManager. They are displayed as links beneath the role headings.

If your credentials have insufficient rights in the eDirectory tree to perform a task, a message will be displayed in the right frame when you try to complete it. If you do have the appropriate level of rights, the interface required to complete the task you selected is displayed in the right frame.

One of the cool features of iManager is the ability to configure Role-Based Services (RBS). By default, RBS is not configured, hence the reason iManager displays all roles and tasks for all users. If you configure RBS, you can associate specific roles and tasks with specific users. When you do this, the users automatically receive all the rights they will need to accomplish the associated tasks in the eDirectory tree.

For example, you can associate a user with the Help Desk role, shown in Figure 5.40.

Figure 5.40. The Help Desk role.

When the user authenticates to iManager, he or she only sees the Help Desk role in the left frame. The user automatically receives the rights needed to clear intruder lockouts, create users, and set user passwords within the area of the tree you specify.

Let's now turn our attention to the last eDirectory management tool we're going to cover in this chapter: iMonitor.

Using iMonitor

iMonitor has a different purpose than iManager. iManager is primarily designed to manage the tree—performing day-to-day tasks such as adding users, creating groups, and assigning rights.

iMonitor, on the other hand, is designed specifically to monitor and troubleshoot the eDirectory database on the servers in your tree. You can view current eDirectory operations based on servers, partitions, or replicas.

iMonitor operates in two different modes: direct mode and proxy mode. Simply speaking, iMonitor is running in direct mode when you are using it to work on the eDirectory database and service on the same server where you are accessing iMonitor.

In proxy mode, you access iMonitor on one server in the eDirectory tree and then use it to manage the eDirectory database and service on a different server in the tree. This is a really useful feature of iMonitor. If you were to install your NNLS server into an existing eDirectory tree where servers are installed running older versions of eDirectory or NDS, you can use proxy mode to manage them as well as your NNLS server.

To access iMonitor, run a web browser and open https://your_server_IP_address:8010/nds. When you do, iMonitor displays an authentication screen, as shown in Figure 5.41.

Figure 5.41. Authenticating to iMonitor.

Unlike in iManager, you authenticate to iMonitor using standard eDirectory naming conventions. For example, if you want to authenticate as the admin user in the tree you installed previously, enter admin.IF.CLE in the Username field.

As with iManager, the tasks you can perform within iMonitor are controlled by the rights assigned to the user object you used to authenticate to the tree.

Most tasks in iMonitor require that the user object you use have the Supervisor right to the server object. This can be either your tree admin user or another user whom you have granted rights to the server object.

After authentication, the iMonitor home page is displayed, as shown in Figure 5.42.

Figure 5.42. The iMonitor home page.

The iMonitor home page displays a summary of the eDirectory agents on your server. You can quickly view the synchronization status of the replicas in the replica ring as well as the status of the various eDirectory processes running on the server.

One of the key roles of iMonitor is to check the health of your eDirectory tree. Let's talk now about how this is done.

Performing an eDirectory Health Check with iMonitor

As mentioned earlier, eDirectory uses a distributed, replicated database. The service, as well as the database data, is distributed among the various servers in the tree. For the most part, eDirectory functions flawlessly. Directory information is synchronized around the various replica rings, and eDirectory processes occur on schedule.

Certain situations can arise, however, that interfere with the proper functioning of the directory. Any of the following can cause errors to appear in the eDirectory database:

  • Dropped network links between servers

  • Lost time synchronization

  • Failed hardware

  • Corrupted eDirectory files

This is only a partial list of the network issues that can cause errors to be introduced into the tree. Fortunately, Novell provides several tools that can be used to fix these errors, with iMonitor being key among them. In this section, we're going to talk about how to use iMonitor to perform an eDirectory health check.

You need to understand just how important these health checks are—a majority of eDirectory problems actually fix themselves if left alone long enough. Experienced eDirectory administrators call this "letting the tree settle down." The phrase "time heals all wounds" is very applicable.

Over the years, I've observed many eDirectory administrators jump right in and start trying to manually repair problems in their tree. However, the majority of these problems will fix themselves over time.

There are times, however, when manual intervention is necessary. If left alone too long, some eDirectory issues will propagate throughout the tree, causing horrendous problems.

What should you do? Run regular eDirectory health checks to make sure everything is functioning as it should. If you have a relatively static eDirectory tree (meaning changes occur in the tree only rarely), you should run a full health check about once or twice a month.

If you have a very dynamic tree where changes are made on a frequent basis, you should run health checks much more often—as much as once or twice a week.

You should also run a health check before you perform any major tree operations, such as creating partitions, adding replicas, or adding servers to the tree.

Using iMonitor, you do the following to perform a basic eDirectory health check:

  • Check the eDirectory version on all the servers in the tree.

  • Verify that time is synchronized on all servers in the tree.

  • Check partition continuity. This involves making sure all replicas of each partition in the tree are able to communicate with each other.

You can also perform an advanced eDirectory health check. We're not going to cover this process here because it isn't required to pass the CLE exam and because it requires more eDirectory knowledge and experience than you have at this time.

In summary, an advanced health check includes the preceding items and adds the following processes:

  • Check to see that the eDirectory schema is synchronized on all servers in the tree.

  • Check for stuck obituaries. Obituaries occur in the eDirectory tree whenever you modify, move, or delete an object. The original information is saved for a time to preserve a history of the object until the change has been synchronized to all replicas in the ring. When the change has been fully synchronized, the obituary is flagged as purgeable and is removed from the system. If an obituary is stuck, it indicates a synchronization problem somewhere in the replica ring that must be rectified.

  • Check external references. An external reference is created when you access information in the tree that isn't actually stored in a replica on the local server. eDirectory creates a shortcut to the actual data residing on a different server in the tree called an external reference.

  • Check the status of the limber processes. Whenever you make a change to a server in the tree, such as changing the server's name or IP address, eDirectory employs a process called limber that propagates the new information around to the other servers in the tree. Without the limber process, changing a server's IP address, for example, would completely destroy the replica ring it participated in. This part of the health check ensures that this process is working properly.

To run a basic health check with iMonitor, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address:8010/nds.

  2. Authenticate as your admin user.

  3. In the left frame, select Agent Configuration. The page shown in Figure 5.43 appears.

    Figure 5.43. The iMonitor Agent Configuration page.

  4. Scroll down the list and note the version of eDirectory installed.

  5. Scroll down and verify that time is synchronized.

  6. In the left frame, scroll down to the Links heading and select Agent Synchronization. The page shown in Figure 5.44 appears.

    Figure 5.44. The iMonitor Agent Synchronization page.

    Note

    Note that there is an Agent Synchronization link under the Agent Configuration heading as well. Be sure to select the link located under Links.

  7. Check the Errors and Last Successful Sync fields. The Errors field should be 0. The Last Successful Sync field displays how long it has been since the entire ring was last successfully synchronized. It should have occurred fairly recently.

  8. You'll notice that each partition has its own row of information. At the right end of each row is a collection of links. For each partition, select its Continuity link.

  9. Verify that the Errors field for each partition is 0 and that the Last Successful Sync happened recently.

  10. Under Links, select Agent Process Status. The page shown in Figure 5.45 appears.

    Figure 5.45. The iMonitor Agent Process Status page.

  11. Identify any error codes displayed for schema sync status, obituary status, external reference status, or limber status.

  12. Run a full unattended repair process on your server by completing the following:

    1. In the iMonitor toolbar, select the Repair icon. The page shown in Figure 5.46 appears.

      Figure 5.46. The iMonitor Repair page.

    2. Mark Run in Unattended Mode.

    3. Select Start Repair.

    4. Wait while the repair process is completed.

That's it! If you perform this procedure on a regular basis with your eDirectory tree, you can help ensure that it continues to operate properly.


Summary

We really covered a lot of territory in this chapter. First, I related how NNLS is distributed and how you can secure an evaluation copy to use in this book's lab exercises. Then, we talked about the five tasks you need to complete in order to prepare for an NNLS installation:

  • Meet system requirements.

  • Make sure NTP is functioning properly.

  • Configure SLP.

  • Enable multicasting.

  • Configure your hosts file.

We then talked about the difference between express and custom installations and performed a custom installation on your server. The next topic addressed was how to use the Red Carpet daemon (rcd) to automate the update process in NNLS. You then completed a lab exercise where you used Red Carpet to download an update to your system and apply it.

With Red Carpet out of the way, I gave you a down-and-dirty review of how eDirectory works, including objects, properties, rights, syntax, partitioning, and replication. We also discussed how eDirectory is integrated with the NNLS LDAP service.

We then turned our attention to a discussion of the various administration utilities used to manage eDirectory, including the various command-line utilities (such as ndsconfig and ndsbackup), iManager, and iMonitor.

To end this chapter, we spent some time discussing how to use iMonitor to perform an eDirectory health check and how to repair the eDirectory database.

In the next chapter, we will move on to the next two NNLS components you will need to know how to deploy in order to pass the CLE exam: eGuide and Linux User Management (LUM).


Chapter 6. Managing User Accounts with eGuide and Linux User Management

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. View user information with eGuide.

  2. Access a Linux Server with Linux User Management (LUM).

In the previous chapter, we covered how to install Novel Nterprise Linux Services (NNLS) on your server and how to manage the eDirectory and LDAP services that are implemented in the process.

In this chapter, you will learn how to use two NNLS components that leverage eDirectory and LDAP: eGuide and Linux User Management.


Working with eGuide

Test Objective Covered:

1. View user information with eGuide.

If you've ever worked in a large organization, you know how frustrating it can be to find information about a particular employee you need to contact. In the past, it was pretty much up to an organization's administrative assistants to keep everyone's contact information up to date. The general procedure has been as follows: Each administrative assistant types up a list of employees and their phone numbers and email addresses. He or she prints hundreds of copies and distributes them to all the employees in the division. Within a week, the list is out of date, so it's updated and redistributed again. A couple weeks later, it's out of date once more and a new copy is distributed. Soon, multiple versions of the same document are floating around the organization, most of which are out of date.

NNLS seeks to improve this situation (and save a lot of trees in the process) by providing a product called eGuide. eGuide serves as a powerful organizational address book. eGuide leverages LDAP to dynamically pull current organizational information out of any LDAP-compliant directory service and display it in a web browser, as shown in Figure 6.1.

Figure 6.1. Finding user information in eGuide.

Let's first discuss how eGuide works.

How eGuide Works

To understand how eGuide works, we first need to spend a few minutes reviewing some basic eDirectory concepts. Recall from the previous chapter that eDirectory objects (sometimes called entries) are composed of attributes (sometimes called properties) and values. An attribute is a property of an object, such as first name, last name, or telephone number. A value is the data associated with the attribute, such as Mike, Huffman, or 555-555-5555.

Each eDirectory tree has a set of rules called the schema. The schema contains definitions for each type of object allowed in the tree, what objects can contain other objects (containment rules), and a list of the attributes assigned to each object class.

When we created user objects in the lab exercises in the previous chapter, you saw some of the basic attributes of the user object, such as first name, last name, context, title, location, phone number, fax number, and email address.

There are actually many more attributes of the user object in the eDirectory tree. In Figure 6.2, we are modifying the properties of the mhuffman.IF.CLE user object. The default page displayed is the General page. In Figure 6.2, however, you can see that there are a number of property pages containing a range of different attributes you can use to describe the user object.

Figure 6.2. User object attributes.

One of the most useful sets of attributes for eGuide is the Business Info page under User Profile, highlighted in Figure 6.2. This page allows you to populate various user object attributes such as the following:

  • Employee ID

  • Company

  • Job Title

  • Location

  • Department

  • Manager

  • Assistant

  • Direct Reports

  • Phone Number

  • Fax Number

  • Mobile Phone Number

  • Pager Number

  • Assistant's Phone Number

  • Email Address

  • Street

  • Mailstop

  • City

  • State/Province

  • ZIP Code

  • Country

Some of these attributes are shown in Figure 6.3.

Figure 6.3. User object business information attributes.

Using these attributes, eGuide can create a feature-rich online organizational address book. Using the Manager, Assistant, and Direct Reports attributes, you can even generate an organization chart with eGuide.

One of the best aspect of using eGuide over your administrative assistant's memos is that the information displayed by eGuide is dynamic. If a new employee is hired, his or her information is immediately available. If an employee leaves the organization or changes positions within the organization, again the change is reflected immediately in eGuide.

This is an incredible benefit for everyone involved. I used to work for a medium-sized corporation a few years ago. After seven years on the job, I had accumulated stacks of paper-based org charts and phone lists. Eventually, this company implemented eGuide, and things were so much easier to use. If you needed to contact a person, you just hit the eGuide website and looked up his or her contact information. If you needed to know who all the members of a given team were, you simply looked up the manager in eGuide and you could see all of his or her direct reports.

Let's talk about how you go about managing your eGuide implementation.

Managing eGuide

You can access your eGuide home page by opening a browser window and navigating to https://your_server_IP_address/eGuide. Note that the URL is case sensitive. If you enter eguide or Eguide in the URL, you'll get a Page Not Found error.

When you go to this URL, the eGuide Login page is displayed, as shown in Figure 6.4.

Figure 6.4. Logging in to eGuide.

eGuide uses LDAP to authenticate to eDirectory, so you need to enter your username using LDAP syntax. For example, if you need to authenticate as mhuffman.IF.CLE, you enter cn=mhuffman, ou=IF, o=CLE in the Username field.

Because eGuide uses LDAP to access directory data, it can be used with directory services other than eDirectory. If your organization uses multiple directory services or multiple eDirectory trees, you can configure eGuide to pull data from all sources simultaneously (as long as the directory service is LDAP compliant).

To do this, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/eGuide.

  2. Authenticate to eGuide as your admin user.

  3. In the eGuide home page, select Administration Utility; the screen in Figure 6.5 appears.

    Figure 6.5. The eGuide Administration utility.

    Tip

    The Administration Utility link is only available when you authenticate as the admin user.

  4. In the left frame, under Configuration, select LDAP Data Sources.

  5. Click New. The screen shown in Figure 6.6 appears.

    Figure 6.6. Adding a new LDAP data source.

  6. In the fields provided, enter the appropriate data for the LDAP service you are connecting eGuide to.

  7. Click Save.

If you want to edit an existing LDAP source, you can select the Edit link under the Properties heading, as shown in Figure 6.7.

Figure 6.7. Editing an existing LDAP data source.

Notice that eGuide has been preconfigured during installation to access data from your eDirectory tree. Generally speaking, you probably won't need to make many changes in this screen unless you make serious changes to the tree itself or decide to access data in a different tree or other directory service.

You may, however, want to make changes to the way eGuide conducts searches for information in your tree. This is done by editing the parameters under the Attributes tab, as shown in Figure 6.8.

Figure 6.8. Configuring eGuide search functionality.

Attributes that are marked as "enabled" are included in the results of the search. Attributes that are marked as "searchable" are displayed in the list of searchable criteria on the eGuide client page, shown in Figure 6.9. Attributes marked as "editable" can be modified by the user in the eGuide interface.

Figure 6.9. Configuring eGuide attributes.

On the eGuide client page is a link named Edit Information. When this link is selected, an interface is displayed that allows the currently logged-in user to modify the values of the attributes flagged as editable; this is shown in Figure 6.10.

Figure 6.10. Editing user object attributes in eGuide.

Lab Exercise 6.1 allows you to spend some time working with eGuide.


Lab Exercise 6.1: Working with eGuide

In this lab, you're going to add users to your eDirectory tree and populate their business information attributes. Then you will use eGuide to search for information in the tree. Finally, you will configure object attributes used by eGuide. Complete the following steps:

  1. Start iManager by opening a web browser and navigating to https://your_server's_IP_address/nps/iManager.html.

  2. Authenticate as admin with a password of novell.

  3. Using the Create Object task under eDirectory Administration, create the following user objects in your tree with the following attributes:

    Note

    After creating each user, you will be presented with a LUM screen. For each user, click Cancel in this screen.

    User

    Attribute

    Value

    JCorry

    First Name

    Jason

    Last Name

    Corry

    Context

    IF.CLE

    Password

    novell

    Title

    Engineer

    Location

    Idaho Falls, Idaho Office

    Department

    Training

    Telephone

    555-555-5551

    Fax

    555-555-5552

    Email Address

    jcorry@cle.com

    JJackson

    First Name

    Jim

    Last Name

    Jackson

    Context

    IF.CLE

    Password

    novell

    Title

    Engineer

    Location

    Idaho Falls, Idaho Office

    Department

    Training

    Telephone

    555-555-5553

    Fax

    555-555-5552

    Email Address

    jjackson@cle.com

    DNelson

    First Name

    Diana

    Last Name

    Nelson

    Context

    IF.CLE

    Password

    novell

    Title

    Administrative Assistant

    Location

    Idaho Falls, Idaho Office

    Department

    Training

    Telephone

    555-555-5550

    Fax

    555-555-5552

    Email Address

    dnelson@cle.com

    MHoffmann

    First Name

    Michele

    Last Name

    Hoffmann

    Context

    SLC.CLE

    Password

    novell

    Title

    Business Development Specialist

    Location

    Salt Lake City, Utah Office

    Department

    Executive Management

    Telephone

    555-555-5554

    Fax

    555-555-5552

    Email Address

    mhoffmann@cle.com

    BJohnson

    First Name

    Brian

    Last Name

    Johnson

    Context

    SLC.CLE

    Password

    novell

    Title

    Director of Sales and

    Marketing

    Location

    Salt Lake City, Utah Office

    Department

    Executive Management

    Telephone

    555-555-5555

    Fax

    555-555-5552

    Email Address

    bjohnson@cle.com

    CValdez

    First Name

    Cindy

    Last Name

    Valdez

    Context

    SLC.CLE

    Password

    novell

    Title

    Administrative Assistant

    Location

    Salt Lake City, Utah Office

    Department

    Executive Management

    Telephone

    555-555-5556

    Fax

    555-555-5552

    Email Address

    cvaldez@cle.com

  4. Using the Modify Object task under eDirectory Administration, modify the following user objects in your tree by adding the specified attribute values on the Business Info page for each object.

    User

    Attribute

    Value

    DCoughanour.SLC.CLE

    Employee ID

    0001

    Company

    CLE, Inc.

    Manager

    none

    Assistant

    CValdez.SLC.CLE

    Direct Reports

    CValdex.SLC.CLE,

    BJohnson.SLC.CLE,

    MHoffmann.SLC.CLE

    Mobile Phone

    555-444-5555

    Street

    100 W. 500 S.

    Mailstop

    101

    City

    Salt Lake City

    State

    Utah

    ZIP

    84602

    Country

    USA

    BJohnson.SLC.CLE

    Employee ID

    0002

    Company

    CLE, Inc.

    Manager

    DCoughanour.SLC.CLE

    Assistant

    CValdez.SLC.CLE

    Direct Reports

    None

    Mobile Phone

    555-444-5556

    Street

    100 W. 500 S.

    Mailstop

    101

    City

    Salt Lake City

    State

    Utah

    ZIP

    84602

    Country

    USA

    MHoffmann.SLC.CLE

    Employee ID

    0003

    Company

    CLE, Inc.

    Manager

    DCoughanour.SLC.CLE

    Assistant

    CValdez.SLC.CLE

    Direct Reports

    None

    Mobile Phone

    555-444-5510

    Street

    100 W. 500 S.

    Mailstop

    101

    City

    Salt Lake City

    State

    Utah

    ZIP

    84602

    Country

    USA

    CValdez.SLC.CLE

    Employee ID

    0010

    Company

    CLE, Inc.

    Manager

    DCoughanour.SLC.CLE

    Assistant

    None

    Direct Reports

    None

    Mobile Phone

    555-444-5511

    Street

    100 W. 500 S.

    Mailstop

    101

    City

    Salt Lake City

    State

    Utah

    ZIP

    84602

    Country

    USA

    CGrayson.IF.CLE

    Employee ID

    0004

    Company

    CLE, Inc.

    Manager

    DCoughanour.SLC.CLE

    Assistant

    DNelson.IF.CLE

    Direct Reports

    JJackson.IF.CLE,

    JCorry.IF.CLE,

    DNelson.IF.CLE

    Mobile Phone

    555-444-5558

    Street

    1548 S. 113 E.

    Mailstop

    202

    City

    Idaho Falls

    State

    Idaho

    ZIP

    83404

    Country

    USA

    JCorry.IF.CLE

    Employee ID

    0005

    Company

    CLE, Inc.

    Manager

    CGrayson.IF.CLE

    Assistant

    DNelson.IF.CLE

    Direct Reports

    None

    Mobile Phone

    555-444-5512

    Street

    1548 S. 113 E.

    Mailstop

    202

    City Idaho

    Falls

    State

    Idaho

    ZIP

    83404

    Country

    USA

    JJackson.IF.CLE

    Employee ID

    0006

    Company

    CLE, Inc.

    Manager

    CGrayson.IF.CLE

    Assistant

    DNelson.IF.CLE

    Direct Reports

    None

    Mobile Phone

    555-444-5513

    Street

    1548 S. 113 E.

    Mailstop

    202

    City

    Idaho Falls

    State

    Idaho

    ZIP

    83404

    Country

    USA

    DNelson.IF.CLE

    Employee ID

    0007

    Company

    CLE, Inc.

    Manager

    CGrayson.IF.CLE

    Assistant

    None

    Direct Reports

    None

    Mobile Phone

    555-444-5514

    Street

    1548 S. 113 E.

    Mailstop

    202

    City

    Idaho Falls

    State

    Idaho

    ZIP

    83404

    Country

    USA

  5. Test the data by completing the following steps:

    1. In your browser window, open https://your_server_IP_address/eGuide.

    2. Authenticate to eGuide as admin with a password of novell.

    3. In the Find People drop-down lists, select Last Name and Starts With.

    4. In the Find People field, enter co and then select Search.

    5. You should see Dave Coughanour and Jason Corry located in the search. View the information eGuide pulled from eDirectory.

    6. Select the Organizational Chart tab. The organizational structure you defined in the user object attributes is displayed.

  6. Configure the attributes displayed by eGuide by completing the following steps:

    1. In eGuide, select Administration Utility.

    2. Select LDAP Data Sources.

    3. On the New_Data_Source line, select Edit.

    4. Select the Attributes tab.

    5. Mark the following check boxes for the following attributes:

      Attribute

      Check Box(es)

      Company

      Enable

      directreports

      Enable, Searchable

      facsimiletelephonenumber

      Enable, Searchable, Editable

      Manager

      Enable, Searchable

      telephonenumber

      Enable, Searchable, Editable

    6. Click Save.

    7. Click the Launch eGuide Client icon.

    8. In the first Find People drop-down list, verify that the preceding searchable attributes are included in the list.

    9. Search for the DCoughanour user object. Verify that the attributes configured previously are displayed.

That's it for eGuide. It's a very solid product that works very well right out of the box. You've probably noticed as we went through the preceding content that it really doesn't require a lot of administrative intervention to deploy.

With eGuide done, you'll now learn about the Linux User Management component of NNLS.


Working with Linux User Management

Test Objective Covered:

2. Access a Linux Server with Linux User Management (LUM).

The LUM component of NNLS serves as the link between the local Linux system and eDirectory. LUM represents a huge leap forward in eDirectory technology.

eDirectory was actually ported over to Linux in 1998. I remember when the first version became available for beta testing. I went to a training session in a room packed with Linux administrators. All of us were waiting with baited breath to see eDirectory on our favorite platform.

We all proceeded through the install portion of the class without incident. Shortly after that, things started to go wrong. The product itself worked fine—it was the way it worked that caused consternation.

As you probably know, Linux administrators tend to have an inquisitive nature. In accordance, after the install portion of the class, most of the students were off experimenting and tinkering with the eDirectory service instead of listening to the instructor (he wasn't terribly interesting to listen to anyway).

As a result of this tinkering, all of us realized in a moment of group collective consciousness that the eDirectory and Linux authentication systems weren't connected to each other in any way. Because of our past experience with NetWare, we were fully expecting to be able to use eDirectory to authenticate Linux users. Instead, we found that Linux users were still being managed with the passwd, shadow, and group files. eDirectory and Linux were in no way connected.

To authenticate to eDirectory, you had to log in using the Novell Client from a Windows or DOS workstation. To log in to the Linux server, you had to authenticate from the login prompt at the server console. Essentially, eDirectory used Linux as a platform to run on and wasn't used to actually manage the server itself.

Needless to say, all the students in the class were very disappointed and called the instructor's attention to this issue. He looked at us in a funny way and said something to the effect of, "Well, of course it doesn't," as if we were expecting the impossible. Thankfully, Novell realized this fact and included LUM in NNLS.

Note

Novell actually started working on this problem prior to NNLS. LUM descends from Novell's Account Management product line. Having used both, LUM is considerably easier to use and works much more reliably.

LUM makes eDirectory do exactly what we were expecting it to do back in 1998: tt redirects authentication to the Linux system through eDirectory. Linux users can authenticate to the system without an entry being required in the passwd file.

This alone makes eDirectory worth its while on the Linux platform. Recall in Chapter 4, "Introduction to Novell Nterprise Linux Services (NNLS)," that we discussed the administrative challenge presented by synchronizing Linux user and group accounts on multiple servers. Previously, you had two options for this problem:

  • You could synchronize accounts manually. In a very large network, this could be a daunting task.

  • You could implement NIS+. NIS+ is an Open Source service that synchronizes accounts between Linux systems.

Either way, it wasn't an easy task.

Using eDirectory to manage your Linux user accounts makes life much easier for the administrator. Instead of trying to synchronize accounts among multiple systems, eDirectory serves as a central repository for all network information.

Tip

It's important that you understand that eDirectory doesn't synchronize user accounts.

With eDirectory, you only need a single user account for every user in your organization. You assign rights to the single user account to control what resources the user can and cannot use.

Recall when we installed NNLS in the previous chapter. We configured NNLS to redirect authentication for PAM-enabled services. PAM stands for Pluggable Authentication Modules. PAM uses a series of shared library files to create a modular authentication system. It allows the administrator to customize the authentication mechanism a particular service, such as login or ftp, uses.

Linux services such as ftp, login, and so on have been redirected to use eDirectory user accounts instead of the user accounts in the passwd file. This is particularly useful when implementing Samba. We'll discuss this topic in more depth in a later chapter.

How LUM Works with eDirectory

When LUM is installed, it extends the eDirectory schema (if you're new to eDirectory, you may not know what this means). Recall in Chapter 5, "NNLS Installation and Administration," that I said the eDirectory schema defines objects that are allowed in the tree, defines the attributes they have, and specifies containment rules.

The base schema installed when you implemented NNLS isn't static. You can add, delete, or modify object classes and attributes in your tree. LUM does exactly this when it is installed. It extends the schema and adds LUM-specific attributes to the default user, group, and template object classes. As you can see in Figure 6.11, the user object receives a new property page called Linux Profile.

Figure 6.11. The user object Linux Profile page.

The following attributes are added to the user object:

  • User ID

  • Primary Group ID

  • Primary Group Name

  • Login Shell

  • Home Directory

  • Comments

In Figure 6.12, you can see that the group object class also has a new property page named Linux Profile.

Figure 6.12. The group object Linux Profile page.

Group objects have the following attributes added:

  • Group ID

  • uamPosixWorkstationList

  • Description

  • memberUid

LUM also extends the schema to add two new types of objects to the tree, as listed in Table 6.1.

Table 6.1. LUM eDirectory Objects

LUM OBJECT

DESCRIPTION

Linux Workstation

Contains access control information for the Linux system. Each Linux system has an associated workstation object in the tree.

Linux Config

Contains LUM configuration information.

Installing LUM also adds the components listed in Table 6.2 to your system.

Table 6.2. LUM Components

LUM COMPONENT

LOCATION

DESCRIPTION

nss_nam.so

/usr/lib

Retrieves user and group information from the eDirectory tree. This module uses LDAP to access eDirectory.

namconfig

/usr/bin/

Used to configure LUM on the server.

pam_nam.so

/usr/lib/security

Provides authentication, account, and password management services on the Linux server using eDirectory.

These new objects and modules play a critical role in LUM. One of the issues encountered when redirecting to eDirectory is that of context. Recall that eDirectory uses a hierarchical database structure. Objects are referenced by their username and their context (for example, DCoughanour.SLC.CLE).

The Linux passwd file, on the other hand, is a flat file. User accounts are not arranged into a hierarchy.

This brings up a new problem: How do you deal with the issue of context in a system that previously had no notion of the concept? To fix this problem, LUM provides Linux users with an authentication process called contextless login, which is just what it sounds like. Users can log in to the Linux system using a typical Linux username.

The LUM nss_nam.so module resolves the contextless user name provided by the user during login to the particular system's workstation object in the eDirectory tree. This object is shown in Figure 6.13.

Figure 6.13. UNIX workstation object.

The workstation object contains a list of all the groups that have been given access to the Linux system. This is shown in Figure 6.14.

Figure 6.14. Authorized groups.

Only users who are members of these groups are allowed to authenticate to the Linux system. In Figure 6.14, only users who are members of the IFEmployees.IF.CLE group or the SLCEmployees.SLC.CLE group are allowed to authenticate to the CLE1 Linux system.

The username supplied by the user is compared with the usernames in the associated LUM groups. If a match is found, the user is authenticated and his or her Linux profile is used to configure the system environment.

Let's look at this redirection process in greater detail.

How LUM Redirection Works

LUM redirection is based on the Name Service Switch (NSS) component integrated into Linux. NSS allows you to configure how you want authentication to occur in the system. The NSS configuration is controlled by the /etc/nsswitch.conf file.

When you install LUM, the NNLS installation script modifies the nsswitch.conf file. This modified file is shown in Figure 6.15.

Figure 6.15. LUM-modified nsswitch.conf file.

Notice that the parameters for passwd, shadow, and group have been modified with the addition of the string nam. With the system configured in the way shown in Figure 6.15, it will first look in the passwd file for the user during login. This is configured by the files directive.

If not found there, it will next use eDirectory for authentication. This is configured by the nam directive. This system is configured to use NIS+ after eDirectory (if we actually had it installed on the system). This is configured by the nisplus directive.

The installation script also modifies the PAM files in the /etc/pam.d directory for services such as login, ftp, and ssh to use eDirectory for authentication. The modified file for the login service is shown in Figure 6.16.

Figure 6.16. LUM-modified login file in /etc/pam.d.

Notice in Figure 6.16 that login has been configured to use the LUM pam_nam.so module. This module redirects authentication requests to the nss_name.so module.

When the nss_nam.so module receives a request, it contacts the LUM daemon, namcd. This service retrieves and caches information from your eDirectory tree. If the username of the user authenticating is already in the daemon's cache, it will return the distinguished name (which is the object name and its context) of the associated user object. Otherwise, it queries eDirectory for the information, returns the distinguished name, and stores the information in its cache.

The namcd daemon can be configured using the /etc/nam.conf configuration file or by running the namconfig utility. A typical nam.conf file is shown in Figure 6.17.

Figure 6.17. A typical nam.conf file.

The parameters in this file are explained in Table 6.3.

Table 6.3. The namcd Configuration Parameters

PARAMETER

DESCRIPTION

base-name

This parameter identifies the base container in your eDirectory tree where LUM has been installed.

admin-fdn

The parameter specifies the name of your eDirectory tree's admin user.

preferred-server

This parameter lists the IP address of the eDirectory LDAP server the namcd daemon is to use.

positive-time-to-live

This parameter specifies the amount of time, in seconds, that object information is kept in the namcd daemon's cache.

This value can range from 1 to 2147483647 seconds. The default value is 600. If you have a static tree, you can increase this value because reads from cache are much faster than reads from the tree.

However, if you have a tree that changes frequently, you may want to keep the value where it is or even reduce it. This is done to ensure that the data in the cache matches the current tree data.

num-threads

This parameter identifies the number of CPU threads concurrently used by the daemon.

The default value is 5. This parameter can be set to a value between 1 and 25 threads.

Schema

This parameter identifies the version of the eDirectory schema used by the tree the daemon is configured to use.

enable-persistent-cache

This parameter enables or disables the namcd daemon's cache.

user-hash-size

The namcd daemon uses a hash algorithm to encrypt data in its cache. This parameter specifies the hash size.

Novell recommends that you use a value that is a prime number equal to or greater than 0.25 times the number of users in the tree. The default value is 211.

group-hash-size

This parameter is the same as the preceding parameter, except it's for groups.

The recommended value is the same: 0.25 times the number of groups in the tree. The default value is 211.

persistent-cache-entries-aging-interval

This parameter specifies the interval, in seconds, after which information in the namcd daemon's cache will be removed from the persistent cache.

This value can range from 1 to 2147483647 seconds. The default value is 7200.

persistent-cache-refresh-period

This parameter specifies how frequently, in seconds, the namcd daemon refreshes the information in its cache from eDirectory.

This value can range from 1 to 2147483647 seconds. The default value is 28800.

persistent-cache-refresh-flag

This parameter specifies whether all user and group information is to be included in the cache during refresh, or just those currently in use.

The default value is all. The other possible value is accessed.

create-home

Specifies whether home directories are created for users. This value can be either yes or no. The default value is no.

type-of-authentication

This parameter specifies whether SSL is to be used (2) or not used (1). The default value is 1.

Certificate-file-type

This parameter specifies the format of the certificate file to be used, if SSL is configured.

The value can be either der or base64. The default value is der.

ldap-ssl-port

This parameter lists the secure IP port that LDAP is using on the eDirectory server. The default value is 636.

ldap-port

This parameter lists the insecure port that LDAP is using on the eDirectory server. The default value is 389.

support-alias-name

This parameter identifies whether eDirectory alias objects that point to regular users and groups in the tree are allowed. The default value is no.

support-outside-base-context

This parameter specifies whether objects outside the base scope configured previously are allowed to use LUM. The default value is no.

As you can see from Figure 6.17, the NNLS installation script automatically configures your system, and usually very little additional configuration is needed—assuming you entered the correct information.

Let's now look at how you enable LUM functionality on your system.

Setting Up LUM

LUM is a highly flexible product, allowing you to configure your system in a variety of different ways. For the CLE certification, you only need to know how to perform a basic configuration, and that is what we will focus on here.

To perform a basic configuration of LUM on your system, you would do the following steps:

Note

This is a set of generic steps. We'll go through a detailed set of steps in the upcoming lab exercise.

  1. In a web browser, navigate to https://your_server's_IP_address/nps/iManager.html.

  2. Authenticate to iManager as the admin user.

  3. Create groups for LUM access. You can create one single group or multiple groups. To do so, complete the following steps:

    1. In iManager, scroll down to the eDirectory Administration role and select Create Object.

    2. In the Available Object Classes field, select Group and then click OK.

    3. In the Group Name field, enter a name for your group.

    4. In the Context field, enter the context where you want the group to reside and then click OK.

    5. When prompted that the group has been created, click OK.

    6. When prompted to convert the group to a LUM group, click Cancel. You'll convert the group at a later point.

  4. Populate the new group with the users you want to be able to authenticate to the Linux system using eDirectory by completing the following steps:

    1. In iManager, select Modify Object.

    2. In the Object Name field, enter the name of your group.

    3. In the drop-down list, select Members.

    4. In the Members field, browse to and select each user object you want in the group.

    5. Click OK.

  5. Convert the group to a LUM group by completing the following steps:

    1. In the left frame, scroll down to the Linux User Management role and select Convert eDirectory Group to LUM Group.

    2. In the Select Group field, browse to and select your group and then click OK.

    3. When prompted to select the workstations you want the group added to, select Linux Workstations.

    4. In the Linux Workstations field, browse to and select your UNIX Workstation object and then click OK.

    5. When prompted that the LUM group was created, click OK.

  6. Convert each user in the group to a LUM user by completing the following steps:

    1. Under the Linux User Management role, select Convert eDirectory User to LUM User.

    2. In the Select User field, browse to and select the first user in your group and then click OK.

    3. When prompted to specify the primary group for the user, browse to and select your group.

    4. Deselect the option to convert the user to a Samba user object; then click OK.

    5. Select Repeat Task.

    6. Repeat these steps for each user in the group.

Test the configuration by completing the following steps:

  1. Switch to a shell prompt by pressing Ctrl+Alt+F2 if you are running in a graphical environment. If you are working from the text-based shell prompt without the X Window System, press Alt+F2.

  2. At the login prompt, enter the username of a user object in the converted group. Don't include the context of the object. For example, if you wanted to authenticate as DCoughanour.SLC.CLE, you would simply enter DCoughanour.

  3. Supply the user's password at the password prompt. You should see a message indicating that a new home directory is being created in /home for the user.

That's all there is to it! In Lab Exercise 6.2, you can configure LUM on your server.


Lab Exercise 6.2: Implementing LUM

In this lab, you're going to configure LUM to redirect user authentication to eDirectory. Complete the following steps:

  1. Start iManager by opening a web browser and navigating to https://your_server's_IP_address/nps/iManager.html.

  2. Authenticate to iManager as your admin user with a password of novell.

  3. Create a group in your IF.CLE container named IFEmployees.

    1. In iManager, scroll down to the eDirectory Administration role and select Create Object.

    2. In the Available Object Classes field, select Group.

    3. Click OK.

    4. In the Group Name field, enter IFEmployees.

    5. In the Context field, enter IF.CLE.

    6. Click OK.

    7. When prompted that the group has been created, click OK.

    8. When prompted to convert the group to a LUM group, click Cancel. We'll convert the group at a later point.

  4. Populate the IFEmployees group with all the users in the IF container by following these steps:

    1. In iManager, select Modify Object.

    2. In the Object Name field, enter IFEmployees.IF.CLE.

    3. In the drop-down list, select Members.

    4. In the Members field, browse to and select each user in the IF container except for the eGuide, iFolder, and admin user objects.

    5. Click OK.

  5. Repeat this process to create a group object named SLCEmployees in the SLC.CLE container. Make each user in the SLC container a member of the group.

  6. Convert the IFEmployees and the SLCEmployees groups to LUM groups by completing the following steps:

    1. In the left frame, scroll down to the Linux User Management role.

    2. Select Convert eDirectory Group to LUM Group.

    3. In the Select Group field, browse to and select the IFEmployees group.

    4. Select OK.

    5. When prompted to select the workstations you want the group added to, select Linux Workstations.

    6. In the Linux Workstations field, browse to and select your UNIX Workstation – CLE1 object, located in the IF.CLE container.

    7. Click OK.

    8. When prompted that the LUM group was created, select Repeat Task.

    9. Repeat these steps to convert the SLCEmployees.SLC.CLE group to a LUM group.

    10. When prompted that SLCEmployees.SLC.CLE has been converted, click OK.

  7. Convert each user in the IF.CLE container to a LUM user by completing the following steps:

    1. Under the Linux User Management role, select Convert eDirectory User to LUM User.

    2. In the Select User field, browse to and select the first user in your IF.CLE container.

      Warning

      Don't convert your admin user object.

    3. Click OK.

    4. When prompted to specify the primary group for the user, browse to and select your IFEmployees group in IF.SLC.

    5. Deselect the option to convert the user to a Samba user object.

    6. Click OK.

    7. Select Repeat Task.

    8. Repeat these steps for each user in the IF container except for the eGuide, iFolder, and admin user objects.

  8. Repeat these steps to convert each user in the SLC.CLE container to LUM a user. Besure to associate these users with the SLCEmployees.SLC.CLE group.

Now it's time to test the system to verify that LUM is working properly. You will first use iMonitor to configure a directory services trace. Then you will log in as users in your tree and verify that eDirectory was used for authentication. Complete the following steps:

  1. Configure a trace so you can observe authentication requests by completing these steps:

    1. Open a second browser window and navigate to https://your_server_IP_address:8010/nds.

    2. Authenticate to iMonitor as admin with a password of novell.

    3. Select the Trace Configuration icon at the top of the screen.

    4. Select Clear All.

    5. Under the DS Trace Options heading, check Authentication.

    6. Select Trace On.

    7. In the left frame under Trace, select Trace History and then select the Trace icon at the top of the screen. The DS Trace screen should be displayed, as shown in Figure 6.18.

      Figure 6.18. DS Trace.

  2. Try to authenticate as CGrayson.IF.CLE by completing the following steps:

    1. Switch to a shell prompt by pressing Ctrl+Alt+F2 if you are running in a graphical environment. If you are working from the text-based shell prompt without the X Window System, press Alt+F2.

    2. At the login prompt, enter CGrayson and supply a password of novell. You should see a message indicating that a new home directory is being created in /home for CGrayson.

    3. At the shell prompt, enter env. Notice that the shell being used is the sh shell. When we converted the user objects over to LUM users, we didn't configure the default shell, so the system defaulted to sh.

    4. At the shell prompt, enter logout.

    5. Switch back to the main console by pressing Alt+F7 if you're using the X Window System or Alt+F1 if you're working with only text-based consoles.

    6. Check your trace results by selecting Update in iMonitor.

    7. Scroll down and locate the authentication event for CGrayson, as shown in Figure 6.19.

      Figure 6.19. DS Trace results.

    8. Close your iMonitor browser window.

  3. Reconfigure your CGrayson user object to use the bash shell by completing the following steps:

    1. In iManager, select Modify Object under eDirectory Administration.

      Warning

      If it's been more than a few minutes since you last used iManager, you may need to reauthenticate as your admin user.

    2. In the Object Name field, browse to and select the CGrayson.IF.CLE user object.

    3. Click OK.

    4. In the drop-down list, select Linux Profile Page.

    5. In the Login Shell field, enter /bin/bash.

    6. Click OK.

    7. Switch back to the alternate server console by pressing Ctrl+Alt+F2 or Alt+F2.

    8. Authenticate as CGrayson with a password of novell.

    9. At the shell prompt, enter env. You should see that the default shell has changed to the bash shell.

    10. Enter logout and switch back to your first console by pressing Ctrl+Alt+F7 or Alt+F1.

Congratulations! You've successfully configured your Linux system to use eDirectory for authentication. Because of the way the /etc/nsswitch.conf file is configured, you can still use users from the passwd file (such as root and student) as well as eDirectory users from your tree.


Summary

That's it for this chapter. We first discussed the eGuide component of NNLS. You learned how it uses LDAP to pull user data from any LDAP-compliant directory service to populate its address book. You also learned how to customize the attributes displayed in the eGuide interface as well as how to configure which attributes are searchable by the user.

We also discussed the LUM component of NNLS. You learned that LUM can be used to redirect authentication of PAM-enabled modules to eDirectory. Doing so can greatly reduce your administrative tasks on a large, multiserver network. You learned how LUM uses the pam_nam and nss_nam modules to redirect authentication to eDirectory through your LDAP server. You also learned how to convert objects in your tree to LUM objects.

In the next chapter, you're going to learn how to synchronize your eDirectory tree with other directory services using the DirXML component of NNLS.


Chapter 7. Synchronizing User Identities with DirXML

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Describe the purpose of DirXML.

  2. Describe how DirXML works.

  3. Install the DirXML Starter Pack on Linux.

  4. Implement the Delimited Text driver for DirXML.

  5. Implement the eDirectory driver for DirXML.

In the previous chapter, you learned how to implement and manage eGuide and LUM. In this chapter, you're going to build upon that and learn how to synchronize user identities using DirXML.


An Introduction to DirXML

Test Objective Covered:

1. Describe the purpose of DirXML

In a perfect networking world, all stakeholders in an organization would sit down together when the company was formed and they would plan their networking needs—both present and future. They would anticipate all future technology shifts and plan to accommodate them. They would anticipate all future technology issues such as lawsuits, viruses, worms, and denial-of-service attacks and plan to circumvent them.

They would plan for all the applications and services that would ever be needed by the organization and plan for their implementation. They would anticipate the growth of their organization and build an infrastructure to accommodate it. Ah, Nirvana.

Unfortunately, this almost never happens. Most organizations tend to take a more haphazard, evolutionary approach toward their networks. They operate reactively instead of proactively. The maxim tends to be one of "If it ain't broke, don't fix it," until the system breaks and everyone screams, "Fix it!"

In addition, many (if not most) networks develop in silos, meaning that each functional group in the organization develops its own network system independently of other groups. The term silo is borrowed from the agricultural community to describe the unconnected nature of each system. Consider the following hypothetical, yet typical company: ABC, Inc.

ABC, Inc. is composed of the following departments:

  • Product Development

  • Sales and Marketing

  • Customer Service

  • Information Systems

  • Human Resources

Each department in the company has different networking needs. Because of this, each department deploys its own network solution irrespective of the needs of the rest of the organization and without an overall master plan in place.

For example, Customer Service uses a popular help desk application that runs on Windows 2000 Server and has deployed this operating system. All user accounts in the department are stored in the server's Active Directory database.

Sales and Marketing uses an older Windows NT server to provide file, print, and database services. All Sales and Marketing employees have a user account in the NT Domain.

Product Development needs huge amounts of fast, reliable storage space, along with centralized printing. To meet this need, they have deployed NetWare servers and eDirectory. All Product Development employees have a user account in the tree.

The Human Resources department uses PeopleSoft as its employee-management solution. Every employee in the company has a record in the PeopleSoft database.

The Information Systems department is responsible for running the company's digital PBX phone system and email servers. Every employee in the company has an account in the phone system along with a Microsoft Exchange email account. This network is depicted in Figure 7.1.

Figure 7.1. Information silos in a typical network.

Does this type of system work? Yes. Is it efficient and easy to manage? Definitely not. Imagine what would happen if a core team for a new product were to be put together. The team has representatives from each department. To facilitate collaboration, each team member needs access to various resources in each department's system.

For example, they may need access to help desk records for the previous version of the product to identify flaws and customer complaints. They may need a level of access to Product Development files as well as files on the Sales and Marketing servers.

In the network's current state, they have to manage duplicate accounts on the various systems involved. Can it be done? Yes. Is it efficient and easy to manage? No.

Further imagine the network-management tasks that need to happen when a new employee is hired. For example, let's suppose Product Development has hired a new engineer. For this new employee to be productive, she needs an account in the Product Development organization's eDirectory tree. She also needs a record created in PeopleSoft so she can start getting paychecks. She also needs a PBX account created so she can get a phone number assigned to her desk. She will likewise need an Exchange email account set up.

She may also need an account created in the Customer Service organization's Active Directory tree so she can access help desk information about products she'll be assigned to work on. She may even need to have an account in the Sales and Marketing department's NT Domain so she can assist them with technical information about products they are promoting.

To provision this new employee, the network administrator must create and manage five separate user identities in five different systems. Can it be done? Yes. Is it efficient and easy? No. Imagine the workload involved for this kind of organization if it is hiring 100 or more people at a time. It could take some time before new employees are fully provisioned.

You may have actually experienced this situation before if you have ever been hired at a company and had to wait a couple weeks before your email account was set up and a phone number was assigned to you. The first job I landed out of college was with a company that was run in exactly this manner. When I arrived for my first day on the job, I was informed that I would have to share a cubicle with another employee for a time until space could be allocated for me. I would also have to share a PC and a phone with this employee until a new computer was procured and a new phone number was assigned. "Excuse me, but can I use the keyboard for a while?"

One of the happiest days of my tenure at this company was when I got my own cubicle, PC, and telephone. Even after that, it took almost a month before I had Internet access and an email account. The company was in growth mode and was literally hiring hundreds of new employees each month. The network administrators simply couldn't keep up.

Because of this situation, the first six weeks I worked at this company were largely wasted. I couldn't accomplish any of my assignments and these weeks were a waste of my time and the company's money.

Sadly, this situation isn't uncommon. I've heard many similar stories from other individuals. Just recently, I worked with an individual at a company who had to use her personal cell phone to make calls because a PBX account hadn't been set up for her yet. She'd been working there for several weeks.

Unfortunately, this situation is likely to remain the status quo for most organizations. Business needs, market revolutions, technology changes, and other issues make most network master plans outdated after a very short amount of time.

The good news is that NNLS includes a component that can integrate and streamline a network that operates in silos, such as the one described previously, into a efficient, cohesive system. This component is called DirXML.

DirXML is an eDirectory-based service that synchronizes information between different systems, including databases, directories, and applications. Using DirXML in our hypothetical company, ABC, Inc., we could synchronize identities between eDirectory, Active Directory, NT Domains, Microsoft Exchange, PeopleSoft, and the company PBX system. This is shown in Figure 7.2.

Figure 7.2. Bridging silos with DirXML.

DirXML is event driven. When DirXML detects a change in one system, such as adding a new user, it replicates the change to the other systems based on a set of rules and filters you configure.

These rules and filters can be configured such that one system becomes the authoritative source for the entire system. For example, you could configure DirXML such that eDirectory is the central repository and authoritative source of information. Create, delete, and modify operations in eDirectory would be immediately synchronized out to the other systems, but not the other way around.

Alternatively, many organizations configure their PeopleSoft system to be their authoritative source. When an employee is hired, fired, or has any information changed, the event is synchronized to the other systems, including eDirectory.

The nice thing about DirXML is that you can customize it to fit your particular organization's needs. You can configure any supported system to be the authoritative data source.

As the name implies, DirXML extracts data from a data source in the form of an XML document. It then uses stylesheets to transform the XML data into a format the destination system can understand. In this way, information from disparate systems can be harmonized.

Let's explore how DirXML works in more detail.


How DirXML Works

Test Objective Covered:

2. Describe how DirXML works.

Before beginning this topic, you need to understand that DirXML is a complex product. We're going to discuss how it works at the conceptual level only. When DirXML was first released in 2000, I had the opportunity to sit in on a class taught by the software engineers who wrote the product.

The class was full of experienced network consultants. However, by the time the class ended two weeks later, we all had acquired a permanent stupefied look on our faces (accompanied by a nervous twitch). The complexity of the product and the level of detail presented in the class made our heads hurt!

Based on that experience, I will endeavor to make DirXML as easy to understand as I can in this book. Let's get started by reviewing the structure of the DirXML product and its various components.

DirXML Components

DirXML is composed of the following elements:

  • The data source

  • The data destination

  • The DirXML engine

  • The DirXML drivers

  • The subscriber channel

  • The publisher channel

  • The subscriber channel rules and filters

  • The publisher channel rules and filters

These are shown in Figure 7.3.

Figure 7.3. DirXML components.

Let's talk about each component. The data source is the system (usually eDirectory) that is monitored for add, modify, and delete events. It's the authoritative data source mentioned earlier.

The data destination is the system to which data from the data source is being synchronized. The DirXML engine is the heart of DirXML. The DirXML engine itself is composed of two components: the eDirectory interface and the join engine. The eDirectory interface is used by the DirXML engine to connect with the eDirectory service on the server where eDirectory is running.

The join engine processes each add, modify, or delete event that comes to the DirXML engine and applies the various rules you've configured to the event. We'll talk more about rules and filters later in this chapter.

An DirXML driver is a product-specific driver that is used as an interface between DirXML and the product. The Starter Pack version of DirXML that comes with NNLS includes licensed drivers for Windows NT Domains, Active Directory, and eDirectory (which allows you to synchronize two eDirectory trees). It also includes evaluation drivers for PeopleSoft, Lotus Notes, and Microsoft Exchange.

DirXML drivers themselves are composed of two parts. Each driver contains an XML interface that is used to process XML documents going to and coming from the DirXML engine. Each driver also contains a product-specific interface that is used to convert information to and from the native data format of the product.

The subscriber channel is used to send events from the data source through the DirXML engine into the destination system. The publisher channel is used to receive events from the destination system through the DirXML engine and into the data source.

Warning

The names of the two channels would lead one to believe that their functions are the opposite of what they really are. This is a point of considerable confusion.

Remember that the subscriber channel moves data to the data destination and that the publisher channel moves data from the data destination.

Each channel contains its own set of rules and filters. The publisher and subscriber channel rules define what action is to be taken for a given event. Such items evaluated include whether "add" events should be ignored or propagated and whether "delete" events be ignored or propagated.

The publisher and subscriber channel filters are used to specify exactly what information you want synchronized. Let's discuss rules and filters in more depth.

DirXML Filters and Rules

Knowing how to configure rules and filters is key to effectively managing a DirXML implementation. Rules and filters help you define the direction data flows in the DirXML system and what data is replicated and what data is not.

Establishing these elements is how you define an authoritative data source. An authoritative data source is the "point of entry" into the system for network information. From this authoritative data source, data is replicated to the rest of the system.

Configuring Authoritative Data Sources with Filters

You can filter by object class or by specific attributes within an object class. For example, you could specify that users but not groups be synchronized from one system to the others. You could also specify that certain attributes of the user object, such as the mailing address, not be synchronized while the remaining attributes are.

To create an authoritative data source, you remove objects or attributes from the publisher channel filter while adding them to the subscriber channel filter. By doing this, you create a data flow in a single direction. This is shown in Figure 7.4.

Figure 7.4. Establishing authoritative data sources with DirXML filters.

Once you have your filters in place, you next need to configure the various rules for each channel.

DirXML Rules

DirXML rules define what action should be taken for a given event. The DirXML engine monitors the following types of events:

  • Add Object events

  • Modify Object events

  • Rename Object events

  • Move Object events

  • Delete Object events

  • Password Modification events

DirXML uses a number of different rules. Matching rules exist on both the publisher and the subscriber channels. The matching rule is the first rule applied on both channels. The matching rule is invoked whenever an Add Object event is detected.

Tip

The term entry used here refers to any database entry in the various systems synchronized by DirXML, including eDirectory.

Within the rule, you specify the attributes you want entries matched on between systems. For example, you could specify that entries be matched between systems on the given name and surname attributes.

When an Add Object event is detected, the matching rule is invoked and a connection is made between the data source and destination systems. The matching rule then attempts to find an existing entry in the destination system that matches the new entry based on the given name and surname attributes.

If a single match is found in the destination system, an association is established between the two entries. Essentially, the new entry in the source system is said to be the same as the entry found in the destination system.

To understand associations, you need to understand that the databases synchronized by DirXML each use different attributes to function as unique identifiers for database entries. No two entries in the DirXML system can have attributes that share the same values.

In one system, it might be the globally unique ID (GUID) attribute. In another system, it could be the employee number attribute.

When DirXML is installed, the eDirectory schema is extended, and each object in the tree has an association attribute added to it. If the matching rule identifies an association between two entries, the association attribute of the eDirectory object is populated with the ID of the correlating entry in the other system. This is shown in Figure 7.5.

Figure 7.5. Object associations.

If multiple matches are found based on the matching rule criteria, DirXML will discard the event. If no match is found, the Add Object event is propagated on to the next rule.

Besides the matching rules are a handful of others to be aware of:

  • Creation rules— Creation rules also exist on both the publisher and the subscriber channels. The creation rule is applied after the matching rule has been applied.

    The create rule is invoked when an Add event has been detected. The creation rule establishes the attributes that must be populated in the newly created entry in order for the Add event to be propagated.

    For example, you could specify that only entries that have the Given Name and Surname attributes populated be created in the other system.

  • Placement rules— Placement rules exist on both the publisher and subscriber channels. The placement rule is also invoked when an Add event is detected and is applied after the matching and creation rules have been applied.

    The placement rule assumes the Add event has met all the criteria specified in the previous rules and is a valid event. The placement rule determines where in the tree or in the product being synchronized the new entry is to be created.

    The placement rule is usually only needed if the information is being synchronized to a product that uses a hierarchical structure (such as eDirectory or Active Directory). If the information is being synchronized to a flat-file product, the placement rule isn't needed.

    Placement of the new object can be configured based either on the placement of the original entry or on specific attributes of the new entry.

  • Schema-mapping rules— Schema-mapping rules exist on both the publisher and the subscriber channels. On the subscriber channel, the schema-mapping rule is applied before the matching rule. On the publisher channel, the schema-mapping rule is applied after the placement rule has been applied.

    The schema-mapping rule is needed because different database systems use different schemas. DirXML uses the schema-mapping rule to specify which eDirectory objects and attributes map to which entries and attributes in the other system.

    For example, you may map the Given Name attribute in eDirectory to the First Name attribute in the remote system. You might map the Surname attribute in eDirectory to Last name. You could also map the Uid attribute in eDirectory to the User Name attribute in the other system.

One important point to remember is that these rules apply only during Add Object events. Once the Add Object event has been fully propagated, an association is established between the entry in the source system and the entry in the destination system. This association remains until one of the entries is deleted or the network administrator breaks the association.

From there on, any other event, such as a Modify, Rename, or Delete event, that is completed on one of the associated objects is immediately completed on the corresponding object in the other system (depending, of course, on how your filters are configured). The rules discussed here are not needed and, therefore, are not applied.

In addition to filters and rules, both the subscriber and the publisher channels provide transformation stylesheets.

Transformation Stylesheets

Transformation stylesheets are used by both channels to customize the functionality of DirXML. Before delving into these stylesheets, you should know that you don't have to know about them to pass the CLE certification. We're going to briefly cover them, however, so you will understand what they are and how they work if you encounter them when working with DirXML. The transformation stylesheets provided by DirXML include those listed in Table 7.1.

Table 7.1. DirXML Transformation Stylesheets

STYLESHEET

LOCATION

FUNCTION

Data transformation

Subscriber channel (input transformation)

Different systems expect data to be entered in different formats. Data transformation stylesheets are used to convert data from one format to another.

Publisher Channel (output transformation)

For example, one system may store phone numbers without parentheses or dashes, as in 8885551234.

Another system may store them with parentheses and dashes, as in (888) 555-1234.

The data transformation stylesheet is used to convert data to the appropriate format as it passes through the DirXML channel.

Command transformation

Subscriber channel

Command transformation stylesheets are used to customize the commands associated with DirXML events.

Publisher channel

Event transformation

Subscriber channel

Event transformation stylesheets allow you to customize how DirXML responds to events.

Publisher channel

There may be times you don't want an Add event to be propagated as an Add event. You may want it propagated as a Delete or a Modify event to the other system.

That's it for the conceptual structure of DirXML. Let's next turn to a discussion of what happens to your system when DirXML is installed. After that, we'll start configuring some drivers.


Changes Made to the System After DirXML Is Installed

Test Objective Covered:

3. Install the DirXML Starter Pack on Linux.

Before we get going in this section, notice that the objective covered is to "install the DirXML Starter Pack." This objective makes it sound like you need to do something extra to get DirXML going on your system. On other DirXML platforms, such as NetWare, this is the case. You must use a separate CD to install the DirXML product. In NNLS, however, this is not the case.

If you performed an Express install, DirXML was installed on your system. If you performed a Custom install, you had the opportunity to select the DirXML component for installation. If you didn't select DirXML during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select DirXML.

  6. Finish the installation according to the instructions presented in Chapter 5, "NNLS Installation and Administration."

After installing the product, the DirXML file is copied to the following locations in your Linux file system:

  • /var/opt/novell/tomcat4/webapps/nps/DirXML.Dirvers— This directory contains components of the preconfigured drivers that come with DirXML.

  • /usr/lib/dirxml/rules— This directory also contains components of the preconfigured drivers that come with DirXML.

  • /usr/lib/dirxml/classes— This directory contains Java archive files (*.jar) for the DirXML product.

You should also notice that the objective refers to the DirXML Starter Pack. The version of DirXML you received with NNLS is a "starter" version of the product. All the main components of DirXML are the full version except for the drivers.

DirXML Starter Pack Drivers

The DirXML Starter Pack includes licensed drivers for Windows NT Domains, eDirectory, and Active Directory. When you implement these drivers, you'll notice a link in the upper-right corner of the DirXML configuration screens in iManager that prompts you to activate your driver license. This is shown in Figure 7.6.

Figure 7.6. Driver activation is required.

After configuring one of these drivers, you have 90 days to submit a product-activation request to Novell. If you don't submit such a request, the drivers will stop working when the grace period expires.

The DirXML Starter Pack also includes a number of evaluation drivers. These drivers are fully functional for 90 days. After that time, you will need to purchase and activate the drivers or else they will cease to function. The DirXML Starter Pack includes the drivers for the following products:

  • PeopleSoft

  • Microsoft Exchange

  • LDAP

  • Delimited Text

  • SAP

  • JDBC (Java Database Connectivity)

  • GroupWise

  • Lotus Notes

  • SIF (Schools Interoperability Framework)

It should be noted that DirXML isn't limited to just these products. With a proper programming background, you can write your own customized driver to interface with nearly any database.

Let's now discuss the DirXML-specific objects in your eDirectory tree.

DirXML Objects Added to Your Tree

When you install the DirXML component of NNLS on your Linux server, it extends your eDirectory schema to include several new object classes:

  • Driver set object— The driver set object is a new type of container object in the tree. It can only contain DirXML driver objects. Each NNLS server can only have one driver set object associated with it.

  • Driver object— The driver object is a leaf object that represents an active DirXML driver. It can only reside in the driver set object container.

  • Rule object— The DirXML rule objects represent the various rules in your DirXML implementation, including the matching rules, creation rules, placement rules, and schema matching rules. You use these objects to configure the rules for your DirXML system.

From my experience, the best way to learn DirXML is to start working with it. In this book, we're going to implement the Delimited Text driver and the eDirectory driver.


Installing and Configuring the DirXML Delimited Text Driver

Test Objective Covered:

4. Implement the Delimited Text driver for DirXML.

To pass your CLE exam, you need to know how to configure the DirXML Delimited Text driver. This is an interesting driver in that instead of synchronizing eDirectory data with a database, it simply writes the synchronized data out to a comma-delimited text file (*.CSV) in the local file system.

This driver can be used to synchronize with older databases that don't have a DirXML driver written and aren't LDAP compliant. If you can import and export data to a comma-delimited text file, you can use this driver to synchronize data. Granted, it requires more administrative intervention than other drivers (mostly to export and import the CSV files), but considerably less administrative overhead than keeping data synchronized manually.

Implementing the Delimited Text Driver

This is a very useful driver for training students on DirXML (hence why Novell includes the driver in its list of objectives for the CLE). If you make a mistake, nothing blows up.

Note

DirXML is an extremely powerful product. It can do things that network administrators previously could only dream about. With that power, however, comes the risk of potential problems. Simply put, you could really mess up your eDirectory tree and your synchronized databases if you implement DirXML incorrectly. Some of the very first DirXML implementations back in 2000 did just that.

A couple very large companies (I'm not at liberty to name them) adopted DirXML in its earliest release. They configured their drivers incorrectly and turned synchronization on. When they did, it totally wiped out their systems. It took quite some time to restore everything from backup. As you probably know, downtime in a corporate network is a very bad thing.

The key mistake they made was that they implemented DirXML on a live system without testing it first.

Because of this, the DirXML engineers were hesitant about including DirXML in the CLE certification. They were concerned that students would feel they knew everything they needed to know after a basic introduction to the product.

In this regard, there are two things you need to keep in mind. First, understand that you should pursue advanced DirXML training before undertaking a large-scale deployment. DirXML is so complex, you could create a full certification program around this one NNLS component alone. The CLE certification only requires that you understand some very basic DirXML skills and concepts.

Second, when working with DirXML you should model your production network in an isolated lab environment and test DirXML in it first.

Chances are, you'll make many mistakes that will need to be fixed. It's much better to learn from these mistakes in this environment than on your organization's network. If you destroy a production system, it's very unlikely that you will be given the opportunity to learn from your mistake.

As with other drivers, the Delimited Text driver uses a publisher channel and a subscriber channel. The publisher channel is configured to read data from comma-separated (CSV) text files located in a directory that you configure in the local file system.

When read, data from the text file is processed by the DirXML engine using the publisher channel rules. Data that meets the criteria specified in the rules is added to your eDirectory tree.

The publisher channel continually scans the directory every 10 seconds (by default) and reads any CSV files that it finds. After a file is processed, the publisher channel changes its extension to .bak to prevent it from being read again.

The Delimited Text driver's subscriber channel monitors your eDirectory tree for DirXML events (such as Add, Modify, Delete, and Rename). When an event is detected, the event is processed through the subscriber channel's rule set. The resulting output is written to a CSV file in the output directory in the file system.

Tip

The Delimited Text driver requires that the input and output directories be separate directories in the file system.

By default, the first output file opened by the subscriber channel is given a name consisting of a random number with a .csv extension. When the number of entries in the file reaches 200, it is closed and a new output file is opened.

If your system is relatively static, the subscriber channel will still close the output file, even though it doesn't contain 200 entries. By default, the subscriber channel is configured to keep the output file open for only 30 seconds. After that time, it is closed and the next output file is opened and written to.

As with other drivers, the Delimited Text driver uses rules on the publisher and subscriber channels. When you implement the driver, it comes preconfigured with some basic rules, which you can modify to suit your needs. The default configuration of the driver is shown in Table 7.2.

Table 7.2. DirXML Delimited Text Driver Defaults

PARAMETER

DESCRIPTION

Publisher Channel matching rule

Matches entries in the text file with objects inthe eDirectory tree using the Internet Email Address attribute.

Publisher channel create rule

The Given Name and Internet Email Address attributes of a user account must be populated for a corresponding user object to be created in eDirectory.

Publisher channel placement rule

Places new user objects in a container in the eDirectory tree specified when you installed the driver.

Subscriber channel event transformation stylesheet

Because the delimited text driver cycles through multiple CSV files, it can't process Modify, Rename, and Delete events. It converts events as other drivers do with databases such as PeopleSoft.

Instead, these types of events are written as a simple record in the output CSV file. The subscriber channel event transformation stylesheet takes care of this process.

Schema-mapping rule

Maps eDirectory attributes to the configured attributes in the CSV file. The default mappings are as follows:

Surname = LastName
Given Name = FirstName
Internet Email Address = Email
Telephone Number = WorkPhone
Facsimile Telephone Number = Fax
Mobile = WirelessPhone
eDirectory attributes are listed on the left; CSV file attributes are on the right.

Input transformation stylesheet

Transforms each entry in the scanned CSV file in the input directory to an Add event in an XML file to be processed by the DirXML engine in the eDirectory tree.

The username for the new user object in the tree is created by merging the FirstName and LastName attributes for the entry from the text file.

For example, a user named Kimberly Tracy in the text file will have a user object named KimberlyTracy created in the tree.

Output transformation stylesheet

Defines the text-delimiting character and the file format for output files. The default values are the comma character and the CSV file format.

The Delimited Text driver is automatically installed on your system when DirXML is installed as a part of NNLS. Let's discuss how to configure this driver.

Configuring the Delimited Text Driver

To configure the Delimited Text driver on a server, you would need to complete the following steps:

Warning

This is intended to be a generic set of steps. Wait until the upcoming lab exercise to implement DirXML on your server.

  1. Run a web browser and open iManager by navigating to https://your_server_ip_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Under the DirXML Management role, select the Create Driver task. The screen shown in Figure 7.7 appears.

    Figure 7.7. DirXML Create Driver Wizard.

  4. In the Create Driver Welcome screen, select the In a new driver set option and then click Next. When you do, the screen shown in Figure 7.8 appears.

    Figure 7.8. Defining DirXML driver set properties.

  5. In the Name field, enter a name for your Driver Set object in the eDirectory tree.

  6. In the Context field, browse to and select the container in your tree where you want your Driver Set object created.

  7. In the Server field, browse to and select the server you want to associate with the Driver Set object.

  8. Check Create a new partition on this driver set.

    Warning

    By default, the Create Driver Wizard creates a new partition in the eDirectory tree on the DirXML Driver Set object. This is done so that the Master replica of the Driver Set object partition remains on the server where DirXML is installed.

    If you deselect this option, DirXML will still function correctly. However, if you were to move all replicas of the partition where the Driver Set object resides to a different server, DirXML will stop working.

    In a multiserver environment, you should replicate this partition among several servers to increase fault tolerance.

  9. Click Next. The screen shown in Figure 7.9 appears.

    Figure 7.9. Selecting the DirXML driver.

  10. Mark Import a pre-configured driver from the server (.XML file).

  11. From the drop-down list, select the DelimitedTextCSVSample.XML driver.

  12. Click Next. The screen shown in Figure 7.10 appears.

    Figure 7.10. Configuring the DirXML Delimited Text driver.

  13. In the Driver Name field, enter a name for your Delimited Text driver.

  14. In the Output Directory field, enter the directory path in the local file system where the output files from the driver will be created and stored. If this directory doesn't exist, you must create it before starting the driver.

  15. In the Input Directory field, enter the directory path in the local file system where the input files will be stored. If this directory doesn't exist, you must create it before starting the driver.

  16. In the User Container field, enter the container in your tree where you want users created by the driver stored in the tree. If this container doesn't exist, you must create it before starting the driver.

    Warning

    The User Container field requires that you enter the value using a very different format than you have learned in this book. Instead of eDirectory format or LDAP format, this field requires that you enter the container using a slash format, much like a directory path in a file system.

    For example, if you wanted to place users in the IF.CLE container, you would enter CLE\IF in this field. Notice that you use slashes instead of periods or commas. Also, notice that the direction changes. Instead of starting with the object lowest in the tree and working up to the tree root, you start at the topmost container and work down to the container where the users will reside.

  17. Click Next. The screen shown in Figure 7.11 is displayed.

    Figure 7.11. Configuring security equivalences and exclusions.

  18. Assign rights to the driver object in the tree by completing the following steps:

    1. Select Define Security Equivalences.

    2. Click Add.

    3. Browse to and select a user object in the tree that has either the Supervisor right or the Browse, Create, Delete, and Rename rights to the container in the tree where the user objects will be created as well as to the Driver Set object. The driver object you're creating will receive the eDirectory rights assigned to this user object.

    4. Click OK.

  19. Keep your admin user object from being synchronized by completing the following steps:

    Warning

    Because admin doesn't represent an actual employee, you shouldn't replicate it to the other databases in the DirXML system. For example, you wouldn't want admin showing up in a PeopleSoft database or in a PBX system.

    As well, depending on how your rules and filters are configured, you could potentially have changes from the other databases synchronized to your admin user object, potentially making it unusable in your tree.

    1. Select Exclude Administrative Roles.

    2. Click Add.

    3. Browse to and select your admin user object.

    4. Click OK.

  20. Click Next. The summary screen shown in Figure 7.12 is displayed.

    Figure 7.12. The DirXML Create Driver Summary screen.

  21. Click Finish with Overview. The DirXML Overview screen is displayed, as shown in Figure 7.13.

    Figure 7.13. DirXML Overview with a stopped driver.

  22. Start the driver by selecting the red circle with the minus sign icon; then select Start Driver.

  23. Wait while the driver starts.

  24. When the driver has started, the red circle changes to a yin-yang icon, as shown in Figure 7.14.

    Figure 7.14. DirXML Overview with the driver started.

Remember that the Delimited Text driver is an evaluation driver. If you don't activate it within 90 days, the driver will shut down. To activate the driver, select the Activation Required link displayed in the top-right corner of the DirXML Overview page, as shown in Figure 7.15. You will be taken to a Novell website where you can register. Follow the prompts displayed in the web page to complete the activation.

Figure 7.15. Activating the driver.

Let's practice implementing DirXML using the Delimited Text driver on your server in Lab Exercise 7.1.


Lab Exercise 7.1: Working with the DirXML Delimited Text Driver

In this lab, you're going to configure the DirXML Delimited Text driver on your server. Then you will test your driver configuration. Complete the following steps:

  1. Open a terminal session and change to your root user account by entering su - and supplying a password of novell.

  2. At the shell prompt, create your input and output directories in your /tmp directory by entering the following commands:

    • mkdir /tmp/DirXML

    • mkdir /tmp/DirXML/Input

    • mkdir /tmp/DirXML/Output

  3. Run a web browser and open iManager by navigating to https://your_server_IP_address/nps/iManager.html.

  4. Authenticate as admin with a password of novell.

  5. Using the Create Object task under the eDirectory Administration role, create an Organizational Unit named DirXMLUsers in IF.CLE.

  6. Under the DirXML Management role, select the Create Driver task.

  7. In the Create Driver Welcome screen, select the In a new driver set option and then click Next.

  8. In the Name field, enter CLEDriverSet.

  9. In the Context field, enter IF.CLE.

  10. In the Server field, enter CLE1.IF.CLE.

  11. Check Create a new partition on this driver set and then click Next.

  12. Mark Import a pre-configured driver from the server (.XML file).

  13. From the drop-down list, select the DelimitedTextCSVSample.XML driver and then click Next.

  14. Leave the default name in the Driver Name field.

  15. In the Output Directory field, enter /tmp/DirXML/Output.

  16. In the Input Directory field, enter /tmp/DirXML/Input.

  17. In the User Container field, enter CLE\IF\DirXMLUsers.

  18. Click Next.

  19. Assign rights to the driver object in the tree by completing the following steps:

    1. Select Define Security Equivalences.

    2. Click Add.

    3. Browse to and select admin.IF.CLE.

    4. Click OK.

  20. Keep your admin user object from being synchronized by completing the following steps:

    1. Select Exclude Administrative Roles.

    2. Click Add.

    3. Browse to and select admin.IF.CLE.

    4. Click OK.

    5. Click Next.

  21. Click Finish with Overview.

  22. Notice that the driver isn't running. Don't start it yet. Instead, select the Delimited Text driver icon. The screen in Figure 7.16 is displayed.

    Figure 7.16. Driver overview.

  23. Review the schema-mapping rule on the subscriber channel by completing the following steps:

    1. On the subscriber channel, select the schema-mapping rule.

    2. Notice that only the user object class is mapped. Select Properties. The screen shown in Figure 7.17 is displayed.

      Figure 7.17. Schema-mapping rule.

    3. Review the default attribute mappings and then select Cancel, Cancel.

  24. View the placement rule on the publisher channel by completing the following steps:

    1. On the publisher channel, click the Placement Rule icon.

    2. In the DirXML Rule drop-down list, select Edit XML. The screen shown in Figure 7.18 is displayed.

      Figure 7.18. Placement rule.

    3. Notice that users from the CSV text files are placed in the DirXMLUsers.IF.CLE container.

    4. Click Cancel.

  25. Repeat these step to view the event and output transformation stylesheets on the subscriber channel as well as the import transformation, matching, and creation rules on the publisher channel. Be sure you don't change any of the default parameters.

  26. Start the driver by selecting the red circle with the minus sign icon; then click Start Driver.

  27. Wait while the driver starts.

    At this point, the driver should start and you're ready to move to Lab Exercise 7.2.


Lab Exercise 7.2: Testing the DirXML Delimited Text Driver

The Delimited Text driver includes a sample CSV file that we're going to use to test the implementation.

To do this, complete the following steps:

  1. At the shell prompt, enter cp /usr/lib/dirxml/rules/delim/sample.csv /tmp/DirXML/Input.

  2. Remember that the publisher channel polls the configured input directory every 10 seconds. Wait this amount of time and then check to see that the information was synchronized by completing these steps:

    1. Under eDirectory Administration in iManager, select Modify Object.

    2. Click the Browse icon.

    3. Select Browse.

    4. Browse to the DirXMLUsers.IF.CLE container. You should see a large number of new users added by the Delimited Text driver.

    5. Select Cancel, Cancel.

The next thing we need to do is export data from the eDirectory tree to a CSV file in the output directory. Complete the following steps:

  1. In iManager, select the Overview task under the DirXML Management role.

  2. Mark Search Entire Tree and then click Search.

  3. In the DirXML Overview screen, click the Text Delimited icon.

  4. Scroll to the bottom of the page and select Migrate from eDirectory. The screen in Figure 7.19 is displayed.

    Figure 7.19. Migrating users from eDirectory.

  5. Click Add.

  6. Browse to and select the first user in the SLC.CLE container in your tree.

  7. Repeat this process to add all the users in the SLC.CLE container.

  8. Click OK.

  9. When prompted that the migration was started, click OK.

  10. At the shell prompt, enter cd/tmp/DirXML/Output.

  11. Enter ls -l. You should see a CSV file listed with a random number for a file name.

  12. View the contents of the file by entering cat ./file_name.csv |more. You should see an entry for each user you specified for migration from the tree.

  13. Stop the Delimited Text driver by clicking the yin-yang icon in the Driver Overview screen in iManager.

  14. Click Stop Driver.

Congratulations! You just configured your first DirXML driver. The Delimited Text driver is relatively simple compared to the other DirXML drivers. Let's ratchet things up a bit and look at how to synchronize two eDirectory trees using DirXML.


Installing and Configuring the DirXML eDirectory Driver

Test Objective Covered:

5. Implement the eDirectory driver for DirXML.

The DirXML eDirectory driver is a very useful tool. Consider the following hypothetical (although quite common) situation: Suppose ABC, Inc. purchases a smaller company and both companies have their own eDirectory trees populated with network information.

What would the network administrators need to do in order to manage the disparate trees? Prior to DirXML, there were three options:

  • Do nothing and maintain separate trees. This isn't a good solution. To provide users in each tree access to network resources, they must maintain duplicate sets of accounts in each tree.

  • Re-create data from one tree in the main tree. This can be done manually or by using LDIF export files. Either way, this represents a sizeable task.

  • Merge the trees. Two eDirectory trees can be merged together. However, this can be a difficult and dangerous endeavor (ask anyone who has done it in a production environment).

DirXML offers a fourth option that is easier and safer than the others. Using the eDirectory driver, the ABC, Inc. administrator can synchronize data between the trees. He can configure one tree to be the authoritative data source, sending but not receiving updates. He can configure the other tree to be a data consumer, receiving but not sending updates.

Alternatively, he can configure a bidirectional system where changes in either tree are immediately synchronized to the other. Whichever approach is selected, this is done the same as with other DirXML drivers, by implementing publisher and subscriber channel filters.

This driver can be a useful tool in a variety of circumstances, including situations such as company acquisitions (mentioned earlier) and consolidating a multitree organization. It can also be implemented in situations where an organization has deployed an LDAP-compliant application that expects all directory information to reside in a single container (this happens frequently).

Using the eDirectory driver, you can configure a second tree in your organization and synchronize all directory data from your production tree (which is hierarchical) to the secondary tree (which is flat).

About the DirXML eDirectory Driver

The eDirectory driver is unique among the various DirXML drivers. With most drivers, there is a driver installed for the third-party database. Only one instance of DirXML is installed and configured, as shown in Figure 7.20.

Figure 7.20. Using DirXML with a third-party database.

When you're using the eDirectory driver, however, things are little bit different. First of all, DirXML is installed on both servers that have trees to be synchronized. Second, an eDirectory driver is configured on both servers, as shown in Figure 7.21.

Figure 7.21. Using DirXML with eDirectory.

Another (third) difference is in the way the publisher and subscriber channels are configured. To understand this, let's use the analogy of how to make a null modem cable out of a serial cable. All you have to do is rewire the cable plug such that the Tx (transmit) wire in the cable connects to the Rx (receive) wire in the serial port plug on the PC. Configured this way, transmitted data is sent from the Tx wire to the Rx wire in the port, and vice versa.

Essentially, you have the same situation with the DirXML eDirectory driver. Because you have two drivers and two DirXML engines, you have two publisher channels and two subscriber channels.

The eDirectory drivers are configured such that the publisher channel in one tree is connected to the subscriber channel in the other, and vice versa. This is depicted in Figure 7.21.

This can complicate things a bit for the NNLS implementer. It means that information travels first through the first tree's subscriber filter—having all its rules and filters applied—and then through the other tree's publisher channel—having all its rules and filters applied.

Having set this kind of implementation up several times, I can tell you that if you can keep this one point in mind, it will make configuring the eDirectory driver much easier for you. My experience has been that it is very easy to think from the standpoint of one tree or the other, but not both at the same time. By forgetting that the subscriber channel becomes the publisher channel, and vice versa, you can potentially make grievous mistakes when configuring your drivers.

You also need to be concerned with object placement. With most other DirXML drivers (with the exception of the Active Directory driver), data is being synchronized with a flat-file database. Object placement in this situation is rather easy. If you're good with the XML markup language, you can even customize your placement rule such that placement is based on a particular attribute.

For example, you can configure the rule such that if the PeopleSoft database shows an employee's address to be in Idaho Falls, Idaho, DirXML automatically creates the associated user object in the IF.CLE container. If the employee's address is in Salt Lake City, Utah, on the other hand, the object is created in the SLC.CLE container.

The fact that one system in the implementation is flat makes this kind of configuration relatively easy. With the eDirectory driver, however, you're dealing with a hierarchical system on both ends of each driver. As a result, object placement becomes more complicated.

As mentioned, it is critical that you think systemically when configuring the eDirectory drivers' placement rules. You must consider how data flows in the system to properly configure the rules. If you don't, you're going to spend a lot of time looking at your tree wondering, "Why is that object being synchronized there?"

Because writing customized placement rules requires a fair amount of XML knowledge (which you don't need to know for the CLE exam), the eDirectory driver includes several predefined placement options that you can use. These options are what we will focus on in this book. They are listed in Table 7.3.

Table 7.3. DirXML eDirectory Driver Placement Options

OPTION

DESCRIPTION

Flat

This option allows you to define a base container for user objects and a base container for group objects in the destination tree.

All objects (users and groups) from the source tree are placed in their respective base container in the destination tree, regardless of where they existed in the source tree's hierarchy.

For example, suppose you specify that the base user container for the destination tree to be .IF.CLE. If you synchronized KRitter.IS.PROVO.NOVELL and JCarr.IS.CAMBRIDGE.NOVELL to this tree, they would both be synced to the IF.CLE container.

Mirrored

This option allows you to specify a base container in the destination tree. When data is synchronized, the original hierarchical structure from the source tree is replicated within the base container in the destination tree.

For example, if you specified the base container to be IF.CLE and were to synchronize the same user objects listed previously, the result would be a user object named KRitter.IS.PROVO.NOVELL.IF.CLE and a user object named JCarr.IS.CAMBRIDGE.NOVELL.IF.CLE.

Department

This option is similar to the mirrored option. However, instead of the entire source tree hierarchy in the base container you specified in the destination tree being mirrored, only the parent container of the object is created.

For example, if you configured a base container of IF.CLE and were to synchronize the same user objects listed previously from the source tree, the result would be a user object named KRitter.IS.IF.CLE and a user object named JCarr.IS.IF.CLE.

As with other DirXML drivers, the eDirectory driver requires that the server where DirXML is installed have either a Read/Write or a Master replica of the partition where the data to be synchronized resides. The DirXML engine needs to be able to write data as well as read it; therefore, Read Only or Subordinate Reference replicas won't work.

Let's discuss how to configure the eDirectory driver.

Configuring the eDirectory Driver

As with the Delimited Text driver, the eDirectory driver is automatically installed along with the DirXML component of NNLS. To configure this driver in a DirXML system, you would complete the following steps:

Warning

Wait until the upcoming lab exercise to implement this driver. The following steps are generic steps.

  1. Run a web browser and open iManager by accessing https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Under the DirXML Management role, select the Create Driver task.

  4. In the Create Driver Welcome screen, select the In a new driver set option and then click Next.

  5. In the Name field, enter a name for your Driver Set object in the eDirectory tree.

  6. In the Context field, browse to and select the container in your tree where you want your Driver Set object created.

  7. In the Server field, browse to and select the server you want to associate with the Driver Set object.

  8. Check Create a new partition on this driver set.

  9. Click Next. The screen shown earlier in Figure 7.9 appears.

  10. Mark Import a pre-configured driver from the server (.XML file).

  11. From the drop-down list, select the eDIR-Driver.xml driver.

  12. Click Next. The screen shown in Figure 7.22 appears.

    Figure 7.22. Configuring the eDirectory driver.

  13. In the Driver Name field, enter a name for this driver.

  14. In the Remote Tree Address and Port fields, enter the IP address of the server running DirXML in the remote tree. The port number should be set to 8196.

  15. In the Configure Data Flow drop-down list, select the role the local server will play. You have the following options:

    • Bidirectional— Selecting this option will configure the driver to send synchronization events to the remote tree and to accept incoming synchronization events.

    • Authoritative— Selecting this option will configure the driver to send synchronization events to the remote tree, but it will not accept incoming synchronization events.

    • Subordinate— Selecting this option will configure the driver to accept incoming synchronization events, but not to send them.

  16. In the Configuration Option drop-down list, select the placement option you wish to use. You can select from the following:

    • Mirrored

    • Flat

    • Department

    The function of these options was presented earlier in this chapter. The one you choose depends on the way you want your DirXML system to work. The files that configure these placement options are located in /usr/lib/dirxml/rules/nds2nds.

  17. If you selected the Mirrored option, enter the desired base container for synchronization in the Remote Base Container field.

  18. In Base Container field, enter the base container for synchronization in the local tree. If you selected Mirrored, this is the local base container to mirror with the remote base container from step 17. If you selected Flat, this is the container to place users into. If you selected Department, this is the parent of the departmental containers.

  19. If you selected the Flat option, enter the base container in the local tree to place synchronized groups into in the Group Container field.

  20. Select Next. The screen shown in Figure 7.23 is displayed.

    Figure 7.23. Configuring security equivalences and exclusions for the eDirectory driver.

  21. Assign rights to the driver object in the tree by completing the following steps:

    1. Select Define Security Equivalences.

    2. Click Add.

    3. Browse to and select a user object that has administrative rights to the tree.

    4. Click OK.

  22. Keep your admin user object from being synchronized by completing the following steps:

    1. Select Exclude Administrative Roles.

    2. Click Add.

    3. Browse to and select your admin user object.

    4. Click OK.

  23. Click Next. The summary screen shown in Figure 7.24 is displayed.

    Figure 7.24. The DirXML eDirectory Driver Summary screen.

  24. Click Finish with Overview. The DirXML Overview screen is displayed, as shown in Figure 7.25.

    Figure 7.25. DirXML Overview with a stopped eDirectory driver.

  25. Repeat all these steps to configure the eDirectory driver on the server in the other tree.

  26. When configuration of both drivers is complete, start them by selecting the red circle with the minus sign icon; then select Start Driver.

  27. Wait while the drivers start.

  28. When the drivers have started, the red circle changes to a yin-yang icon.

Remember that the eDirectory driver is an evaluation driver. If you don't activate it within 90 days, the driver will shut down. To activate the driver, select the Activation Required link displayed in the top-right corner of the DirXML Overview page.

At this point, you should edit the filters and rules for each channel on each server to configure the dataflow in the manner you desire. Remember that DirXML is event driven. Just having the drivers installed and configured will not automatically synchronize the two trees. As you will see later in the chapter, you can initially synchronize the two trees using the Migrate from eDirectory and the Migrate to eDirectory options in iManager.

Let's practice implementing the DirXML eDirectory driver and configuring these parameters in Lab Exercise 7.3.


Lab Exercise 7.3: Working with the DirXML eDirectory Driver

In this lab, you're going to configure the DirXML eDirectory driver on two servers. Then you will test your driver configuration.

Warning

To complete this exercise, you will need a second computer that can communicate through a network medium with the server you have been working with throughout this book. This may present a challenge for you, and you may be tempted to skip this exercise. Before you do, be aware that you will probably need to know how to configure this driver to pass the CLE exam.

VMWare can be particularly useful in this exercise. With enough system RAM, you can run two virtual Linux sessions concurrently on the same physical PC hardware. See http://www.vmware.com for more information.

Complete the following steps:

  1. Secure a second PC system that meets the requirements specified for NNLS.

    Warning

    Be sure you back up any data on this PC that you want to preserve!

  2. Install SLES 8 on this second system. Name the server CLE2.

  3. Configure the server to use CLE1 as its primary DNS server.

  4. Configure the NTP daemon on CLE2 to synchronize its time with CLE1.

  5. Download and install the OpenSLP package on CLE2.

  6. Configure the slp.conf file such that CLE2 is a Directory Agent (DA) and services the same scope as CLE1. Refer to Chapter 5 for specific instructions.

  7. Add the multicast route to CLE2 and start the slpd daemon. Refer to Chapter 5 if you need specific directions on how to do this.

  8. Install NNLS on this second system using the ISO images and NICI files you downloaded for the lab exercises in Chapter 5. Use the following parameters:

    • Install Type—Express Install

    • Tree Name—CLE2-TREE

    • Admin Name—cn=admin.ou=CLE.O=ANNAPOLIS

    • Admin Password—novell

    • Domain Name for NetMail Server—CLE1.com

  9. Add containers to hold synchronized objects in your CLE-Tree by completing the following steps:

    1. Run a web browser and open iManager by navigating to https://your_CLE1_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Using the Create Object task under the eDirectory Administration role, create an Organizational Unit named RemoteUsers in IF.CLE.

    4. Using the Create Object task under the eDirectory Administration role, create an Organizational Unit named RemoteGroups in IF.CLE.

  10. Prepare your CLE2-Tree for DirXML synchronization by completing the following steps:

    1. Run a web browser and open iManager by navigating to https://your_CLE2_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Using the Create Object task under the eDirectory Administration role, create an Organizational Unit named RemoteUsers in CLE.ANNAPOLIS.

    4. Using the Create Object task under the eDirectory Administration role, create an Organizational Unit named RemoteGroups in CLE.ANNAPOLIS.

    5. Add the following users to your CLE2-Tree:

      User

      Attribute

      Value

      JAstin

      First Name

      John

      Last Name

      Astin

      Context

      CLE.ANNAPOLIS

      Password

      Novell

      Title

      Director of Operations

      Location

      Annapolis, MD Office

      Department

      Operations

      Telephone

      555-555-5551

      Fax

      555-555-5552

      Email Address

      jastin@cle2.com

      JShannon

      First Name

      Jerry

      Last Name

      Shannon

      Context

      CLE.ANNAPOLIS

      Password

      Novell

      Title

      Facilities Manager

      Location

      Annapolis, MD Office

      Department

      Operations

      Telephone

      555-555-5553

      Fax

      555-555-5552

      Email Address

      jshannon@cle2.com

      KLarsen

      First Name

      Kimberly

      Last Name

      Larsen

      Context

      CLE.ANNAPOLIS

      Password

      Novell

      Title

      Facilities Manager

      Location

      Annapolis, MD Office

      Department

      Operations

      Telephone

      555-555-5550

      Fax

      555-555-5552

      Email Address

      klarsen@cle2.com

      DAverett

      First Name

      Darren

      Last Name

      Averett

      Context

      CLE.ANNAPOLIS

      Password

      Novell

      Title

      Administrative Assistant

      Location

      Annapolis, MD Office

      Department

      Operations

      Telephone

      555-555-5554

      Fax

      555-555-5552

      Email Address

      daverett@cle2.com

  11. Verify that the time on both servers is synchronized by completing the following steps:

    1. Open a terminal session on both servers.

    2. At both shell prompts, enter ntpq -p.

    3. CLE1 should report an offset of less than 1 second with the public NTP time source you configured in an earlier exercise. Remember that the offset is displayed in milliseconds.

    4. CLE2 should report an offset of less than 1 second with CLE1.

      Note

      As an alternative, you could configure CLE2 to get its time from the same public time provider as CLE1. It doesn't matter, as long as the time on the two servers is the same.

    5. If you've lost synchronization, refer to the steps listed in Chapter 5 to reestablish time synchronization using NTP.

  12. Configure the eDirectory driver on CLE1 by completing the following steps:

    1. Run a web browser and open iManager by navigating to https://your_CLE1_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Under the DirXML Management role, select the Create Driver task.

    4. In the Create Driver Welcome screen, select In an new driver set and then click Next.

    5. In the Name field, enter CLEDriverSet2.

    6. In the Context field, enter IF.CLE.

    7. In the Server field, enter CLE1.IF.CLE and then click Next.

    8. In the Import a pre-configured driver from the server (.XML file) drop-down list, select eDIR-Driver.xml and then click Next.

    9. In the Driver Name field, enter eDIR-Driver.

    10. In the Remote Tree Address and Port fields, enter the IP address of your CLE2 server. Be sure 8196 is entered in the Port field.

    11. In the Configure Data Flow drop-down list, select Bidirectional.

    12. In the Configuration Option drop-down list, select Flat.

    13. In the Base Container field for users, enter RemoteUsers.IF.CLE.

    14. In the Group Container field, enter RemoteGroups.IF.CLE.

      Warning

      In steps m and n, don't use the Browse button. It causes problems!

    15. Click Next.

    16. Select Define Security Equivalences.

    17. Click Add.

    18. Browse to and select admin.IF.CLE and then click OK.

    19. Select Exclude Administrative Roles.

    20. Click Add.

    21. Browse to and select admin.IF.CLE and then click OK.

    22. Click Next.

    23. In the Summary screen, click Finish with Overview.

  13. Configure the filters in the CLE1-Tree by completing the following steps:

    1. In iManager, view the Driver Overview screen by selecting the eDirectory icon.

      Warning

      Don't select the red minus sign, which is used to start and stop the driver.

    2. On the subscriber channel, select the Subscriber Filter icon. The attributes displayed are those that are allowed through the filter.

    3. Notice that the Access Control List (ACL) attribute is allowed through the filter. This should be removed. Most ACLs contain tree-specific information that can cause synchronization problems. Select For All Classes in the Filter.

    4. In the right column, deselect the ACL attribute and then click OK.

    5. Click OK.

    6. On the publisher channel, select the Publisher Filter icon.

    7. Notice that the ACL attribute is also allowed through on the publisher channel. Repeat the preceding steps to remove this attribute.

  14. Review the default publisher and subscriber channel rules by completing the following steps:

    1. On the publisher channel, select the Creation Rule icon.

    2. In the DirXML Rule drop-down list, select Edit XML. Notice that user objects must have the Given Name and Surname attributes populated in order for them to be created in the tree.

    3. Click Cancel.

    4. On the publisher channel, select the Placement Rule icon.

    5. In the DirXML Rule drop-down list, select Edit XML. Notice that users will be placed in RemoteUsers.IF.CLE and groups will be placed in RemoteGroups.IF.CLE.

    6. Click Cancel.

    7. On the publisher channel, select the Matching Rule icon.

    8. In the DirXML Rule drop-down list, select Edit XML. Notice that users will be matched on the CN, Given Name, and Surname attributes. Also, notice that groups will be matched only on the CN attribute.

    9. Click Cancel.

    10. In the Driver Overview screen, notice that the input transformation rule, schema-mapping rule, event transformation rule, and the command transformation rule are all blank. Because we're synchronizing two similar databases, these aren't needed.

    11. Also in the Driver Overview screen, notice that none of the subscribe channel rules are populated. Because the subscriber channel is connected to the publisher channel on the other system, the rules on the remote publisher channel will be used to configure data.

  15. Configure the eDirectory driver on CLE2 by completing the following steps:

    1. Run a web browser and open iManager by navigating to https://your_CLE2_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Under the DirXML Management role, select the Create Driver task.

    4. In the Create Driver Welcome screen, select In an new driver set and then click Next.

    5. In the Name field, enter CLE2DriverSet.

    6. In the Context field, enter CLE.ANNAPLOLIS.

    7. In the Server field, enter CLE2.CLE.ANNAPOLIS and then click Next.

    8. In the Import a pre-configured driver from the server (.XML file) drop-down list, select eDIR-Driver.xml and then click Next.

    9. In the Driver Name field, enter eDIR-Driver.

    10. In the Remote Tree Address and Port fields, enter the IP address of your CLE1 server. Be sure 8196 is entered in the Port field.

    11. In the Configure Data Flow drop-down list, select Bidirectional.

    12. In the Configuration Option drop-down list, select Flat.

    13. In the Base Container field for users, enter RemoteUsers.CLE.ANNAPOLIS.

    14. In the Group Container field, enter RemoteGroups.CLE.ANNAPOLIS.

    15. Click Next.

    16. Select Define Security Equivalences.

    17. Click Add.

    18. Browse to and select admin.CLE.ANNAPOLIS and then click OK.

    19. Select Exclude Administrative Roles.

    20. Click Add.

    21. Browse to and select admin.CLE.ANNAPOLIS and then click OK.

    22. Click Next.

    23. In the Summary screen, click Finish with Overview.

  16. Configure the filters in the CLE2-Tree by completing the following steps:

    1. In iManager, view the Driver Overview screen by selecting the eDirectory icon.

      Warning

      Don't select the red minus sign, which is used to start and stop the driver.

    2. On the subscriber channel, select the Subscriber Filter icon.

    3. Select For All Classes in the Filter.

    4. In the right column, deselect the ACL attribute and then click OK.

    5. Click OK.

    6. On the publisher channel, select the Publisher Filter icon.

    7. Select For All Classes in the Filter.

    8. In the right column, deselect the ACL attribute and then click OK.

    9. Click OK.

  17. Start the eDirectory driver on both servers by completing the following steps:

    1. Open a second browser window and open https://your_CLE1_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Under DirXML Management, select Overview and then select Search.

    4. Select the eDirectory driver icon in the CLEDriverSet2 driver set.

    5. You should now have two browser windows, one with the CLE1 Driver overview displayed, and the other with the CLE2 Driver overview displayed.

    6. In each window, select the red minus sign and then select Start Driver.

    Tip

    If you experience problems with starting the driver, you may need to restart the ndsd daemon. Do this by entering /etc/init.d/ndsd stop and then /etc/init.d/ndsd start. Then refresh the Overview screen.

  18. Check the state of the synchronization by completing the following steps:

    1. In both trees, use the Modify Object task under eDirectory Administration to browse the contents of the RemoteUsers containers.

    2. Notice that they are empty. The eDirectory driver is event driven. Without an event, no synchronization occurs.

    3. Click Cancel.

  19. Manually migrate users by completing the following steps:

    1. In the CLE2 iManager browser window, select the Overview task under the DirXML Management role.

    2. Click Search.

    3. Select the eDirectory driver icon.

    4. Scroll down to the bottom of the page and select Migrate from eDirectory.

    5. In the Migrate Data screen, click Add.

    6. Browse to CLE.ANNAPOLIS and select JAstin.

    7. Repeat this to add the rest of the users, except for admin, eGuidePublicUser, and iFolder_ServiceAgent, in the CLE container.

    8. Click OK.

    9. When prompted that the migration was started, click OK.

    10. Wait while the users are migrated.

    11. When the migration is complete, click OK.

    12. Switch to your CLE1 iManager browser window.

    13. Use the Modify Object task under the eDirectory Administration role to browse the contents of the RemoteUsers.IF.CLE container. You should see all the users you migrated from the remote tree.

    14. Select Cancel, Cancel.

    15. In the CLE1 iManager browser window, repeat the preceding steps to migrate all users in the IF.CLE container, except for admin, eGuidePublicUser, and iFolder_ServiceAgent, to the CLE2-Tree.

    16. Switch back to the CLE2 iManager browser window.

    17. Use the Modify Object task under the eDirectory Administration role to browse the contents of the RemoteUsers.CLE.ANNAPOLIS container. You should see all the users you migrated from the remote tree.

  20. Recall that the matching rule establishes associations between objects in the connected systems. Changes made to one object should be synchronized to its associated object in the other tree. Test synchronization by completing the following steps:

    1. In the CLE2 iManager browser window, use the Modify Object task to change the title of the KLarsen.CLE.ANNAPOLIS user object to Assistant Director.

    2. In the CLE1 iManager browser window, use the Modify Object task to verify that the title of the KLarsen.RemoteUsers.IF.CLE user was changed to Assistant Director.

  21. eDirectory synchronization is working! Before ending this exercise, shut down your DirXML drivers on both servers by completing the following steps:

    1. In your CLE1 iManager browser window, select Overview under DirXML Management.

    2. Select Search.

    3. Click the yin-yang icon for the eDirectory driver and then select Stop Driver.

    4. Switch to your CLE2 iManager window and repeat these steps to shut down the eDirectory driver on CLE2.

    5. In the eDirectory driver overview, select the eDirectory Driver icon.

    6. In the drop-down menu, select Driver Configuration.

    7. Scroll down to the Startup options and select Disabled.

    8. Click OK.

Congratulations! You have just successfully configured and implemented the most difficult component of NNLS. Although difficult to learn, once you get the hang of DirXML, the possibilities are immense.


Summary

In this chapter, you learned about the business problems DirXML is designed to solve. By synchronizing data silos, you can add a high degree of efficiency to your organization.

You also learned that DirXML expresses data in the form of XML documents. The DirXML engine uses rules and filters on the publisher and subscriber channels to reformat the data in a manner that third-party databases can understand. DirXML drivers are used to interface with these databases and synchronize data.

You then learned how to implement a simple DirXML driver: the Delimited Text driver. You learned how to use this driver to read and write eDirectory data to CSV files that can be imported and exported to and from non-LDAP-aware databases.

With the basics down, you then learned how to configure the DirXML eDirectory driver to synchronize users and groups between two eDirectory trees. You also learned how to configure the publisher and subscriber filters to prevent unwanted attributes from being synchronized.

In the next chapter, you will learn how to deploy iFolder, one of Novell's most powerful end-user productivity tools.


Chapter 8. Implementing File Services with iFolder, Samba, and NetStorage

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Describe the purpose and architecture of iFolder.

  2. Install and configure iFolder.

  3. Describe the purpose and architecture of Samba.

  4. Install and configure Samba.

  5. Describe the role and function of NetStorage.

  6. Install and configure NetStorage.

In the previous chapter, you learned how to implement the Delimited Text and eDirectory DirXML drivers. In this chapter, you're going to learn how to increase end-user productivity with the three file-access components of NNLS: iFolder, Samba, and NetStorage.


An Introduction to iFolder

Test Objective Covered:

1. Describe the purpose and architecture of iFolder.

The iFolder component of NNLS is one of the coolest features of the product. iFolder solves two key problems network administrators face when working with end users' files:

  • End users use multiple PCs to do their work. The average employee uses a desktop PC at his or her desk, a laptop on the road, and his or her home computer when working from home.

  • End users tend to save their work on the local hard drives of these computers instead of using network storage.

These two factors cause headaches for network administrators and end users alike. For instance, end users must figure out a means for transferring their work files between these various computers. Sometimes, smaller files can be accommodated by floppy disks, whereas large files may be transferred by burning a CD.

Lately, one of the more popular means is email. Prior to iFolder, one of the easiest ways to get a large file from your work computer to your home computer was to simply email it to yourself. At home, you download the file to the local hard drive and work on it. When done, you send it back to yourself and download the updated version of the file at work.

This can lead to a critical issue: version control. If you've ever juggled files using the process described here, you know that you eventually end up with many different versions of the same file.

The risk of doing the wrong thing with the wrong file is significant in this situation. Is that file you just sent to your boss the final version, or did you accidentally send her an older version? Is that file you're about to delete an old version of the file, or is it the latest version? There's nothing more frustrating than the realization that you just erased the only good copy of a file you had.

The other problem this scenario presents is that of backup. Recall that we began the previous chapter with a description of the "ideal network." This network was planned before it was implemented and all possible contingencies were accounted for.

A key element of this ideal network is that users would save their data on a network storage medium instead of their local hard drive. The reason for this is simple: backup. If you're a network administrator worth your salt, you back up your server's storage media religiously. There's no better way to lose your job in the IT industry than to not have a current backup available after a system goes down.

In the real world, however, users almost universally persist in saving their work on the local hard drive. The reasons for this vary. For some, the network access time is too slow and they want file open and file save operations to be faster. Some fear that sensitive documents will be visible to others if saved on a network server. Others simply save their files on the local drive because that's the default location presented when they select File, Save As.

The problem with this is that most network administrators don't back up hard drives on users' workstations. The amount of time and tape space required to do this makes it unfeasible for all but the smallest organizations.

Imagine trying to back up thousands of 40GB workstations' hard disk drives each night. The fact that user workstations don't get backed up means that a huge amount of a given organization's intellectual property is continually at risk.

The iFolder component of NNLS is designed to fix these problems. iFolder is a slick product from Novell that synchronizes files between users' workstations and the iFolder server.

If users create, modify, or delete files of any type from a specified directory on their local hard drive, the changes are synchronized to a copy of the files stored on the iFolder server. Doing this allows end users to keep saving their files on their local hard drives as they are used to, but it also keeps an identical copy of their work on the iFolder server, which is backed up regularly.

If a given user logs in from a different computer, all his files are synchronized from the iFolder server down to the new computer. It doesn't matter whether the new computer is a laptop in a hotel room or a PC in the user's home office.

Warning

Remember that iFolder only synchronizes changes to files. However, if the user connects with a different PC (such as a borrowed laptop), all the files will need to be initially downloaded. If the user is connected with a modem, this could take some time.

Any changes he makes to these files is, again, synchronized back to the iFolder server. Then, when the user accesses them from his desk computer at work, all the changes he made are synchronized back to that system. This is shown in Figure 8.1.

Figure 8.1. iFolder data synchronization.

Sounds pretty good, huh? I've had many opportunities to introduce network administrators over the years to iFolder. I love the look that comes over their faces when they realize what it could do for them. Universally, they all say the same thing: "Coooooooooool…." Especially when it is mentioned that iFolder is extremely scalable. It has been tested with up to 10,000 users working on a single iFolder server!

Let's look at how iFolder works.

How iFolder Works

The iFolder service is composed of three components:

  • The iFolder server— The iFolder server is responsible for storing user files and synchronizing them.

  • The iFolder client— The iFolder client is a small piece of client software installed on Windows workstations. When it is installed, a specific directory on the workstation is configured as an iFolder directory.

    Tip

    Rumor has it that an iFolder client for Linux is due out from Novell any time.

    If you create a file in this directory, the iFolder client will synchronize it to the iFolder server. If you modify an existing file in this directory that has already been synchronized to the iFolder server, the changes will be applied to the version of the file that resides on the server.

    One cool feature of iFolder is the fact that it doesn't synchronize the entire file. Only the change made to the file is copied. This conserves huge amounts of network bandwidth and makes iFolder a feasible solution for dial-up connections.

    For example, suppose you have a 5MB word-processing file in the iFolder directory on your home PC. Your PC uses a 56Kbps dial-up connection to access the Internet. You review the document and notice an "a" that needs to be changed to "an" and you make the correction.

    If iFolder synchronized the entire file, it would take more than an hour to apply the change. However, iFolder only synchronizes the 4KB block of data where the addition of the letter n was saved. This transaction occurs in a matter of seconds.

    If you were to delete a file that resides in the iFolder directory on your workstation, the corresponding file stored on the iFolder server would be deleted as well.

  • The iFolder applet— If users need to access their iFolder files from a workstation that doesn't have the iFolder client installed, they can access the iFolder server using the Internet Explorer 5.0 or later web browser. The iFolder applet allows the user to download and upload his or her iFolder files.

    This is a nice solution that can be a real lifesaver for remote users who are in a panic trying to get access to their files. However, if your iFolder server resides behind your corporate firewall, you need to make sure ports 80 and 443 are opened up so users outside the firewall can get to the iFolder server.

Let's look at how iFolder leverages LDAP and eDirectory to control access.

How iFolder Authentication Works

iFolder uses encryption to protect data as it crosses the network. When users authenticate to iFolder, they must supply both a password and a pass phrase. The pass phrase is used to encrypt the files and protect them from prying eyes.

When a user authenticates, the iFolder server accesses eDirectory using LDAP to check the users' credentials. If the credentials match, the user is given access to the files associated with his or her user identity. The iFolder server can be configured to use the insecure LDAP port (389) or the secure LDAP port (636). Unless you have a good reason not to, you should always configure iFolder to use the secure port 636.

The reason to use port 636 is because the LDAP service doesn't have to be running on the same server as iFolder (although it can be). The iFolder service can use the LDAP service on any server in the eDirectory tree. If you use the insecure LDAP port and you have iFolder and LDAP running on different servers, all authentication information, such as usernames and passwords, will be transferred in clear text, thus allowing them to be easily captured using a network sniffer.

Tip

iFolder can also use Active Directory to authenticate users.

If you have iFolder running on the same server as the LDAP service, you can get away with using port 389. Because all LDAP queries from the iFolder server are made on the same machine, they don't cross the network medium and can't be sniffed. It's still good form, however, to use the secure LDAP port (636).

If you choose to use port 636 and your LDAP service is running on a different server than your iFolder server, you'll need to complete some additional configuration steps. You will need, for example, to export the LDAP server's trusted root certificate and copy it to your iFolder server.

It's also important to note that you can configure a single iFolder server to use up to eight different LDAP services to authenticate users. This is useful if your organization has multiple directory services where user accounts are stored.

Many students new to iFolder at this point ask, "If ports 80 and 443 must be opened up on the firewall for iFolder to work, should I also open ports 389 and 636 so LDAP authentication works too?"

Actually, no, they probably don't need to be opened. This is because the iFolder client doesn't send the LDAP requests to the LDAP service. It's the job of the iFolder server to do this. If both the iFolder service and the LDAP service are either behind the firewall or on the same server, you don't need to open the LDAP port(s) in your firewall configuration—and this is usually the case.

If, for some reason, a firewall exists between your iFolder server and your server running the LDAP service, you need to open up your LDAP ports in your firewall configuration.

With that in mind, let's turn to a quick overview of the synchronization process.

Synchronizing Files with iFolder

The first time you log in to your iFolder server with the iFolder client, an account is created for your user object on the iFolder server and an iFolder directory is created in the local Windows user account's My Documents directory, as shown in Figure 8.2.

Figure 8.2. iFolder synchronization directory.

In addition, a shortcut to the iFolder directory is placed on the desktop for the local Windows workstation user account; this is shown in Figure 8.3.

Figure 8.3. iFolder shortcut.

With the iFolder directory created, you can begin using iFolder to synchronize data. iFolder uses the following process to do this:

  1. The user supplies the required login credentials to the iFolder client running on his or her workstation.

  2. The iFolder client sends these credentials to the iFolder server.

  3. The iFolder server binds to the configured LDAP service and verifies the user credentials in eDirectory.

  4. The iFolder client compares the files in the local iFolder directory against the files in the user's account on the iFolder server and identifies any 4KB file blocks that don't match up.

  5. The iFolder client downloads any changes to existing files it has identified from the iFolder server. As mentioned earlier, the iFolder client doesn't download the entire file. It only downloads the 4KB blocks where data has been changed.

  6. The iFolder client uploads any new files or blocks of files that have been changed since the last synchronization.

  7. The iFolder server marks the files it has received as having been synchronized. It uses an attribute called the Sync Index Number. The iFolder server and client use this attribute in the future to determine whether a given file is synchronized or not. A file that has the identical value in this attribute in the server and client versions is assumed to be synchronized. A file that has differing values is assumed to be out of synchronization.

    If the two versions of the file have the same Sync Index Number but are obviously different, the file is said to have a conflict. iFolder will then compare the time stamps on the two versions to determine which version is the most current and use synchronization to update the other.

Note

If a conflict is detected, iFolder will keep the older version of the file in the Conflict Bin, just in case it was the correct version.

With this introductory material in mind, let's dig in so you can learn how to install and configure iFolder on your server.


Installing and Configuring iFolder

Test Objective Covered:

2. Install and configure iFolder.

Notice that the CLE objective we're covering in this section of the chapter requires you to install and configure iFolder. However, we're not going to spend a great deal of time reviewing how to install iFolder.

Installing iFolder

As with DirXML, if you performed an Express install, iFolder was installed on your system. If a Custom install was done, you had the opportunity to select the iFolder component for installation.

If you didn't select iFolder during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select iFolder.

  6. Finish the installation according to the instructions presented in Chapter 5, "NNLS Installation and Administration."

The first time you access the iFolder Management Console and select Global Settings, the schema of your eDirectory tree is extended. The following object classes are added:

  • iFolder Server— This object represents your iFolder server in the eDirectory tree.

  • iFolder User LDAP— This object represents the LDAP server iFolder will use to authenticate users.

  • iFolder Settings— This object stores the global configuration settings for your iFolder server.

After installation, the following iFolder directories are created and populated in your server's file system:

  • /var/opt/novell/ifolderdata/ACCOUNTS— This directory contains the files that are synchronized with iFolder clients.

  • /opt/novell/httpd/bin/httpd— This directory contains configuration files for your Apache web server that configure it to work with iFolder.

  • /opt/novell/ifolder— This directory contains the iFolder system files.

  • /opt/novell/ifolder/DocumentRoot— This directory contains iFolder HTML files.

  • /opt/novell/ifolder/bin— This directory contains the iFolder server modules used by the Apache web server.

With that, let's now discuss how to configure and administer iFolder on your system.

Configuring and Managing iFolder

The iFolder and DirXML components of NNLS are somewhat similar in that each can be configured in a myriad of ways to meet the particular demands of your network. For the CLE exam, however, you only need to know how to complete the following iFolder management tasks:

  • Configuring user access

  • Configuring server parameters

  • Installing and configuring the iFolder client

  • Monitoring the iFolder system

We'll cover each of these topics in this section. Let's start with configuring user access.

Configuring User Access

Before users can use the iFolder service on your server, you must configure the user objects in your eDirectory tree with iFolder access. To do this, you must first define the contexts within your tree that will be serviced by the iFolder server. Only user objects that reside within these contexts can use iFolder.

Following that, you must enable user objects to use iFolder. Both of these tasks are done using the iFolder Management Console. The iFolder Management Console is a web-based utility used specifically to configure the iFolder service on your server.

To access the iFolder Management Console, open a browser window and navigate to https://your_server_IP_address/iFolderServer/Admin. When you do, the screen in Figure 8.4 appears.

Figure 8.4. The iFolder Management Console.

Using the iFolder Management Console, you configure user access by completing the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/iFolderServer/Admin.

  2. Under Welcome to iFolder, select Global Settings.

  3. Authenticate as your admin user. After authentication, the screen shown in Figure 8.5 appears.

    Figure 8.5. The iFolder General Information screen.

  4. Define the contexts where users who are authorized to use iFolder reside by completing the following:

    1. Under Global Settings, select User LDAPs. The screen in Figure 8.6 appears.

      Figure 8.6. The iFolder User LDAPs screen.

    2. Under User LDAPs, select your iFolder server. Notice that the only context displayed is the one you specified for the Admin context during installation; this is shown in Figure 8.7.

      Figure 8.7. The iFolder Context Configuration screen.

    3. Click Add.

    4. Click Search.

    5. In the Search Results screen, select the container you wish to add and then click Add.

    6. Repeat this process until all the containers you want to enable are selected.

      Tip

      By default, iFolder will only search for users in the specified contexts. If you wish all subcontainers beneath the selected containers to be included, be sure to mark Search Subcontexts.

    7. Click Update.

  5. Enable user access to iFolder by completing the following steps:

    1. Select the User Management icon.

    2. In the iFolder Management Console, select Advanced Search. The screen in Figure 8.8 appears.

      Figure 8.8. The iFolder User Search screen.

    3. Configure your search criteria to perform a filtered search for user objects; then click Search. To view all users, leave the search field blank and then click Search. The screen in Figure 8.9 appears.

      Figure 8.9. The iFolder User Search Results screen.

    4. Mark the users you want to enable for iFolder access.

    5. Select Enable checked users as iFolder users.

    6. When prompted to confirm the operation, click OK.

At this point, user access to iFolder has been configured. Before allowing users to log in, however, you need to configure various parameters for your iFolder server.

Configuring Server Parameters

To configure global policies for your iFolder server, complete the following steps:

  1. In the iFolder Management Console, select the Global Settings icon.

  2. Select Global Policies.

  3. In the Global Policies screen, select Display next to Server Policies. The screen shown in Figure 8.10 appears.

    Figure 8.10. The iFolder Global Server Policies screen.

  4. In the Initial Client Quota field, enter a quota for user file storage.

  5. In the Session Timeout field, enter the amount of time, in minutes, after which a session will be terminated if no synchronization occurs.

If, for some reason, you don't want synchronized user files to be saved in /var/opt/novell/ifolderdata/ACCOUNTS, you can change the iFolder storage location in your server's file system. This is done by completing the following steps:

  1. Create a directory in the file system where you want iFolder data saved.

  2. Copy the existing contents of /var/opt/novell/ifolderdata to the new directory.

  3. Open the /etc/opt/novell/ifolder/httpd_ifolder_unix.conf file in a text editor.

  4. Scroll down to the iFolderServerRoot line, shown in Figure 8.11.

    Figure 8.11. Editing the iFolder Conf file.

  5. Change the value of the iFolderServerRoot parameter to the new directory you just created.

  6. Save the changes to your file.

  7. Change the owner of the new directory to the novlwww user.

  8. Change the group associate with the directory to the novlwww group.

    Tip

    Steps 7 and 8 can be accomplished by entering chown novlwww:novlwww directory_name at a shell prompt.

  9. Change the permissions of the new directory to 700.

    Tip

    Step 9 can be done by entering chmod 700 directory_name at a shell prompt.

  10. Restart the novell-httpd service.

The next thing you need to do is set global client policies on your server. These policies serve as the default parameters for iFolder clients that attach to your server. For most parameters, you can choose from the following levels, as shown in Figure 8.12.

Figure 8.12. iFolder Client Policies.

  • On— Selecting this item enables a given setting. If this is the only parameter selected for a given setting, the policy will be applied by default, but users can override the policy using configuration settings in the iFolder client.

  • Enforced— If this item is selected for a given setting, the policy will be applied by default. Users will be able to see the policy in their iFolder Client Configuration screen. However, the policy will be grayed out and users will not be able to override the setting.

  • Hidden— If this item is selected for a given setting, the policy will be enforced by default, but it will not be visible in the iFolder Client Configuration screen.

Using these levels, you can configure the following iFolder policies in the Global Client Policies screen:

  • Encryption— Enabling this policy encrypts user files stored on the iFolder server using the pass phrase.

  • Save Password— Enabling this policy allows the user to save his or her password in the iFolder client.

  • Save Pass Phrase— Enabling this policy allows the user to save his or her pass phrase in the iFolder client.

  • Recover Pass Phrase— Enabling this policy allows the network administrator to recover a user's lost pass phrase. You should use this policy with caution. Because the pass phrase is used as the key to encrypt files, allowing the administrator to see a user's pass phrase also gives him or her the ability to decrypt the user's files on the iFolder server.

  • Automatic Sync— Enabling this policy will cause iFolder clients to automatically synchronize changes with the iFolder server. If this policy is disabled, users must manually synchronize their iFolder clients with the iFolder server.

  • Sync to Server Delay— If the Automatic Sync policy is enabled, this policy configures the amount of time, in seconds, after which a change that's made to a file in the iFolder directory is synchronized to the iFolder server.

  • Sync from Server Interval— If the Automatic Sync policy is enabled, this policy specifies the interval in seconds that the iFolder client waits between queries to the iFolder server to download updated files.

  • Conflict Bin Space— This policy specifies the amount of space to be reserved for Conflict Bin files for each iFolder user. By default, the space allocated is 25MB. If users primarily work with word processing documents, this allocation should be sufficient. If your users work with graphic, video, or audio files, you should consider increasing the amount of space allocated to the Conflict Bin.

  • iFolder Location— This policy specifies the default location for the iFolder directory on the users' workstations.

Warning

It's important that you understand that the policies marked with an asterisk in Figure 8.12 are not dynamic. They are applied only when the iFolder user account is first created. If you change one of these policies after user accounts have been created, you must delete the user accounts and re-create them in order for the change to be applied.

To configure global client policies, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/iFolderServer/Admin.

  2. In the iFolder Welcome screen, select Global Settings.

  3. Authenticate as your admin user.

  4. Select Global Policies.

  5. On the Client Policies line, select Display.

  6. Configure your policies.

  7. Select Update Client Policy.

Global client policies are very useful for establishing a baseline system configuration. It is very likely, however, that there will be users who require a slightly different configuration.

You can accommodate them by configuring a customized set of policies for individual users. Individual user policies override global client polices. To configure an individual user's client policies, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/iFolderServer/Admin.

  2. In the iFolder Welcome screen, select User Management.

  3. Authenticate as your admin user.

  4. In the Enter Username field, enter the username you wish to configure a customized policy for.

  5. Click Search.

  6. In the search results, select the user whose policies you want to edit.

  7. Scroll down to the Policy line, then select Edit. The Polices screen appears. Notice that, although it appears identical to the Global Client Policy screen we worked with previously, the policies displayed only apply to the selected user.

  8. Configure your policies.

  9. Select Update Client Policy.

That's it. You're server is ready to go. Next, you need to install and configure the iFolder client on the Windows workstations in your network.

Installing and Configuring the iFolder Client

Before we address this task, you need to understand that you don't necessarily have to use the iFolder client. As mentioned earlier, you can opt to simply use the iFolder applet from within a web browser (sorry, it only works with Internet Explorer 5 or later) to access your iFolder files.

If you choose the web browser route, however, your users won't have the benefit of automatic synchronization. They will have to manually download and upload their files. In my opinion, you should deploy the iFolder client to all your users' workstations, including their desktop PCs, their notebook PCs, and even their home computers if they do a lot of work from home.

The web page option should be reserved for emergencies when users need access to their iFolder files from a computer that doesn't have the iFolder client installed. An example of this would be a sales representative visiting a client, and the notebook computer's hard drive crashes.

In this case, the presentation files saved in the iFolder directory are no longer available. Using the web page option, the sales rep can borrow a PC and access the iFolder server over the web without having to install the iFolder client on the borrowed PC.

iFolder can also provide a huge benefit to users on the road. Users can even access their files using an airport kiosk Internet terminal.

The iFolder client can be installed on Windows 98, Windows Me, Windows 2000 Professional, and Windows XP systems. The systems you are going to deploy the iFolder client on must have Internet Explorer 5.0 or later installed.

When you think of installing the iFolder client on all the Windows workstations in your network, it sounds like a daunting task. Novell makes it relatively easy, however, by providing the client software through the iFolder website. You don't have to worry about running a CD around to all your users' workstations.

To install the iFolder client, complete the following steps:

Note

Depending on how you have configured your iFolder global client policies, you may not see some of the options listed in the following steps (such as the Remember Pass Phrase option). These steps are written using the default iFolder policy configuration.

  1. On the user workstation, open Internet Explorer and navigate to https://your_server_IP_address/iFolder.

  2. If prompted, select Yes to accept the security certificate. The screen in Figure 8.13 appears.

    Figure 8.13. The iFolder home page.

  3. Under iFolder Windows Client, click Download.

  4. In the File Download dialog, click Open.

  5. Wait while the installation file is downloaded and run.

  6. In the iFolder Welcome screen, click Next.

  7. In the License Agreement Language screen, select your language and then click Next.

  8. Read the license agreement and then close the browser window.

  9. When prompted to accept the license agreement, select Yes. The screen in Figure 8.14 is displayed.

    Figure 8.14. The iFolder Choose Destination Location screen.

  10. Select the destination folder for your client installation and then click Next.

  11. When prompted that the installation is complete, click Finish.

  12. Read the ReadMe file, then close the Notepad window.

  13. When prompted, select Yes, I Want to Restart My Computer Now; then click Finish.

  14. Wait while your workstation reboots. When the system has been restarted, the screen shown in Figure 8.15 is displayed.

    Figure 8.15. The iFolder Setup Complete screen.

  15. Click Continue. The screen in Figure 8.16 is displayed.

    Figure 8.16. The iFolder Login screen.

  16. In the User ID field, enter the username of a user in your eDirectory tree.

    Tip

    You don't need to include the user's context. The iFolder server will search for the user in the contexts you configured previously.

  17. In the Password field, enter the user's password.

  18. Click Login. The iFolder Location screen appears.

  19. The iFolder Location field is automatically populated with the path you specified in your global client policies screen. If you want to use a different directory, enter it here; otherwise, click OK. The screen in Figure 8.17 appears.

    Figure 8.17. The iFolder New Internet Folder Setup screen.

  20. In the iFolder New Internet Folder Setup screen, mark the following as desired:

    • Enable automatic login at startup— This option will automatically authenticate the iFolder client to the iFolder server at startup using the username and password you supplied. This option works well if the workstation only has one user. If you have multiple users using the same workstation, you may not want to use this option.

    • Encrypt files— Selecting this option will encrypt the files on the iFolder server. Unless you have a good reason not to, you should always select this option.

  21. Click OK. The screen in Figure 8.18 is displayed.

    Figure 8.18. The iFolder Get Pass Phrase screen.

  22. In the iFolder Get Pass Phrase screen, enter a pass phrase for the user account in the Enter pass phrase and Confirm pass phrase fields.

    Tip

    The pass phrase is used as an encryption key for encrypting files on the iFolder server.

  23. In the Hint field, enter a pass phrase hint.

  24. If you want the pass phrase to be automatically entered during login, mark Remember pass phrase. Otherwise, click OK. The screen in Figure 8.19 is displayed.

    Figure 8.19. The iFolder Pass Phrase Recovery screen.

  25. In the iFolder Pass Phrase Recovery screen, if you want the network administrator to be able to recover a lost pass phrase, mark Enable pass phrase recovery. Otherwise, click OK.

Warning

Be aware that if a user forgets his or her pass phrase and pass phrase recovery is disabled, the account must be deleted and re-created. Using the pass phrase recovery option is usually a good idea for this reason.

The iFolder installation is now complete. You should see the iFolder shortcut created on your Windows desktop, as shown in Figure 8.20.

Figure 8.20. The iFolder shortcut on the Desktop.

You will also see an iFolder icon in your system tray, as shown in Figure 8.21.

Figure 8.21. The iFolder icon in the system tray.

Your users can now start adding files to the iFolder directory on their workstations, and synchronization will begin.

We now discuss how to customize policies from within the iFolder client. Recall when we were configuring global and individual user client polices that you have the option of using On, Enforced, and Hidden for each policy.

If you have simply turned a policy on without enforcing it or hiding it, the end user can override the policy by configuring his or her iFolder client on the workstation.

To do this, complete the following steps:

  1. At the client workstation, right-click your iFolder icon in your system tray.

  2. Select Account Information. The screen in Figure 8.22 appears.

    Figure 8.22. iFolder client account information.

    This screen displays the currently logged-in user, the location of the iFolder directory, the amount of the user's storage quota that has been used, and the amount of data waiting to be synchronized.

  3. Select the Preferences tab. The screen in Figure 8.23 appears.

    Figure 8.23. iFolder client preferences.

  4. In the Preferences tab, you can configure the followings policies:

    • Automatic sync

    • Synchronize to server delay

    • Synchronize from server interval

    • Remember password

    • Remember pass phrase

    The options you see may differ from what is shown in Figure 8.23. If you have configured enforced or hidden policies, they will be grayed out or hidden in this dialog.

  5. Click Apply.

You're system is up and running! With iFolder in service, you need to monitor your system to ensure that synchronization occurs properly.

Monitoring the iFolder System

Through the iFolder Management Console, you can monitor the status of the iFolder system and generate historical reports. If you're experiencing problems, this information can help you pinpoint the source.

To monitor the status of iFolder system, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/iFolderServer/Admin.

  2. In the iFolder Welcome screen, select System Monitoring.

  3. Authenticate as your admin user. The screen shown in Figure 8.24 appears.

    Figure 8.24. The iFolder System Monitoring screen.

This screen displays the following information:

  • User LDAPs Status— This area of the screen displays the status of the user LDAP servers your iFolder server is configured to use. The LDAP server's host name, IP address, and status are shown.

  • iFolder Servers— This area of the screen displays information about each iFolder server in your network. It displays each server's host name, IP address, status, current user accounts, concurrent users, concurrent sessions, available disk space, and up time.

If you are experiencing problems and need to shut down synchronization, you can use the bottom item in this screen to do so. In the iFolder Server drop-down list, select the server you wish to stop synchronization on and then select Stop Sync.

iFolder also provides a series of reports that can be used to monitor performance of the server. To do this, complete the following:

  1. Open a web browser and navigate to https://your_server_IP_address/iFolderServer/Admin.

  2. In the iFolder Welcome screen, select Reporting.

  3. Authenticate as your admin user. The screen shown in Figure 8.25 appears.

    Figure 8.25. The iFolder System Reporting screen.

  4. In this screen you can generate a series of reports using the links shown on the left side of the page. The following options are available:

    • General Info— The General Info link displays a summary report listing the total number of users, total disk quota, and the total disk space used. This report is shown in Figure 8.25.

    • iFolder Servers— This link displays detailed information about a specified iFolder server. The information displayed includes the server name, IP address, up time, server version, user accounts, current users, current sessions, disk space used, disk quotas, host operating system, host web server, user data directory, and iFolder root directory. This report is shown in Figure 8.26.

      Figure 8.26. The iFolder Servers report.

    • User LDAPs— This link displays information about the LDAP server used to authenticate iFolder users. The report displays the LDAP server's host name, IP address, status, total users, and iFolder users. This report is shown in Figure 8.27.

      Figure 8.27. The User LDAPs report.

    • User Accounts— This link displays detailed information about the user accounts on a given iFolder server. This report displays the user names, iFolder server name, disk space used, last synchronization date, total files, directories, uploads, downloads, and the type of encryption employed. This report is shown in Figure 8.28.

      Figure 8.28. The User Accounts report.

That's it for iFolder installation and configuration. It's now time to get your hands dirty configuring iFolder on your NNLS server.


Lab Exercise 8.1: Implementing iFolder

In this lab, you're going to configure iFolder on your server. Then you will install the iFolder client on a Windows workstation and test synchronization.

Warning

In order to complete this exercise, you will need a second computer that can communicate through a network medium with the server you have been working with throughout this book. This may present a challenge for you, and you may be tempted to skip this exercise. Before you do, be aware that you need to know how to configure and manage iFolder to pass the CLE exam.

VMWare can be particularly useful in this exercise. With enough system RAM, you can run a virtual Linux server and a Windows workstation concurrently on the same physical PC hardware. See http://www.vmware.com for more information.

Complete the following steps:

  1. Secure a copy of Windows 98, Me, 2000 Professional, or XP.

  2. Secure a second PC system that meets the minimum requirements for your version of Windows.

    Warning

    Be sure you back up any data on this PC that you want to preserve!

  3. Install Windows on this second system.

  4. Open a web browser and navigate to https://your_server_IP_address/iFolderServer/Admin.

  5. Configure the contexts to be searched by the iFolder server by completing the following steps:

    1. Under Welcome to iFolder, select Global Settings.

    2. Authenticate as admin with a password of novell.

    3. Under Global Settings, select User LDAPs.

    4. Under User LDAPs, select your iFolder server. Notice that the IF.CLE container is already configured.

    5. Click Add.

    6. Click Search.

    7. In the Search Results screen, select the SLC.CLE container and then click Add.

    8. Click Update.

  6. Enable user access to iFolder by completing the following steps:

    1. Select the User Management icon.

    2. In the iFolder Management Console, select Advanced Search.

    3. View all users in the tree by leaving the search field blank and selecting Search.

    4. Mark each user in your tree except for your admin and eGuidePublicUser user objects.

    5. Select Enable checked users as iFolder users.

    6. When prompted to confirm the operation, click OK.

  7. Configure global policies for your iFolder server by completing the following steps:

    1. In the iFolder Management Console, select the Global Settings icon.

    2. Select Global Policies.

    3. In the Global Policies screen, select Display next to Server Policies.

    4. In the Initial Client Quota field, enter 500. This sets a quota of 500MB of disk space for each user.

    5. Click Update.

  8. Configure global client policies by completing the following steps:

    1. In the iFolder Management Console, select the Home icon.

    2. In the iFolder Welcome screen, select Global Settings.

    3. Select Global Policies.

    4. On the Client Policies line, select Display.

    5. Configure the following policies:

      Policy

      On

      Enforced

      Hidden

      Encryption

      X

      X

      Save password

      Save pass phrase

      Recover pass phrase

      X

      X

      X

      Automatic sync

      X

      X

      Sync to server delay

      X

      X

      Sync from server interval

      X

      X

      Conflict Bin space

      iFolder location

    6. Select Update Client Policy.

  9. Install the iFolder client by completing the following steps:

    1. On your Windows workstation, log in as administrator.

    2. Open Internet Explorer and navigate to https://your_server_IP_address/iFolder.

    3. If prompted, select Yes to accept the security certificate.

    4. Under iFolder Windows Client, click Download.

    5. In the File Download dialog, click Open. Wait while the installation file is downloaded and executed.

    6. In the iFolder Welcome screen, click Next.

    7. In the License Agreement Language screen, select your language and then click Next.

    8. Read the license agreement and then close the browser window.

    9. When prompted to accept the license agreement, click Yes.

    10. In the Choose Destination Location screen, click Next.

    11. When prompted that the installation is complete, deselect View the ReadMe File and then click Finish.

    12. In the InstallShield Wizard Complete screen, select Yes, I want to restart my computer now; then click Finish. Wait while your workstation reboots.

    13. When the system has rebooted, authenticate to the workstation as administrator.

    14. The Novell iFolder Setup Complete window is displayed. Click Continue.

    15. The iFolder Login window appears. In the User ID field, enter DNelson.

    16. In the Password field, enter novell.

    17. Verify that your iFolder server's IP address is listed in the Server field; then click Login.

    18. In the iFolder Location screen, click OK.

    19. In the iFolder New Internet Folder Setup screen, notice that the Encrypt files option is grayed out, but the Enable automatic login at setup option is not. This is due to the global client policies you configured earlier. In this screen, simply click OK.

    20. In the iFolder Get Pass Phrase screen, enter barracuda in the Enter pass phrase and Confirm pass phrase fields.

    21. In the Hint field, enter Muscle Car; then click OK. Notice that the Pass Phrase Recovery screen is not displayed. Again, this is because of the global client policies you configured.

    The iFolder installation is now complete. You should see the iFolder shortcut created on your Windows desktop and an iFolder icon in your system tray.

  10. Test your iFolder implementation by completing the following steps:

    Warning

    The following steps are written using Windows XP Professional. If you are using a different version of Windows, you will need to modify the steps to match.

    1. On your desktop, double-click the DNelson Home shortcut.

    2. Select File, New, WordPad Document.

    3. Name the file MyFile.

    4. Double-click MyFile.

    5. In the WordPad window, enter This is the first line of text.

    6. Save the file and exit WordPad.

    7. Check synchronization by right-clicking the iFolder icon in your system tray and selecting Account Information.

    8. You should see a small amount of space consumed on the server.

    9. Select View Activity. You should see a recent synchronization entry for the file.

      Tip

      If you need to manually synchronize the iFolder client with the server, you can select Sync in this screen.

    10. Close the iFolder window.

    11. Close the Home window.

That's it! iFolder is now working on your server. If you have a second Windows workstation available, try installing the iFolder client on it. Then log in to iFolder as DNelson.

When you do, you'll see that the file created in the iFolder directory on the first Windows workstation is automatically synchronized to the iFolder directory on the second Windows workstation.

If you ever start having trouble with your iFolder implementation, you can configure your iFolder server to write debug information in a log file so you can see what's happening "behind the scenes." To do this, complete the following steps:

  1. Access the iFolder Management Console by opening a web browser and navigating to https://your_server_IP_address/iFolderServer/Admin.

  2. Select Global Settings.

  3. Authenticate as your admin user.

  4. Select Global Policies.

  5. On the Server Policies line, click Display.

  6. Mark Debug Output and then click Update.

  7. On your server, open a terminal session and change to the /var/opt/novell/ifolder/DocumentRoot directory.

  8. Using the mkdir command, create a directory named logs.

  9. Enter vi /etc/opt/novell/ifolder/httpd_ifolder_unix.conf.

  10. Scroll to the end of the file and press Ins.

  11. Enter the following text (all on one line):

   iFolderServerLogging

   "/var/opt/novell/ifolder/DocumentRoot/logs/index.html"

    1. Press Esc; then enter :exit.

    2. At the shell prompt, enter chmod 757 /var/opt/novell/ifolder/DocumentRoot/logs.

    3. Using the init scripts in /etc/init.d, stop and then restart the novell-httpd service.

You can access the log file by opening a web browser and navigating to http://your_server_IP_address/iFolder/logs/index.html. A sample of this log file is shown in Figure 8.29.

Figure 8.29. The iFolder log file.

As you can see, iFolder is very useful tool in the workplace. It gives users (especially mobile users) seamless access to their files no matter what workstation they use. It also ensures that an organization's critical intellectual property is properly backed up.

With that, let's shift gears and talk about Samba!


An Introduction to Samba

Test Objective Covered:

3. Describe the purpose and architecture of Samba.

If you've never used Samba before, you're in for a real treat. Samba is an Open Source service that allows your Linux operating system to participate in a Microsoft Windows network.

It can be configured such that your Linux server emulates a Windows server. In this mode, you can configure share points for directories in your file system. Users running Windows on their desktop systems can map drives to the shares as if they were on a typical Windows server. In Figure 8.30, you can see a Linux server running Samba displayed in the Workgroup Windows workgroup.

Figure 8.30. Samba server in Network Places.

The Samba service can also operate in client mode. Using Samba, your Linux server can mount Windows shares or shares on other Samba servers.

In this book, we're going to configure our NNLS system with Samba to provide file storage services for Windows client workstations. Why would we want to do this? There are a few reasons:

  • Deploying Samba can be considerably less expensive than deploying Windows servers. Licenses for Windows servers are very expensive. Depending on the distribution you're using, deploying Samba on a Linux server can cost as little as, well, nothing!

  • Because of the stability of Linux, using Samba instead of a Windows server can dramatically increase the reliability of your network. As much as you may like Windows servers, it's an acknowledged fact that they aren't as stable as we would like them to be (especially Windows NT!).

    In fact, most Windows system administrators make a practice of rebooting their servers periodically. If you don't, it's not a question of if the Windows server will experience problems, it's a question of when.

    Linux, on the other hand, is extremely stable. It's a lot like NetWare in this respect. You can leave it running for years on end without rebooting. By deploying Samba, you get the functionality of a Windows file server with the reliability of Linux. This makes for a very nice implementation!

  • On most hardware, Samba is much more scalable and much faster than a Windows server. With only a few users, both systems perform on a roughly equal basis. However, when the load increases, Samba runs two to three times faster than Windows. For detailed test results from a series of tests run by PC Magazine, visit http://www.pcmag.com/article2/0,1759,17201,00.asp on the Web.

In order to implement Samba, you need to understand the protocols Samba uses to provide file access.

Samba Protocols

Samba relies on the same underlying protocol as Windows: the Server Message Block (SMB) protocol. IBM originally developed SMB in the mid-1980s. IBM didn't do much with the concept and, in 1987, Microsoft picked up SMB and developed it into the widely deployed protocol that it is today. Support for SMB has been included in every version of Windows since Windows 95.

SMB uses a simple client/server network model. SMB clients request services from an SMB server. SMB servers respond with the requested service. It's that simple.

SMB allows network clients to access files on a remote computer. The SMB protocol exists at the Presentation and Application layers of the OSI model. As such, it runs on top of most basic network communication protocols, including TCP/IP, IPX, and NetBEUI. In addition to file access, SMB allows remote clients to use a given host's printers as well as to request services from any network application that is SMB-aware.

If you've ever configured a Windows server, you know that it uses two security levels. This is actually a function of the SMB protocol. SMB defines the following:

  • Share-level security— In the share-level security model, each share on the server has its own password. Any user can access the share (and the files and subdirectories it contains) as long as he or she supplies the correct password.

  • User-level security— The user-level security model is similar to the Linux (and NetWare) file security model. Every user must authenticate to the server. Then, access to each file and directory in the file system is based on its assigned permissions.

To access a file server using SMB, the client workstation must run SMB client software. For the purposes of this book, we're going to use the Microsoft Client for Microsoft Networks.

The version of the SMB protocol used by Samba isn't the same version as that implemented by Windows servers. Many years ago, Microsoft released an Open Source version of SMB called the Common Internet File System (CIFS) protocol. Samba uses CIFS to provide its service. The good news is that SMB and CIFS are completely compatible. When a connection is initially established, the SMB/CIFS client negotiates with the SMB/CIFS server to establish a common protocol. This allows Linux and Windows operating systems to interoperate in a network.

Let's now talk about the NNLS version of Samba.

Samba in NNLS

Samba is not unique to NNLS. Samba is an Open Source service that can be downloaded from any number of websites. In fact, most Linux distributions include a version of Samba.

While installing NNLS, however, you probably noticed that your existing version of Samba was removed and a new version was installed. As you can see in Figure 8.31, the smb init script has been replaced with a script called novell-smb.

Figure 8.31. Novell's Samba service.

So, what's the difference between other versions of Samba and the one that comes with NNLS? Samba in NNLS has been customized to work with eDirectory through LDAP to support LUM users in the tree. Using the NNLS version, Samba can use encrypted LDAP communications to authenticate users.

With that in mind, we need to discuss how to install and configure Samba.


Installing and Configuring Samba

Test Objective Covered:

4. Install and configure Samba

As with preceding NNLS components, the CLE exam objectives specify that you be able to install and configure Samba. Just as we've done before, we're only going to touch the installation of Samba lightly because we spent a great deal of Chapter 5 discussing NNLS installation procedures.

Installing Samba

As with iFolder, if you performed an Express install, Samba was installed on your system. If you performed a Custom install, you had the opportunity to select the Samba component for installation.

If you didn't select Samba during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select Samba.

  6. Finish the installation according to the instructions presented in Chapter 5.

Let's spend the rest of this section discussing how to configure Samba.

Configuring Samba

If you've implemented the Open Source version of Samba before, you may be tempted to skip this section and configure this service the same old way you always have. Be aware that the NNLS version of Samba is a little bit different.

Because of its eDirectory/LUM integration, the steps for configuring this version are a little bit different. To configure the NNLS version of Samba, you need to do the following:

  • Enable Samba users.

  • Configure the Samba configuration file.

  • Start the Samba service.

Let's look at each of these tasks.

Enabling Samba Users

Unlike the traditional version of Samba, you have to enable the user objects in your eDirectory tree to use Samba. To do this, you must first implement Linux User Management (LUM). We covered LUM in Chapter 6, "Managing User Accounts with eGuide and Linux User Management."

Once LUM has been configured, you can LUM-enable and Samba-enable a new user when you create his or her object in the tree. To do this, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Verify your LUM configuration. Ensure sure you have a LUM group enabled in your tree.

  3. Under the eDirectory Administration role, select the Create Object task.

  4. In the Available Object Classes field, scroll down to and select User.

  5. Click OK.

  6. Fill in the user object attributes in the Create User screen, shown in Figure 8.32.

    Figure 8.32. The Create User screen in iManager.

  7. Click OK.

  8. When prompted that the user was created, click OK. The screen shown in Figure 8.33 is displayed. This screen is used to LUM-enable and Samba-enable the user object.

    Figure 8.33. Enabling a user object for LUM and Samba.

  9. In the Enter the Primary Group for this User field, browse to and select your LUM group.

  10. Make sure the Also convert this User object to a Samba User object box is marked.

  11. In the Enter the desired Samba password field, enter a Samba password for the user. You need to understand that the NNLS Samba service doesn't use the user object's eDirectory password. When a user object is Samba-enabled, an attribute is added to the user object that stores its Samba password. By default, this field is automatically populated with the eDirectory password. Novell recommends that the Samba password be the same as the eDirectory password to avoid confusion.

  12. Click OK.

  13. When prompted that the user has been LUM-enabled, click OK.

After the object is created, the user has two extra property pages: the Linux Profile Page and the Samba Profile Page. This is shown in Figure 8.34.

Figure 8.34. Additional user object property pages.

The Samba Profile Page allows you to change the user's Samba password, as shown in Figure 8.35.

Figure 8.35. Samba Profile Property Page.

Before the user can use Samba, he or she needs to have a home directory created in the Linux server's file system. The easiest way to do this is to simply have the user log in. Recall from Chapter 6 that when a LUM user authenticates to the system, a home directory is created and associated with the user object in the eDirectory tree.

In Figure 8.36, the JJackson eDirectory user has used an ssh utility to log in to the Linux server. During authentication, notice that a home directory for the JJackson user object was automatically created in the /home directory.

Figure 8.36. Automatic home directory creation.

If you check the Linux Profile Page for the user object in iManager after the user has logged in, you will see that the Home Directory attribute has been populated. This is shown in Figure 8.37.

Figure 8.37. Home Directory attribute in the Linux Profile Page.

You may be asking, "What if I already have users in the eDirectory tree who I want to make Samba users? Do I have to manually re-create each one to Samba-enable them?" Never fear! As with LUM, NNLS includes iManager tasks under the Linux User Management role that will allow you to convert existing users to Samba users. These roles are shown in Figure 8.38.

Figure 8.38. Tasks for converting existing users to Samba users.

If you have users who aren't currently LUM users, you can use the Convert eDirectory User to LUM User task in iManager to convert a user object to both a LUM user and a Samba user at the same time.

If you have users who are currently LUM users but not Samba users, you can use the Convert LUM User to Samba User task. For the purposes of this book, we're going to focus on the former option, converting users to both LUM and Samba users at the same time.

To convert existing eDirectory users to LUM and Samba users, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Using the steps discussed in Chapter 6, configure one or more groups in your tree that will contain LUM/Samba users.

  3. Using the steps presented in Chapters 5 and 6, populate the group(s) with the users who will be converted to LUM/Samba users.

  4. Under Linux User Management, select Convert eDirectory User to LUM User.

  5. In the Select User field, browse to and select the user you want to convert.

  6. Click OK. The screen in Figure 8.39 appears.

    Figure 8.39. Converting an existing user to a Samba user.

  7. In the Enter the Primary Group for this User field, browse to and select the LUM-enabled group the given user is a member of.

  8. Make sure the Also convert this User object to a Samba User object box is marked.

  9. In the Enter the desired Samba password field, enter the Samba password for the user. As mentioned before, you should consider using the user's eDirectory password for the Samba password. Otherwise, the user will have to remember two passwords—one to authenticate to the tree and one to access Samba resources.

  10. Click OK.

  11. When prompted that the process was successful, click OK. If you have more users to convert, you could select Repeat Task to repeat this process on the rest of the user objects.

NNLS also includes a version of the smbpasswd utility that you may be familiar with if you've implemented the non-NNLS version of Samba. You can use this utility to set the Samba password for a user object. However, it doesn't convert the user to a LUM/Samba user, nor does it configure LUM attributes. Novell recommends that you use iManager to configure your Samba users instead.

Now that your user objects have been converted to Samba users, the next thing we need to do is configure your Samba server.

Configuring the Samba Configuration File

As with most components, the NNLS Samba server is configured with a text file. In this case, the file is the smb.conf file located in /etc/opt/novell/samba. This file is shown in Figure 8.40.

Figure 8.40. The smb.conf file

If you're familiar with the non-NNLS version of Samba, you know that it is a very powerful product with many advanced configuration options. Entire books have been devoted to this product. For the purposes of the CLE, however, you only need to know how to perform a basic configuration. In essence, you just need to get it up and running.

In accordance, we're going to implement a basic configuration in this book. Table 8.1 references the required elements in the smb.conf file that you should become familiar with.

Table 8.1. smb.conf Directives

DIRECTIVE

DESCRIPTION

SAMPLE VALUES

ldap admin dn =

This directive specifies the eDirectory user who Samba should use to authenticate through the LDAP service on your server.

This eDirectory user's password is stored in the secrets.tdb file located in the /etc/opt/novell/samba/ directory.

If you change this user's eDirectory password, you must use the smbpasswd utility, mentioned earlier, to update the secrets. tdb file with the new password.

cn=admin,ou=IF,o=CLE

ldap ssl =

Specifies whether to encrypt communications with the LDAP server.

on (Default) off

ldap port =

Specifies the port number used by the LDAP server

389 636(Default)

ldap server =

Specifies the IP address or DNS name of the LDAP server to be used by Samba.

192.168.1.36 CLE1.CLE.com

security =

This parameter specifies the security level employed by Samba.

share user (Default)

encrypt passwords =

Identifies whether passwords coming from Windows client workstations will be arriving in encrypted form.

yes (Default)

Workgroup

Sets the name of the workgroup this server will participate in.

workgroup (Default)

netbios name =

Specifies the name of the eDirectory server (using LDAP syntax) that will be used for authentication.

cn=CLE1,ou=IF,ou=CLE

comment =

This directive sets the name of the Samba server displayed in My Network Places on Windows workstations.

Home Directories (Default)

browseable =

Specifies whether users' home directories are displayed in My Network Places on Windows workstations.

yes no (Default)

writable =

This directive controls whether users can create or edit files within the share.

yes (Default) no

[Share Name]

Defines a new share point in the Linux server's file system.

[Temp] path = /tmp read only = no

This set of directives creates a read/write share on the /tmp directory.

Once your smb.conf file has been edited, you can start the Samba service on your server.

Starting the Samba Service

The Samba service is started using the novell-smb init script located in /etc/init.d/ (or /etc/rc.d/init.d/ on a Red Hat server). By default, the NNLS installation script configures the Samba server to automatically start at runlevels 3, 4, and 5. Therefore, after editing your smb.conf file, you will actually need to stop the Samba server and then restart it.

After doing so, you can open My Network Places (Windows 2000 and XP) or Network Neighborhood (Windows 9x and Me) and browse to your Samba server. Within the server, you should see all the shares you configured in your smb.conf file and be able to map network drives to them. Your workstation thinks it's accessing shared directories on a Windows server. Little does it know that it's actually talking to a Linux server!

Let's practice implementing the Samba component of NNLS.


Lab Exercise 8.2: Implementing Samba

In this lab, you're going to configure Samba on your server. Then you will use a Windows workstation to access a shared folder on your Linux server.

Warning

As with iFolder, you will need a second computer that can communicate through a network medium with your server to complete this exercise.

Again, VMWare can be particularly useful in this exercise. With enough system RAM, you can run a virtual Linux server and a Windows workstation concurrently on the same physical PC hardware. See http://www.vmware.com for more information.

The steps in this exercise are written using Windows XP. You may need to adjust them if you are using a different version of Windows.

This lab also assumes that you completed the labs in Chapter 6. If not, be sure to go back and complete these first.

Complete the following steps:

  1. Ensure you have a functional Windows workstation running Windows 98, 2000 Professional, XP, or Me.

  2. Create a new Samba user by completing the following steps:

    1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Under the eDirectory Administration role, select Create Object.

    4. In the Available Object Classes field, select User; then click OK.

    5. Create a user using the following attributes:

      Attribute

      Value

      Username

      AGresko

      First Name

      Aaron

      Last Name

      Gresko

      Context

      IF.CLE

      Password

      novell

      Title

      Lab Manager

      Location

      Idaho Falls, Idaho Office

      Department

      Information Systems

      Telephone

      555-555-1234

      Fax Number

      555-555-2345

      Email Address

      agresko@cle.com

    6. Click OK.

    7. When prompted that the operation is complete, click OK.

    8. In the Enter the primary group for this user field, browse to and select IFEmployees.IF.CLE.

    9. Make sure the Also convert this User object to a Samba User object box is selected.

    10. In the Enter the desired Samba password field, enter novell.

    11. Click OK.

    12. When prompted that the LUM user was created, click OK.

  3. Create a home directory for AGresko by completing the following steps:

    1. Open an alternate shell by pressing Ctrl+Alt+F2.

    2. Authenticate as AGrekso with a password of novell.

    3. Verify that a home directory was created for AGresko in /home.

    4. Enter logout at the shell prompt.

    5. Press Alt+F7.

  4. Convert the existing users in your tree to Samba users by completing the following steps:

    Warning

    This step assumes you deselected the option to make these users Samba users in the Chapter 6 lab exercises.

    1. In iManager, scroll down to the Linux User Management role and select Convert LUM User to Samba User.

    2. In the Select User field, browse to and select CGrayson.IF.CLE.

    3. Click OK.

    4. When prompted, enter a password of novell in the Enter the desired Samba password field.

    5. Click OK.

    6. When prompted that the process was successful, select Repeat Task.

    7. Convert the remaining user objects in IF.CLE to Samba users using the preceding process.

    8. Convert the user objects in SLC.CLE to Samba users using the preceding process.

  5. Create a home directory for all users in your tree by completing the following steps:

    1. Open a terminal session and check the subdirectories of the /home directory on your server.

    2. Make a list of users in your tree who don't have a home directory.

    3. Open an alternate shell by pressing Ctrl+Alt+F2.

    4. Authenticate the first user in your list who doesn't have a home directory.

    5. Verify that a home directory was created in /home.

    6. Enter logout at the shell prompt.

    7. Repeat this process for each user in your tree who doesn't have a home directory.

    8. When you're done, press Alt+F7.

  6. Configure your Samba server by completing the following steps:

    1. From a shell prompt, enter vi /etc/opt/novell/samba/smb.conf.

    2. Scroll down to the workgroup line.

    3. Press Ins.

    4. Change the value of the workgroup directive to CLEWorkgroup, as shown in Figure 8.41.

      Figure 8.41. Changing the workgroup name.

    5. Scroll down to the server string line.

    6. Change the value of the server string directive to CLE1.

    7. Scroll down to the [tmp] share within the Share Definitions section of the smb.conf file.

    8. Enable the [tmp] share by uncommenting the comment, path, read only, and public lines. When you're done, this share should appear as shown in Figure 8.42.

      Figure 8.42. Enabling the [tmp] share.

    9. Press Esc.

    10. Enter :exit.

    11. At the shell prompt, enter /etc/init.d/novell-smb stop; then enter /etc/init.d/novell-smb start.

  7. Test the configuration by mapping a drive to AGresko's home directory share. Complete the following steps:

    1. On your Windows workstation, select Start, My Computer.

    2. Select Tools, Map Network Drive.

    3. Set the Drive drop-down list to Z:.

    4. In the Folder field, enter \\your_server_IP_address\AGresko.

    5. Select Connect Using a Different User Name.

    6. In the User Name field, enter AGresko.

    7. In the Password field, enter novell.

    8. Click OK.

    9. Click Finish. The contents of AGresko's home directory are displayed in drive Z:.

  8. Browse to the [tmp] share by completing the following steps:

    1. On your Windows workstation, select Start, My Network Places.

    2. Select View Workgroup Computers. This should allow you to browse the workgroup your workstation is a member of.

    3. To see all the workgroups on the network, select the Up a Level icon.

    4. Double-click the CLEWorkgroup icon. You should see an icon for your CLE1 server.

    5. Double-click the CLE1 icon. You should see all the shares defined on the CLE1 Samba server.

    6. Double-click the tmp icon. You should see the contents of the /tmp directory on your server.

That's it! You now have a functioning Samba server that can be an inexpensive, yet very powerful addition to your network. As mentioned earlier, we've only scratched the surface of what can be done with Samba. To learn more, visit http://us4.samba.org/samba/docs/. If you're running Windows servers in your organization and are looking to move to Linux, you'll be salivating over the possibilities Samba offers.

Before we end this chapter, we need to discuss one more file-access component in NNLS: NetStorage.


An Introduction to NetStorage

Test Objective Covered:

5. Describe the role and function of NetStorage.

NetStorage is a handy little component of NNLS. The function of NetStorage is relatively simple—to provide web-based access to user files. With NetStorage and a browser such as Mozilla, Netscape, or Internet Explorer, users can download and upload their files to and from the Linux server.

This can be done from within the organization behind the firewall or remotely over the Internet. NetStorage greatly reduces (some would say eliminates) the need for VPNs. In addition to up- and downloading, NetStorage also allows users to create, copy, move, delete, and rename files on the server using only a web browser for a client.

At this point, most students new to Novell and NNLS throw up a stop sign and say, "Hold on! Doesn't iFolder also do that? What's the difference between the two?" These two products may appear redundant at first, but as we work through a discussion of how NetStorage works, you'll see that, far from being redundant, this component and iFolder complement each other very nicely.

The Function of NetStorage

NetStorage functions as a mid-layer service that can be leveraged by other services, such as iFolder and Virtual Office (which we will discuss later in this book). You can access NetStorage by opening a browser window and navigating to https://your_server_IP_address/NetStorage. After authentication, the screen in Figure 8.43 is displayed.

Figure 8.43. The NetStorage home page.

NetStorage can be configured to provide access to specific directories in the Linux server's file system using Storage Location objects (discussed later in this chapter). It can also be configured to provide access to Samba shares or to users' iFolder accounts.

This is where NetStorage shines. Recall from our iFolder discussion earlier in this chapter that you can access your iFolder files using a browser. Consider what would happen, however, if you saved your file in a directory using a drive mapping to a Samba share and you needed access to the file from a remote location.

iFolder can't help you in this situation. Because the file isn't a synchronized iFolder directory, you can't access it using iFolder tools. With a properly configured NetStorage service running on your server, however, users can get access to the Samba share using a browser and gain access to their files.

NetStorage leverages the CIFS protocol such that user permissions are enforced when accessing a Samba share with a web browser. Because of this, you have to LUM/Samba-enable users in eDirectory before they can access a Samba share with NetStorage.

As mentioned, NetStorage also allows users to access their iFolder files on the iFolder server in a browser window. As with Samba, users must be iFolder-enabled before they can do this.

As you can see, NetStorage truly complements iFolder and Samba rather than duplicating their functionality. Sometimes students new to NNLS express security concerns about transferring files over the Internet (or even over their organizational network) using browser protocols.

We've all heard horror stories about hijacked FTP and Telnet sessions. With NetStorage, you don't need to worry. You can configure NetStorage to encrypt file transfers using SSL. With that, let's talk about NetStorage storage locations.

NetStorage Storage Locations

Refer back to Figure 8.43 and notice that there is a folder named shared. By default, NetStorage provides a shared storage location for all NetStorage users, even if they aren't LUM/Samba or iFolder enabled. This shared folder is located, by default, in the /var/opt/novell/netstorage/shared directory in your server file system.

Refer to Figure 8.43 again and notice that there's a folder for users' iFolder accounts. If users have been iFolder enabled, they can access their iFolder files from the iFolder server.

When the user clicks the iFolder folder, he or she will be prompted to provide an iFolder pass phrase. This is shown in Figure 8.44.

Figure 8.44. Providing the iFolder pass phrase in NetStorage.

In Exercise 8.1, you configured iFolder for the DNelson.IF.CLE user object. As a part of the exercise, you created a directory named MyFile.doc and entered some text into it. Using NetStorage, you can access the synchronized version of that file residing on the iFolder server. This is shown in Figure 8.45.

Figure 8.45. Accessing iFolder files in NetStorage.

I mentioned earlier that NetStorage can also access Samba shares. Access to this kind of storage is configured through Storage Location objects.

A Storage Location object is a pointer object in the eDirectory tree that directs NetStorage to a Samba share that has already been defined in the smb.conf file. Users are associated with the Storage Location objects, providing them access to the Samba share through the NetStorage web interface. Because Storage Location objects rely on Samba, NetStorage users must be LUM/Samba enabled.

If you want to create a directory in the Linux file system and provide NetStorage users with access to it, you must first define a share for the directory in the smb.conf file and restart the novell-smb service. Let's look at how this is done.


Configuring NetStorage

Test Objective Covered:

6. Install and configure NetStorage.

As with iFolder and Samba, the CLE exam objectives specify that you be able to install and configure NetStorage. Just as we've done before, we're only going to touch the installation of NetStorage lightly because most of Chapter 5 was spent discussing NNLS installation procedures.

Installing NetStorage

The only critical item you need to keep in mind about NetStorage is the fact that it can't be installed alone. If you perform a Custom NNLS installation, you'll notice that there's no option for NetStorage in the component-selection screen.

To install NetStorage, you have to install the NNLS Virtual Office component. When NNLS was in its early beta phase, this was not the case. NetStorage could be installed alone. During the mid-beta phase of the product, this was changed, and NetStorage was rolled into the Virtual Office product. I had the opportunity to speak with the NetStorage programmers at the time and asked them why this was done.

They explained that it simply was such an integral part of Virtual Office that it made sense for them to merge the two products into a single install. When we cover Virtual Office later in this book, I think you'll agree that this decision makes sense.

As with iFolder, if you performed an Express install, NetStorage was installed on your system. If you performed a Custom install, you had the opportunity to select the Virtual Office component for installation.

If you didn't select Virtual Office (and hence, NetStorage) during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select Virtual Office.

  6. Finish the installation according to the instructions presented in Chapter 5.

Let's spend the rest of this chapter discussing how to configure NetStorage.

Configuring NetStorage

Refer back to Figure 8.43 and notice that the only storage available through NetStorage is the user's iFolder directory and the common shared directory. This is because NetStorage hasn't been configured with Storage Location objects in the eDirectory tree.

Configuring Storage

To create a Storage Location object, complete the following steps:

  1. Create the directory in the Linux file system you want NetStorage users to be able to access.

  2. Edit your smb.conf file to create a Samba share for the directory created in step 1.

  3. Restart your novell-smb service.

  4. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  5. Authenticate as your admin user.

  6. Scroll down to the File Access (NetStorage) role and select the Storage Location: Create task. The Storage Locations: Create Object screen appears, as shown in Figure 8.46.

    Figure 8.46. Creating a Storage Location object.

  7. In the Object Name field, enter a name for the Storage Location object.

  8. In the Display Name field, enter the name for the Storage Location object that you want users to see in NetStorage.

  9. In the Directory Location field, enter the location of the directory in the Linux file system.

    This step trips up a lot of folks the first time they configure a Storage Location object (at least, it tripped me up the first time I tried to create a Storage Location object). The field name makes it sound like you can enter a simple directory path, but nothing is further from the truth.

    Instead of a path such as /tmp, you have to enter a URL in this field. If you're pointing to a directory on a Linux server, the format for the URL is as follows:

    cifs://server_IP_address/Samba_share

    For example, if your share name is tmp (such as the one we created earlier in this chapter) and your server's IP address is 192.168.1.36, you would enter the following:

    cifs://192.168.1.36/tmp

    Tip

    If you happen to be pointing to a NetWare server, you enter the URL as ncp:// server_IP_address/volume_name/path.

  10. In the Context field, enter the context where the Storage Location object will reside in the eDirectory tree.

  11. Click Create.

  12. When prompted that the object was created, click OK.

After you have created all your Storage Location objects, you next need to create Storage Location Lists, which are used to associate Storage Location objects with eDirectory user, group, or container objects. Users associated through such lists will see the storage locations in the list displayed when they authenticate to NetStorage.

To create a Storage Location List, complete the following steps:

  1. In iManager, select the Storage Location: Create/Modify List task under File Access (NetStorage). The screen shown in Figure 8.47 is displayed.

    Figure 8.47. Creating a Storage Location List.

  2. In the Object field, browse to and select a user, group, or container object you want to associate with the Storage Location object.

    If you select a user object, only that user will have access to the storage location. If you select a group object, all users who are members of the group will have access. If you select a container, all users who reside within the container will have access.

  3. Click OK. The screen in Figure 8.48 appears.

    Figure 8.48. Associating a storage location with a Storage Location List.

  4. In the Storage Location Objects field, browse to and select the Storage Location object(s) you want to associate with the list. You can select multiple objects.

  5. Click OK.

  6. When prompted that the list has been created, click OK.

At this point, the Samba share is available to NetStorage users who have been associated with the Storage Location List and who are LUM/Samba enabled.

Tip

A common mistake made on the CLE exam is that candidates forget to LUM/Samba-enable the users who are associated with the Storage Location List.

To access the share through NetStorage, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/NetStorage. The screen in Figure 8.49 appears.

    Figure 8.49. Authenticating to NetStorage.

  2. Authenticate as a user associated with the Storage Location List you created previously. You must use the distinguished name of the user, such as CGrayson.IF.CLE.

  3. Click OK.

  4. The NetStorage interface appears.

In Figure 8.50, a Storage Location object named Test has been created. This Storage Location object points to the [tmp] share we created in Lab Exercise 8.2.

Figure 8.50. Samba share in NetStorage.

A Storage Location List was created and associated with the Test Storage Location object and with the IF.CLE container in the eDirectory tree. Because CGrayson exists in the IF.CLE container, he has access to the Test Storage Location.

Once in NetStorage, you can use the File menu to create a new folder, delete a file or folder, rename a file or folder, upload a file to your NetStorage server, download files, e-mail a file, purge deleted files, undelete a file, archive files, and set file properties. This is shown in Figure 8.51.

Figure 8.51. Managing files in NetStorage.

Using the Edit menu, you can move and copy files. This is shown in Figure 8.52.

Figure 8.52. Using the Edit menu in NetStorage.

Using the View menu, you can refresh the NetStorage display and show files that you have deleted. This is shown in Figure 8.53.

Figure 8.53. Using the View menu in NetStorage.

Let's now turn to a discussion of how to configure the NetStorage server itself.

Configuring the NetStorage Server

Out of the box, the default NetStorage server configuration works perfectly for most implementations. It is unlikely that you will need to actually change any settings. If you do, however, the NetStorage server settings are configured using iManager. To configure NetStorage parameters, do the following:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Scroll down to the File Access (NetStorage) role.

  4. Choose from the following configuration tasks:

    • Authentication Domains— This task allows you to add eDirectory servers used by NetStorage to authenticate users. By clicking Add Domain, you can add multiple eDirectory servers. This task also allows you to configure the eDirectory contexts serviced by NetStorage. This is shown in Figure 8.54.

      Figure 8.54. Configuring Authentication Domains.

    • Current Sessions— This task displays a list of users who are currently using NetStorage. A sample report is shown in Figure 8.55.

      Figure 8.55. Viewing Current Sessions.

    • General— This task allows you to configure the NetStorage proxy user, location, security certificate, timeout value, and LDAP port. This screen is shown in Figure 8.56.

      Figure 8.56. Configuring NetStorage General settings.

    • iFolder Storage Provider— This task allows you to configure NetStorage with the IP address of your iFolder server, as shown in Figure 8.57.

      Figure 8.57. Configuring NetStorage iFolder Provider settings.

    • Resource Usage— This task displays a detailed report of resource utilization for the NetStorage server, as shown in Figure 8.58.

      Figure 8.58. NetStorage Resource Usage.

    • Statistics— This task displays a detailed report of various NetStorage server statistics, as shown in Figure 8.59.

      Figure 8.59. NetStorage Statistics.

  5. If you make any changes, you will need to restart the NNLS Apache web server after saving them. This is done by opening a terminal session and entering /etc/init.d/novell-httpd stop and then entering /etc/init.d/novell-httpd start.

With that, let's spend some hands-on time working with NetStorage.


Lab Exercise 8.3: Working with NetStorage

In this lab, you're going to use a browser to access Samba shares through NetStorage.

Warning

This lab assumes you completed the labs in Chapter 6 and the preceding labs in this chapter. If not, be sure to go back and complete these first.

Complete the following steps:

  1. Test the default shared folder in NetStorage by completing the following:

    1. Open a web browser and navigate to https://your_server_IP_address/NetStorage.

    2. In the User Name field, enter JJackson.IF.CLE.

    3. In the Password field, enter novell.

    4. Click OK. The NetStorage screen appears.

    5. Select shared. The content of the shared folder appears. Remember that this folder is common to all NetStorage users.

    6. Select File, Upload.

    7. In the File field, browse to and select a file you want to upload. You can use any file you wish.

    8. Click Upload.

    9. Wait while the file is uploaded. When the upload is complete, you will see the file displayed in the shared folder.

    10. Select Logout; then close your browser window.

      Warning

      You have to close the browser after logging out. Otherwise, if you try to access the NetStorage page again, you will automatically be reauthenticated as the original user.

    11. Open a new browser window and navigate to https://your_server_IP_address/NetStorage.

    12. Authenticate as CGrayson.IF.CLE with a password of novell.

    13. Select shared.

    14. The file you uploaded as JJackson should be displayed in the shared folder.

    15. Select Logout; then close the browser window.

  2. Create a Storage Location object for the JJackson user's home directory share by completing the following steps:

    Warning

    JJackson.IF.CLE must be configured as a LUM/Samba user for this exercise to work. If you completed the Samba lab in this chapter, JJackson should have been converted to a LUM/Samba user.

    1. Open a browser window and navigate to https://your_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. Scroll down to the File Access role and select the Storage Location: Create task.

    4. In the Object Name field, enter JJacksonStorageLocation.

    5. In the Display Name field, enter Jim Jackson's Home Directory.

    6. In the Directory Location field, enter cifs://your_server_IP_address/JJackson.

    7. In the Context field, enter IF.CLE.

    8. Click Create.

    9. When prompted that the Storage Location has been created, click OK.

    10. Under the File Access role, select Storage Location: Create/Modify List.

    11. In the Object field, browse to and select the JJackson.IF.CLE user object.

      Note

      Because this Storage Location object points to a user's home directory, we don't want it to appear in any other user's list of storage locations in NetStorage.

      Therefore, we're associating the Storage Location object to a specific user instead of a group object or a container.

    12. Click OK.

    13. In the Storage Location Objects field, browse to and select the JJacksonStorageLocation Storage Location object.

    14. Click OK.

    15. When prompted that the location has been created, click OK.

    16. Test the configuration by opening a new browser window and navigating to https://your_server_IP_address/NetStorage.

    17. Authenticate as JJackson.IF.CLE with a password of novell.

    18. You should see a storage location named Jim Jackson's Home Directory. You can upload and download files from this storage location as you did the shared location previously.

  3. Create a Samba share for Idaho Falls employees in the IF.CLE container by completing the following steps:

    1. On your server, open a terminal session.

    2. Create a new directory for the Idaho Falls employees by entering mkdir /var/ifemployees.

    3. Associate the ifemployees directory with the IFEmployees group in your eDirectory tree by entering chown root:IFEmployees /var/ifemployees.

      Warning

      Remember that we converted the IFEmployees group to a LUM group in Chapter 6. If you didn't complete the exercises in that chapter, this lab won't work.

    4. Give Group read, write, and execute permissions while denying permissions to Owner and Others for the ifemployees directory by entering chmod 070 /var/ifemployees.

    5. Now you need to create a Samba share for this directory. At the shell prompt, enter vi /etc/opt/novell/samba/smb.conf.

    6. Scroll down to the Share Definitions section of the file.

    7. Press Ins.

    8. Add the following text to this section:

   [IFEmployees]

       path = /var/ifemployees

       writable = yes

    public = no

       group = IFEmployees

    9. Press Esc.

    10. Enter :exit.

    11. To activate the share, you need to restart the Samba service on your server. At the shell prompt, enter /etc/init.d/novell-smb stop; then enter /etc/init.d/novell-smb start.

  4. Create a Storage Location object for the new Samba share by completing the following:

    1. Open iManager in a browser window, if it's not already running.

    2. Under File Access, select Storage Location: Create.

    3. In the Object Name field, enter IFEmployeesStorageLocation.

    4. In the Display Name field, enter IF Employee Storage.

    5. In the Directory Location field, enter cifs://your_server_IP_address/IFEmployees.

    6. In the Context field, enter IF.CLE.

    7. Click Create.

    8. When prompted that the Storage Location object has been created, click OK.

    9. Under File Access, select Storage Location: Create / Modify List.

    10. In the Object field, browse to and select the IFEmployees.IF.CLE group.

    11. Click OK.

    12. In the Storage Location Objects field, browse to and select the IFEmployeesStorageLocation.IF.CLE object.

    13. Click OK.

    14. When prompted that the assignment was made, click OK.

  5. Test the new storage location by completing the following steps:

    1. Open a new browser window and navigate to https://your_server_IP_address/NetStorage.

    2. Authenticate as CGrayson.IF.CLE with a password of novell.

    3. You should see the IF Employees Storage storage location displayed. You can create folders, upload files, and download files as you did in the shared storage location previously.

Tip

Remember that your users must be LUM/Samba enabled before they can use NetStorage. If you experience problems, this is the first thing to check!

That's it for this exercise and for this chapter. At this point, you should start to see how tightly NNLS integrates its various components. When properly configured, eDirectory, LDAP, eGuide, LUM, iFolder, Samba, and NetStorage all work together in harmony.


Summary

In this chapter, you learned how iFolder works. You learned how the iFolder server, iFolder client, and iFolder applet work together to provide users with anywhere access to their files.

You also learned how iFolder protects an organization's intellectual property by ensuring user files saved on workstation hard drives are synchronized to the iFolder server, where they can be regularly backed up.

In addition to iFolder, you learned about the NNLS version of Samba. You learned that Samba implements the SMB protocol, making your Linux server emulate a Windows file server. You learned that the NNLS version of Samba is tightly integrated with eDirectory through LDAP.

You also learned how to convert eDirectory users to LUM/Samba users. You learned how to configure Samba shares in the smb.conf file and how to access them with a Windows workstation.

In addition to iFolder and Samba, you also learned about the NNLS NetStorage service in this chapter. You learned that NetStorage provides users with web-based access to their server files using a browser. You learned that NetStorage provides access to users' iFolder accounts as well as Samba shares on the server.

You also learned that NetStorage uses Storage Location objects and Storage Location Lists to provide access to Samba shares. These control which users in the eDirectory tree can access them through the NetStorage interface.

In the next chapter, we'll add yet another service to our NNLS implementation that greatly increases user productivity: iPrint.


Chapter 9. Implementing Print Services with iPrint

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Identify the benefits of iPrint.

  2. Describe how iPrint works.

  3. Install and configure iPrint.

  4. Print with iPrint.

In the previous chapter, you learned how to implement the three file storage services in NNLS: iFolder, Samba, and NetStorage. In this chapter, you're going to learn how to increase end-user productivity with iPrint.


An Introduction to iPrint

Test Objective Covered:

1. Identify the benefits of iPrint.

Consider the following scenario: You are leading a project team for your company. In the morning, you have a meeting with executive management where you will be required to present a Product Requirements Document (PRD) for the new product your team is designing.

You're home for the evening when you receive a panicked phone call from one of your key team members indicating there is a glaring problem with the product design. Fortunately, she has found a solution to the problem and has uploaded some new specs to your team's shared NetStorage folder.

You fire up your home computer and download the specs. You realize that the changes will require a dramatic revision to the PRD, which is already nearly 100 pages long. It's going to be a very long night. Using iFolder, you access your PRD file from your home PC and start typing.

At 2:00 in the morning, you finally finish making the changes to the document. Unfortunately, you still have a problem. Being an organized project manager, you arranged to have 10 copies of the PRD printed and inserted in binders early yesterday. Now those 1,000 pages are completely outdated and are headed for the recycle bin.

You need to print out fresh copies of the PRD before your 9:00 a.m. meeting with management. Your inkjet printer at home isn't up to printing a 1,000 page run, nor is it capable of the quality required for a management presentation. You need access to the color laser printer at the office, which is capable of printing full-color documents at four pages per minute. At that rate, it's going to take over four hours to print all 10 copies.

To make your meeting, you need to start printing immediately. That will leave you enough time to get the pages punched and inserted in the binders.

Under typical circumstances, you would need to drive into the office and start the print job running, wasting a considerable amount of time that could be spent getting some rest before your big presentation. I can tell you from personal experience that there are few experiences more unpleasant than trying to coherently make an important presentation when you haven't had any sleep the night before.

If, however, your organization has implemented the iPrint component of NNLS, printing this document becomes a non-issue. iPrint uses the Internet Printing Protocol (IPP) to provide printer access over the Internet.

If you have experience managing Linux systems, you know that the CUPS and LPRNG services are available and also provide IPP support. The value of iPrint over these solutions, however, is the ease of use it provides for the user.

With iPrint, a user can open a web browser and access the iPrint web page on an NNLS server. In this web page, the user can locate and select the printer he or she wants to print to in a graphical floor plan. All the software required to allow his or her Windows workstation to print to the printer using IPP is downloaded and installed, including the correct print driver.

If you've ever supported users in a help desk role, you know how critical this functionality is. I can't tell you how many times I've seen users send print jobs using the wrong print driver because they didn't know how to correctly set up a printer in Windows. The result is usually 500 wasted pages of PostScript code. iPrint prevents this problem by automatically configuring the printer at the workstation with the correct IPP URL and driver.

Using iPrint, employees can print to your organization's printers from anywhere they have an Internet connection and a web browser. This can be a boon for mobile employees in large organizations. They can configure their workstations to send print jobs to printers in the local office where they are currently working without help desk assistance.

Many new to NNLS get nervous at this point. They're concerned that individuals outside the company might discover the URL to the iPrint web page and be able to wreak havoc with their printers. Never fear! iPrint is fully integrated with eDirectory and, therefore, access to iPrint printers is controlled by eDirectory rights. Those trying to access the printers without an eDirectory user account will not be able to do so.

In addition, you can use eDirectory rights to restrict access within your organization. For example, suppose you have a high-quality color laser printer that is very expensive to operate. You can restrict access to the printer to a specific group of eDirectory users who specifically need it to print presentations, brochures, or other collateral that needs high-quality color printing. Employees who don't need it aren't allowed access to it.

Another important benefit of iPrint is the fact that it is managed using iManager. This gives you a single point of management for all your printers. Because iManager is web based, it also provides you with remote printer management capabilities. This is of great value when you get a support call in the middle of the night. Instead of driving all the way in to work to fix a minor problem, you can boot up your home PC, access iManager, and fix the problem without changing out of your pajamas.

With this introduction in mind, let's discuss how iPrint works.


iPrint Components and Functionality

Test Objective Covered:

2. Describe how iPrint works.

Administrators implementing the iPrint component in NNLS for the first time tend to get a little confused in the process. It's very different from the print services provided with most server operating systems.

My experience has been that if the new administrator can learn the various components that comprise the iPrint system and how they interact, the implementation process is considerably easier and fewer configuration mistakes are made. In this section of the chapter, you'll learn about iPrint's components and how they function. iPrint is composed of the following pieces:

Warning

In this chapter, we're going to be focusing on network-aware printers that have network interfaces and can be assigned IP addresses. Although it is possible to configure iPrint to work with a non-networked printer connected to the server's LPT port with a parallel cable, I don't recommend implementing your system in this manner.

Instead, you should purchase an external print server and use it to connect your non-network-aware printer to the network medium. Such a device has a built-in network interface that connects to your printer's parallel port.

  • The Printer Agent— Printer Agents are software or firmware entities that control a specific printer. A limited number of printers are available that have an iPrint-compatible Printer Agent embedded within the printers' firmware.

    Be aware, however, that most printers don't have an embedded Printer Agent. To accommodate these printers, you can create a virtual Printer Agent within the iPrint system. This software agent resides on the NNLS server and communicates with the printer over the network media.

    The job of the Printer Agent is to receive print jobs from the iPrint Manager (discussed next) and submit them to the printer hardware. It also sends notifications from the printer, such as "Paper Jam" or "Out of Paper," back to the iPrint Manager.

  • The iPrint Manager— The iPrint Manager is the heart of the iPrint system. This component runs as a service, called ipsmd, on your Linux server. The iPrint Manager service does just what its name implies—it manages Printer Agents. The iPrint Manager is represented by an object in your eDirectory tree. A single iPrint Manager can manage multiple Printer Agents. However, only one iPrint Manager can exist on a given NNLS server.

    The iPrint Manager accepts print jobs from client workstations and directs them to the appropriate Printer Agent. It also provides the administrator with the status of each Printer Agent it has been configured to manage.

  • The IPP Server— The IPP server runs on your NNLS server. Its job is to accept requests submitted to your server's Apache web server from users using web browsers and forward them to the correct iPrint component.

  • The iPrint Driver Store— As mentioned earlier in this chapter, iPrint automatically downloads the correct printer driver to workstations requesting access to an iPrint printer.

    To do this, iPrint maintains a database of printer drivers for each printer. This is the iPrint Driver Store, which is represented by an object in your eDirectory tree. When you configure an iPrint printer, you will be required to upload the appropriate drivers into the iPrint Driver Store.

    As you'll see in an upcoming lab exercise, the iPrint Driver Store can be configured with printer drivers for Windows 95, 98, Me, 2000, and XP for each printer. When a client workstation requests access to a given printer, the iPrint Manager checks to see what version of Windows the client is running and sends down the appropriate driver from the Driver Store.

    To speed access times, the iPrint Manager caches a given driver in RAM after the first time it is requested by a user. This cache is refreshed whenever you upload an updated driver.

  • The iPrint Client— As with iFolder, iPrint requires a small piece of client software to be running on the workstation requesting iPrint services. Currently, Novell only provides an iPrint Client for Windows workstations. The good news is that all versions of Windows since Windows 95 are supported.

    When a user selects a printer in the iPrint web interface, the workstation is checked for the iPrint Client. If it isn't found, the user is presented with a link and prompted to download and install the client.

    The iPrint Client is configured within the Windows printing system to be a print provider. This allows the iPrint Client to interface with the workstation's spooler and accept print jobs from Windows applications.

    When the iPrint Client receives a print job from the Windows spooler, it forwards the job to the iPrint Manager it has been configured to work with.

  • The Map Designer— Earlier, I mentioned that iPrint provides end users with a web-based interface that displays a floor plan of a given office with icons for each printer. By clicking a printer, the iPrint Client automatically downloads the appropriate driver and adds a printer to the Windows workstation.

    iPrint provides you with a simple web-based utility called the Map Designer, which allows you to import a graphic representing your office's floor plan. It also allows you to place icons representing your organization's printers on the graphic and associate them with your Printer Agents.

    When you save your map, it is displayed for end users to use in the iPrint web page. However, you don't have to use this interface if you don't want to (although I highly recommend it). By default, iPrint will display a simple list of printers in a web page that users can use to install printers.

The way these components interact can be confusing. Figure 9.1 displays the function of these iPrint components.

Figure 9.1. iPrint components.

In Figure 9.1, an employee using a Windows XP workstation that has the iPrint Client installed opens the iPrint web page and selects a laser printer on the second floor of his office (1). The iPrint Manager checks and sees that the correct driver for the printer isn't installed on the workstation. The iPrint Manager then secures the driver from the Driver Store and sends it down to the workstation (2).

With the correct driver in place, the user can submit a print job. The iPrint Client receives the job from the Windows spooler and submits it to the iPrint Manager (3). The iPrint Manager waits for the printer to become available and then sends the job to the Printer Agent for the laser printer (4). The job is then printed on the printer.

Let's look at how you go about installing and configuring iPrint on your NNLS server.


Installing and Configuring iPrint

Test Objective Covered:

3. Install and configure iPrint.

As with the NNLS components discussed in the previous chapter, the CLE objectives require you to know how to install and configure iPrint. Just as with these other products, we're not going to spend a great deal of time discussing how to install the iPrint service because NNLS installation procedures and dependencies were presented in depth in Chapter 5, "NNLS Installation and Administration." Instead, we will focus on installing the iPrint Client and configuring the iPrint service in this chapter.

Installing the iPrint Service

If you performed an Express NNLS installation, iPrint was installed on your system. If you performed a Custom install, you had the opportunity to select the iPrint component for installation.

If you didn't select iPrint during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select iPrint.

  6. Finish the installation according to the instructions presented in Chapter 5.

During the installation process, the iPrint system files are copied to the following directories in your server's file system:

  • /var/opt/novell/iprint— This directory holds print jobs as they are spooled to the iPrint Manager.

  • /var/opt/novell/log— This directory contains the iPrint system log file (ipsmd.log).

    Warning

    Be aware that the Novell Apache web server installed with NNLS has the Access Logging directive in the configuration file enabled. If your iPrint system is heavily used, it is theoretically possible for the logs created by the web server to fill up your disk, thus bringing your system to a stop. You should periodically delete the old log files or disable Access Logging in the conf file.

  • /var/opt/novell/httpd/htdocs/ippdocs— This directory contains your system's printer maps.

  • /etc/opt/novell/iprint/— This directory contains the configuration file for the iPrint daemon (ipsmd.conf).

Installing the iPrint Client

As mentioned earlier, Novell only provides an iPrint Client for Windows workstations at the present time. There are rumblings that an iPrint Client for Linux will become available in future releases. We'll have to wait and see if that actually happens.

For now, let's talk about how the iPrint Client is installed on Windows workstations. As with the iFolder Client we discussed earlier in this book, Novell makes the client software for iPrint available on the iPrint website that is installed by default on your server when you install NNLS.

This makes your job as an administrator very easy. Instead of having to run around to all the PCs in your company with a stack of CDs, the end user can simply access this website and download the required client software.

It also makes the required software easily accessible to remote users. Recall the scenario introduced at the beginning of this chapter. Odds are that the employee working from home at 2:00 in the morning will not have a CD with client software handy. Putting the client software on the iPrint website makes it available to any employee who needs it when he or she needs it.

To install the iPrint Client, you need to do the following:

  1. On your Windows workstation, open a web browser and navigate to http://your_server_IP_address/ipp. If you don't have the iPrint Client installed, the dialog in Figure 9.2 is displayed.

    Figure 9.2. iPrint Client installation.

  2. When prompted to install the iPrint Client, click OK.

  3. In the File Download dialog, click Open.

  4. If prompted that the web page is trying to close the browser window, click Yes. The Novell iPrint Client Setup screen appears, as shown in Figure 9.3.

    Figure 9.3. iPrint Client setup.

  5. Click Next. The client files are copied as shown in Figure 9.4.

    Figure 9.4. iPrint Client file copy.

  6. When the file copy is complete, the Install Complete screen is displayed, as shown in Figure 9.5. Click Finish.

    Figure 9.5. iPrint Client installation complete.

  7. Shut down and restart the workstation.

Let's now talk about how to configure your iPrint implementation.

Configuring iPrint

In order to configure your iPrint system, you need to complete a series of tasks. These include the following:

  • Configuring the Driver Store

  • Configuring the iPrint Manager

  • Configuring Printer Agents

  • Creating location-based print maps

Let's look at the first task: configuring your system's Driver Store.

Configuring the iPrint Driver Store

As we discussed earlier, the iPrint Driver Store contains the drivers for the printers serviced by your iPrint Manager. However, the Driver Store is not created during the installation of iPrint. You must create it manually with iManager. To do this, follow these steps:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. In the left frame, scroll down to the iPrint role, shown in Figure 9.6.

    Figure 9.6. iPrint role in iManager.

  4. Select Create Driver Store. The screen in Figure 9.7 appears.

    Figure 9.7. Creating a Driver Store.

  5. In the Driver Store name field, enter a name for your Driver Store object in the eDirectory tree.

  6. In the Container name field, enter the container where you want your Driver Store object to reside.

  7. In the Target Server field, enter the IP address of your iPrint server.

  8. In the eDir Server field, browse to and select the server object for your NNLS server in the eDirectory tree.

  9. Click OK.

  10. When prompted that the Driver Store object has been created, click OK.

After completing this process, you will see a new Driver Store object in your eDirectory tree. In Figure 9.8, a Driver Store object named CLEDriverStore has been created in the IF.CLE container.

Figure 9.8. Driver Store object in the eDirectory tree.

With the Driver Store object created, the next task you need to complete is to add printer drivers to the Driver Store. By default, NNLS doesn't provide any printer drivers, as shown in Figure 9.9.

Figure 9.9. No drivers in the Driver Store.

Before you can deploy iPrint, you must upload the appropriate drivers for your printers into the Driver Store object. Using iManager, you can upload drivers in two ways:

  • You can upload drivers from a driver floppy disk, from a CD-ROM, or from files downloaded from the Internet.

  • You can upload drivers directly from the Windows operating system's set of drivers.

To upload drivers, you must access iManager using Internet Explorer. You can't use Mozilla or Netscape Navigator. You must also access iManager from a workstation that already has the iPrint Client installed. Once these conditions are met, you can upload a driver by doing the following:

  1. From a Windows workstation, open Internet Explorer and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Expand the iPrint role in iManager.

  3. Select Manage Driver Store. The screen in Figure 9.10 is displayed.

    Figure 9.10. Selecting the Driver Store to manage.

  4. In the iPrint Driver Store name field, browse to and select your Driver Store object; then click OK. The screen in Figure 9.11 is displayed.

    Figure 9.11. Managing the Driver Store.

  5. Select the Drivers tab.

  6. Select the operating system you want to upload a printer driver for. In Figure 9.12, the screen for Windows XP driver upload is displayed.

    Figure 9.12. Uploading Windows XP printer drivers.

  7. If you have a printer drivers saved in the file system (such as on a floppy or on a CD), do the following:

    1. Select Add From File.

    2. In the Open dialog, browse to and select the .inf file for the driver you are uploading, as shown in Figure 9.13.

      Figure 9.13. Selecting the .inf file for a printer driver.

    3. Click Open. The Add Resource dialog is displayed, as shown in Figure 9.14.

      Figure 9.14. Adding the printer driver.

    4. Select the printer driver you want to add.

    5. Select the page description language for the driver.

    6. Click OK.

    7. Wait while the driver files are uploaded.

    8. When the upload is complete, you should see the driver listed in the Current drivers list, as shown in Figure 9.15.

      Figure 9.15. Printer driver saved in the Driver Store.

    Warning

    You can only do this if you're running your browser on a Windows workstation. If you want to upload a printer driver for Windows XP, you must run the browser from a Windows XP system. If you want to upload a Windows Me printer driver, you must run the browser from a Windows Me system.

  8. If you want to add printer drivers from the workstation's Windows operating system, do the following:

    1. Select Add From System. The Add Resource screen appears with a list of all the printer drivers found in the Windows driver database, as shown in Figure 9.16.

      Figure 9.16. Adding drivers from the Windows Driver database.

    2. In the Add Resource dialog, select the printer driver you want to upload.

    3. Select the Page Description Language for the driver.

    4. Click OK.

    5. Wait while the driver files are uploaded.

    6. When the files have been uploaded, the driver appears in the Current drivers list, as shown in Figure 9.17.

      Figure 9.17. Driver saved in the Driver Store.

  9. When you have uploaded all the drivers necessary to support your printers, click OK.

You can also add an individual driver to your Driver Store when you create a Printer Agent. We'll discuss how to do this later in the chapter.

With your Driver Store created and configured with drivers, the next task in configuring your iPrint system is to configure an iPrint Manager for your server.

Configuring an iPrint Manager

As we discussed earlier in this chapter, the iPrint Manager is the heart of the iPrint system. The iPrint Manager runs as a daemon (ipsmd) on your NNLS server. However, it is created and managed as an object in your eDirectory tree using iManager.

Unlike configuring a Driver Store, creating and managing an iPrint Manager can be done with any supported web browser and doesn't require the iPrint Client to be installed on the system where the web browser is running. To create and configure an iPrint Manager, do the following:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Under the iPrint role, select the Create Print Manager task. The screen in Figure 9.18 appears.

    Figure 9.18. Creating an iPrint Manager.

  4. In the Manager name field, enter a name for your iPrint Manager object in the eDirectory tree.

  5. In the Container name field, enter the context in the tree where you want the iPrint Manager object created.

  6. In the Target Server field, enter the IP address of your iPrint server.

  7. In the eDir Server field, browse to and select the server object for your NNLS server in the eDirectory tree.

  8. In the Driver Store field, browse to and select the Driver Store object you created previously.

  9. Ensure that Start print manager after creation is marked and then click OK.

  10. When prompted that the iPrint Manager was created, click OK.

That's all there is to it. At this point, your Driver Store and your iPrint Manager are configured. The next thing you need to do is configure Printer Agents for your network printers.

Configuring Printer Agents

Remember that Printer Agents represent each physical printer in your network. The relationship between Printer Agents and printers is one-to-one. A Printer Agent can only be associated with one physical printer.

Note

Interestingly, you can actually have multiple Printer Agents representing a single physical printer. This is very useful because you can create, through eDirectory rights assignments, one Printer Agent with one set of printer settings (such as paper size, duplexing, and so on) available to one type of user and then another Printer Agent with a different set of printer settings available to a different category of user.

As well, a single iPrint Manager (of which there can only be one per server) can manage multiple Printer Agents.

As with the iPrint Manager, Printer Agents are configured using iManager. You can use any supported web browser to configure Printer Agents, and you don't have to have the iPrint Client installed on the workstation you are using to access iManager. To create a Printer Agent, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Under the iPrint role, select the Create Printer task. The screen in Figure 9.19 appears.

    Figure 9.19. Creating a Printer Agent.

  4. In the Printer name field, enter a name for the Printer Agent object in the eDirectory tree.

  5. In the Container name field, enter the context where you want the Printer Agent object to reside in the eDirectory tree.

  6. In the Manager name field, browse to and select the iPrint Manager object you created previously.

  7. In the DNS name or IP address field, enter the IP address or DNS name of your printer.

    Tip

    Novell recommends that you use DNS names in this field. This way, if you ever move the printer and it ends up with a different IP address, you won't have to edit the Printer Agent object.

  8. In the Location field, enter a description of the physical location of the printer.

  9. In the Description field, enter a description of the physical printer.

  10. Click Next. The screen in Figure 9.20 appears.

    Figure 9.20. Configuring printer drivers for a Printer Agent.

  11. In the drop-down list for each version of Windows, select the appropriate printer driver from the Driver Store object.

  12. Click Next.

  13. When prompted that the Printer Agent has been created, click OK.

That's all there is to creating Printer Agents in your tree. Before continuing, you need to understand a couple issues regarding TCP/IP communications between the iPrint Client, the iPrint Manager, and the Printer Agent.

First, data sent between the iPrint Client and the iPrint Manager can be encrypted using IP port 443. You can also use IP port 631 to send data between these two components unencrypted. Unless you have a compelling reason not to, you should always use encrypted communications.

Second, data passing from the Printer Agent and the physical printer is sent using the LPR protocol. LPR doesn't support encryption; therefore, data sent between the Printer Agent on the server and the physical printer hardware is passed in clear text. With this in mind, you should be sure communications between these two components doesn't cross a public network (such as the Internet). The best way to prevent this is to place both components behind the same firewall.

With that said, there's still one more Printer Agent configuration task to be completed. This task is related to the way printers can be added to Windows NT, 2000, and XP workstations. Remember that these operating systems are multiuser systems. Each local user in the system has his or her own profile, Desktop, and My Documents directory (among other things).

Warning

In this context, the term local user refers to Windows user accounts, not eDirectory user accounts. The Administrators and Power Users groups mentioned refer to Windows groups on the local workstation, not to eDirectory groups.

Windows 95, 98, and Me, on the other hand, are not multiuser systems.

Tip

Windows Me can be configured as a quasi multiuser system, but its default configuration is a single-user system.

On Windows 9x and Me systems, every user who uses the system sees the same Desktop and the same My Documents folder, and has access to the same installed printers. If an iPrint printer is downloaded and installed on one of these operating systems, it is available to all local users in the system.

With Windows NT, 2000, and XP, a printer can be installed such that it is available to all local users on the system, much like a Windows 9x or Me system. Only users who are members of the Administrators or Power Users group can create this type of printer.

However, a printer can also be configured on these system such that it is available only to the local user who installed it. This type of printer can be created by any local user.

iPrint can be configured to support either type of printer. This is done by editing the /var/opt/novell/httpd/htdocs/ippdocs/iprint.ini file on your NNLS server, a portion of which is shown in Figure 9.21.

Figure 9.21. Configuring iPrint to support user printers.

In Figure 9.21, notice the AllowUserPrinters parameter. This is used to define how printers installed in the Windows system by iPrint are implemented. If this parameter is set to 0 (which is the default value), iPrint printers can only be installed by local users who are members of the Administrators or Power Users groups. In this situation, iPrint printers installed are available to all local users in the system.

If this parameter is set to 1, then local users who are members of the Administrators or Power Users group can install iPrint printers for all users in the system as they can when this is set to 0. However, if the local user is not a member of either group, he or she can only install the iPrint printer for his or her own user account. In this situation, the printer will only be available to the given user, and other local users won't see the printer.

If this parameter is set to 2, then all users will only be able to install iPrint printers for their own local user accounts. Even users in the Administrators or Power Users group can only install iPrint printers for themselves.

As implied earlier, these parameters have no impact on Windows 95, 98, and Me workstations.

The best way to configure this file depends on your organization's standards. Some will direct that iPrint printers be created only for the individual Windows users. Others may not be quite so rigid. When you're done configuring this file, you're ready to complete the last iPrint configuration task: creating printer location maps.

Creating Location-Based Printer Maps

iPrint can be configured to display the Printer Agents associated with the iPrint server in two different ways. The first way is called the list view. As shown in Figure 9.22, when you access the iPrint web page, located at http://your_server_IP_address/ipp, with Internet Explorer, a simple list of configured printers is displayed. This is the default view for your iPrint server.

Figure 9.22. iPrint list view.

This display is nice, but it seems rather dull to me. You've probably noticed that throughout this chapter I've referred to the fact that you can configure iPrint to display an office map with printer icons that users can use to access printers.

This is the second way Printer Agents for your iPrint system can be displayed. In my opinion, this is the best way to do it. It provides users with an easy way to pick the printer they want to print to. iPrint comes with the iPrint Map Designer, which is a simple web-based tool that you can use to create a customized map for your organization.

To do this, you will need a Windows workstation that has Internet Explorer 5.5 and the iPrint Client installed. You'll also need a graphic (in BMP, GIF, or JPEG format) of your office's floor plan. If you just want to experiment, NNLS includes a couple sample maps in the /var/opt/novell/httpd/htdocs/ippdocs/images/maps directory. We'll use these sample maps later in a lab exercise for this chapter.

Once you have your workstation and your map image files ready, you can configure your location-based printing maps by doing the following:

  1. On your Windows workstation, map a drive to a Samba share on your NNLS server.

  2. Copy your map image files to the /var/opt/novell/httpd/htdocs/ippdocs/images/maps directory on your iPrint server.

  3. On your Windows workstation, open Internet Explorer and navigate to http://your_server_IP_address/ippdocs/maptool.htm. When you do, the screen in Figure 9.23 appears.

    Figure 9.23. iPrint Map Designer.

  4. In the left frame, scroll down to the Background drop-down list. This drop-down list is dynamically populated with the map image files you copied to the maps directory in step 2.

  5. In the Background drop-down list, select a background image file. The map is set as the page background, as shown in Figure 9.24.

    Figure 9.24. Adding a map image file to the Map Designer.

  6. Scroll back up to the Printer icon drop-down list.

  7. In the Printer icon drop-down list, select the printer icon that best matches your physical printer.

  8. Drag the printer icon to the location on the background map where the physical printer is situated. The icon is placed on the map and is framed in a blue square, as shown in Figure 9.25.

    Figure 9.25. Adding a printer icon to a map.

  9. Click the printer icon you just placed on the map.

  10. In the Printer List drop-down list, select the Printer Agent you want to associate with the icon.

  11. Scroll down to the Printer Agent section. Notice the Printer URL is automatically populated for you.

  12. In the Mouse Over Text field, enter text you want to appear when the user hovers the mouse cursor over the printer icon on the Windows workstation.

  13. In the Printer Caption field, enter a caption for the printer.

  14. Above the map, select Driver Settings. The dialog in Figure 9.26 appears.

    Figure 9.26. Configuring printer defaults.

  15. Configure the default settings for your printer; then click OK.

  16. In the top frame, click Save.

  17. Using a filename of your choice, save the file to the drive mapped to the Samba share on your NNLS server.

  18. Close your browser window.

  19. On your server, copy the file from your Windows workstation to the /var/opt/novell/httpd/htdocs/ippdocs directory on your NNLS server.

    With that, the iPrint system is ready to go! Let's now discuss how to install iPrint printers on Windows workstations.


Configuring iPrint Printers on Windows Workstations

Test Objective Covered:

4. Print with iPrint.

With the iPrint Client installed, the Driver Store configured, the iPrint Manager implemented, the Printer Agents configured, and the iPrint maps created, you're ready to start configuring iPrint printers on client Windows workstations.

This is done using the map HTML file you created and copied to your iPrint server. To access this map and install the printers it contains, you need to do the following:

Warning

These steps are written using Windows XP Professional. If your organization uses a different version of Windows, the steps may be slightly different.

  1. Verify that the iPrint Client has been installed on your Windows workstation. To do this, you can do the following:

    1. Select Start, Control Panel, Add or Remove Programs.

    2. Verify that the Novell iPrint Client is displayed in the list of installed programs, as shown in Figure 9.27.

      Figure 9.27. Verifying that the iPrint Client is installed.

    3. Close the Add or Remove Programs and Control Panel windows.

  2. On your Windows workstation, run Internet Explorer and navigate to http://your_server_IP_address/ippdocs/your_map_file. For example, if your server's IP address is 192.168.1.36 and the filename of the iPrint map you created is map.htm, you would enter http://192.168.1.36/ippdocs/map.htm. The map you created previously is displayed, as shown in Figure 9.28.

    Figure 9.28. iPrint location-based printing map.

  3. In the map, click the printer you want to use. The dialog in Figure 9.29 appears.

    Figure 9.29. Selecting an iPrint printer.

  4. When prompted to install the printer, click OK. The screen in Figure 9.30 appears.

    Figure 9.30. Installing an iPrint printer.

  5. When prompted that the printer has been installed, click OK.

  6. Verify that printer was installed correctly by selecting Start, Control Panel, Printers and Faxes. You should see an icon for the iPrint printer.

You can now use the iPrint printer just as you would any other printer. When you select File, Print in any application, you can select the iPrint printer to send the job to.

On occasion, I've had students express the opinion that configuring iPrint is somewhat complex and represents a fair amount of work for the network administrator. To that, I agree. It does take a little more work than going into the console of a Windows server and sharing a printer.

If you've ever worked as a help desk technician supporting user printing, however, you'll immediately see how helpful iPrint can be for end users.

Face it: If you're an experienced Windows user and you know something about computer networking, setting up a network printer isn't very hard.

Most employees at any given company, however, are not experienced Windows users, nor do they know anything about networking. With iPrint, you can give users a URL that they can browse to (something most employees are very good at). There they can simply click the printer they want to use, and all the network configuration information is automatically done. Yes, iPrint does take a little bit of work to get set up. But once done, it will save the network administrator huge amounts of time after that in the form of reduced support calls.

This solution tends to be very popular with help desk personnel. Help desk incidents related to printing are usually the most common calls help desk techs must deal with. iPrint reduces these calls because it only requires the end users to know where the printer exists in the office; it doesn't require them to know where it resides in the network.

Enough talk; let's spend some time configuring iPrint on your server.


Lab Exercise 9.1: Implementing iPrint

In this lab, you're going to configure iPrint on your server. Then you will install the iPrint Client on your Windows workstation and test automated printer driver download.

Warning

In order to complete this exercise, you will need the second Windows workstation you used for the exercises in Chapter 8, "Managing File Services with iFolder." This computer must be able to communicate through a network medium with the server you have been working with throughout this book.

You will also need a network-aware printer to complete this exercise. If you are completing this lab exercise at work and have access to a network printer on your company's network, go ahead and use it.

If you do, you should probably get your network administrator's permission to do so. You can probably talk him or her into letting you use it if you point out that setting up iPrint for this lab exercise will have little or no impact on your organization's existing print configuration.

If you're completing this lab from home, you can use your home printer, but you will need to purchase an external print server. Instead of plugging your printer into your server, you plug these devices into your printer's parallel port; they provide an integrated Ethernet interface with an RJ-45 connector.

This allows you to connect your home printer directly into your network. These devices can be purchased for less than $50 at most computer stores. You may be able to get one for even less at one of the many auction websites on the Internet.

Complete the following steps:

  1. Record your printer's IP address and subnet mask. You'll need this information when you configure a Printer Agent for the printer.

  2. Install the iPrint Client on your Windows workstation by completing the following:

    Warning

    These steps are written for Windows XP Professional. If you're using a different version, you may have make some adjustments.

    1. On your Windows workstation, open a web browser and navigate to http://your_server_IP_address/ipp.

    2. When prompted to install the iPrint Client, click OK.

      Tip

      If, for some reason, you're not prompted to install the iPrint Client, you can initiate the installation by selecting the Install iPrint Client link.

    3. In the File Download dialog, click Open.

    4. If prompted that the web page is trying to close the browser window, click Yes.

    5. Click Next.

    6. When the file copy is complete, the Installation Complete screen is displayed. Click Finish.

    7. Shut down and restart the workstation.

    8. When the workstation has rebooted, authenticate to the workstation as Administrator.

  3. Create a Driver Store by completing the following steps:

    1. On your Windows workstation, open Internet Explorer and navigate to https://your_server_IP_address/nps/iManager.html.

    2. Authenticate as admin with a password of novell.

    3. In the left frame, scroll down to and expand the iPrint role.

    4. Select Create Driver Store.

    5. In the Driver Store name field, enter CLEDriverStore.

    6. In the Container name field, enter IF.CLE.

    7. In the Target Server field, enter the IP address of your server.

    8. In the eDir Server field, browse to and select the CLE1.IF.CLE server object.

    9. Click OK.

    10. When prompted that the Driver Store object has been created, click OK.

  4. Configure the Driver Store with drivers for your printer:

    1. Under the iPrint role in iManager, select Manage Driver Store.

    2. In the iPrint Driver Store name field, browse to and select the CLEDriverStore.IF.CLE Driver Store object; then click OK.

    3. Select the Drivers tab.

    4. Select Windows XP Drivers.

      Warning

      If you're using a different version of Windows, select the appropriate version in this screen.

    5. If the driver for your printer is saved on a floppy disk or a CD, do the following:

      1. Select Add From File.

      2. In the Open dialog, browse to and select the .inf file for your driver.

      3. Click Open.

      4. In the Add Resource screen, select the printer driver you want to add.

      5. Select the Page Description Language for the driver.

      6. Click OK.

      7. Wait while the driver files are uploaded.

      8. When the upload is complete, you should see the driver listed in the Current drivers list.

    6. If you want to add a printer driver for your printer from your workstation's Windows driver database, do the following:

      1. Select Add From System. The Add Resource dialog appears with a list of all the printer drivers found in the Windows driver database.

      2. In the Add Resource dialog, select the printer driver you want to upload.

      3. Select the Page Description Language for the driver.

      4. Click OK.

      5. Wait while the driver files are uploaded.

      6. When the files have been uploaded, the driver appears in the Current drivers list. Click OK.

  5. Configure an iPrint Manager by completing the following steps:

    1. Under the iPrint role, select the Create Print Manager task.

    2. In the Manager name field, enter CLEManager.

    3. In the Container name field, IF.CLE.

    4. In the Target Server field, enter the IP address of your server.

    5. In the eDir Server field, browse to and select your CLE1.IF.CLE server object.

    6. In the Driver Store field, browse to and select the CLEDriverStore.IF.CLE object you created previously.

    7. Ensure that Start print manager after creation is marked; then click OK.

    8. When prompted that the iPrint Manager was created, click OK.

  6. Create a Printer Agent for your printer by completing the following steps:

    1. Under the iPrint role, select the Create Printer task.

    2. In the Printer name field, enter CLE-PA.

    3. In the Container name field, enter IF.CLE.

    4. In the Manager name field, enter CLEManager.IF.CLE.

    5. In the DNS Name or IP Address field, enter the IP address of your printer.

    6. In the Location field, enter a description of the physical location of the printer.

    7. In the Description field, enter a description of the printer.

    8. Click Next.

    9. In the drop-down list for the version of Windows running on your workstation, select your printer driver from the Driver Store object.

    10. Click Next.

    11. When prompted that the Printer Agent has been created, click OK.

  7. Configure your iPrint service to support user workstations by completing the following steps:

    1. On your server, open a terminal session.

    2. Change to the root user account by entering su - and supplying a password of novell.

    3. At the shell prompt, enter vi /var/opt/novell/httpd/htdocs/ippdocs/iprint.ini.

    4. Scroll down to the AllowUserPrinters line.

    5. Press Ins.

    6. Change the value of the AllowUserPrinters parameter to 1.

    7. Press Esc.

    8. Enter :exit.

    9. At the shell prompt, enter /etc/init.d/novell-ipsmd stop and then enter /etc/init.d/novell-ipsmd start.

At this point, you have a functioning iPrint system. You could use the list view in the iPrint web page to distribute printer information to user workstations. However, we want to configure location-based printer maps to make this process more intuitive.


Lab Exercise 9.2: Implementing Location-Based Printing

In this lab, you will use the iPrint Map Designer to create a location-based printer map. Then you will test the system by downloading an iPrint printer to your Windows workstation. Complete the following steps:

  1. On your Windows workstation, map drive I: to the IFEmployees Samba share on your server.

    Next, create a location-based print map for the second floor of a hypothetical office building by completing the following:

    1. Open Internet Explorer and navigate to http://your_servers_IP_address/ippdocs/maptool.htm.

    2. In the left frame, scroll down to the Background drop-down list.

    3. In the Background drop-down list, select Office2.gif.

    4. In the left frame, scroll back up to the Printer Icon drop-down list.

    5. In the Printer Icon drop-down list, select a printer icon that closely matches the appearance of your printer.

    6. Drag the printer icon from the left frame to the Media Room on the background map.

    7. Click the new printer icon on the background map.

    8. In the Printer List drop-down list, select your CLE-PA Printer Agent.

    9. In the left frame, scroll down to the Mouse Over Text field.

    10. In the Mouse Over Text field, enter your printer's make and model.

    11. In the Printer Caption field, enter Media Room Printer.

    12. Select Driver Settings.

    13. Configure the defaults for your printer and then click OK.

    14. Click Save.

    15. In the Save In drop-down list, select drive I: (which should be mapped to the IFEmployees share on your server).

    16. In the File name field, enter Floor2; then click Save.

    17. Close your browser window.

    18. On your server, open a terminal session.

    19. Change to your root user account by entering su - and supplying a password of novell.

    20. At the shell prompt, enter cp /var/ifemployees/Floor2.htm/var/opt/novell/httpd/htdocs/ippdocs.

  2. Test your iPrint configuration by completing the following:

    1. On your Windows workstation, open Internet Explorer and navigate to http://your_server_IP_address/ippdocs/Floor2.htm. The location-based printing map you created previously should be displayed.

    2. Click the Media Room Printer icon.

    3. When prompted to install the printer, click OK.

    4. Wait while the printer driver is installed.

    5. When prompted that the driver has been installed, click OK.

      Tip

      Sometimes errors occur when downloading drivers to Windows XP workstations. If you receive a 126 error, the path in the workstation's environment variable isn't configured correctly. To fix it, right-click My Computer and select Properties. Select the Advanced tab. Select Environment Variables. Select the Path string; then select Edit. Add the following string to the beginning of the variable string (all on the same line):

      %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\

      Wbem;%SystemRoot%\system32\nls;%SystemRoot%\system32\nls\

      ENGLISH;

      Restart the workstation and access the printer map again.

    6. With the location-based printing map displayed in your Internet Explorer window, select File, Print.

    7. In the General tab, select your iPrint printer and then click Print.

    8. Verify that your document is printed on your printer.

  3. View the statistics for your printer by completing the following steps:

    1. In your browser window, access iManager and authenticate as admin with a password of novell.

    2. Under the iPrint role, select Manage Printer.

    3. In the iPrint printer name field, enter CLE-PA.IF.CLE.

    4. Click OK. The Manage Printer screen appears, as shown in Figure 9.31.

      Figure 9.31. Installing an iPrint printer.

    5. Select Printer health monitor.

    6. When prompted, authenticate as admin with a password of novell. The Printer Agent Information screen is displayed.

    7. View the statistics for your printer. When you're done, click Back. The iPrint Manager summary screen is displayed.

    8. Select Advanced iPrint Manager Information.

    9. View the iPrint Manager current status; then click Back.

    10. Close your browser windows.

You're done! You've successfully configured an iPrint system! Let's review what you learned in this chapter.


Summary

In this chapter, you learned how iPrint provides IPP-based printing services to users over the Internet. Using iPrint, end users can use location-based printing maps to automatically configure printers on workstations without help desk intervention.

You learned that iPrint is composed of the following components:

  • iPrint Printer Agent

  • iPrint Manager

  • IPP Server

  • iPrint Driver Store

  • iPrint Client

  • Map Designer

You also learned how to install the iPrint service on your Linux server and how to install the iPrint Client on Windows workstations.

After installing the service and the client, you learned to configure your iPrint server by completing the following tasks:

  • Configure the Driver Store.

  • Configure the iPrint Manager.

  • Configure Printer Agents.

  • Create location-based print maps.

You also learned how to access your iPrint maps in Internet Explorer to download printer drivers.

In the next chapter, you'll learn how to use NNLS to provide email services with NetMail.


Chapter 10. Implementing Email Services with NetMail

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Identify NetMail features.

  2. Describe NetMail components.

  3. Describe how NetMail works.

  4. Install NetMail.

  5. Configure and use NetMail.

In the previous chapter, you learned how to provide your users with Internet-based printing using iPrint. In this chapter, you will learn how to increase your users' collaboration capabilities with the NetMail component of NNLS.


An Introduction to NetMail

Test Objectives Covered:

1. Identify NetMail features.

2. Describe NetMail components.

Since the early 1990s, email has become a mainstay of most organizations. Today, it's one of the primary means of communication in most offices. Several years ago, I worked for a company that used vast seas of cubicles to provide working space for its employees.

I always found it funny that the members of my team (myself included) would use email almost exclusively to communicate, even though we all sat within 30 feet of each other. We could have just as easily poked our heads over the cubicle walls and communicated verbally. This dynamic has been repeated in corporations and other organizations around the world.

To further demonstrate this dependence, imagine what would happen in your organization if your email server were to go down. I've also experienced this scenario on occasion. When the email system goes down, productivity in the organization slows to a crawl.

With this in mind, NNLS includes a powerful email solution for your implementation: NetMail. If you've worked with Linux previously, you know that many email solutions are already available for this platform. If you're running SUSE, the postfix mail service is automatically installed. If you're running most other distributions, your system is probably running a version of sendmail.

In and of themselves, these two services are pretty basic. If you search Open Source websites, such as Sourceforge.net, you can find numerous add-ons, such as POP3, SMTP, and web interface support, to these services that turn them into full-service email solutions.

If you want an email solution with a little more muscle, you could also implement SUSE's Openexchange email server. Openexchange is a very powerful email solution (also available from Novell through its acquisition of SUSE). With all these email solutions available, why should you consider implementing the NetMail component of NNLS?

The answer relates to one of NetMail's key benefits: NetMail is fully integrated with eDirectory. Other than Novell's new GroupWise for Linux release, no other email package boasts the level of eDirectory integration provided by NetMail.

Note

Due to the way GroupWise works with eDirectory, many would argue that NetMail provides a higher level of eDirectory integration than GroupWise. We're not going to get into that argument in this book. The NetMail-versus-GroupWise tensions within the Novell community can run very high.

In Chapter 5, "NNLS Installation and Administration," I stated that eDirectory is the backbone of NNLS. By now, you should fully understand this statement. Every product you have implemented so far, from eGuide to iPrint, relies on eDirectory as a data store and as an authentication system. NetMail is no different. It leverages eDirectory to store its server configuration settings as well as to authenticate users.

If you were to implement a different email package, you would have to maintain a separate set of user accounts. In a very small company, this may not pose a serious problem. But in medium-to-large organizations, this represents a tremendous (and expensive) workload for the network administrator. By implementing NetMail, every user in your tree can have an email account. When new users are added to the tree, they automatically have an email account.

Let's review some of the features of NetMail.

NetMail Features and Benefits

In addition to eDirectory integration, NetMail provides the following features and benefits:

  • NetMail is very easy to deploy.

  • NetMail is less expensive to maintain than other Linux email products.

  • Using standards-based protocols, including POP3 and IMAP, the NetMail server is compatible with all email client software, including Novell's GroupWise client and Microsoft's Outlook client.

  • NetMail is highly scalable. A single Linux server can support thousands of email users. Novell has even tested NetMail successfully with 30,000 email users on a single Linux server!

  • NetMail is modular. Different NetMail components can be distributed among Linux servers in your network. This even further enhances NetMail's scalability. Modules can also be distributed redundantly, providing a degree of fault tolerance in the event of a server failure.

  • NetMail supports multiple processors.

  • NetMail supports Secure Sockets Layer, Transport Layer Security, and Secure MIME protocols to protect data.

  • NetMail provides a web-based user interface, allowing full-featured access without email client software.

  • NetMail provides a full collaboration solution by providing email, calendaring, and scheduling services.

As you implement NetMail in this chapter's lab exercise, you will come to understand just how powerful this NNLS component really is. Before we get into the installation and configuration of NetMail, however, you need to understand the various components that comprise the product.

NetMail Components

As mentioned previously, NetMail is a highly modular product. This modularity allows you to distribute your implementation among several Linux servers, which can make your system very fast.

It also allows you to customize your deployment to meet your organization's requirements. This is done by only deploying the NetMail components that you need. This further increases NetMail's scalability and speed. Alternatively, you can also install all your required NetMail components on the same Linux server. NetMail components are referred to as agents. Let's discuss the role and function of each agent.

NetMail Agents.

Each NetMail agent is represented by an object in the eDirectory tree. This is shown in Figure 10.1.

Figure 10.1. NetMail agents.

Each agent provides a particular service to the NetMail system. One may provide POP3 support, one may provide IMAP support, and another may provide an address book function. Functioning together, these agents make up the entire NetMail system. The agents provided by NetMail include the following:

  • The Address Book Agent— This agent allows LDAP-compliant email clients to populate their address books with user information from your eDirectory tree. The Address Book Agent uses IP port 52389. The Configuration attributes of the Address Book Agent are shown in Figure 10.2.

    Figure 10.2. Address Book Agent object properties.

  • The Alias Agent— The Alias Agent is used to automatically generate email addresses for users. The email addresses generated are referred to as user aliases. You can generate user aliases using various combinations of the user objects' given name and surname attributes. For example, you could configure a user alias to be formatted as givenname.surname@your_domain, givenname_surname@your_domain, or givenname_first_letter+surname@your_domain.

    Warning

    Don't confuse these aliases with alias objects in the eDirectory tree (as discussed in Chapter 5). The email aliases generated by the Alias Agent are stored in memory, not in the eDirectory tree.

    This value is used to automatically populate the Internet Email Address property of user objects in your tree.

  • The AntiSpam Agent— The AntiSpam Agent in NetMail allows you to configure spam filters for your implementation. The filtering capabilities are relatively basic, but they can be very effective. The AntiSpam Agent allows you to build a list of filtered domains and/or email addresses from which your NetMail system will refuse to accept email messages. The attributes of the AntiSpam Agent object are shown in Figure 10.3.

    Figure 10.3. AntiSpam Agent object properties.

  • The AntiVirus Agent— The AntiVirus Agent allows you to integrate third-party antivirus programs with your NetMail system. The AntiVirus Agent will delete any infected messages from the system. It can also be configured to return an infected message back to the sender or just send a notification that an infected message was received.

    The AntiVirus Agent supports McAfee NetShield, CA InnoculateIT, Symantec CarrierScan, and Command Antivirus. To use these products, you must install and configure them prior to configuring the AntiVirus Agent.

  • The AutoReply Agent— The AutoReply Agent allows users to configure autoresponses for their email accounts. Users can configure a message to be automatically sent to senders. They can also configure received messages to be forwarded to a different email address.

  • The Calendar Agent— The Calendar Agent in NetMail allows users to schedule appointments and invite other users to attend. When this is done, the invitees are sent an appointment and given the opportunity to accept or decline the invitation.

    The NetMail system keeps track of users who have accepted and who have declined, allowing the user who scheduled the appointment to identify who will be attending.

    This agent is optional if you are using email client software that supports its own calendaring system (such as Outlook XP). If so, you can let the clients manage calendaring tasks by not implementing the Calendar Agent. In this situation, NetMail simply delivers the appointments as messages to the clients and doesn't process them as calendar items.

    If you are deploying the NetMail web interface, however, you must deploy the Calendar Agent if you want users to be able to send and receive appointments. The configurable property of the Calendar Agent object in your tree is minimal, as shown in Figure 10.4.

    Figure 10.4. Calendar Agent object property.

  • The Connection Manager Agent— This agent is used by the NetMail system to keep track of users who have authenticated to the system. The POP and IMAP Agents (discussed later) forward authenticated users' IP addresses to the Connection Manager Agent. This information is used by other NetMail agents to prevent the system from being used to relay email messages.

    Note

    Email relay occurs when an unauthorized third party uses your SMTP service to send email messages. This effectively spoofs the origin of the email, leading recipients to believe the message originated from your organization. This strategy is frequently used by shady email spammers to conceal the real origin of their messages.

    The Connection Manager Agent runs in IP port 689. Because of the risk of relayers, Novell recommends that the server hosting the Connection Manager Agent be situated behind your organization's firewall. The Connection Manager Agent object attribute is shown in Figure 10.5.

    Figure 10.5. Connection Manager Agent object property.

  • The IMAP Agent— The IMAP Agent is used to allow users to access their mailboxes in the NetMail system with a client using the IMAP 4 protocol.

    Note

    IMAP stands for Internet Message Access Protocol. IMAP is a protocol used to download messages from an email server. IMAP allows you to store your email messages on the email server and/or download them to the local email client.

    IMAP also provides you with the ability to download only the message header from the server to the client, allowing you to determine whether you want to download the entire message. IMAP allows you to maintain multiple folders on the server and move email messages between them. IMAP uses IP port 143.

    According to Novell, each concurrent IMAP connection to your NetMail server consumes about 300KB of RAM. To keep your system functioning smoothly, you should try to anticipate the load that will be placed on your server by the IMAP Agent and add RAM to accommodate it. The attribute of the IMAP Agent object is shown in Figure 10.6.

    Figure 10.6. IMAP Agent object property.

  • The List Server Agent— The List Server Agent allows your NetMail server to function as a list server. You can use this agent to service lists generated manually or generated using eDirectory objects. For example, you could generate a list using the IF.CLE organizational unit in your tree. All users in the container would be included in the list. New users added later to the container would be added dynamically to the list.

  • The Modular Web Agent— As mentioned previously, NetMail can be used with standard email client software or with its own web-based user interface. The Modular Web Agent is the service that provides this interface. It runs on IP port 52080 (insecure) and port 52443 (secure).

    The Modular Web Agent employs two default templates used to create the web interface. These are the WebMail and WebAccess templates. If you have a little programming experience, you can modify these templates to customize the appearance of these interfaces.

    As with the IMAP Agent, the Modular Web Agent consumes about 300KB of RAM for each concurrent session. You should calculate the load that will be placed on your Modular Web Agent and add RAM to your system accordingly. The properties of the Modular Web Agent object are shown in Figure 10.7.

    Figure 10.7. Modular Web Agent object properties.

  • The NMAP Agent— The Network Messaging Application Protocol (NMAP) Agent is the heart of the NetMail system. Its primary job is the processing of messages through the NetMail system. Unlike many of the other NetMail agents, the NMAP Agent is not optional. You must have at least one NMAP Agent running in your network for the NetMail system to function.

    The NMAP Agent is the only NetMail agent that has access to the message store directory in the Linux server's file system. The NMAP agent maintains a mailbox for each NetMail user.

    The NMAP Agent is also the only NetMail agent that has access to the message queue in the Linux file system. Every message waiting to be processed is stored in this queue.

    All other NetMail agents access the message store or the message queue through the NMAP Agent. For example, if the IMAP Agent needs to retrieve a message from a user's mailbox, it contacts the NMAP Agent, which processes the request on behalf of the IMAP Agent.

    Because the NMAP Agent requires access to the file system, it must be deployed on the same server where the message store and message queue are located. The attributes of the NMAP Agent object are shown in Figure 10.8.

    Figure 10.8. NMAP Agent object properties.

  • The POP Agent— The POP Agent allows email clients to access user mailboxes using the POP3 protocol.

    Note

    Like IMAP, POP3 is an email protocol used to retrieve messages from an email server. Unlike IMAP, POP3, by default, always deletes the message from the email server when it is downloaded to an email client. It also only allows a single folder on the email server for each user. POP3 runs on IP port 110.

    As you may have gathered from the preceding discussion, the NetMail system can't deliver messages to clients unless an agent specific to the protocol used by the clients has been deployed. For example, if you want users to have IMAP access to their mailboxes, you must deploy the IMAP Agent. If you want them to have access to their mailboxes using POP3, you must deploy the POP Agent. If you don't implement either of these, users won't be able to access their mailboxes using email client software.

    If you only want users to be able to access their mailboxes using NetMail's web interface, you only need to deploy the Modular Web Agent. The IMAP and POP Agents aren't required to use the Modular Web Agent. The property of the POP Agent object is shown in Figure 10.9.

    Figure 10.9. POP Agent object property.

  • The Proxy Agent— The Proxy Agent is a useful agent that allows users to configure their NetMail mailbox to retrieve email from up to three other email accounts external to the NetMail system using the POP3 or IMAP protocol. Messages retrieved from the external accounts are stored in and can be retrieved from the user's NetMail mailbox. The attributes of the Proxy Agent object are shown in Figure 10.10.

    Figure 10.10. Proxy Agent object properties.

  • The SMTP Agent— The SMTP Agent has two main roles in the NetMail system. First, whereas the IMAP and POP3 Agents are used to transfer messages from the NetMail server to remote email clients, the SMTP Agent's job is to allow messages to be sent from email client software to the NetMail server.

Note

SMTP stands for Simple Mail Transfer Protocol. The SMTP protocol supports both sending and receiving email messages; however, its receiving capabilities are very limited. Therefore, it is usually deployed in conjunction with IMAP and/or POP3. SMTP is used to send mail, whereas IMAP or POP3 is used to receive mail. SMTP runs on IP port 25.

If you don't implement an SMTP Agent, users who employ email client software, such as Outlook, won't be able to send messages.

Its second job is to function as an interface between the NetMail system and the external network (including the Internet). Messages sent by NetMail users to other internal NetMail users are delivered by the NMAP Agent. However, if a NetMail user sends a message to an external recipient, the SMTP Agent is employed to send the message over the Internet to the destination mail server.

The SMTP Agent can be configured with a variety of settings that restrict the host domains that messages can be sent to, limit the maximum message size allowed, and perform reverse DNS lookups. The properties of the SMTP Agent object are shown in Figure 10.11.

Figure 10.11. SMTP Agent object properties.

As mentioned, each of these agents is represented by an object in your eDirectory tree. All configuration parameters for each are stored as attributes of the object.

The NetMail installation also adds several other objects to your eDirectory tree. Let's look at each.

NetMail Objects Added During Installation

During the installation of NetMail, the schema of your eDirectory tree is extended and several new object classes are added. Corresponding objects are also created in the tree. In addition to the agent objects discussed previously, the following objects are also added:

  • Internet Services— The Internet Services object is a container object. It is always installed at the root of your eDirectory tree, and there can be only one instance per tree. The Internet Services container can only contain NetMail objects. The Internet Services container is shown in Figure 10.12.

    Figure 10.12. Internet Services container.

  • Messaging Server— The Messaging Server object represents your NetMail server. The Messaging Server object contains all the NetMail agent objects the server has been configured to use, as shown in Figure 10.13.

    Figure 10.13. The Messaging Server object.

    In addition to housing agent objects, the Messaging Server object also contains configuration parameters for the NetMail service running on your server. These are shown in Figure 10.14.

    Figure 10.14. Messaging Server object properties.

    Note

    Don't worry about how you use all these configuration parameters yet. We'll discuss configuration tasks later in this chapter.

  • Parent Objects— Although it sounds plural, the Parent Objects eDirectory object is actually a single container object. It is used when you want to break up your NetMail system into smaller units, which allows you to configure multiple groups of agents with different settings. Each group functions as if it were its own autonomous email system. The Parent Objects container is shown in Figure 10.15.

    Figure 10.15. The Parent Objects container.

    Don't worry too much about this functionality for the CLE exam. You will only be required to manage NetMail as a single messaging system.

  • Templates— The Templates object in the eDirectory tree is a container object that contains the WebAccess and WebMail templates (discussed earlier) to provide users with a browser-based interface into their NetMail mailboxes. The Templates container is shown in Figure 10.16.

    Figure 10.16. The Templates container.

    By default, your Modular Web Agent is configured to use the WebAccess template, as shown previously in Figure 10.7. This is a good choice, in my opinion. As you'll see in this chapter's lab exercise, the WebAccess template provides a well-designed, intuitive user interface.

    The WebMail template functions just fine, but to be frank, it is very plain. I've even heard some students refer to it as "ugly." I prefer a kinder term, such as "minimalist."

    When your Modular Web Agent is loaded during the NetMail startup, it loads the specified template into RAM.

  • Mailing Lists— The Mailing Lists object is a container object residing within the Internet Services container. As mentioned earlier, your NetMail server, using the List Server Agent, can function as a list server. When a message is sent to the list server, it is automatically forwarded to every email address contained in the mailing lists the server is configured to use.

    Within the Mailing Lists container, you can create two different types of mailing list objects: Mailing List and NDS Mailing List. Mailing List objects function in a manner similar to traditional list servers. Users manually subscribe to a list. When they do, a List User object is created for the email address within the Mailing List object. Messages sent to the list are sent to each List User object.

    The NDS Mailing List object functions differently. NDS Mailing Lists are composed of container, group, user, organizational role, or alias objects from the eDirectory tree. When a message is sent to the list, it is delivered to each user configured in the NDS Mailing List object.

    This can be very powerful, especially if you use container or group objects, because these objects are dynamic. If you add or delete users from these objects, they are automatically added or deleted from the list. There's no need to keep a list updated manually.

In addition to these new object classes, NetMail also extends the schema to add new attributes to several existing object classes, including organization, organizational unit, user, and server objects.

Tip

These added attributes are not visible from within iManager. You can only see and modify them from within WebAdmin. WebAdmin is a web-based administration tool that is used to configure your NetMail implementation. We'll cover WebAdmin later in this chapter.

Organization and organizational unit objects have Domain and Message Store attributes added, as shown in Figure 10.17.

Figure 10.17. Container object NetMail attributes.

The Domain attribute allows you to set a customized email domain for users in that container. The Message Store attribute allows you to configure a customized message store directory for users in the container. This parameter doesn't change the message queue or scms directory used by the NMAP Agent. The message queue and the scms directories are discussed later in this chapter (see Table 10.1).

Table 10.1. NetMail Directories

DIRECTORY

DESCRIPTION

/opt/novell/netmail/bin

This directory contains the NetMail binaries. The NetMail binary, ims, is located in this directory. Binaries for each NetMail agent discussed previously also reside in this directory.

/var/opt/novell/netmail/users

This directory is NetMail's default message store. All NetMail users' mailboxes and associated messages are stored within this directory structure.

/var/opt/novell/netmail/users/user/INBOX.box

This file contains all of the given NetMail user's incoming email messages. Email attachments are included within the file.

/var/opt/novell/netmail/users/user/INBOX.idx

This file contains an index of all messages in the given NetMail user's inbox.

/var/opt/novell/netmail/users/user/MAIN.cal

This file contains all of the given NetMail user's calendar items.

/var/opt/novell/netmail/users/user/MAIN.idc

This file is similar to the INBOX.idx file. This file contains an index of all calendar items in the given NetMail user's MAIN.cal file.

/var/opt/novell/netmail/users/user/folder.box

When a user creates a folder in his or her NetMail mailbox, a single file is created in the user's mailbox directory. All items copied to the folder are actually added to this file.

/var/opt/novell/netmail/users/user/folder.idx

This file contains an index of messages contained in the mailbox folder file discussed previously.

/var/opt/novell/netmail/scms

This directory is the single copy message store (SCMS). In NetMail, if a message is sent to multiple recipients and if the message is more than 2KB in size, the NMAP Agent delivers the actual message to the scms directory. The recipients receive a message in their inbox that points to the scms directory instead of the same large message being replicated to multiple recipients. Messages are stored in subdirectories of the scms directory. The messages are sorted by the last character of their hexadecimal filename and placed in directories corresponding to the last hex character of their filename.

/var/opt/novell/netmail/scms/directory/nnn.cnt

This file is a counter file. The data in this file is a value equal to the total number of recipients a particular message has been sent to. Each time a recipient deletes the message from their inbox, the value of this file is decreased by 1. If the value reaches 0, the message and the counter file are deleted from the scms directory.

/var/opt/novell/netmail/spool

This directory is the Message Queue. Incoming or outgoing messages waiting to be processed are stored in this directory.

User objects have many new attributes added. A partial list of NetMail user attributes is shown in Figure 10.18. These attributes include the following:

Figure 10.18. User object NetMail attributes.

  • User Status— Allows you to enable or disable the given user as a NetMail user.

  • Timeout— Specifies the amount of inactive time (in minutes) before the user is logged out of the NetMail web interface.

  • Privacy— Specifies what information is displayed to end users through the Address Book Agent. When this attribute is set to None, the user's email address and full name are displayed by the Address Book Agent. When it's set to Limited, only the user's email address is displayed. When it's set to Unlisted, no information is displayed.

  • Reply To Address— Specifies the user's reply-to address. This address appears in the From field in outgoing messages.

  • Quota— When enabled, this parameter specifies how much disk space the given user's mailbox may consume.

  • Forwarding— When enabled, this parameter forwards received messages to a specified email address.

  • Auto Reply— When enabled, this parameter allows the user to send an automatic response to senders when a message is received.

  • Time Zone— Specifies the time zone the user resides in.

  • Template— Allows the user to specify which NetMail web interface he or she wants to use.

The server object has the Novell NetMail Server attribute added, as shown in Figure 10.19. This attribute cannot be edited.

Figure 10.19. Server object NetMail attribute.

With that, we need to discuss changes made to the server file system when NetMail is installed.

NetMail Directories in the File System

During installation, NetMail is configured to use the directories shown in Table 10.1 in your server's file system.

You should be aware that these directories represent the default directory structure for NetMail. Many of them can be customized by reconfiguring the NMAP Agent, as shown in Figure 10.20.

Figure 10.20. Editing the default directories.

Before we go any further, we need to discuss the utility used to manage your NetMail server: WebAdmin.

Using WebAdmin

You've probably noticed that the screens displayed in the figures presented in this chapter don't look much like iManager screens. NetMail has its own unique administration utility called WebAdmin. Like iManager, WebAdmin is a web-based tool that is accessed from your Linux server. The main WebAdmin interface is shown in Figure 10.21.

Figure 10.21. The WebAdmin interface.

Notice that at the bottom of the list in the left frame is your Internet Services container. Expanding this list displays the various components of your NetMail system.

Note

You can actually use WebAdmin to perform basic eDirectory administration tasks. By expanding your organization object, you can access the objects in your tree. You won't be able to do nearly as much as you can with iManager, but it can be useful in a pinch.

You can access WebAdmin in two ways. If you're already in iManager, you can select the Launch NetMail Management task located under the NetMail Management role. This is shown in Figure 10.22.

Figure 10.22. Launching WebAdmin from within iManager.

You can also access WebAdmin directly by opening a web browser and navigating to http://your_server_IP_address:8018 or https://your_server_IP_address:8020. When you do, the WebAdmin authentication page is displayed, as shown in Figure 10.23.

Figure 10.23. Authenticating to WebAdmin.

To authenticate, enter the distinguished name and password for your admin user object; then click Login. When you do, the screen shown earlier in Figure 10.21 is displayed.

With that, we're done discussing the various components of NetMail. Now we need to discuss how NetMail works.


NetMail Message Processing

Test Objective Covered:

3. Describe how NetMail works.

Before we get into the installation and configuration of NetMail, the CLE objectives specify that you be able to describe the way NetMail processes messages. Let's look at a general overview of the process that occurs when the NetMail server receives a message. This process applies to both incoming and outgoing messages.

When NetMail receives a message, two files are created in the Message Queue: a control file and a data file. The control file contains sender and recipient addresses, priority flags, and message-processing information. The control file is named C nnnnnnn. in where nnnnnnn is a hashed version of the date and time when the file was received.

The data file contains the message itself. The file is named D nnnnnnn. in where nnnnnnn is a hashed version of the date and time when the file was received. After the message has been completely received and saved in the Message Queue, the data file is renamed with an .msg extension. The control file passes through nine stages. In each stage, specific operations are performed on it.

Tip

Be aware that Novell refers to each of these stages as a queue. This terminology is somewhat misleading. It makes it sound like there are nine different directories that the control file passes through. This is not the case. Instead of queue, this book will refer to these as stages to clarify exactly what is happening to the control file.

After a given operation has been performed, the extension of the control file is changed, indicating that the file is ready for the next stage. Be aware that, although the extension changes, the hashed part of the control filename remains the same. The following processes occur:

  • Stage 0— The extension of the control file is changed from .in to .000. In this stage, the NMAP Agent verifies that the control file is valid. Then it directs the AntiVirus Agent (if configured) to scan the data file associated with the control file. If the message has attachments, they are delivered to the third-party virus scanning engine you configured the AntiVirus Agent to use. If found clean, the message progresses to Stage 1.

  • Stage 1— The control file is given an extension of .001. In this stage, the NMAP Agent directs the AntiSpam Agent to check the control file and ensure the message meets the antispam rules you have configured. If it does, the NMAP Agent directs the List Agent to check the control file to see if the message is intended for the NetMail List server. If so, the List Agent creates a new message from the original message for each recipient in the list. Each of these new messages is returned to Stage 0 and processed individually. The List Agent then deletes the original message.

  • Stage 2— The control file is given an extension of .002. In this stage, the NMAP Agent directs the Alias and the AutoReply Agents to process the control file. If the Alias Agent matches a recipient to a user object's alias, the Alias Agent replaces the alias with the correct email address. The AutoReply Agent checks the recipient's autoreply and forwarding rules and then takes action accordingly.

  • Stage 3— The control file is given an extension of .003. In this stage, the NMAP Agent checks for any rules defined in the recipient's user object (shown in Figure 10.24) and applies them.

    Figure 10.24. User message rules.

  • Stage 4— The control file is given an extension of .004. This stage is not currently used by a NetMail agent.

  • Stage 5— The control file is given an extension of .005. In this stage, the control file is processed by the Calendar Agent to see if the message is an appointment or a response to an appointment (such as an Accept or Decline message). If so, the Calendar Agent processes the message using the parameters it has been configured to use and updates the recipient's MAIN.cal file.

  • Stage 6— The control file is given an extension of .006. In this stage, the NMAP Agent processes the control file to see if the message is intended for internal NetMail users. If so, the message is delivered to the intended recipients.

  • Stage 7— The control file is given an extension of .007. This stage is only applied to outgoing messages. If this stage is reached, the NMAP Agent processes the control file and delivers the message to the SMTP Agent. The SMTP Agent then sends the file to the destination email server.

  • Stage 8— The control file is given an extension of .008. This stage is hit only when a message is returned as undeliverable. The bounced message is kept in this stage until the system is idle. Then the control and data files are reprocessed, starting at Stage 0, in an attempt to redeliver the message.

In each of these stages, if a NetMail agent modifies the original message, its extension is changed back to .000 and it is returned to Stage 0 for reprocessing.

With this process in mind, let's now spend some time covering how to install and configure NetMail.


Designing, Installing, and Configuring NetMail

Test Objectives Covered:

4. Install NetMail.

5. Configure and use NetMail.

The modular nature of NetMail provides you with a great deal of flexibility in how it is deployed. The first topic we need to cover here is how to plan your NetMail deployment.

Planning Your NetMail Deployment

The way you deploy NetMail is heavily dependent on the load you anticipate it to handle. If your NetMail system will be servicing tens of thousands of users, you may want to consider a distributed system.

According to Novell, a single Linux server running NetMail can handle up to 30,000 users and 1.1 million messages a day. This probably works great in the lab, but in a production environment, you should probably scale that number back to around 10,000 users.

Both of these numbers assume that you aren't running much else on the server, such as iFolder or iPrint. If you're running multiple services on the single server along with NetMail, you should reduce the maximum number of supported users even further.

Even at that, it should be noted that a single NetMail server supports a tremendous number of users when compared to other competing enterprise email solutions. This serves as a strong testament to the scalability of both the Linux operating system and Novell's NetMail service. Let's look at how a single-server system is implemented.

Single-Server Deployment

In a single-server deployment, all the NetMail components are installed on the same server, as shown in Figure 10.25.

Figure 10.25. Standalone NetMail deployment.

The advantages of this strategy are ease of implementation and ease of administration. All your components and agents are on the same server. For a small-to-medium organization, this is a viable deployment option. To deploy your NetMail server in this fashion, you need to ensure that the Distributed Processing attribute of the Messaging Server object is disabled, as shown in Figure 10.26.

Figure 10.26. Configuring a standalone NetMail server.

However, if you've worked with servers for any length of time, you can probably see a couple glaring downsides to this type of deployment. Key among them is fault tolerance. If something were to happen to your Linux server, such as a failed hard drive, an overheated CPU, or even an extended power outage, your organization's mail service will go down. Nothing will make you more unpopular with the users you support than for them not to be able to access their email accounts.

This type of deployment also has limited scalability. If your organization grows and your server is required to support more user mailboxes, its performance is going to slip accordingly.

If your NetMail implementation is intended to support a large organization, you should consider a distributed deployment.

Distributed Deployment

In a distributed deployment, you install different NetMail components on several different Linux servers in your eDirectory tree. Although they are distributed, all the components function together as a unified NetMail service. This type of deployment is shown in Figure 10.27.

Figure 10.27. Distributed NetMail deployment.

To deploy your NetMail servers in this mode, you need to ensure that the Distributed Processing attribute of the Messaging Server object is enabled. You also need to make sure that each server that will host a NetMail component has been installed into your eDirectory tree.

When you install NetMail, each server will have an associated Messaging Server object within the Internet Services container in your eDirectory tree. Because all the servers exist in the same tree, they can interact with each other to share NetMail components.

The benefits of this strategy are clear. By distributing components among several servers, you dramatically increase the scalability and speed of NetMail. You can also use this configuration to increase the level of fault tolerance of the system if you place NetMail components redundantly on different servers.

The main drawback to this strategy is the increased level of complexity. It requires considerably more hardware and expertise to deploy. For the CLE exam, you only need to know how to deploy a single-server system. With your deployment plan in place, the next thing we need to talk about is actually installing the NetMail service.

Installing NetMail

Before you install your NetMail servers, you need to keep a few points in mind:

  • Make sure you have adequately planned for user mailbox storage requirements. NetMail itself only requires about 20MB of disk space. However, user messages and especially attachments can consume your server's hard disk space in a voracious manner.

  • Make sure the server you are going to install NetMail on has a Read/Write replica of the eDirectory partition(s) where the users it will service reside.

  • Make sure your DNS server is up and that it has been configured to resolve for the domain your NetMail server will service. This DNS server must be up and reachable during the NetMail installation. If it isn't, the service won't operate properly without a lot of manual reconfiguration.

  • By default, the NNLS installation script will automatically stop send-mail or postfix on your Linux server and reconfigure its runlevels so it doesn't automatically start. Make sure you don't load either of these services after NetMail has been installed. If you do, you'll experience a port conflict and none of your email services will work.

  • Speaking of ports, watch out for port conflicts! The NetMail service uses many IP ports. The default ports (which you should use unless you have a compelling reason not to) are shown in Table 10.2.

    Table 10.2. NetMail Ports

    PORT

    AGENT

    25

    SMTP Agent

    110

    POP Agent

    143

    IMAP Agent

    689 (UDP)

    Connection Manager

    689 (TCP)

    NMAP Agent

    993

    IMAP Agent (SSL)

    995

    POP Agent (SSL)

    8018

    WebAdmin (insecure)

    8020

    WebAdmin (secure)

    52080

    Modular Web Agent (insecure)

    52389

    Address Book Agent

    52443

    Modular Web Agent (secure)

  • You should exclude mail messages from your system's log. If you don't, your system log could eventually consume all your hard disk space. To do this, open the /etc/syslog.conf file in a text editor. Scroll down to the mail.* line and insert a comment character (#) at the beginning of the line. Save the changes and exit your text editor. Stop and then restart your syslog service (the init script to do this is located in /etc/init.d).

After accounting for these items, you're ready to install NetMail. If you performed an Express NNLS installation, NetMail was installed on your system. If you performed a Custom install, you had the opportunity to select the NetMail component for installation.

If you didn't select NetMail during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select NetMail.

  6. Finish the installation according to the instructions presented in Chapter 5.

With NetMail installed, you're ready to configure your system.

Configuring NetMail

The default installation of NetMail is extremely simple and affords you a working email system with little-to-no administrative intervention. However, because of its modular nature, NetMail can be a complex product to configure. As I pointed out earlier, each component has its own set of properties that you can configure. There are potentially thousands of different ways you could configure your NetMail system. Rather than bore you with a review of each component's configuration parameters, a better approach to learning how to configure NetMail is to work with your system in a hands-on lab exercise.


Lab Exercise 10.1: Implementing NetMail

In this lab, you're going to configure NetMail on your server. Then you will send email messages back and forth between two users in your eDirectory tree.

Warning

In order to complete this lab exercise, you must ensure that the DNS server (provided by the named daemon) you configured in Chapter 5 is running on your server and configured to service the CLE.com zone. If you haven't configured it, go back to Chapter 5 and complete those steps before starting this exercise.

Also, if you decide to use a separate workstation to test your NetMail system, you will need to configure its TCP/IP stack to use your Linux server as its DNS server.

Complete the following steps:

  1. Verify that your DNS server is resolving properly by completing the following:

    1. On your Linux server, open a terminal session.

    2. Log in as a user in your eDirectory tree (such as CGrayson) with a password of novell.

    3. Change to your root user account by entering su - with a password of novell.

    4. At the shell prompt, enter nslookup.

    5. At the prompt, enter cle1.cle.com.

    6. Your named service should resolve this name to your server's IP address.

      Tip

      If it doesn't resolve correctly, verify that the service is running by entering chkconfig –-list named. The service should be configured to start at run-levels 3, 4, and 5. Also check your /etc/named.conf file and make sure an entry exists for the cle.com zone that points to the /var/named/named.hosts file. Check your /var/named/named.hosts file and make sure a record exists for your CLE1 server.

    7. Enter exit.

  2. Using the chkconfig command, make sure postfix and sendmail are set to off at runlevels 3, 4, and 5.

  3. Configure the contexts in your eDirectory tree serviced by the NetMail server by completing the following:

    1. Open a browser window and navigate to http://your_server_IP_address:8018.

    2. In the User Name field, enter admin.if.cle.

    3. In the password field, enter novell.

    4. Expand your Internet Services container.

    5. Expand your CLE1 Messaging Server object.

    6. Select your NMAP Agent object.

    7. Select the Context tab. When you do, the screen in Figure 10.28 is displayed.

      Figure 10.28. Setting the user context for the NMAP Agent.

    8. The Managed Contexts field should be automatically populated with the context where the CLE1 server object resides in the tree (in this case, IF.CLE).

    9. Click the Browse icon.

    10. Browse to and select the SLC.CLE container.

    11. Click Save.

    12. In the Contexts tab, click Save.

  4. Limit the size of outgoing messages to 2MB by completing the following:

    1. In the left frame, select your SMTP Agent object.

    2. Scroll down to the Message Size Limit drop-down list.

    3. In the Message Size Limit drop-down list, select 2.

    4. Click Save.

  5. Select your POP Agent and verify that its Agent Status is set to Enabled.

  6. Select your IMAP Agent and verify that its Agent Status is set to Enabled.

  7. Configure your AntiSpam Agent to block messages coming from the SpamIsUs.com domain by completing the following:

    1. In the left frame, select your AntiSpam Agent object.

    2. Configure the AntiSpam Agent to return spam messages back to the sender by marking Yes under Send Back.

    3. Configure the AntiSpam Agent to send a copy of the spam message back to the sender's postmaster by marking Yes under CC Postmaster.

    4. In the Blocked Sites field, enter SpamIsUs.com.

    5. Click Save.

  8. Configure your NetMail server's Modular Web Agent by completing the following:

    1. In the left frame, select your Modular Web Agent object.

    2. In the Default Language drop-down list, select your language.

    3. In the Default Time Zone drop-down list, select your time zone.

    4. Scroll down to the Default Template field. Verify that it is set to use the WebAccess template.

    5. Click Save.

    6. Expand your Modular Web Agent object.

    7. Select the IMS Mail Module.

    8. In the Message Size Limit drop-down list, select 2.

    9. In the Personal section under Address Book, select Enabled.

    10. Under System-Wide, select Enabled.

    11. In the field under System-Wide, enter your server IP address.

    12. Under Default LDAP Server, select Enabled.

    13. In the field under Default LDAP server, enter your server IP address.

    14. Click Save.

  9. Test your NetMail system by completing the following:

    1. Open a new browser window and navigate to http://your_server_IP_address:52080.

    2. When prompted, authenticate as CGrayson with a password of novell. The NetMail web user interface is displayed using the WebAccess template, as shown in Figure 10.29.

      Figure 10.29. The NetMail WebAccess template.

    3. Select Add Folder.

    4. In the Folder Name field, enter MyStuff.

    5. Mark Mailbox and then click OK.

    6. Switch back to your terminal session.

    7. At the shell prompt, enter cd/var/opt/novell/netmail/users/CGrayson.

    8. Enter ls.

    9. You should see the MyStuff.box and MyStuff.idx files in CGrayson's directory, as shown in Figure 10.30.

      Figure 10.30. User mailbox folder files.

    10. Switch back to your browser window.

    11. In the far left side of the screen, click the Compose Message icon. The Mail Message screen appears, as shown in Figure 10.31.

      Figure 10.31. Creating a new mail message.

    12. In the To field, enter DNelson@CLE.com.

    13. In the Subject field, enter Test Message.

    14. In the Message field, enter Test Message.

    15. Click Send.

    16. In the WebAccess screen, click the Exit icon.

    17. Select Login.

    18. In the User Name field, enter DNelson.

    19. In the Password field, enter novell.

    20. The Test Message email from CGrayson should be displayed, as shown in Figure 10.32.

      Figure 10.32. New message in DNelson's inbox.

    21. Select the Test Message email message.

    22. Click the Close icon.

  10. Test the functionality of your Address Book Agent and your Modular Web Agent by completing the following:

    1. Click the Compose Message icon.

    2. Click the Address Book button.

    3. In the Search For field, enter Jackson.

    4. Select Search.

    5. Under System-Wide, mark the Jim Jackson user.

    6. Select To:.

    7. Click Compose.

    8. In the Subject field, enter New Message.

    9. In the Message field, enter New Message.

    10. Click Send.

    11. Log out and log back in as JJackson with a password of novell.

    12. You should see the New Message email message displayed in Jim Jackson's inbox.

  11. Click the Exit icon.

You now have a functional NetMail system that is fully integrated with your eDirectory tree. No more will you need to maintain separate user accounts for your email system. If you add a user to a context supported by your NMAP Agent, he or she automatically has an email account. In all but the smallest of organizations, this can amount to a huge time (and cost) savings.

Let's review what you learned in this chapter.


Summary

In this chapter, you learned about the features and benefits of NetMail. You learned that NetMail is fully integrated with eDirectory, is easy to deploy, is modular, and is highly scalable. You also learned that NetMail's modularity is created using modular agents, including the following:

  • Address Book Agent

  • Alias Agent

  • AntiSpam Agent

  • AntiVirus Agent

  • AutoReply Agent

  • Calendar Agent

  • Connection Manager Agent

  • IMAP Agent

  • List Server Agent

  • Modular Web Agent

  • NMAP Agent

  • POP Agent

  • Proxy Agent

  • SMTP Agent

You also learned that installing NetMail extends the schema of your eDirectory tree, adding several new object classes as well as new attributes to your organization, organizational unit, server, and user objects.

You then learned about the directories in your Linux server's file system that are used for the Message Store and the Message Queue. You also learned that the NetMail system is configured using the WebAdmin utility, which is separate from the iManager utility you've used to configure other NNLS products.

You learned that NetMail creates two files when it receives an email message: a control file and a data file. You then learned about the nine stages that these files progress through as they are processed in the NetMail system.

You then learned about the two ways NetMail can be deployed: as a single-server implementation or as a distributed system. Single-server deployments are appropriate for small-to-medium organizations. Large organizations are best served by a distributed deployment. We then spent some time configuring your NetMail server.

In the next chapter, we will tie all the various NNLS components together in a unified interface using Virtual Office.


Chapter 11. Tying It All Together with Virtual Office

This chapter covers the following testing objectives for Novell Course 3015: Novell Nterprise Linux Services:

  1. Describe Virtual Office.

  2. Install Virtual Office.

  3. Configure Virtual Office.

Since Chapter 5, "NNLS Installation and Administration," you have been introduced to all the various components that compose Novell's NNLS product:

  • eDirectory

  • eGuide

  • Linux User Management (LUM)

  • Samba

  • DirXML

  • iFolder

  • NetStorage

  • iPrint

  • NetMail

In this chapter, you'll learn how to tie all these disparate components together into a unified web interface using the Virtual Office component of NNLS.


An Introduction to Virtual Office

Test Objective Covered:

1. Describe Virtual Office.

As you've progressed through this book and learned about the various components supplied with NNLS, you probably thought to yourself, "Wow! Cooool! No way!" A network administrator understands the value and benefit associated with NNLS.

The problem comes in when you deploy these services. Most end users don't have the same level of technical expertise you have. They tend to be very resistant to change in an organization's network.

Face it: They really aren't concerned with the network itself. Their focus is on their jobs. The network should make their jobs easier. Network changes require them to learn new skills and procedures, which, during the initial rollout, make their work harder. Hence, they don't share your enthusiasm for your new network services.

This could be especially true with NNLS, particularly if you're moving from a network based on Windows servers to one based on Linux. Many of the network tasks they have become familiar with in a Windows network won't apply any more. Even though the services included in NNLS can dramatically increase end-user productivity, initially they will probably just see these services as new "things" they have to learn, taking time away from the work they are under pressure to get done.

Authenticating to a Linux server using eDirectory is relatively easy, but it's different from logging in to a Windows server. Looking up user information in eGuide is easy, but it's different from what your users are used to. Using iFolder to manage files is quite easy and very powerful, but it's different from what they are used to.

Setting up a printer using iPrint is very easy, but, again, it's very different from what the end users are used to. Using NetMail for communicating over email is also very easy, but, once again, it can be very different for the users if you have them use the web interface instead of their traditional email clients.

Just think of the dramatic reduction in virus threats you could experience by having end users employ the Modular Web Agent web interface instead of the various virus-prone email clients commonly deployed today.

With this end-user fear factor in mind, Novell included the Virtual Office product in NNLS. Virtual Office unifies all the various NNLS components into a single web-based interface. To the network administrator, Virtual Office probably is nice, but not all that exciting. That's because you already know how to use NNLS components.

To the end user, however, Virtual Office is a lifesaver. Instead of having to learn how to use eGuide, iFolder, NetStorage, iPrint, and NetMail separately, Virtual Office presents all these services in an easy-to use interface. From the end user's perspective, he or she only has to learn one new tool, not four or five.

In addition to NNLS component integration, Virtual Office also provides several additional features and benefits that further increase end-user productivity. These include the following:

  • Virtual teams— Using Virtual Office, end users can create virtual collaboration teams composed of eDirectory users. These teams have access to a team file share (provided by NetStorage), chat capabilities, and a team web page for sharing information.

  • Easier remote access— Using Virtual Office, end users can access team collaboration information as well as have access to NNLS services through a single web page. End users only have to remember a single URL to access this information instead of six or seven. For end users on the road or working in remote locations, this greatly enhances their productivity (and greatly reduces the support calls you have to service).

  • Personal user management— Using Virtual Office, users can manage many aspects of their own user account in the NNLS system without having to call the help desk. For example, they can change their password or edit their personal contact information. These changes are saved in their eDirectory user objects without them having to know anything about iManager. Pushing these relatively menial tasks onto the users can really free up a lot of your time as the network administrator.

With this introduction in mind, the next skill you need to understand for your CLE exam is how to install Virtual Office.


Installing Virtual Office

Test Objective Covered:

2. Install Virtual Office.

As with other NNLS components, Virtual Office is an optional product that can be installed during the NNLS installation process. If you installed NNLS using the Express installation option, Virtual Office was automatically installed on your server. If you selected the Custom installation option, you had the opportunity to select Virtual Office as an optional component to be included in the installation.

When installing NNLS, be aware that Virtual Office functions as a front end to the various components you install. If you don't install a particular component, such as iFolder, it won't be available to users using the Virtual Office interface.

When planning your deployment, be sure you either already have these NNLS components. Although it is possible to install NNLS components and integrate them into Virtual Office after the fact, this will require a great deal of manual reconfiguration of your Virtual Office service.

Virtual Office can integrate NNLS components on the same server where it is running or on a distributed NNLS implementation. If you have deployed NNLS in the latter configuration, Virtual Office really shines. End users don't have to remember one URL for iFolder, another URL for NetMail, and yet another for iPrint. They simply pull up Virtual Office using a single URL and then have access to all the other NNLS components you have deployed.

If you didn't select Virtual Office during the initial installation of NNLS, you can perform a post-installation by completing the following steps:

  1. Mount your NNLS ISO image.

  2. Run the install.sh script.

  3. When prompted, specify a Custom installation.

  4. When prompted to select the products to be installed, deselect all products.

  5. Select Virtual Office.

  6. Finish the installation according to the instructions presented in the lab exercise in Chapter 5.

During the installation process, the Virtual Office system files are copied to the /opt/novell/virtualoffice/bin directory in your Linux server's file system. The contents of this directory are shown in Figure 11.1.

Figure 11.1. Virtual Office files.

Once Virtual Office is installed, you can access it by opening a web browser and navigating to http://your_server_IP_address/vo. When you do, the screen in Figure 11.2 is displayed.

Figure 11.2. Authenticating to Virtual Office.

Virtual Office is fully integrated with eDirectory. To authenticate to Virtual Office, enter an eDirectory username in the Username field and the associated password in the Password field. When you do, the screen in Figure 11.3 is displayed.

Figure 11.3. The Virtual Office home page.

Before you deploy Virtual Office, you need to configure several settings. Let's discuss how this is done.


Configuring Virtual Office Parameters

Test Objective Covered:

3. Configure Virtual Office.

As you will see as we work through this part of the chapter, Virtual Office has many configuration parameters. Some are configured in iManager; others are configured from within the Virtual Office interface itself.

Before doing so, you need to understand how to load the Virtual Office modules into iManager. I have had several occasions where the iManager modules for Virtual Office aren't installed when I installed Virtual Office after the initial NNLS installation.

Tip

If you installed Virtual Office during the initial NNLS installation, you probably won't need to do this. I've never had any problems with the Virtual Office iManager modules in this situation.

For whatever reason, the modules just aren't registered. If you install Virtual Office at some point after the initial NNLS installation, you'll know this has happened to you because the Virtual Office administration tasks in iManager will be displayed, as shown in Figure 11.4, but will generate exception errors when you try to use them.

Figure 11.4. The Virtual Office iManager tasks.

If you experience this problem, complete the following steps to rectify it:

  1. Open a browser window and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Select the Configure icon. The screen in Figure 11.5 is displayed.

    Figure 11.5. The iManager Configuration page.

  4. Under iManager Configuration, select Modules. The screen in Figure 11.6 is displayed.

    Figure 11.6. The iManager Modules page.

  5. Scroll to the far right side of the page and click the Install button.

  6. When prompted, browse to and select the /var/opt/novell/iManager/nps/packages/VirtualOffice.npm module.

  7. Click Install.

  8. Repeat this process and install the /var/opt/novell/iManager/nps/packages/VirtualOfficeAdmin.npm module.

  9. When the module has been installed, close iManager.

  10. Open a terminal session.

  11. Change to your root user account using the su - command.

  12. At the shell prompt, enter /etc/init.d/novell-tomcat4 stop; then enter /etc/init.d/novell-tomcat4 start.

If you complete these steps, you should now be able to manage your Virtual Office implementation using iManager. To configure Virtual Office, you need to configure the following settings:

  • The Virtual Office Services Administration settings in iManager

  • The Virtual Office Environment Administration settings in iManager

Let's first look at how you configure the Virtual Office Services Administration settings.

Configuring Services Administration Settings

The Services Administration settings are the most important Virtual Office configuration parameters. These settings are responsible for integrating the various NNLS components, such as iPrint, iFolder, NetMail, and NetStorage, with Virtual Office. We're going to discuss how to configure the following Virtual Office parameters:

  • Company Info

  • NetStorage

  • iPrint

  • eGuide

  • Bookmarks

  • eMail

  • Public Webpage

  • Change Password

Let's first discuss how to configure the Company Info area of the Virtual Office home page.

Configuring Company Info

In the Virtual Office home page, a Company Info area is displayed on the right side of the page. This is shown in Figure 11.7.

Figure 11.7. The Company Info box.

The text shown in Figure 11.7 is the default text in the field. You will probably want to edit this text to reflect information about your organization. To do this, complete the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/nps/iManager.html.

  2. Authenticate as your admin user.

  3. Scroll down to the Virtual Office role and select the Services Administration task. The screen in Figure 11.8 is displayed.

    Figure 11.8. The Company Info configuration tab.

  4. In the Language drop-down list, select your language.

  5. In the Company Info field, enter your desired text to describe your organization. You can enter the information in plain text, or, if you have HTML experience, you can mark up the text using HTML tags.

  6. Click OK.

You can also integrate Virtual Office with the NetStorage service installed on your NNLS server. Let's look at how to do this next.

Integrating Virtual Office with NetStorage

As we discussed way back in Chapter 7, "Synchronizing User Identities with DirXML," Virtual Office is heavily dependent on NetStorage. Using this service on your NNLS server, Virtual Office can provide virtual teams with a team file share, as shown in Figure 11.9.

Figure 11.9. Team file share.

Virtual Office also provides each user with access to his or her NetStorage home page through the Virtual Office interface. This is done using an icon at the top of the Virtual Office screen (see Figure 11.10).

Figure 11.10. NetStorage icon in Virtual Office.

When you click this icon, Virtual Office opens the NetStorage home page for the currently logged-in user. This is shown in Figure 11.11.

Figure 11.11. Accessing NetStorage from within Virtual Office.

To configure your Virtual Office deployment to use a NetStorage service, you need to do the following:

  1. From within iManager, select the Services Administration task.

  2. Select the NetStorage tab. The screen in Figure 11.12 is displayed.

    Figure 11.12. Integrating Virtual Office and NetStorage.

  3. By default, the Enable check box should be marked. If not, turn NetStorage integration on by clicking Enable.

  4. By default, the Launch to this Server's NetStorage Home Page option should be marked. This configures Virtual Office to connect to the NetStorage service on the same server where Virtual Office is installed. If you want to connect to the NetStorage service on a different server, mark the Launch to a Remote Server's NetStorage Home Page button and enter the IP address or DNS name of the NetStorage server.

  5. Click OK.

With your NetStorage settings configured, you next need to integrate your Virtual Office deployment with iPrint.

Integrating Virtual Office with iPrint

As with NetStorage, Virtual Office provides users with easy access to the iPrint service on your NNLS server. This is done by providing the user an iPrint icon from within the user's Virtual Office page. This icon is shown in Figure 11.13.

Figure 11.13. iPrint icon in Virtual Office.

In order to provide this access, you must configure your Virtual Office service with the address of the iPrint server. To do this, you need to complete the following steps:

  1. From within iManager, select the Services Administration task.

  2. Select the iPrint tab. The screen in Figure 11.14 is displayed.

    Figure 11.14. Integrating iPrint within Virtual Office.

  3. By default, the Enable check box should be marked. If not, turn iPrint integration on by clicking Enable.

  4. By default, the Launch to this Server's iPrint Home Page option should be marked. This configures Virtual Office to connect to the iPrint service on the same server where Virtual Office is installed. If you want to connect to the iPrint service on a different server, mark the Launch to a Remote Server's iPrint Home Page button and enter the IP address or DNS name of the iPrint server.

  5. Click OK.

With your NetStorage and iPrint services integrated within Virtual Office, your next task is to integrate your NNLS server's eGuide service.

Integrating eGuide with Virtual Office

As with NetStorage and iPrint, Virtual Office also provides end users with simplified access to the eGuide service on your server. In the Virtual Office home page, each user has an eGuide icon, as shown in Figure 11.15.

Figure 11.15. eGuide icon in Virtual Office.

When the end user clicks this icon, Virtual Office launches the eGuide home page from the eGuide server it has been configured to use, as shown in Figure 11.16.

Figure 11.16. Launching eGuide from within Virtual Office.

Virtual Office can also be configured to provide a quick search feature on the end user's Virtual Office home page. This is shown in Figure 11.17.

Figure 11.17. The eGuide Quick Search field in Virtual Office.

To integrate eGuide with your Virtual Office deployment, you need to complete the following steps:

  1. From within iManager, select the Services Administration task.

  2. Select the eGuide tab. The screen in Figure 11.18 is displayed.

    Figure 11.18. Integrating eGuide within Virtual Office.

  3. By default, the Enable check box on the eGuide Link line should be marked. If not, turn eGuide integration on by selecting Enable.

  4. If you want the eGuide Quick Search field displayed on users' Virtual Office home page, mark Enable on the Home Page eGuide Quick Search line.

  5. By default, the Launch to this Server's eGuide Home Page option should be marked. This configures Virtual Office to connect to the eGuide service on the same server where Virtual Office is installed. If you want to connect to an eGuide service on a different server, mark the Launch to a Remote Server's eGuide Home Page button and enter the IP address or DNS name of the eGuide server.

  6. Click OK.

Let's now look at how you can configure Virtual Office's Bookmarks service.

Configuring Virtual Office Bookmarks

Virtual Office provides users with the ability to save important bookmarks. These are accessible in two places. First, Virtual Office provides an icon at the top of the users' home page where they can maintain a list of bookmarks. This icon is shown in Figure 11.19.

Figure 11.19. Bookmarks icon in the Virtual Office home page.

You can also configure Virtual Office to display users' bookmarks in a field on their home page. This is shown in Figure 11.20.

Figure 11.20. Bookmarks field in the Virtual Office home page.

To configure the Bookmarks service in your Virtual Office deployment, you need to do the following:

  1. From within iManager, select the Services Administration task.

  2. Select the Bookmarks tab. The screen in Figure 11.21 is displayed.

    Figure 11.21. Configuring the Virtual Office Bookmark service.

  3. By default, the Enable check box on the Bookmarks Link line should be marked. If not, display the Bookmarks icon in the Virtual Office interface by selecting Enable.

  4. If you want the Bookmarks field displayed on users' Virtual Office home page, mark Enable on the Home Page Bookmarks line.

  5. By default, a bookmark for the Novell website is defined. Any bookmarks defined in the Current Bookmarks field are displayed in all Virtual Office users' bookmark lists. You can configure additional bookmarks that will be displayed for all Virtual Office users by completing the following steps:

    1. Under Current Bookmarks, click Add. The screen in Figure 11.22 is displayed.

      Figure 11.22. Adding a bookmark.

    2. In the Name field, enter a name for the bookmark.

    3. In the URL field, enter the URL to the web page you want to bookmark.

    4. Click OK. The new bookmark appears in the Current Bookmarks field.

  6. Click OK.

With your Bookmarks service configured, the next thing you need to do is to integrate Virtual Office with the NetMail service on your NNLS server.

Integrating NetMail with Virtual Office

As with eGuide, NetStorage, and iPrint, you can also integrate your NetMail email service on your NNLS server with Virtual Office. At the top of the Virtual Office home page, you can configure a NetMail icon to be displayed. This icon is shown in Figure 11.23.

Figure 11.23. NetMail icon in the Virtual Office home page.

When the end user clicks this icon, Virtual Office launches a new window and displays the user's inbox using NetMail's Modular Web Agent, as shown in Figure 11.24.

Figure 11.24. Accessing NetMail from within Virtual Office.

In addition, Virtual Office can be configured to display the user's most recent email messages within his or her home page. This is referred to as the Reduced eMail View. The Reduced eMail View is displayed in Figure 11.25.

Figure 11.25. Reduced eMail View within Virtual Office.

To integrate NetMail within Virtual Office, you need to complete the following steps:

  1. From within iManager, select the Services Administration task.

  2. Select the eMail tab. The screen in Figure 11.26 is displayed.

    Figure 11.26. Integrating NetMail and Virtual Office.

  3. By default, the Enable check box on the eMail Link line is marked. If not, display the eMail icon in the Virtual Office interface by clicking Enable.

  4. In the Email Server drop-down list, select NetMail.

    Tip

    Virtual Office can also be integrated with a GroupWise, Lotus Notes, or Microsoft Exchange email server. It can also be integrated with any other email server that supports the IMAP or POP3 protocol. The steps for doing this are almost identical to the steps required to integrate NetMail.

  5. Click Edit. The screen in Figure 11.27 is displayed.

    Figure 11.27. Configuring the NetMail URL.

  6. In the NetMail URL field, the default URL of https://%*serverdnsnoport%: 52443 is displayed. The text %*serverdnsnoport% is a variable that is replaced with the address of the same server where Virtual Office is running. If your NetMail service is running on a different server, enter its IP address or DNS name in the URL in this field, including the port number used by your NetMail server.

  7. If the NetMail service is configured to use the same eDirectory tree as your Virtual Office server (which generally is the case), then mark Synchronized with the Virtual Office Tree. When a user selects the eMail link in Virtual Office, he or she will be automatically authenticated to NetMail using the user name and password supplied to authenticate to Virtual Office.

  8. If the NetMail Service is configured to use a different eDirectory tree than your Virtual Office server, then mark Different than the Virtual Office Tree. This will require users to provide a user name and password to authenticate to NetMail when they select the eMail link in the Virtual Office home page.

  9. Click OK.

  10. If you want the Reduced eMail field displayed on users' Virtual Office home page, complete the following:

Note

The Reduced eMail View gadget doesn't use NetMail's Modular Web Agent the way the eMail link (configured previously) does. Instead, it uses either the POP3 or IMAP protocol to access your NetMail server. To use this, then you need to make sure you have configured a POP or IMAP Agent for your NetMail server.

  1. Mark Enable on the Home Page Reduced eMail View line.

  2. Click Edit. The screen in Figure 11.28 is displayed.

    Figure 11.28. Configuring the Reduced eMail View.

  3. Under Mail Server Type, select the protocol that will be used to access your NetMail server. Your choice will depend on the NetMail agents you've deployed.

  4. In the Incoming Mail Server DNS Name field, the default address of %*serverdnsnoport% is displayed. As mentioned earlier, the text %*serverdnsnoport% is a variable that is replaced with the address of the same server where Virtual Office is running. If your NetMail service is running on a different server, enter its IP address or DNS name in this field.

  5. In the SMTP Server DNS Name field, the default address of %*serverdnsnoport% is displayed. If NetMail is running on the same server as Virtual Office, leave this parameter as it is. If your NetMail service is running on a different server, enter its IP address or DNS name in this field.

  6. If the NetMail service is configured to use the same eDirectory tree as your Virtual Office server, mark Synchronized with the Virtual Office Tree. If the NetMail service is configured to use a different eDirectory tree than your Virtual Office server, mark Different than the Virtual Office Tree.

  7. Click OK.

  8. Implement the changes by clicking OK.

With your NetMail server integrated, you next need to configure the Virtual Office Public Web Page link.

Configuring the Public Web Page Link

Virtual Office provides users with the ability to publish a web page in the Virtual Office interface. This allows users to convey such things as personal contact information, team membership information, bookmarks, or collaboration files. To provide this functionality, Virtual Office provides the Edit My Web Page icon at the top of the interface, as shown in Figure 11.29.

Figure 11.29. The Edit My Web Page icon in Virtual Office.

When the user clicks this icon, the user's public web page is displayed. A sample page is shown in Figure 11.30.

Figure 11.30. Virtual Office user web page.

To enable this functionality in Virtual Office, you need to do the following:

  1. From within iManager, select the Services Administration task.

  2. Select the Public Web Page tab. The screen in Figure 11.31 is displayed.

    Figure 11.31. Enabling the Virtual Office public web page.

  3. If you want the Public Web Page link to be displayed for users in Virtual Office, mark Enable.

  4. Click OK.

Users can now select the View and Edit My Webpage icon in the Virtual Office interface to edit their web pages. This is done by clicking the Edit button located on the right side of the screen, as shown in Figure 11.32.

Figure 11.32. Editing a user's public web page.

When the Edit button has been clicked, the interface shown in Figure 11.33 is displayed.

Figure 11.33. Public web page configuration parameters.

If the user wants a particular parameter displayed, such as User Information, he or she can simply mark it and then click OK. The user can also upload files to be shared through the web pages. This is done by clicking the Edit button on the Published Files line. The screen in Figure 11.34 is then displayed.

Figure 11.34. Uploading published files.

The user then clicks Upload and browses to and selects the files he or she wants uploaded. Then the user clicks Upload. The files will then be available for other Virtual Office users to download.

When you have configured your Public Web Page settings, the last Service Administration task you need to take care of is configuring the Change Password service.

Configuring the Change Password Service

Using Virtual Office, you can provide your users with the ability to manage the password for their user object in the eDirectory tree. This is provided in the Virtual Office interface using the Change My Password icon, shown in Figure 11.35.

Figure 11.35. The Change My Password icon.

To enable this service in your Virtual Office deployment, you need to do the following:

  1. From within iManager, select the Services Administration task.

  2. Select the Change Password tab. The screen in Figure 11.36 is displayed.

    Figure 11.36. Enabling the Change Password service.

  3. If you want the Change Password link to be displayed for users in Virtual Office, mark Enable.

  4. Click OK.

When you enable this service, users can select the Change My Password icon in the Virtual Office home page. When they do, the screen in Figure 11.37 is displayed.

Figure 11.37. Changing user passwords.

To change his or her password, the user must first supply his or her current eDirectory password in the Current password field. If the correct password is supplied, the user can then enter a new password in the New password fields. As well, the user can have his or her Samba password changed to match his or her new eDirectory password by marking Synchronize Samba Password. To save the change, the user should then click OK.

At this point, your Virtual Office Services Administration tasks are complete. Now you need to use iManager to configure the Virtual Office environment.

Configuring the Virtual Office Environment

The Services Administration tasks you just learned about are primarily focused on integrating the various NNLS components and configuring the user interface. The Virtual Office Environment Administration tasks covered here are used to configure the behavior of the Virtual Office service itself.

The Environment Administration task is located beneath the Virtual Office role in iManager. Using this task, you can configure virtual team parameters as well as set logging levels. Let's look at each of these functions.

Warning

You'll notice as we go through this section that a third function is available in the Environment Administration screen: configuring portal information. We're not going to cover these parameters here. The Virtual Office software engineers at Novell have indicated that the average user shouldn't touch these settings unless a Novell Support Engineer has directed him or her to do so.

Setting Team Configuration Parameters

Before talking about how to configure team parameters, we need to discuss exactly what a team is. Virtual Office allows users to create virtual teams. These teams allow employees in an organization to collaborate through email, real-time chat, file sharing, and calendaring.

An end user can create a virtual team from within his or her Virtual Office home page. When this happens, the user who created the team becomes the owner of the team and the first team member. The team owner can then invite other users to join the team as members. The invitees will be sent notification and given the opportunity to accept or decline the invitation to join.

You can control, to an extent, the way teams are handled by Virtual Office by configuring team parameters in iManager. To do this, you need to complete the following steps:

  1. Open iManager and scroll down to the Virtual Office role.

  2. Select the Environment Administration task. The screen in Figure 11.38 is displayed.

    Figure 11.38. Configuring team parameters.

  3. If you want to allow end users to create teams, set Enable Team Creation setting to On. (This parameter is turned on by default.)

  4. The team file share is used to store uploaded files. Configure the team file share by doing the following:

    1. On the Team File Share line, click Edit. The screen in Figure 11.39 is displayed.

      Figure 11.39. Configuring the team file store.

    2. In the Team file share field, enter the URL to the team file share. Recall from the NetStorage chapter that this URL must point to a Samba share. The URL format is cifs://server_IP_address/share_name. For example, we created a Samba share named IFEmployees earlier in this book. If your server's IP address were 192.168.1.36, you would enter cifs://192.168.1.36/IFEmployees in this field.

      Tip

      Of course, you can also use DNS names instead of IP addresses.

    3. In the Username field, enter a LUM username that has read and write permissions to the directory the Samba share points to.

    4. In the Password fields, enter the LUM user's password.

    5. Click OK.

  5. Virtual Office can be configured to send notification messages to the network administrator. To do this, you must configure Virtual Office with the address of your NetMail server. Completing the following:

    1. Click the Edit button the SMTP Address line. The screen is shown in Figure 11.40.

      Figure 11.40. Configuring the email server.

    2. In the SMTP address field, enter the IP address of your NetMail server.

    3. In the Username field, enter the username of a NetMail user to whom you want Virtual Office email notifications sent to (this is probably yourself).

    4. In the Password fields, enter the user's password.

    5. Click OK.

  6. By default, the Virtual Office chat applet runs on IP port 2122. If you want to change this to a different port, enter the desired port number in the Chat server IP port field.

  7. Virtual Office also allows you to specify which users can and which users can't create virtual teams. By default, anyone in your eDirectory tree can create a team. If you want to restrict this access, do the following:

    1. On the Manage Team Access line, click the Edit button. The screen in Figure 11.41 is displayed.

      Figure 11.41. Configuring team owner access.

    2. In the Search for drop-down list, select Users or Containers.

      Tip

      Virtual Office allows you to restrict team ownership for individual users or for entire containers.

    3. Click Search.

    4. Select the user or container you want to manage access for, then click Select. The screen in Figure 11.42 is displayed.

      Figure 11.42. Configuring team owner access flags.

    5. To deny a user or a container the ability to create a virtual team, change the value of the Allow users to create teams setting to Off.

    6. Click Save.

  8. Save your changes to the Virtual Office team configuration by clicking Save and then clicking OK.

Now let's talk about how you can configure Virtual Office logging levels.

Configuring Virtual Office Logging

From time to time, you may need to enable logging to troubleshoot Virtual Office problems. Virtual Office provides you the ability to log Virtual Office events to a file in your Linux server's file system. To do this, complete the following steps:

  1. In iManager, select the Environment Administration task under the Virtual Office role. The screen in Figure 11.43 is displayed.

    Figure 11.43. Configuring Virtual Office logging.

  2. To enable logging, mark the Logging check box.

  3. Configure your logging level by selecting High, Medium, or Low.

  4. In the Logging modules field, enter the names of the Virtual Office modules you want to log. If you leave the field blank, all Virtual Office modules will be logged.

  5. Click OK.

With your Virtual Office service configured, your users can now create virtual teams. Let's talk about how this is done.


Configuring Virtual Teams

Test Objective Covered:

3. Configure Virtual Office.

Knowing that end users would be the ones creating virtual teams, Novell made the process very easy. I have to say that the Virtual Office web interface is one of the most intuitive user interfaces I've ever used. No matter what it is you want to do, the path for accomplishing it is easy to discern and follow. To create a virtual team, perform the following steps:

  1. Open a web browser and navigate to https://your_server_IP_address/vo.

  2. In the Login screen, authenticate as a user in your eDirectory tree. The screen in Figure 11.44 is displayed.

    Figure 11.44. The home page for JJackson.

  3. In the left frame, select Create Virtual Team. The screen in Figure 11.45 is displayed.

    Figure 11.45. Creating a new virtual team.

  4. In the Name field, enter a name for the virtual team.

  5. In the Description field, enter a description for the team.

  6. Click Create.

  7. When prompted that the team has been created, click OK. Notice that the team appears under the My Virtual Teams heading on the left side of the page.

  8. To manage the new team, select the team you just created under My Virtual Teams. The screen in Figure 11.46 is displayed.

    Figure 11.46. Managing a new virtual team.

    Warning

    If the workstation you are running your browser from doesn't have the Sun Java Virtual Machine plug-in installed, you'll be prompted to download it. The chat applet in the team home page is a Java applet and requires this plug-in to be displayed in a browser window. Follow the prompts presented to download and install the plug-in.

  9. To invite other users to join the team, complete the following:

    1. Select Invite a user. The screen in Figure 11.47 is displayed.

      Figure 11.47. Inviting users to a virtual team.

    2. Click Add. The screen in Figure 11.48 is displayed.

      Figure 11.48. Searching for users to invite to a virtual team.

    3. Enter a first name and/or a last name in the respective fields for the user you want to invite and then click Search.

      Tip

      If you want to see all users in your tree, leave both fields blank.

    4. In the Users Found field, select the user you want to invite.

    5. Mark Send an Invitation by Email; then click Add. The screen in Figure 11.49 is displayed.

      Figure 11.49. Inviting a user to join a virtual team.

    6. Click Send.

By completing these steps, your users can create virtual teams and populate them with team members. Within the virtual team home page, you can also perform management tasks such as these:

  • Display a list of team members.

  • Request membership for a team.

  • Approve or deny membership requests.

  • Add or remove team owners.

    Tip

    Virtual teams can have more than one owner. Each team owner has exactly the same management rights to the team. That means a team owner added by the team creator can delete the team creator as an owner. The point is, add team owners with caution.

  • Block specific users from joining a team.

  • Edit the properties of an existing team.

  • Delete an existing team.

Whenever a team member performs a task within a team, such as posting a note in the discussion area, uploading a file, or scheduling a calendar event, Virtual Office can send notifications to all the other members of the team. Each team member can configure his or her own personal notification preferences. This is done by completing the following steps:

  1. After having authenticated to Virtual Office, select the team you want to configure notification preferences for in the My Virtual Teams list.

  2. Under Team Membership, select Set Notify Preferences. When you do, the screen in Figure 11.50 is displayed.

    Figure 11.50. Configuring notification preferences.

    In Figure 11.50, notice that there are two sets of configurable preferences. Because the current user is also the team owner, he can customize his own personal preferences as well as global preferences for the entire team.

    If the current user were not the team owner, only the personal notification preferences would be displayed. Personal notification preferences configured by a user override the global preferences configured by the team owner.

  3. Configure your personal notifications by marking the events you would like to be notified of.

  4. (Team owner only.) Configure global notification preferences for the team by marking the events you want team members to receive notifications for by default.

  5. Click Save.

Before we start the lab exercise for this chapter, we need to do one more thing. We need to quickly review the various parts of the Virtual Office user and team home pages. The user home page is displayed in Figure 11.51.

Figure 11.51. The Virtual Office user home page.

In the Virtual Office user home page, users can do the following:

  • Use eGuide to search for user information.

  • Use the Reduced Email View applet to read or compose email messages.

  • Use their saved bookmarks to navigate to favorite web pages.

  • View company information.

  • Select a team home page.

The team home page, shown in Figure 11.52, contains information and functionality not available in the user home page.

Figure 11.52. The Virtual Office team home page.

In the team home page, you can do the following:

  • Post messages to the team using the discussion applet.

  • Upload and download files from the team file share.

  • Chat in real time with other team members using the chat applet.

  • View the team calendar, shown in Figure 11.53.

    Figure 11.53. The Virtual Office team calendar page.

Let's now spend some time working with the Virtual Office service installed on your Linux server.


Lab Exercise 11.1: Configuring Virtual Office

In this lab, you're going to configure Virtual Office on your server. Then you configure a virtual team and invite users to join it.

Warning

Because Virtual Office is dependent on all the other NNLS components, you must complete all exercises in this book up to this point before attempting this lab exercise. If you haven't completed the preceding exercises, go back and complete them before starting this exercise.

Complete the following steps:

  1. Configure the Virtual Office SMTP server parameters by following these steps:

    1. Open a browser window and navigate to https://your_server_IP_address/nps/iManager.html.

    2. Authenticate to iManager as admin with a password of novell.

    3. In the left frame, scroll down to the Virtual Office role.

    4. Select the Environment Administration task.

    5. Verify that Enable team creation is set to On.

    6. On the SMTP address line, click Edit.

    7. In the SMTP address field, enter your server's IP address. This will configure Virtual Office to send notification messages through your NetMail server.

    8. In the Username field, enter admin. This will configure notifications to be sent to your admin user's email account.

    9. In the Password fields, enter novell.

    10. Click OK.

    11. Click Save.

    12. Click OK.

  2. Configure your company info field by completing the following steps:

    1. In iManager, select the Services Administration task.

    2. Verify that Home Page Company Info is enabled.

    3. In the Company Info field, remove the existing text and replace it with the following text:

<center><H1>Welcome to Perpetual Motion, Inc.</H1></center>

<hr><br>

Perpetual Motion, Inc. is the world's leading provider of

perpetual motion engines.<p>

    4. Click OK.

  3. Add a global bookmark for Novell's support website by completing the following steps:

    1. In iManager, select Services Administration.

    2. Select the Bookmarks tab.

    3. Under Current Bookmarks, click Add.

    4. In the Name field, enter Novell Support.

    5. In the URL field, enter http://support.novell.com.

    6. Click OK.

    7. Click OK a second time.

    8. Click the Exit icon.

    Tip

    If you don't exit iManager, you will be automatically authenticated to Virtual Office as your admin user.

  4. Access Virtual Office as Jim Jackson and create a virtual team by completing the following:

    1. Open a second browser window and navigate to https://your_server_IP_address/vo.

    2. Authenticate to Virtual Office as JJackson with a password of novell.

    3. Under Virtual Team Tasks, select Create Virtual Team.

    4. In the Name field, enter Perpetual Motion Core Team.

    5. In the Description field, enter Virtual collaboration team for the Perpetual Motion core team.

    6. Click Create.

    7. When prompted that the team has been created and that JJackson is the team owner, click OK.

    8. Under My Virtual Teams, select Perpetual Motion Core Team. The Perpetual Motion Core Team home page is displayed.

    Warning

    If you don't have a compatible Java Virtual Machine plug-in installed in your browser, you will be prompted to download it. If this is the case, follow the prompts to download the Sun Java Virtual Machine. If you're using Mozilla, be sure you download the Mozilla version of the plug-in.

  5. Invite Christopher Grayson and Diana Nelson to join the virtual team by completing the following steps:

    1. Under Team Membership, select Invite a User.

    2. Click Add.

    3. Click Search.

    4. Hold down the Ctrl key and select the CGrayson and DNelson users.

    5. Click Add.

    6. Click Send.

    7. Select Show Team Members. Notice that Christopher Grayson and Diana Nelson don't appear in the list. They need to accept the invitation.

  6. Accept the invitation to participate on the team by completing the following steps:

    1. In Virtual Office, select Logout.

    2. Log in as CGrayson with a password of novell.

    3. In the left frame, select Manage Virtual Team.

    4. In the Virtual Teams Inbox, select Perpetual Motion Core Team [Invitation].

    5. Click Join.

    6. Under My Virtual Teams, select Perpetual Motion Core Team.

  7. Configure CGrayson's notification preferences by completing the following:

    1. Under Team Membership, select Set Notify Preferences.

    2. Under Notification Preferences, select all events.

    3. Click Save.

    4. When prompted that the preferences have been saved, click OK.

    5. Click Logout.

  8. As JJackson, provision the virtual team with project information by completing the following steps:

    1. Log back in as JJackson with a password of novell.

    2. Select the Perpetual Motion Core Team.

    3. Under Files, select Upload.

    4. In the Upload Files field, browse to and select a file (of your choosing).

    5. Click Upload.

    6. When prompted that the file has been uploaded, click Close. The file appears in the Files area.

    7. Select Show Team Calendar.

    8. Under Events, select New.

    9. In the Subject field, enter Core Team Meeting.

    10. Set the date to tomorrow's date.

    11. Set the time to 8:00 a.m.

    12. Mark Include Time.

    13. In the Location field, enter Conference Room B.

    14. In the Message field, enter Someone bring bagels!

    15. Click Save.

    16. When prompted that the event was created, click Close.

    17. Select Perpetual Motion Core Team.

    18. In the Discussion field, select New Message.

    19. In the Subject field, enter Marketing Question.

    20. In the Message field, enter How are we going to market our new perpetual motion engine?

    21. Click Post.

    22. Click Logout.

  9. Log in as CGrayson and view the information provided by JJackson by completing the following steps:

    1. Authenticate to Virtual Office as CGrayson with a password of novell.

    2. Select the Perpetual Motion Core Team.

    3. Note the new topic in the Discussion area and the file uploaded by JJackson.

    4. Check the team calendar by selecting Show Team Calendar.

    5. Under Events, select the Core Team Meeting event.

    6. Read the message and then click Close.

That's it for this exercise! You have a functioning Virtual Office system. By implementing this product, you can dramatically increase your users' productivity while decreasing the amount of time you'll need to spend retraining them on a new system.

Let's review what you learned in this chapter.


Summary

In this chapter, you learned that Virtual Office ties together all the various NNLS components into a single web interface. This can dramatically reduce user fear about migrating to a new system.

Virtual Office can also increase user productivity by allowing them to create virtual collaboration teams. Users in a virtual team can chat in real time, upload files, discuss topics, and schedule calendar items.

You also learned that Virtual Office can increase user productivity by providing remote users with easy-to-use web access to your NNLS system. This aspect can be a great boon to mobile users as well as telecommuters.

You then learned how to install Virtual Office. You also learned about the directory structure used by Virtual Office in the Linux server's file system.

You then learned how to configure Virtual Office services' parameters and environment settings. Finally, you learned how to create virtual teams and invite users to participate.

We're almost done with this book. Before we end it, however, we need to spend some time in the next chapter prepping you for the scenarios you will face in your CLE exam.


Chapter 12. CLE Practice Scenario

You did it! You made it all the way through the Novell Nterprise Linux Services (NNLS) components. You now know how to implement eDirectory, eGuide, Linux User Management (LUM), iFolder, Samba, NetStorage, DirXML, iPrint, NetMail, and Virtual Office. The trick now is to remember everything you've learned. There are so many NNLS components that it is very easy to forget many important details.

This is one of the reasons the CLE certification exam is so difficult. Put simply, it's hard to remember so much "stuff." The goal of this chapter is to increase your odds of passing the exam. I'll do this by presenting you with a sample NNLS implementation scenario that you will use to redeploy your NNLS system.

Before we do that, let's review the CLE objectives.


CLE Exam Objectives

Before scheduling your exam, it's critical that you understand the objectives you will be held accountable for when you take it. The CLE exam objectives include the following:

  • Describe the characteristics of Linux.

  • Use the Linux command-line interface.

  • Manage the Linux file system.

  • Manage Linux applications.

  • Manage Linux network interfaces.

  • Describe NNLS.

  • Perform an NNLS installation.

  • Manage NNLS with Red Carpet.

  • Describe the purpose of eDirectory.

  • Describe how eDirectory works.

  • Perform eDirectory administration tasks.

  • Manage user objects with iManager.

  • View user information with eGuide.

  • Access a Linux server with LUM.

  • Describe the purpose of DirXML.

  • Describe how DirXML works.

  • Install the DirXML Starter Pack on Linux.

  • Implement the Delimited Text driver for DirXML.

  • Implement the eDirectory driver for DirXML.

  • Describe the purpose and architecture of iFolder

  • Install and configure iFolder.

  • Describe the purpose and architecture of Samba.

  • Install and configure Samba.

  • Describe the role and function of NetStorage.

  • Install and configure NetStorage.

  • Identify the benefits of iPrint.

  • Describe how iPrint works.

  • Install and configure iPrint.

  • Print with iPrint.

  • Identify NetMail features.

  • Describe NetMail components.

  • Describe how NetMail works.

  • Install NetMail.

  • Configure and use NetMail.

  • Describe Virtual Office.

  • Install Virtual Office.

  • Configure Virtual Office.

Remember from Chapter 1, "Introduction to the CLE Practical Exam," that the CLE Practicum is scenario based. Instead of a list of questions that test your knowledge, you will be presented with a deployment scenario in the form of a Business Requirements Document (BRD). The BRD is simply a list of requirements and expectations you must fulfill. You'll notice that the BRD is based on these objectives. However, most Practicum scenarios don't necessarily include all the CLE objectives. You may find that several are omitted.

If you've ever worked as a consultant, you know that working from a BRD is "real life." Consultants generally sit down with their clients when they start a project and come up with some form of BRD (many companies call it a "Statement of Work"). The BRD is usually included in the contract between the consultant and the client.

The BRD serves as protection for both the consultant and the client. It ensures that the work the client wants done is clearly specified. The consultant knows exactly what it is the client expects. If the consultant fails to complete any item specified in the BRD, he or she has breached the contract and may not get paid.

The BRD also serves as protection for the consultant. Once the BRD is established and a bid issued, the client can't make radical changes to the BRD or add items to it. If you've ever hired a contractor to build a house, you know how this works. If you try to make changes to the building specs after construction starts ("Honey, can't we move the bathroom to the other side of the room?"), they will charge you a horrendous change-order fee (or just tell you "no way!"). That's because you're changing the requirements of the contract.

When you sit down to take your CLE practical exam, you will take the role of a consultant who has been hired to deploy an NNLS system. You will be given a scenario in the form of a BRD that you must deploy on a virtual network.

As discussed in Chapter 1, the CLE Practicum is delivered on a series of virtual servers. You need to be absolutely sure you have met each and every requirement specified in the scenario. Remember that the CLE Practicum is a pass/fail exam. If you fail to fulfill a single requirement in the scenario, you will fail the entire exam. I strongly suggest that you review the test-taking strategies presented in Chapter 1 and commit them to memory. Doing so will help you to be in the minority that actually pass the CLE exam!

In addition to memorizing these strategies, you should also practice extensively before going in to take your exam. As alluded to earlier in this chapter, it's relatively easy to deploy individual NNLS products one at a time as we have done in this book. It's much harder to deploy them all at once in a unified system without the help of a book or documentation (and under a time constraint).

Tip

If you get stuck while taking your CLE exam, remember that most screens in iManager, WebAdmin, and Virtual Office have help screens that can help you with specific steps for completing a particular task. Many CLE candidates forget that these are available.

To help you practice, this chapter will present you with a BRD for a hypothetical company. If you really want to pass your CLE exam, you should work through this scenario and try to do it "closed book." Your goal should be to replicate the exam environment as closely as possible.

With this goal in mind, the manner in which this chapter is structured is very different from the preceding chapters. Earlier in this book, you were presented with conceptual information followed by a lab exercise in each chapter. The exercises were written such that each and every scroll and click action was specified for you.

This is a sound model for presenting new information. It's analogous to learning to ride a bicycle by installing training wheels. Just as training wheels help keep the new learner upright, the detailed exercise steps keep you from making mistakes and ensure that you will be able to complete the activity successfully.

However, at some point, you have to take the training wheels off of the bicycle in order to really learn how to ride. With the training wheels off, the learner initially experiences a number of falls and crashes. However, the new rider soon learns how to balance without them and subsequently masters the art of riding a two-wheeled bicycle.

In this chapter, I'm going to "take the training wheels off." You will not be presented with any new information, nor will you be provided with specific steps (welcome to the "real world") for completing the scenario presented. Instead, you will be required to recall information and skills presented previously in the book.

Just as with the bicycle, you will probably run into problems and difficulties, but if you stick with it, you will soon master the NNLS product. It's a painful experience, but it's the only way you can truly progress to the point where you can pass the CLE practical exam. Only when you can complete this scenario without having to check the book or read the NNLS documentation are you sufficiently prepared for the real exam.

If you find yourself lacking while trying to complete this scenario, you should work through it again several times until you can do it without any help. Only then should you schedule your exam. Otherwise, I can pretty much guarantee that your Practicum experience will be a costly waste of time.

As you review the scenario in this chapter, you will notice that it is significantly different from the scenario we used in the lab exercises in this book. To approximate the Practicum experience (and to reduce the complexity of the scenario), I strongly suggest that you start with a fresh server. Yes, this means you should start from scratch. Begin by reinstalling your SLES 8 server using the skills you learned in the early chapters in this book. Then start working on your NNLS deployment.

Tip

In the Practicum, your SLES 8 servers will already be installed for you. I want you to reinstall the operating system for this scenario to ensure that you're working from a clean system.

Let's review the scenario you should complete.


Business Requirements Document for InfoTec, Inc.

In this scenario, you are a consultant employed by ServersRUs, Inc., a network-consulting firm that specializes in the deployment of Novell products. InfoTec, Inc. has hired ServersRUs to implement NNLS companywide. Being an experienced consultant, you're going to model this deployment in a lab environment on a single Linux server before attempting it on the production network.

About InfoTec, Inc.

InfoTec, Inc. specializes in the production of infomercials for late-night and weekend television spots. It provides a complete suite of solutions for its clients, including the following:

  • Market analysis

  • Customer focus groups

  • Pre-production planning

  • Script development

  • Video production

  • Post-production

  • Broadcast and cable spot placement

  • Order fulfillment

InfoTec, Inc. owns a single suite of offices in Lexington Park, Maryland. To service its clients, InfoTec employs a very large mobile sales force. Sales representatives work onsite with clients to help them through the initial stages of the product cycle. Video production is done in a studio owned by InfoTec or at a rented studio near the client.

Post-production occurs in InfoTec's extensive editing bay in its office suite. All spot placement and order fulfillment functions also take place in InfoTec's office suite.

InfoTec employs 800 individuals. InfoTec's top-level organizational chart is shown in Figure 12.1.

Figure 12.1. InfoTec, Inc. organizational chart.

The requirements of the project are listed in Table 12.1

Table 12.1. InfoTec, Inc. NNLS Deployment Business Requirements

SPECIFICATION

DETAILS

SLES 8 Server Name

InfoTec-1

Static IP Address

Use an appropriate IP address, subnet mask, and default router address for your network.

DNS Server Address

Your server's IP address.

Server Software

The InfoTec-1 server should have the following applications deployed prior to deploying NNSL:

  • OpenSLP— InfoTec-1 should be configured as a DA servicing the InfoTecScope scope.

  • named— InfoTec-1 should be configured to be a DNS server resolving for the InfoTec.com zone. An A record and an NS record should be created for InfoTec-1.

  • Mozilla 1.5 or later.

  • NTP— An NTP package should be installed on InfoTec-1 and configured to synchronize time with a public NTP server on the Internet.

eDirectory Tree Name

InfoTec-Tree

Top-level Container in the Tree

O=InfoTec

Admin Name and Context

.CN=admin.O=InfoTec

Server Context

.OU=IS.O=InfoTec

eDirectory Structure

Organize your eDirectory tree according to function. Create an organizational unit for each of the following functional groups in the company:

  • Information Systems

  • Sales

  • Marketing

  • Management

  • Pre-Production

  • Video Production

  • Post-Production

  • Order Fulfillment

Be sure to use short, easy-to-remember organizational unit names or abbreviations for these groups.

Be sure to run an eDirectory health-check after the tree is initially installed.

eDirectory User Accounts

Input the user accounts shown in Table 12.2. Reporting relationships should be configured for each user object according to the chart in Figure 12.1.

Red Carpet Updates

Red Carpet should be deployed to download NNLS updates.

eGuide

eGuide should be deployed and configured to display the following user information:

  • Company

  • Manager

  • Direct Reports

  • Employee Number

  • Fax Number

  • Telephone Number

eGuide should also be configured to search on the telephone number and department attributes in addition to the default searchable attributes.

Linux User Management

The following LUM tasks should be completed:

  • LUM should be enabled on the system.

  • Each organizational unit should have a LUM-enabled group object in the tree.

  • Each user in a given container should be a member of the respective LUM group.

  • Each user in the tree should be LUM enabled.

  • Each user in the tree should have a home directory created using LUM in the /home directory of your server.

  • Each LUM user object should be configured to use the bash shell.

DirXML

InfoTec, Inc. uses a legacy employee management application and has no plans to migrate to a new package at this time. This application can be configured to export and import employee data to and from comma-separated text files.

You need to configure DirXML to import and export data to and from a CSV file. eDirectory should be configured as the authoritative data source.

All employee data in the external application will need to be rebuilt from eDirectory data, so be sure to export all users from the tree after the driver has been initially started.

iFolder

Configure iFolder according to the following parameters:

  • Every user should be iFolder enabled and have an iFolder account.

  • Each user account should have a quota of 300MB of storage space.

  • Encryption should be enabled for all users. Users must not be able to turn this feature off.

  • Users must not be able to save passwords and pass phrases in the client.

  • The network administrator should be able to recover a forgotten pass phrase.

  • iFolder must automatically sync data. Users must not be able to turn this feature off, except for GVanAlfen, who will need to be able turn this feature off and on as needed.

  • Each user workstation must have the iFolder client installed.

  • iFolder must be configured to save a log in the /var/opt/novell/ifolder/DocumentRoot/logs directory.

Samba

Configure Samba according to the following specifications:

  • Each user should be Samba enabled.

  • The Samba server should be configured to participate in the InfoTecWorkgroup workgroup.

  • Each user's home directory should have a Samba share. Only the given user should have access to his or her share.

  • Each functional organization should have a directory in /var.

  • Each of these directories should have a Samba share configured for them.

  • Only users in a given container should have access to the associated share.

NetStorage

Configure NetStorage according to the following parameters:

  • Each Samba share for each functional organization should have a Storage Location object created for it.

  • A Storage Location List should be created for each Storage Location object that allows only users in the associated container to access it.

iPrint

Configure iPrint according to the following parameters:

  • Every user workstation should have the iPrint client installed.

  • A location-based printing map should be created for the Lexington Park, Maryland office suite, with each network printer displayed on it.

  • Drivers for Windows 2000 and Windows XP should be uploaded for each printer.

NetMail

Configure NetMail according to the following specifications:

  • All users in the tree must have an email account.

  • NetMail must support IMAP and POP3 email! clients as well as provide a web-based email interface.

  • Users must be able to search the eDirectory tree for user email addresses, regardless of whether they are using a workstation email client or NetMail's web-based email interface.

  • Messages from spam.com must not be allowed into the system.

  • NetMail must be configured to use English as the default language.

  • NetMail must be configured to use the Eastern time zone.

  • All users will use the WebAccess template, except for Mike Huffman, who wants to use the WebMail template.

  • Messages larger than 5MB must not be allowed.

  • Because Mike Huffman is frequently away from his desk, he needs an autoresponse configured that directs senders to contact his administrative assistant.

Virtual Office

Configure Virtual Office using the following specifications:

  • The company info field on the users' home page needs to reflect the services provided by InfoTec, Inc.

  • Virtual Office must be configured to use the NetStorage, iPrint, eGuide, and NetMail services on the same NNLS server.

  • Virtual Office must be configured to use the NetMail server for email notifications.

  • Only members of management are to be allowed to create virtual teams.

  • Each functional unit in the company needs a virtual team created, named after the given organization. For example, Information Systems needs a virtual team named Information Systems Team. Because the users are new to NNLS, you need to create the initial teams.

  • The head of each organization needs to be made the owner of his or her team.

  • All users in a given organization are to be members of their respective teams.

  • Each team needs to have an appointment scheduled for all team members to train them on Virtual Office.

The users you need to create in the InfoTec, Inc. company tree are shown in Table 12.2.

Table 12.2. InfoTec, Inc. Employees

EMPLOYEE

ATTRIBUTE

VALUE

MHuffman

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Mike

Huffman

CEO

Lexington Park, MD

Management

555-555-5551

555-555-5552

mhuffman@InfoTec.com

MIreland

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Mary

Ireland

Administrative Assistant

Lexington Park, MD

Management

555-555-5553

555-555-5552

mireland@InfoTec.com

BJohnson

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Brian

Johnson

Vice-President

Lexington Park, MD

Management

555-555-5554

555-555-5552

bjohnson@InfoTec.com

LMCCarter

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Lyn

McCarter

Vice-President

Lexington Park, MD

Management

555-555-5555

555-555-5552

lmccarter@InfoTec.com

JThatcher

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

John

Thatcher

Director of Marketing

Lexington Park, MD

Marketing

555-555-5556

555-555-5552

jthatcher@InfoTec.com

MSteele

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Mark

Steele

Marketing Specialist

Lexington Park, MD

Marketing

555-555-5557

555-555-5552

msteele@InfoTec.com

AArdnt

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Amy

Ardnt

Director of Pre-Production

Lexington Park, MD

Pre-Production

555-555-5558

555-555-5552

aardnt@InfoTec.com

SRodgers

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Sean

Rodgers

Pre-Production Specialist

Lexington Park, MD

Pre-Production

555-555-5559

555-555-5552

srodgers@InfoTec.com

CJenkins

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Craig

Jenkins

Director of Video Production

Lexington Park, MD

Video Production

555-555-5510

555-555-5552

cjenkins@InfoTec.com

AGresko

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Aaron

Gresko

Video Production Specialist

Lexington Park, MD

Video Production

555-555-5511

555-555-5552

agresko@InfoTec.com

JCarr

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Jason

Carr

Director of Post-Production

Lexington Park, MD

Post-Production

555-555-5512

555-555-5552

jcarr@InfoTec.com

JLeckie

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Jason

Leckie

Editor

Lexington Park, MD

Post-Production

555-555-5513

555-555-5552

jleckie@InfoTec.com

STolman

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Sid

Tolman

Director of Sales

Lexington Park, MD

Sales

555-555-5514

555-555-5552

stolman@InfoTec.com

THendricks

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Ty

Hendricks

Sales Representative

Lexington Park, MD

Sales

555-555-5515

555-555-5552

thendricks@InfoTec.com

KRitter

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Kellie

Ritter

Director of Order Fulfillment

Lexington Park, MD

Order Fulfillment

555-555-5516

555-555-5552

kritter@InfoTec.com

LGardner

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Leslie

Gardner

Shipping Clerk

Lexington Park, MD

Order Fulfillment

555-555-5517

555-555-5552

lgardner@InfoTec.com

GVanAlfen

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Greg

VanAlfen

Director of Information Systems

Lexington Park, MD

Information Systems

555-555-5518

555-555-5552

gvanalfen@InfoTec.com

MJensen

First Name

Last Name

Title

Location

Department

Telephone

Fax

Email Address

Michael

Jensen

Network Administrator

Lexington Park, MD

Information Systems

555-555-5519

555-555-5552

mjensen@InfoTec.com

As stated earlier, you need to be able to implement this system without needing to refer to this book to do it. If you need to refer to the book to complete the process, you're not ready for your CLE exam. If you can complete the deployment without any reference material or assistance, good for you! You're about as prepared as you can be for the exam.

Be aware, however, that being able to compete this scenario is no guarantee that you will pass the CLE exam. The actual scenarios are carefully guarded secrets at Novell. There's always a chance the scenario writers will throw in a quirky twist that none of us can foresee. Therefore, once you've mastered this scenario, you may want to come up with a scenario of your own and practice deploying it.

Also be aware that the scenario designers at Novell assume that you have an LPI Level 1 skill set. They may ask you to configure server parameters from the shell prompt. Be sure you're up on your Linux skills!

In case you haven't noticed, the key to passing your CLE exam is extensive practice. It's much like a football game. If you show up for the big game having only read about the sport, it's very unlikely you will win. However, if you've practiced yourself to the brink of exhaustion well before the game, your chances are much better.

Succeeding in the CLE Practicum works the same way. Conceptual knowledge alone won't cut it. You must know the system intimately, and the only way you can do that is to practice, practice, practice.

Let's review what you learned in this chapter.


Summary

In this chapter, we first reviewed the CLE exam objectives to remind you of the knowledge and skills you need to have prior to taking your test.

Then you learned that the CLE Practicum will provide you with a Business Requirements Document (BRD) whose requirements you must satisfy in order to pass the exam. Missing a single requirement will result in failure.

We then discussed the fact that the best way to prepare for the CLE Practicum is to practice deploying NNLS extensively. To assist in this process, you were presented with a practice NNLS deployment scenario for a hypothetical company: InfoTec, Inc.

If you are able to complete the InfoTec scenario without using any reference materials, you are in good shape to take your CLE exam. If not, more practice is necessary.

That's it for this book. Thank you for giving me the opportunity to share what I have learned with you. I hope you found this book to be useful, easy to read, and intuitive. I wish you the best of luck on your CLE exam and in your subsequent NNLS pursuits!


index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]


index_SYMBOL

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

/bin directory
/boot partition
/dev directory
/etc directory
/home directory
/media directory
/mnt directory
/root directory
/tmp directory
/usr directory
/var directory
\#211rip and replace\#211 deployment


index_A

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

accessing
iFolder files
in NetStorage
iMonitor
accounts
groups
file system security 2nd 3rd 4th
gshadow file 2nd
information storage 2nd
new users, assigning 2nd
permissions, assigning 2nd
root users
security warnings
users
creating
deleting
file system security 2nd 3rd 4th 5th
information storage 2nd 3rd
passwd file 2nd 3rd 4th 5th
synchrnization of (Linux User Management) 2nd
Add Object event
rules (DirXML)
add self property rights
eDirectory objects
Address Book Agent (NetMail)
Administration Utility (eGuide)
administrators
DirXML
training requirements 2nd
NNLS
integrated implementation
standalone implementation
agents (NetMail)
Address Book
Alias
AntiSpam
AntiVirus
AutoReply
Calendar 2nd
Connection Manager 2nd
IMAP 2nd
List Server
Modular Web 2nd
NMAP 2nd
objects
representation in eDirectory tree
POP 2nd
Proxy
SMTP 2nd
agents (SLP)
Directory Agent (DA)
Service Agent (SA)
User Agent (UA)
Alias Agent (NetMail)
Alias objects
eDirectory tree leaf objects 2nd
AntiSpam Agent (NetMail)
AntiVirus Agent (NetMail)
applications
Open Source
developmental cost advantages
versus services
attributes
group objects
Linux User Management
organizational unit objects (NetMail) 2nd
server objects (NetMail)
user objects
eGuide 2nd 3rd
Linux User Management 2nd
user objects (NetMail) 2nd
users
configuring in eGuide (lab exercise 6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
authentication
iFolder
LDAP port usage 2nd 3rd
pass phrases
Linux User Management (LUM) 2nd
contextless logins 2nd
redirection 2nd 3rd 4th 5th
Pluggable Authentication Modules (PAM)
user accounts
users
configuring in LUM (lab exercise 6-2) 2nd 3rd 4th 5th 6th 7th
WebAdmin utility (NetMail)
Authentication Domains
NetStorage configuration
authoritative data sources
filters
configuring (DirXML) 2nd
authrnticating
Virtual Office
AutoReply Agent (NetMail)


index_B

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

backups
files
handling (iFolder) 2nd
bash (Bourne Again Shell)
bookmarks
Virtual Office
configuring 2nd 3rd
bootloaders
Grand Unified Boot Loader (GRUB)
Linux Loader (LILO)
Bourne Again Shell (bash)
Bourne Shell (bsh)
BRD (Business Requirements Document)
exam scenario 2nd
InfoTec, Inc. 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
broadcasts
versus multicasts
browse rights
eDirectory
burning
ISO images
NNLS installations 2nd 3rd
Business Requirements Document (BRD)
exam scenario 2nd
InfoTec, Inc. 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th


index_C

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

C compiler (gcc)
C Shell (csh)
Calendar Agent (NetMail) 2nd
candidates
CLE
required prerequisites 2nd 3rd
cat command
cd command
CDs
mounting (mount command) 2nd 3rd
certification
additional educational aids 2nd
knowledge objectives 2nd
NNLS courseware element
objectives 2nd 3rd
practicum element
Certified Directory Engineer, [See CDE]
Certified Linux Engineer, [See CLE]
Certified Novell Administrator, [See CNA]
Certified Novell Engineer, [See CNE]
Change Password Service
Virtual Office
configuring 2nd
channels
NNLS
Red Carpet component 2nd
Channels tab (iManager)
rcd product updates
chkconfig command
services
default state configuration 2nd 3rd
chmod utility
permissions
numeric arguments 2nd 3rd 4th 5th
Choose Destination Location screen (iFolder) 2nd
chown command
file ownership information
GNOME file utility 2nd
CIFS protocol
(Common Internet File System)
CLE
(Certified Directory Engineer)
(Certified Linux Engineer)
candidates
prerequisites 2nd 3rd
certification
additional educational aids 2nd
knowledge objectives 2nd
NNLS courseware element
objectives 2nd 3rd
practicum element
CLE Practicum
components
Novell server
testing center computer
virtual server sessions
scenarios
handling strategies 2nd
implementation strategies
planning strategies
testing resolution of 2nd
tips/strategies 2nd 3rd
CLE Practicum exam
pass/fail 2nd
test-taking strategies 2nd 3rd 4th
Client (iPrint) 2nd
installing 2nd 3rd
clients
global policies
configuring (iFolder) 2nd 3rd 4th 5th
iFolder
configuring 2nd
installing 2nd 3rd 4th 5th 6th
remote access
supported platforms
CNE
(Certified Novell Administrator)
(Certified Novell Engineer)
collaboration services
NNLS components
Virtual Office
command-line interface
command entry 2nd 3rd
commands
echo
env
halt
ifconfig
info
init0
init6
man
netstat
reboot
route
startx
su
top
which
whoami
yast2
multiple terminal sessions
running
shells 2nd 3rd 4th
bash (Bourne Again Shell)
csh (C Shell)
sh (Bourne Shell)
tcsh (Tom\#213s C Shell)
zsh (Z Shell)
system utilities 2nd
cat
cd
cp
dir
find
gedit 2nd
grep
less
locate
ls
mkdir
more
mount 2nd 3rd 4th 5th 6th 7th
mv
pwd
rm
rmdir
tail
tar 2nd 3rd 4th
vi 2nd 3rd 4th 5th
using (lab exercise 2-2) 2nd 3rd
command-line utilities
eDirectory
ldapconfig
ndsbackup
ndslogin
ndsmerge
ndspconfig
ndsrepair
ndsstat
ndstrace
commands
env
Common Internet File System, [See COFS protocol]
Communications Networking Riser (CNR)
company information
Virtual Office
Services Administration settings 2nd
compare property rights
eDirectory objects
component data
retrieving for NNLS installations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
components
DirXML
data destination
data source
drivers
engine
interface
publisher channel
subscriber channel 2nd
Linux User Management
installing 2nd
NNLS
post-installation of 2nd
compressing
files
gzip command 2nd
tar command 2nd
configuring
DirXML
delimited text driver 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
delimited text driver (lab exercise 7-1) 2nd 3rd 4th 5th
eDirectory driver 2nd 3rd 4th 5th 6th
eDirectory driver (lab exercise 7-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
eGuide 2nd 3rd
iFolder
client 2nd
global client policies 2nd 3rd 4th 5th
server parameters 2nd 3rd 4th 5th 6th
user access 2nd 3rd 4th
iPrint
Driver Store component 2nd 3rd 4th 5th 6th 7th
Manager component 2nd
Printer Agents 2nd 3rd 4th 5th
Linux User Management (LUM) 2nd 3rd
NetMail 2nd 3rd 4th 5th 6th 7th 8th
NetStorage
Authentication Domains
Current Sessions
iFolder Storage Provider
Resource Usage
server parameters 2nd 3rd 4th
Statistics
Storage Location object 2nd 3rd 4th 5th 6th
Red Carpet component (NNLS) 2nd
product updates 2nd 3rd 4th 5th 6th 7th
RCD Group creation
RCD Group modification 2nd
RCD Group population
Samba 2nd
file directives 2nd 3rd 4th
Virtual Office 2nd 3rd 4th
Environment Administration settings 2nd 3rd 4th 5th 6th 7th 8th
lab exercise 11-1 2nd 3rd 4th 5th 6th 7th
Services Administration settings 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th
Conflict Bin
iFolder
file versions
Connection Manager Agent (NetMail) 2nd
container objects
eDirectory tree structure
Country objects
Organization objects
Organizational Unit objects
Context Configuration screen (iFolder)
contextless logins
Linux User Management (LUM) 2nd
contexts
eDirectory
object naming conventions 2nd
control files
message processing
NetMail
converting
eDirectory users
to Samba users 2nd 3rd
Country objects
eDirectory tree container
courseware (exam)
NNLS
test objectives 2nd
cp command
CPUs
NNLS
installation requirements
Create Driver Wizard (DirXML)
create rights
eDirectory
creation rules
DirXML
csh (C Shell)
Current Sessions
NetStorage configuration
custom installation
NNLS 2nd 3rd
response file
Custom installs
iFolder


index_D

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

DA mode (SLP) 2nd 3rd
daemons (SLP)
OpenSLP 2nd
configuring 2nd 3rd 4th 5th
parameters 2nd
slpuasa 2nd
configuring 2nd 3rd
parameters 2nd
stopping
data destination component (DirXML)
data files
message processing
NetMail
data source component (DirXML)
data synchronization
files
handling (iFolder) 2nd 3rd 4th 5th
databases
partitioning (eDirectory) 2nd 3rd
replicas (eDirectory)
Master
Read-Only
Read/Write
Subordinate Reference
default file structure
/bin directory
/dev directory
/etc directory
/home directory
/media directory
/mnt directory
/root directory
/tmp directory
/usr directory
/var directory
default partitions
/boot
swap
Delete Object event
rules (DirXML)
delete rights
eDirectory
delimited text driver
DirXML
configuring (lab exercise 7-1) 2nd 3rd 4th 5th
testing (lab exercise 7-2) 2nd 3rd
delimited text driver (DirXML)
activated status
configuration of 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
fields 2nd
function of 2nd
installation of 2nd 3rd 4th 5th 6th 7th 8th
security equivalences 2nd
stopped status
summary information screen
department option placement
eDirectory driver (DirXML)
dependencies
DirXML
iFolder version
iManager version
iPrint version
Linux User Management (LUM)
NetMail version
Samba version
Tomcat version
Virtual Office
deploying
NetMail
distributed servers 2nd
planning for 2nd 3rd 4th 5th 6th
single-server 2nd
designing
eDirectory tree structure 2nd 3rd
devices
mounting
dir command
direct mode (iMonitor) 2nd
directives
Samba
file configuration 2nd 3rd 4th
directories
/bin
/dev
/etc
/home
/media
/mnt
/root
/tmp
/usr
/var
full-service
eDirectory 2nd 3rd
iFolder
installation 2nd
iPrint installations 2nd
listing (PATH variable) 2nd 3rd
management of (lab exercise 2-3) 2nd 3rd 4th 5th
NetMail file system 2nd 3rd 4th 5th
Directory Agent (DA)
NNLS mode 2nd 3rd
SLP
DirXML
admninistrators
training requirements 2nd
complexity of implementation 2nd
components
data destination
data source 2nd 3rd 4th 5th
engine
interface
Create Driver Wizard 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
delimited text driver
activated status
configuration of 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
configuring (lab exercise 7-1) 2nd 3rd 4th 5th
fields 2nd
function of 2nd
installation of 2nd 3rd 4th 5th 6th 7th 8th
security equivalences 2nd 3rd
stopped status
summary information screen
testing (lab exercise 7-2) 2nd 3rd
eDirectory driver
activated status
configuration of 2nd 3rd 4th 5th 6th
configuring (lab exercise 7-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
department option placement
flat option placement
function of 2nd
installation of 2nd 3rd 4th 5th 6th
mirrored option placement
stopped status
summary information screen
events
monitoring
filters 2nd
authoritative data source configuration 2nd
installation
affected directories
Custom installs 2nd
Express installs 2nd
tree object additions 2nd
NNLS component
required data
NNLS identity management functions 2nd 3rd 4th 5th 6th 7th 8th
rules 2nd
event monitoring 2nd 3rd 4th 5th 6th 7th
Starter Pack
driver installations 2nd
transformation stylesheets 2nd
disk space
NNLS
installation requirements
distinguished names
eDirectory naming conventions 2nd
distributed server deployment
NetMail 2nd
distributions (Linux)
number of 2nd
DNS
addresses
modifying (YaST)
downloading
NNLS
NNLS 1.0 evaluation copy
SUSE Linux Enterprise Server 8
driver component (DirXML)
driver object (dirXML) 2nd
driver set object (dirXML) 2nd
Driver Store (iPrint) 2nd
configuring 2nd 3rd 4th 5th 6th 7th
drivers
DirXML Starter Packs
installing 2nd


index_E

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

echo command
eDirectory
command-line utilities
Ldapconfig
ndsbackup
ndsconfig
ndsdstat
ndslogin
ndsmerge
ndsrepair
ndstrace
databases
partitioning 2nd 3rd
replica 2nd 3rd 4th 5th
directories
full-service 2nd 3rd
former name of Novell Directory Services
health checks
executing via iMonitor 2nd 3rd 4th 5th 6th
LDAP binds 2nd
LDAP terminology differences 2nd
management of (lab exercise 5-5) 2nd 3rd 4th 5th 6th 7th 8th 9th
NNLS component
required data 2nd 3rd
NNLS identity management functions
objects
inheritance rights 2nd 3rd
Linux User Management (LUM)
naming conventions 2nd 3rd 4th 5th 6th 7th 8th
partitioning 2nd
primary functions of
replication 2nd
rights
browse
create
delete
property 2nd
rename
supervisor
server clocks
synchronization of 2nd 3rd 4th 5th 6th 7th
tree structure
container objects 2nd 3rd 4th
designs 2nd 3rd
installation errors
leaf objects 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
schemas
users
converting to Samba users 2nd 3rd
eDirectory driver
DirXML
configuring (lab exercise 7-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
eDirectory driver (DirXML)
activated status
configuration of 2nd 3rd 4th 5th 6th
department option placement
flat option placement
function of 2nd
installation of 2nd 3rd 4th 5th 6th
mirrored option placement
security equivalences
stopped status
summary information screen
effective rights
object inheritance 2nd
blocking
eGuide
Administration Utility
configuring 2nd 3rd
LDAP sources
adding
logging in 2nd 3rd 4th
NNLS component
required data 2nd
NNLS identity management functions
overview 2nd
search functionality
user objects
attributes 2nd 3rd
users
adding (lab exercise 6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
attribute configuration (lab exercise 6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Virtual Office
integrating with 2nd 3rd
email [See also NetMail]
evolution of
importance of
services
NetMail
Openexchange
postfix
email servers
virtual teams
setting
enabling
Samba users 2nd 3rd
Linux User Management (LUM) 2nd 3rd
end users
files
handling (iFolder) 2nd 3rd 4th 5th 6th
engine component (DirXML)
event monitoring functions 2nd
env command
shell usage determination
Environment Administration settings
Virtual Office 2nd
logging parameters 2nd
team settings 2nd 3rd 4th
eth0 interface 2nd 3rd
network parameters
eth1 interface 2nd 3rd
eth2 interface 2nd 3rd
events
DirXML
monitoring 2nd
rules
monitoring (DirXML) 2nd 3rd 4th 5th 6th 7th
exam
Business Requirements Document (BRD) 2nd
InfoTec, Inc. 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
CLE Practicum
pass/fail 2nd
test-taking strategies 2nd 3rd 4th
exercises
equipment requirements 2nd 3rd
software requirements 2nd
NNLS courseware
test objectives 2nd
practicum element
Novell server
scenarios 2nd 3rd 4th
testing center computer
testing scenario resolutions 2nd
tips/strategies 2nd 3rd
virtual server sessions
traditional approaches
versus practical testing 2nd 3rd
Execute permission 2nd 3rd 4th 5th 6th 7th 8th
exercises
Configuring Virtual Office (11-1) 2nd 3rd 4th 5th 6th 7th
Implementing iFolder (8-1) 2nd 3rd 4th 5th 6th 7th 8th 9th
Implementing iPrint (9-1) 2nd 3rd 4th 5th 6th 7th
Implementing Location-Based Printing (9-2) 2nd 3rd 4th 5th
Implementing LUM (6-2) 2nd 3rd 4th 5th 6th 7th
Implementing NetMail (10-1) 2nd 3rd 4th 5th 6th 7th
Implementing NTP (3-3) 2nd 3rd
Implementing Samba (8-2) 2nd 3rd 4th 5th 6th 7th
Importing an LDIF File (5-6) 2nd 3rd
Installing a New SUSE Linux Server (2-1) 2nd 3rd 4th 5th 6th
Installing and Configuring SLP (5-1) 2nd 3rd 4th 5th
Installing Linux Products and Managing Processes (3-2) 2nd 3rd 4th 5th
Installing NNLS (5-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Managing eDirectory (5-5) 2nd 3rd 4th 5th 6th 7th 8th 9th
Managing Linux Files and Directories (2-3) 2nd 3rd 4th 5th
Managing Linux Security (3-1) 2nd 3rd 4th 5th 6th
Preparing to Install NNLS (5-2) 2nd 3rd 4th 5th 6th 7th 8th 9th
Testing the DirXML Delimited Text Driver (7-2) 2nd 3rd
Updating NNLS with rcd (5-4) 2nd 3rd 4th 5th
Using the Linux Command Line (2-2) 2nd 3rd
Working with DirXML Delimited Text Driver (7-1) 2nd 3rd 4th 5th
Working with DirXML eDirectory Driver (7-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
Working with eGuide (6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Working with NetStorage (8-3) 2nd 3rd 4th 5th 6th 7th 8th
exercises (exam)
equipment requirements 2nd 3rd
software requirements 2nd
explicit rights assignments
express installation
NNLS 2nd
response file 2nd
Express installs
iFolder
EXT2 partitions 2nd
EXT3 partitions 2nd


index_F

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

fault tolerance
NetMail
single-server deployment issues
file management
NNLS components
iFolder 2nd
NetStorage 3.0
Samba 2nd
file shares
virtual teams
setting
file system
bootloaders
Grand Unified Boot Loader (GRUB)
Linux Loader (LILO)
case sensitivity
versus Windows system
default structure
/bin directory
/dev directory
/etc directory
/home directory
/media directory
/mnt directory
/root directory
/tmp directory
/usr directory
/var directory
devices
mounting
directories
/bin
/dev
/etc
/home
/media
/mnt
/root
/tmp
/usr
/var
creating
files
saving
journaling process
management of (lab exercise 2-3) 2nd 3rd 4th 5th
mount points 2nd 3rd
partitions
/boot (default)
EXT2 2nd
EXT3 2nd
ResierFS 2nd
swap (default)
remote access
Network File System (NFS) service
root directory 2nd
security
group accounts 2nd 3rd 4th
user accounts 2nd 3rd 4th 5th
user scenarios 2nd 3rd
similarity to Windows file system
subdirectories
file system direcgories
NetMail 2nd 3rd 4th 5th
File Systems Hierarchy (FSH)
files
end users
backups (iFolder) 2nd
data synchronization (iFolder) 2nd 3rd 4th 5th
handling (iFolder) 2nd 3rd 4th 5th 6th
version control (iFolder)
ownership
assigning (lab exercise 3-1) 2nd 3rd 4th 5th 6th
viewing 2nd
permissions
assigning 2nd 3rd 4th 5th 6th 7th 8th
Execute 2nd 3rd 4th 5th 6th 7th 8th
Read 2nd 3rd 4th 5th 6th 7th 8th
Write 2nd 3rd 4th 5th 6th 7th 8th
remote access
iFolder
storage
directory locations (NetStorage)
versions
Conflict Bin (iFolder)
filters
DirXML 2nd
authoritative data source configuration 2nd
find command
flat option placement
eDirectory driver (DirXML)
floppy disks
mounting (mount command) 2nd
full-service directories
eDirectory 2nd 3rd


index_G

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

gcc compiler
gedit text editor
text files
editing 2nd
General Information screen (iFolder)
generic user accounts
Get Pass Phrase screen (iFolder)
Global Client Policies screen (iFolder)
Automatic Sync
Conflict Bin Space
Encryption
Location
Recover Pass Phrase
Save Pass Phrase
Save Password
Sync from Server Interval
Sync to Server
Global Server Policies screen (iFolder)
GNBU project
C compiler (gcc)
GNOME file utility
file ownership
viewing 2nd
GNOME graphical interface (X Window)
GNU project
End User Licensing Agreement (EULA)
General Public License (GPL)
origins
Stallman, Richard
Grand Unified Boot Loader (GRUB)
grep command
group accounts
new users
assigning 2nd
permissions
assigning 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
assigning (lab exercise 3-1) 2nd 3rd 4th 5th 6th
security features 2nd 3rd 4th
Group object (LDAP)
Group objects
eDirectory tree leaf objects
groups
Linux User Management (LUM)
object attributes
groups accounts
gshadow file 2nd
GroupWise
versus NetMail
gshadow file
group accounts 2nd
gzip command
files
compressing for archival purposes 2nd


index_H

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

halt command
hardware
NNLS
installation requirements 2nd
hardware moderator
Linux function
health checks
eDirectory
executing via iMonitor 2nd 3rd 4th 5th 6th
home directory
user accounts
creating
home page (iMonitor)
hosts file
configuring for NNLS installations 2nd


index_I

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

identity management
NNLS components
DirXML 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
eDirectory
eGuide 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Limux User Management (LUM) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
ifconfig command
network interfaces
configuring 2nd 3rd
parameters 2nd
typical output
iFolder
applet component 2nd
authentication
LDAP port usage 2nd 3rd
pass phrases
Choose Destination Location screen 2nd
client component 2nd
remote access
supported platforms
configuration
client 2nd
global client policies 2nd 3rd 4th 5th
server parameters 2nd 3rd 4th 5th 6th
user access 2nd 3rd 4th
Context Configuration screen
desktop shortcut 2nd
end user files
backups 2nd
data synchronization 2nd 3rd 4th 5th
handling 2nd 3rd 4th 5th 6th
version control
file access in NetStorage
file versions
Conflict Bin
General Information screen
Get Pass Phrase screen
Global Client Policies screen
Automatic Sync
Conflict Bin Space
Encryption
Location
Recover Pass Phrase
Save Pass Phrase
Save Password
Sync from Server Interval
Sync to Server
Global Server Policies screen
home page
implementation (lab exercise 8-1) 2nd 3rd 4th 5th 6th 7th 8th 9th
installation
client 2nd 3rd 4th 5th 6th
Custom installs
directory population 2nd
Express installs
post-installation process
Login screen
Management Console
New Internet Folder Setup screen
NNLS component
required data 2nd
NNLS file management functions 2nd
object classes
Server
Settings
User LDAP
Open Source contributions
Pass Phrase Recovery screen
remote file access
server component 2nd
Setup Complete screen
Storage Folder
NetStorage configuration
system
monitoring 2nd 3rd
System Monitoring screen 2nd 3rd
System Reporting screen 2nd
User LDAPs screen
User Search screen
iManager
authentication page 2nd
Help Desk role
NNLS component
required data 2nd 3rd
NNLS web-based administration functions
rcd product updates
Channels tab
management of 2nd 3rd 4th 5th 6th 7th
Preferences tab 2nd
Software tab 2nd
Role-Based Services (RBS)
roles
tasks
Virtual Office modules
exception errors 2nd
loading 2nd 3rd
IMAP
(Internet Message Access Protocol)
IMAP Agent (NetMail) 2nd
iMonitor
accessing
agent listings
direct mode 2nd
eDirectory
health checks 2nd 3rd 4th 5th 6th
home page
NNLS web-based administration functions
proxy mode 2nd
info command
InfoTec, Inc.
Business Requirements Document (BRD)
employee list 2nd 3rd 4th 5th
exam scenario 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th
NNLS deployment requirements 2nd 3rd 4th 5th 6th
inheritance
blocking
effective rights 2nd
explicit rights assignments
Inherited Rights Filters (IRFs) 2nd
Inherited Rights Filters (IRFs) 2nd
init0 command
init6 command
insane time (NTP)
installations
iPrint
Client component 2nd 3rd
directories 2nd
NNLS 2nd
component data 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
components, post-installation of 2nd
custom type 2nd 3rd 4th
default ports 2nd
download components 2nd 3rd 4th
establishment of active connections
express type 2nd 3rd 4th
file locations 2nd
hardware requirements 2nd
hosts file configuration 2nd
ISO image, burning 2nd 3rd
multicast routing (SLP) 2nd
preparations (lab exercise 5-2) 2nd 3rd 4th 5th 6th 7th 8th 9th
process (lab exercise 5-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
product dependencies 2nd 3rd
SAP advertising services 2nd 3rd
SLP agents
SLP configuration 2nd
SLP DA mode 2nd 3rd
SLP daemons 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
SLP implementation 2nd 3rd
SLP SA-Only mode 2nd 3rd
SLP scopes 2nd
software requirements 2nd
system preparations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th 38th 39th 40th 41st 42nd 43rd 44th 45th 46th 47th 48th 49th 50th 51st 52nd 53rd 54th 55th 56th 57th 58th 59th 60th 61st
time synchronization 2nd 3rd
troubleshooting guidelines 2nd 3rd 4th
updates (lab exercise 5-4) 2nd 3rd 4th 5th
installing
DirXML
Custom installs 2nd
delimited text driver 2nd 3rd 4th 5th 6th 7th 8th
eDirectory driver 2nd 3rd 4th 5th 6th
Express installs 2nd
Starter Pack, drivers 2nd
tree object additions 2nd
iFolder
client 2nd 3rd 4th 5th 6th
Custom installs
directory population 2nd
Express installs
post-installation process
Linux User Management (LUM) components 2nd
Mozilla web browser (lab exercise 3-2) 2nd 3rd 4th 5th
NetMail
port conflicts
preparations 2nd 3rd 4th
NetStorage 2nd
packages
via rpm command 2nd 3rd
via tarball archive extraction 2nd
via YaST Control Center 2nd
Samba 2nd
SUSE Linux Server
lab exercise 2-1 2nd 3rd 4th 5th 6th
Virtual Office 2nd 3rd
interface component (DirXML)
interfaces
command-line
command entry 2nd 3rd
echo command
env command
halt command
ifconfig command
info command
init0 command
init6 command
man command
netstat command
reboot command
route command
shells 2nd 3rd 4th
startx command
su command
system utilities 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th
top command
which command
whoami command
yast2 command
networks
configuring (ifconfig command) 2nd 3rd
configuring (YaST) 2nd 3rd 4th 5th
default router gateway (YaST)
DNS server address modification (YaST)
eth0 2nd 3rd 4th
eth1 2nd 3rd
eth2 2nd 3rd
IP address modification (YaST) 2nd 3rd
lo
management of 2nd 3rd
PCI slots, number assignments 2nd
viewing information on (ifconfig command)
X Window System graphical interface
Internet
active connections
establishing for NNLS installations
Internet Message Access Protocol, [See IMAP]
Internet Print Protocol (IPP)
Internet Printing Protocol (IPP)
Internet Services object (NetMail)
inviting
users to virtual teams 2nd
IP addresses
network interfaces
modifying (YaST) 2nd 3rd
IPP Server (iPrint)
iPrint [See also printers]
benefits 2nd
components
Client 2nd 3rd 4th 5th
Driver Store 2nd
function of 2nd
IPP Server
iPrint Manager 2nd 3rd 4th
Map Designer 2nd 3rd 4th 5th 6th 7th
Printer Agent 2nd
Printer Agents 2nd 3rd 4th 5th
configuration
Driver Store component 2nd 3rd 4th 5th 6th 7th
implementing
lab exercise 9-1 2nd 3rd 4th 5th 6th 7th
installation
directories 2nd
Internet Printing Protocol (IPP)
location-based printing
lab exercise 9-2 2nd 3rd 4th 5th
NNLS component
required data
NNLS print management functions
printers
non-IP address assignments
Windows workstations configuration 2nd 3rd 4th
remote printing
use scenario 2nd 3rd 4th
Virtual Office
integrating with 2nd
iPrint Client 2nd
installing 2nd 3rd
iPrint Driver Store 2nd
iPrint Manager 2nd
configuring 2nd
iPrint Map Designer 2nd
location-based printer maps
creating 2nd 3rd 4th 5th
ISO image
NNLS installations
burning to disc 2nd 3rd


index_J

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

journaling process
paritions


index_K

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

KDE graphical interface (X Window)


index_L

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

lab exercises
Configuring Virtual Office (11-1) 2nd 3rd 4th 5th 6th 7th
Implementing iFolder (8-1) 2nd 3rd 4th 5th 6th 7th 8th 9th
Implementing iPrint (9-1) 2nd 3rd 4th 5th 6th 7th
Implementing Location-Based Printing (9-2) 2nd 3rd 4th 5th
Implementing LUM (6-2) 2nd 3rd 4th 5th 6th 7th
Implementing NetMail (10-1) 2nd 3rd 4th 5th 6th 7th
Implementing NTP (3-3) 2nd 3rd
Implementing Samba (8-2) 2nd 3rd 4th 5th 6th 7th
Importing an LDIF File (5-6) 2nd 3rd
Installing a New SUSE Linux Server (2-1) 2nd 3rd 4th 5th 6th
Installing and Configuring SLP (5-1) 2nd 3rd 4th 5th
Installing Linux Products and Managing Processes (3-2) 2nd 3rd 4th 5th
Installing NNLS (5-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Managing eDirectory (5-5) 2nd 3rd 4th 5th 6th 7th 8th 9th
Managing Linux Files and Directories (2-3) 2nd 3rd 4th 5th
Managing Linux Security (3-1) 2nd 3rd 4th 5th 6th
Preparing to Install NNLS (5-2) 2nd 3rd 4th 5th 6th 7th 8th 9th
Testing the DirXML Delimited Text Driver (7-2) 2nd 3rd
Updating NNLS with rcd (5-4) 2nd 3rd 4th 5th
Using the Linux Command Line (2-2) 2nd 3rd
Working with DirXML Delimited Text Driver (7-1) 2nd 3rd 4th 5th
Working with DirXML eDirectory Driver (7-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
Working with eGuide (6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Working with NetStorage (8-3) 2nd 3rd 4th 5th 6th 7th 8th
launching
Samba service
LDAP
(Lightweight Directory Access Protocol)
attributes
binds
binds to eDirectory 2nd
Data Interchange Format (LDIF) 2nd
data sources
adding (eGuide)
entries
Group object
LDIF (LDAP Data Interchange Format)
importing (lab exercise 5-6) 2nd 3rd
naming contexts
Server object
service binary (nldap)
terminology differences with eDirectory 2nd
LDAP ports
iFolder authentication 2nd 3rd
ldapconfig utility
LDIF (LDAP Data Interchange Format) 2nd
importing (lab exercise 5-6) 2nd 3rd
leaf objects
eDirectory tree structure
Alias objects 2nd
Group objects
Organizational role objects 2nd
Printer objects
Server objects
Template objects
User objects
less command
Lightweight Directory Access Protocol, [See LDAP]
Linux
distributions
LinixISO.org Web site
number of 2nd
Red Hat
Slackware
SUSE
End User Licensing Agreement (EULA)
file system
bootloaders 2nd 3rd
case sensitivity
default structure 2nd
device mounting
directory creation
File Systems Hierarchy (FSH)
journaling process
mount points 2nd 3rd
partitions 2nd 3rd 4th
root directory 2nd 3rd
saving files
similarity to Windows system 2nd
subdirectories
functions
application platform
file storage
hardware moderator
security
GNU
General Public License (GPL)
GNU General Public License (GPL)
GNU project
effects on development 2nd
historical review of
initial release
components
interfaces
command-line interface 2nd 3rd 4th 5th 6th 7th 8th
command-line interface, common commands 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
command-line interface, system utilities 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th
X Window System graphical interface
NNLS courseware
exam objectives 2nd
server usage statistics
source code
worldwide availability of
Torvalds, Linus
user accounts
authentication
creating
generic user
root
superuser
versus traditional software development
Linux Loader (LILO)
Linux Network Information Service (NIS) Web site
Linux servers
Samba
function of 2nd 3rd 4th
Linux Standards Base (LSB)
directory structure
Linux User Management
implementing (lab exercise 6-2) 2nd 3rd 4th 5th 6th 7th
Linux User Management (LUM)
namcd daemon configuration parameters 2nd 3rd 4th
NNLS component
required data 2nd
NNLS identity management functions
account synchronization 2nd
authentication 2nd
basic configuration of 2nd 3rd
contextless logins 2nd
development of 2nd
eDirectory objects
group object attributes
installing components 2nd
oser object attributes 2nd
redirection of authentication requests 2nd 3rd 4th 5th
Samba
users, enabling 2nd 3rd 4th 5th 6th
LinuxBase.org Web site
directory structures resources
LinuxISO.org Web site
distibution resources
List Server Agent (NetMail)
listing
directories
PATH variable 2nd 3rd
lo interface
locate command
location-based printer maps
creating (iPrint Map Designer) 2nd 3rd 4th 5th
location-based printing
implementing (lab exercise 9-2) 2nd 3rd 4th 5th
logging
into eGuide 2nd 3rd 4th
Virtual Office
configuration parameters 2nd
Login screen (iFolder)
lost synchronization
recovering
ls command
permissions
viewing list of 2nd
Lunix
popularity of


index_M

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Mailing Lists object (NetMail) 2nd
man command
Management Console (iFolder)
server parameters
configuring 2nd 3rd 4th 5th 6th
user access
configuring 2nd 3rd 4th
Map Designer (iPrint) 2nd
location-based printer maps
creating 2nd 3rd 4th 5th
Master replica
eDirectory databases
matching rules
DirXML
messages
processing
control files (NetMail)
data files (NetMail)
stage 0 (NetMail) 2nd
stage 1 (NetMail)
stage 2 (NetMail)
stage 3 (NetMail)
stage 4 (NetMail)
stage 5 (NetMail)
stage 6 (NetMail)
stage 7 (NetMail)
stage 8 (NetMail)
processing (NetMail)
Messaging Server object (NetMail) 2nd
messaging services
NNLS components
NetMail
Minix
as educational version of Unix OS 2nd 3rd
mirrored option placement
eDirectory driver (DirXML)
mkdir command
Modify Object event
rules (DirXML)
Modular Web Agent (NetMail) 2nd
modules
Virtual Office
exception errors 2nd
loading into iManager 2nd 3rd
monitoring
iFolder system 2nd 3rd
more command
motherboards
mount command
CDs
mounting 2nd 3rd
file system type support 2nd
floppy disks
mounting 2nd
syntax 2nd
mount points
partitions 2nd 3rd
Move Object event
rules (DirXML)
Mozilla web browser
installing (lab exercise 3-2) 2nd 3rd 4th 5th
multicasts
versus broadcasts
multicasts (SLP) 2nd
routing 2nd
mv command


index_N

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

namcd file
configuration parameters
Linux User Management (LUM) 2nd 3rd 4th
naming conventions
eDirectory
contexts 2nd
distinguished names 2nd
relative names 2nd
typeful
typeless
ndsbackup utility
ndsconfig utility
ndslogin utility
ndsmerge utility
ndsrepair utility
ndsstat utility
ndstrace utility
NetMail
agents
Address Book
Alias
AntiSpam
AntiVirus
AutoReply
Calendar 2nd
Connection Manager 2nd
IMAP 2nd
List Server
Modular Web 2nd
NMAP 2nd
object representation in eDirectory tree
POP 2nd
Proxy
SMTP 2nd
benefits 2nd 3rd
client software compatability
colloboration features
configuring 2nd 3rd 4th 5th 6th 7th 8th
cost benefits
deployment
distributed servers 2nd
planning for 2nd 3rd 4th 5th 6th
single-server 2nd
directories
file system 2nd 3rd 4th 5th
ease in deloyment
installing
port conflicts
preparations 2nd 3rd 4th
integration with eDirectory 2nd
maximum daily messages
maximum users
message processing
control files
data files
stage 0 2nd
stage 1
stage 2
stage 3
stage 4
stage 5
stage 6
stage 7
stage 8
modularity of
NNLS component
required data 2nd
NNLS messaging services functions
objects
Internet Services
Mailing Lists 2nd
Messaging Server 2nd
organizational unit 2nd
Parent
server
Templates 2nd
user 2nd
ports
default injstallations 2nd
processor support
scalability of
security protections
versus GroupWise
Virtual Office
integrating with 2nd 3rd 4th 5th
web-based user interface
WebAdmin utility
authentication process
function of
interface
launching
NetMail WebAdmin
NNLS web-based administration functions
netstat \#208nr command
multicast routing 2nd
netstat command
NetStorage
accessing
configuration
Authentication Domains
Current Sessions
iFolder Storage Provider
Resource Usage
server parameters 2nd 3rd 4th
Statistics
Storage Location object 2nd 3rd 4th 5th 6th
function of 2nd 3rd 4th
iFolder
file access
installation 2nd
storage directory locations
Storage Location object
Virtual Office
integrating with 2nd 3rd
wortking with (lab exercise 8-3) 2nd 3rd 4th 5th 6th 7th 8th
NetStorage 3.0
NNLS file management functions
NetWare
historical review of 2nd 3rd 4th
network boards
varieties
Network Messaging Application Protocol, 2nd [See NMAP]
Network Time Protocol, [See NTP]
networks
interfaces
configuring (ifconfig command) 2nd 3rd
configuring (YaST) 2nd 3rd 4th 5th
default router gateway (YaST)
DNS server address modification (YaST)
eth0
IP address modification (YaST) 2nd 3rd
lo
management of 2nd 3rd
PCI slots, number assignments 2nd
viewing information on (ifconfig command)
time synchronization
eDirectory tree 2nd 3rd 4th 5th 6th 7th
New Internet Folder Setup screen (iFolder)
new users
group accounts
assigning 2nd
NICI (Novell International Cryptographic Infrastructure) key file
NNLS download component
NMAP
(Network Messaging Application Protocol) 2nd
NMAP Agent (NetMail) 2nd
NNLS
(Novell Nterprise Linux Service)
(Novell Nterprise Linux Services) 2nd
CLE certification element
collaboration services components
Virtual Office
components
Virtual Office unification 2nd 3rd
DirXML component
required data
downloadable components
Companion CD
NICI key file
version 1.0 CD
eDirectory component
required data 2nd 3rd
eGuide component
required data 2nd
evaluation copies
downloading
evaluation copy
downloading
evolution of 2nd 3rd 4th
exam courseware
test objectives 2nd
existing systems
synchronization
file management components
iFolder 2nd
NetStorage 3.0
Samba 2nd
identity management components
DirXML 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
eDirectory
eGuide 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
Linux User Management (LUM) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
iFolder component
required data 2nd
iManager component
required data 2nd 3rd
installation 2nd
component data 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
components, post-installation of 2nd
custom type 2nd 3rd 4th
default ports 2nd
download components 2nd 3rd 4th
establishment of active connections
express type 2nd 3rd 4th
file locations 2nd
hardware requirements 2nd
hosts file configuration 2nd
ISO image, burning 2nd 3rd
Linux distributions 2nd
multicast routing (SLP) 2nd
preparations (lab exercise 5-2) 2nd 3rd 4th 5th 6th 7th 8th 9th
process (lab exercise 5-3) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
product dependencies 2nd 3rd
SAP advertising services 2nd 3rd
SLP agents
SLP configuration 2nd
SLP DA mode 2nd 3rd
SLP daemons 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
SLP implementation 2nd 3rd
SLP SA-Only mode 2nd 3rd
SLP scopes 2nd
software requirements 2nd
system preparations 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th 38th 39th 40th 41st 42nd 43rd 44th 45th 46th 47th 48th 49th 50th 51st 52nd 53rd 54th 55th 56th 57th 58th 59th 60th
time synchronization 2nd 3rd
troubleshooting guidelines 2nd 3rd 4th
update process (lab exercise 5-4) 2nd 3rd 4th 5th
integrated implementation
iPrint component
required data
Linux User Management (LUM) component
required data 2nd
messaging service components
NetMail
NetMail component
required data 2nd
obtaining
Pluggable Authentication Modules (PAM)
print management components
iPrint
product services
Red Carpet Client component
required data 2nd
Red Carpet component
channels 2nd
configuring 2nd
product updates 2nd 3rd 4th 5th 6th 7th
rcd daemon 2nd
RCD Group creation
RCD Group modification 2nd
RCD Group population
update files 2nd
updating 2nd
Samba component
required data 2nd 3rd
Samba version 2nd
standalone implementation
supported Linux distributions 2nd
TCO (total cost of ownership) benefits
user benefits
on-site location 2nd
remote location 2nd
version management services components
Red Carpet
Virtual Office component
required data
web-based administration components
iManager
iMonitor
NetMail WebAdmin
NOS (network operating system)
NetWare
historical review of 2nd 3rd 4th
notifications
virtual teams
user settings 2nd
Novell
as certification pioneer
Novell Directory Services
introduction of
name change to eDirectory
Novell exteNd
Novell International Cryptographic Infrastructure (NICI) key file
NNLS download component
Novell Ngage
Novell Nsure
Novell Nterprise Linux Services, 2nd 3rd [See NNLS]
Novell.com Web site
NNLS
downloading copies
NTP
(Network Time Protocol)
eDirectory trees
clock synchronization 2nd 3rd 4th 5th 6th 7th
implementing (lab exercise 3-3) 2nd 3rd
insane time
time servers
list of
xntp package
configuring 2nd 3rd
installing 2nd
NTP.org Web site


index_O

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

object associations
matching rules
DirXML
objects
DirXML
driver 2nd
driver set 2nd
rule 2nd
eDirectory
naming conventions 2nd 3rd 4th 5th 6th 7th 8th
eDirectory tree
inheritance rights 2nd 3rd
eDirectory trees
property rights 2nd
trustee rights 2nd
Linux User Management (LUM)
eDirectory
NetMail
Internet Services
Mailing Lists 2nd
Messaging Server 2nd
organizational unit 2nd
Parent
server
Templates 2nd
user 2nd
oneNet
introduction of 2nd
onetNet
Novell exteNd
Novell Ngage
Novell Nterprise
Novell Nure
strategic goals 2nd
Open Source
applications development
cost advantages
Novell\#213s corporate direction
advantages
total cost of ownership (TCO)
Openexchange mail service
OpenSLP
SLP daemon 2nd
configuration of 2nd 3rd 4th 5th
parameters 2nd
Organization objects
eDirectory tree container
Organizational role objects
eDirectory tree leaf objects 2nd
Organizational Unit objects
eDirectory tree container
organizational unit objects (NetMail)
attributes 2nd
ownership
files
assigning (lab exercise 3-1) 2nd 3rd 4th 5th 6th
viewing 2nd
virtual teams
setting 2nd


index_P

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

packages
installation methods
rpm command 2nd 3rd
tarball archive extraction 2nd
YaST Control Center 2nd
paper certification
versus practical certification 2nd 3rd
Parent object (NetMail)
partitions
default
/boot
swap
eDirectory databases 2nd 3rd
EXT2 2nd
EXT3 2nd
mount points 2nd 3rd
ResierFS 2nd
Pass Phrase Recovery screen (iFolder)
pass phrases
iFolder authentication
passwd file
user accounts
modifying
shadow files 2nd 3rd
Password Modification event
rules (DirXML)
passwords
group accounts
storage information 2nd
Virtual Office
user management options 2nd
PATH variable
list of directories 2nd 3rd
PC Magazine Web site
Samba testing
PCI slots
number assignments 2nd
permissions
assigning 2nd 3rd 4th 5th 6th 7th 8th
assigning (lab exercise 3-1) 2nd 3rd 4th 5th 6th
chmod utility
numeric arguments 2nd 3rd 4th 5th
Execute 2nd 3rd 4th 5th 6th 7th 8th
group accounts
assigning 2nd
lists
viewing (ls command) 2nd
Read 2nd 3rd 4th 5th 6th 7th 8th
Write 2nd 3rd 4th 5th 6th 7th 8th
placement rules
DirXML 2nd
platforms
iFolder client
Pluggable Authentication Modules (PAM)
POP Agent (NetMail) 2nd
ports
NetMail
installations 2nd
post-installation process
iFolder
postfix mail service
practical certification
versus paper certification 2nd 3rd
Practicum
components
Novell server
testing center computer
virtual server sessions
scenarios
handling strategies 2nd
implementation strategies
planning strategies
testing resolution of 2nd
tips/strategies 2nd 3rd
practicum element (CLE)
PRD
(product requirements document
traditional software development
Preferences tab (iManager)
rcd product updates 2nd
print management
NNLS components
iPrint
Printer Agent (iPrint) 2nd
Printer Agents (iPrint)
configuring 2nd 3rd 4th 5th
Printer objects
eDirectory tree leaf objects
printers [See also iPrint]
drivers
uploading (iPrint Driver Store) 2nd 3rd 4th 5th 6th
Implementing iPrint (lab exercise 9-1) 2nd 3rd 4th 5th 6th 7th
Implementing Location-Based Printing (lab exercise 9-2) 2nd 3rd 4th 5th
location-based maps
creating (iPrint Map Designer) 2nd 3rd 4th 5th
Windows workstations
configuring (iPrint) 2nd 3rd 4th
printing
remote locations
iPrint
process ID (PID) 2nd 3rd 4th
processes
management of (lab exercise 3-2) 2nd 3rd 4th 5th
process ID (PID) 2nd 3rd 4th
viewing (top utility) 2nd 3rd 4th
processing
messages
control files (NetMail)
data files (NetMail)
NetMail
stage 0 (NetMail) 2nd
stage 1 (NetMail)
stage 2 (NetMail)
stage 3 (NetMail)
stage 4 (NetMail)
stage 5 (NetMail)
stage 6 (NetMail)
stage 7 (NetMail)
stage 8 (NetMail)
product dependencies
DirXML
iFolder version
iManager version
iPrint version
Linux User Management (LUM)
NetMail version
NNLS
installation requirements 2nd 3rd
Samba version
Tomcat version
Virtual Office
product requirements document, [See PRD]
property rights
eDirectory objects 2nd
add self
compare
read
supervisor
write
protocols
Samba
CIFS
SMB 2nd 3rd 4th
Proxy Agent (NetMail)
proxy mode (iMonitor) 2nd
Public Web Page Link
Virtual Office
configuring 2nd 3rd
publisher channel component (DirXML)
creation rules
delimited text driver usage 2nd 3rd 4th
placement rules 2nd
schema-mapping rules 2nd
transformation stylesheets 2nd
pull protocols
push protocols
pwd command


index_R

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

RAM
NNLS
installation requirements
rcd daemon
configuring (NNLS Red Carpet) 2nd 3rd 4th 5th 6th
NNLS
Red Carpet component 2nd
updating (lab exercise 5-4) 2nd 3rd 4th 5th
product updates (NNLS Red Carpet) 2nd 3rd 4th 5th 6th 7th
RCD Groups
creating (NNLS)
modifying (NNLS) 2nd
populating (NNLS)
Read permission 2nd 3rd 4th 5th 6th 7th 8th
read property rights
eDirectory objects
Read-Only replica
eDirectory databases
Read/Write replica
eDirectory databases
reboot command
Red Carpet
NNLS version management services functions
Red Carpet Client
NNLS component
required data 2nd
Red Carpet component
configuring rcd daemon 2nd 3rd 4th 5th 6th
NNLS
channels 2nd
rcd daemon 2nd
update files 2nd
update function 2nd
product updates
managing 2nd 3rd 4th 5th 6th 7th
RCD Groups
creating
modifying 2nd
populating
Red Carpet daemon
active Internet connections
configuring for NNLS installations
Red Hat Linux
Red Hat Package Manager (RPM)
package installations 2nd 3rd
RedHat Enterprise Linux AS 2.1
NNLS platform support 2nd
RedHat Enterprise Linux ES 2.1
NNLS platform support 2nd
redirection
Linux User Management (LUM)
authentication requests 2nd 3rd 4th 5th
relative names
eDirectory naming conventions 2nd
remote access
Virtual Office
remote files
accessing (NFS)
Rename Object event
rules (DirXML)
rename rights
eDirectory
replica rings
replicas
eDirectory databases
Master
Read-Only
Read/Write
Subordinate Reference
reports
iFolder
system monitoring 2nd 3rd 4th
ResierFS partitions 2nd
Resource Usage
NetStorage configuration
reverse-compiling software
rights
eDirectory
browse
create
delete
inheritance of 2nd
inheritance of, blocking
property 2nd
rename
supervisor
Inherited Rights Filters (IRFs) 2nd
rm command
rmdir command
root directory
referencing
root user accounts
security warnings
route command
routers
network interfaces
configuring (YaST)
rpm command
package installations 2nd 3rd
rule object (dirXML) 2nd
rules
DirXML 2nd
event monitoring 2nd 3rd 4th 5th 6th 7th
runlevels
services 2nd 3rd 4th


index_S

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

SA-Only mode (SLP) 2nd 3rd
Samba
CIFS protocol
configuration 2nd
configuration file
directives 2nd 3rd 4th
eDirectory users
converting from 2nd 3rd
function of 2nd 3rd 4th
implementation (lab exercise 8-2) 2nd 3rd 4th 5th 6th 7th
installation 2nd
NNLS component
required data 2nd 3rd
NNLS file management functions 2nd
NNLS version 2nd
PC Magazine Web site
testing of
Samba.org Web site
service
launching
SMB protocol 2nd
share-level security
user-level security
users
enabling 2nd 3rd 4th 5th 6th
versus Windows servers
benefits 2nd
Samba.org Web site
SAP
(Service Advertisement Protocol) 2nd 3rd
drawbacks
bandwidth
dependency on IPX
IPX server broadcasts
push protocol
server availability 2nd 3rd
versus SLP
scenarios
CLE Practicum 2nd
implementation plans
resolution testing 2nd
strategy plans
schema-mapping rules
DirXML 2nd
schemas
eDirectory tree structure
scopes (SLP)
configuring 2nd
security
file system
group accounts 2nd 3rd 4th
user accounts 2nd 3rd 4th 5th
user scenarios 2nd 3rd
management of (lab exercise 3-1) 2nd 3rd 4th 5th 6th
Server Message Block protocol, [See SMB protocol]
Server object (LDAP)
Server objects
eDirectory tree leaf objects
server objects (NetMail)
attributes
server parameters
NetStorage
configuring 2nd 3rd 4th
servers
advertisement of availability (SAP) 2nd 3rd
hosts file
configuring for NNLS installations 2nd
iFolder
parameter configuration 2nd 3rd 4th 5th 6th
insane time (NTP)
Linux usage statistics
Service Advertisement Protocol, 2nd 3rd [See SAP]
Service Agent (SA)
NNLS mode 2nd 3rd
SLP
Service Location Protocol, [See SLP]
services
function of
runlevels 2nd 3rd 4th
starting on SUSE server 2nd
automatic
stopping on SUSE server
versus applications
Services Administration settings
Virtual Office 2nd
bookmarks 2nd 3rd
Change Password Service 2nd
company information 2nd
eGuide integration 2nd 3rd
iPrint integration 2nd
NetMail integration 2nd 3rd 4th 5th
NetStorage integration 2nd 3rd
Public Web Page Link 2nd 3rd
Setup Complete screen (iFolder)
sh (Bourne Shell)
shadow files
password encryption 2nd 3rd
share-level security
SMB protocol (Samba)
shells
command-line interface 2nd 3rd 4th
bash (Bourne Again Shell)
csh (C Shell)
sh (Bourne Shell)
tcsh (Tom\#213s C Shell)
zsh (Z Shell)
prompts
switching (Ctrl+Alt+function key)
usage determination (env command)
silos
DirXML
network management 2nd
typical network development 2nd 3rd 4th
single-server deployment
NetMail
fault tolerance issues
Slackware Linux
SLP
(Service Location Protocol)
agents
Directory Agent (DA)
Service Agent (SA)
User Agent (UA)
configuration prior to NNLS installation
DA mode 2nd 3rd
daemons
OpenSLP 2nd 3rd 4th 5th 6th 7th
slpuasa 2nd 3rd 4th 5th
installation and configuration of (lab exercise 5-1) 2nd 3rd 4th 5th
locating services
multicasts 2nd 3rd
pull protocol
RFC 2165
RFC 2608
SA-Only mode 2nd 3rd
scopes
configuring 2nd
URL responses 2nd
versus SAP
slptool utility
command listing 2nd
slpuasa
SLP daemon 2nd
configuration of 2nd 3rd
parameters 2nd
stopping
SMB protocol
(Server Message Block)
smb.conf file
Samba directives 2nd 3rd
SMTP Agent (NetMail) 2nd
software
NNLS
installation requirements 2nd
reverse-compiling
Software tab (iManager)
rcd product updates 2nd
Sourceforge.net Web site
email service add-ons
stage 0
message processing (NetMail) 2nd
stage 1
message processing (NetMail)
stage 2
message processing (NetMail)
stage 3
message processing (NetMail)
stage 4
message processing (NetMail)
stage 5
message processing (NetMail)
stage 6
message processing (NetMail)
stage 7
message processing (NetMail)
stage 8
message processing (NetMail)
Stallman, Richard
GNU project
standalone servers
NetMail deployment
fault tolerance issues
Starter Pack (DirXML)
drivers
installations 2nd
starting
services
SUSE server 2nd
SUSE server, automatic configuration
startx command
Statistics
NetStorage configuration
stopping
services
SUSE server
Storage Location object
NetStorage
configuring 2nd 3rd 4th 5th 6th
su command
subdirectories
Linux file system
Subordinate Reference replica
eDirectory databases
subscriber channel component (DirXML) 2nd
creation rules
delimited text driver usage 2nd 3rd 4th
placement rules 2nd
schema-mapping rules 2nd
transformation stylesheets 2nd
superuser accounts
supervisor property right
eDirectory objects
supervisor rights
eDirectory
SUSE Enterprise Server 8
NNLS platform support 2nd
SUSE Linux
SUSE Linux Enterprise Server 8
downloading evaluation copy
SUSE Linux Server
installing (lab exercise 2-1) 2nd 3rd 4th 5th 6th
SUSE server
services
automatic startup
starting 2nd
stopping
swap partition
synchronizing
files
iFolder 2nd 3rd
System Monitoring screen (iFolder) 2nd 3rd
System Reporting screen (iFolder) 2nd
system utilities 2nd
cat
cd
cp
dir
find
gedit text editor 2nd
grep
gzip 2nd
less
locate
ls
mkdir
more
mount 2nd 3rd 4th 5th 6th 7th
mv
pwd
rm
rmdir
tail
tar 2nd
vi text editor 2nd 3rd 4th 5th


index_T

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

tail command
Tanenbaum, Andrew S.
Minix development 2nd 3rd
relationalship with Linus Torvalds
tar command
files
compressing for archival purposes 2nd
tarball archives
package installations 2nd
tarballs (compressed archives) 2nd
TCO (total cost of ownership) benefits (NNLS)
tcsh (Tom\#213s C Shell)
Template objects
eDirectory tree leaf objects
Templates object (NetMail) 2nd
testing
DirXML
delimited text driver (lab exercise 7-2) 2nd 3rd
text files
editing (gedit text editor) 2nd
editing (vi text editor) 2nd 3rd 4th 5th
time
synchronization
eDirectory tree 2nd 3rd 4th 5th 6th 7th
time servers
site listings
time synchronization
lost
recovering
NNLS
installation requirements 2nd 3rd
SAP advertising services 2nd 3rd
SLP agents
SLP configuration 2nd
SLP implementation 2nd 3rd
SLP SA-Only mode 2nd 3rd
Tom\#213s C Shell (tcsh)
top command
top utility
command lines 2nd 3rd
processes
viewing 2nd 3rd 4th
Torvalds, Linus
free availability of Linux
relationship with Andrew Tanenbaum
traditional certification
versus practical testing approach 2nd 3rd
traditional software development
PRDs
versus GNU project
versus Linux development
transformation stylesheets
DirXML 2nd
trees
eDirectory
design structure 2nd 3rd
eDirectory naming conventions
distinguished names 2nd
relative names 2nd
typeful naming
typeless naming
partitioning 2nd
replication 2nd
time servers
synchronization of 2nd 3rd 4th 5th 6th 7th
troubleshooting
eDirectory tree structure
installation errors
typeful naming
eDirectory naming conventions
typeless naming
eDirectory naming conventions


index_U

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Unix
source code
update files
NNLS
Red Carpet component 2nd
updating
NNLS
rcd daemon (lab exercise 5-4) 2nd 3rd 4th 5th
Red Carpet component 2nd
uploading
printer drivers
iPrint Driver Store 2nd 3rd 4th 5th 6th
URLs
SLP responses 2nd
user accounts
authentication
creating 2nd
deleting
generic user
information storage 2nd 3rd
passwd file
modifying
shadow files 2nd 3rd
permissions
assigning 2nd 3rd 4th 5th 6th 7th 8th
assigning (lab exercise 3-1) 2nd 3rd 4th 5th 6th
root
security features 2nd 3rd 4th 5th
superuser
User Agent (UA)
SLP
User LDAPs screen (iFolder)
User objects
eDirectory tree leaf objects
user objects (NetMail)
attributes 2nd
User Search screen (iFolder)
user-level security
SMB protocol (Samba)
users
DirXML
silo network development 2nd 3rd 4th 5th 6th
eGuide
adding to (lab exercise 6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
attribute configuration (lab exercise 6-1) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
attributes 2nd 3rd
configuring 2nd 3rd
LDAP sources, adding
logging in 2nd 3rd 4th
organizational functions 2nd
search functionality
group accounts
assigning 2nd
iFolder
access configuration 2nd 3rd 4th
Linux User Management (LUM)
account synchronization 2nd
authentication 2nd
authentication configuration (lab exercise 6-2) 2nd 3rd 4th 5th 6th 7th
basic configuration of 2nd 3rd
contextless logins 2nd
development of 2nd
object attributes 2nd
redirection of authentication requests 2nd 3rd 4th 5th
Samba
enabling 2nd 3rd 4th 5th 6th
Virtual Office
home pages 2nd
management features
virtual teams
management tasks 2nd
notification preferences 2nd


index_V

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

variables
PATH 2nd 3rd
version control
files
handling (iFolder)
version management services
NNLS components
Red Carpet
vi text editor
Command mode
Insert mode
text files
editing 2nd 3rd 4th 5th
viewing
processes
top utility 2nd 3rd 4th
Virtual Office
authentication
calendar home pages
configuration 2nd 3rd 4th
Environment Administration 2nd 3rd 4th 5th 6th 7th 8th
Services Administration settings 2nd
Services Administration settings, bookmarks 2nd 3rd
Services Administration settings, Change Password Service 2nd
Services Administration settings, company information paramaters 2nd
Services Administration settings, eGuide integration 2nd 3rd
Services Administration settings, iPrint integration 2nd
Services Administration settings, NetMail integration 2nd 3rd 4th 5th
Services Administration settings, NetStorage integration 2nd 3rd
Services Administration settings, Public Web Page Link 2nd 3rd
configuring
lab exercise 11-1 2nd 3rd 4th 5th 6th 7th
installation 2nd 3rd
modules
exception errors 2nd
loading into iManager 2nd 3rd
NNLS collaboration services functions
NNLS component
required data
NNLS components
unification fetaures 2nd 3rd
personal user management
remote access
team home pages 2nd
user home pages 2nd
virtual teams
creating 2nd
management tasks 2nd
notification preferences 2nd
user invitations 2nd
virtual servers
CLE Practicum component
virtual teams
configuration parameters
setting 2nd 3rd 4th
creating 2nd
email server parameters
setting
file shares
setting
ownership
setting 2nd
users
inviting 2nd
management tasks 2nd
notification preferences 2nd
Virtual Office
calendar pages
home pages 2nd
VMWare


index_W

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Web sites
Linux Network Information Service (NIS)
LinuxBase.org
LinuxISO.org
NTP.org
PC Magazine
Samba testing
Samba.org
SourceForge.net
mail service add-ons
web-based administration services
NNLS components
iManager
iMonitor
NetMail WebAdmin
WebAdmin utility (NetMail)
authentication process
function of
interface
launching
which command
whoami command
Windows
workstations
printer configuration (iPrint) 2nd 3rd 4th
Windows servers
versus Samba
benefits 2nd
workstations
iFolder client
configuring 2nd
Write permission 2nd 3rd 4th 5th 6th 7th 8th
write property rights
eDirectory objects


index_X

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

X Window System graphical interface
GNOME
KDE
X Windows
network interfaces
configuring (YaST) 2nd 3rd 4th 5th
XFree86 Project
xntp package
configuring (NTP) 2nd 3rd
installing (NTP) 2nd


index_Y

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

YaST
network interfaces
configuring 2nd 3rd 4th 5th
default router gateway
DNS server address modification
IP address modification 2nd 3rd
package installations 2nd
users
creating
deleting
yast2 command


index_Z

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Z Shell (zsh)
zsh (Z Shell)