3100 Manual

www. novel l .
com Novel l Trai ni ng Servi ces

AUTHORI ZED COURSEWARE
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Upgrading to Novell Certified Linux
Professional 11
Manual
3 1 0 0
Novell, Inc. Copyright 2009-1 HARDCOPY PERMITTED. NO OTHER PRINTING, COPYING, OR DISTRIBUTION ALLOWED.
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Legal Notices
Novell, Inc., makes no representations or warranties with respect to the contents
or use of this documentation, and specifically disclaims any express or implied
warranties of merchantability or fitness for any particular purpose. Further,
Novell, Inc., reserves the right to revise this publication and to make changes to
its content, at any time, without obligation to notify any person or entity of such
revisions or changes.
Further, Novell, Inc., makes no representations or warranties with respect to any
software, and specifically disclaims any express or implied warranties of
merchantability or fitness for any particular purpose. Further, Novell, Inc.,
reserves the right to make changes to any and all parts of Novell software, at any
time, without any obligation to notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be
subject to U.S. export controls and the trade laws of other countries. You agree to
comply with all export control regulations and to obtain any required licenses or
classification to export, re-export or import deliverables. You agree not to export
or re-export to entities on the current U.S. export exclusion lists or to any
embargoed or terrorist countries as specified in the U.S. export laws. You agree
to not use deliverables for prohibited nuclear, missile, or chemical biological
weaponry end uses. See the Novell International Trade Services Web page (http:/
/www.novell.com/info/exports/) for more information on exporting Novell
software. Novell assumes no responsibility for your failure to obtain any
necessary export approvals.
Copyright 2008 Novell, Inc. All rights reserved. No part of this publication
may be reproduced, photocopied, stored on a retrieval system, or transmitted
without the express written consent of the publisher.
Novell, Inc., has intellectual property rights relating to technology embodied in
the product that is described in this document. In particular, and without
limitation, these intellectual property rights may include one or more of the U.S.
patents listed on the Novell Legal Patents Web page (http://www.novell.com/
company/legal/patents/) and one or more additional patents or pending patent
applications in the U.S. and in other countries.
Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com
Online Documentation: To access the latest online documentation for
this and other Novell products, see the Novell Documentation Web
page (http://www.novell.com/documentation).
Novell Trademarks
For Novell trademarks, see the Novell Trademark and Service Mark list (http://
www.novell.com/company/legal/trademarks/tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.
Contents
Copying all or part of this manual, or distributing such copies, is strictly prohibited.
To report suspected copying, please call 1-800-PIRATES.
3 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Introduction 7
SECTION 1 Manage Software for SUSE Linux Enterprise 11 13
Objective 1 Overview of Software Management in SUSE Linux Enterprise 11 14
Repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Objective 2 Manage Software with zypper 16
Repository Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Package Management Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Patching and Updating Packages with zypper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Exercise 1-1 Manage RPM Software Repositories with zypper . . . . . . . . . . . . . . . . . . . . . . . . . 21
Summary 22
SECTION 2 Manage Hardware 23
Objective 1 Differences between SLE 10 and SLE 11 24
Managing Hardware in SUSE Linux Enterprise 10 . . . . . . . . . . . . . . . . . . . . . . . . 24
Managing Hardware in SUSE Linux Enterprise 11 . . . . . . . . . . . . . . . . . . . . . . . . 24
Objective 2 Describe the sysfs File System 25
Objective 3 Describe how udev Works 26
The Purpose of udev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
How udev Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Persistent Interface Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Exercise 2-1 Modify udev Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Objective 4 Administer udev 30
Monitoring udev . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Querying udev. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Summary 35
SECTION 3 Configure NFS (Network File System) 37
Objective 1 Configure NFS (Network File System) 38
NFS Background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
NFS Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
NFS Client Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Automounter Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
NFS System Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Exercise 3-1 Set Up and Manage Network File System (NFS). . . . . . . . . . . . . . . . . . . . . . . . . . 55
Upgrading to Novell Certified Linux Professional 11 / Manual
Version 1 4
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary 56
SECTION 4 Configure and Use OpenLDAP 57
Objective 1 Describe How LDAP Works 58
How Directory Services Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
What is LDAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
How the LDAP Directory Tree Is Structured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Objective 2 Install and Configure OpenLDAP on SLES 11 72
Install and Configure the LDAP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Install and Configure the LDAP Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Objective 3 Add, Modify, and Delete Entries to the LDAP Directory Tree 91
Managing LDAP Users and Groups from the Shell Prompt . . . . . . . . . . . . . . . . . . 91
Managing LDAP Users and Groups in YaST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Exercise 4-1 Configure OpenLDAP on SLE 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Summary 106
SECTION 5 Configure and Use Samba 109
Objective 1 Describe the Role and Function of Samba 110
SMB Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
NetBIOS Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
How SMB Communications Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
How Samba Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Objective 2 Configure a Simple File Server with Samba 114
Installing Samba on the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Using the Samba Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Configuring Samba in YaST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Exercise 5-1 Create a Basic Samba Share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Objective 3 Configure Samba Authentication 128
Configuring the Samba User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Configuring Samba to Require User Authentication . . . . . . . . . . . . . . . . . . . . . . 134
Exercise 5-2 Configure Samba to Use LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Objective 4 Use Sambas Client Tools 138
Using nmblookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Using smbclient. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Mounting Samba Shares in the Linux File System. . . . . . . . . . . . . . . . . . . . . . . . 140
Exercise 5-3 Work with Samba Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
5 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary 143
SECTION 6 Configure and Use IPv6 145
Objective 1 Understand IPv6 Theory 146
IPv6 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
IPv6 Address Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Objective 2 Configure IPv6 on SLE 11 151
IPv6 Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Setting an IPv6 Address Using YaST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Managing IPv6 Addresses Using the Command Line Tools . . . . . . . . . . . . . . . . 155
Connecting to Other IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Exercise 6-1 Configure IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Summary 162
SECTION 7 Deploy SUSE Linux Enterprise 11 163
Objective 1 Introduction to AutoYaST 164
Autoinstallation Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Installation Options and Deployment Strategies . . . . . . . . . . . . . . . . . . . . . . . . . 165
Objective 2 Installation Server: Setup and Use 168
Set Up an Installation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Use the Installation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Exercise 7-1 Set Up an Installation Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Objective 3 Set Up PXE Boot for Installations 181
Install and Configure tftp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Configure pxelinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Install and Configure the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Exercise 7-2 Set Up PXE Boot for Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Objective 4 Create a Configuration File for AutoYaST 191
Exercise 7-3 Create an AutoYaST Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Objective 5 Perform an Automated Installation 195
Provide the Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Boot and Install the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Exercise 7-4 Perform an Automated Installation of SUSE Linux Enterprise Server 11 . . . . . . 199
Exercise 7-5 Activate PXE Booting and Install SUSE Linux Enterprise Server (Conditional,
depending on hardware support) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Version 1 6
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary 201
SECTION 8 Manage Virtualization with Xen 203
Objective 1 Understand How Virtualization with Xen Works 204
Understand Virtualization Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Understand the Xen Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Objective 2 Install Xen 208
Install a Xen Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Install a Xen Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Exercise 8-1 Install a Xen Server and an Unprivileged Domain . . . . . . . . . . . . . . . . . . . . . . . . 218
Objective 3 Manage Xen Domains with Virt-Manager 219
Exercise 8-2 Change Memory Allocation of a Guest Domain. . . . . . . . . . . . . . . . . . . . . . . . . . 224
Objective 4 Manage Xen Domains from the Command Line 225
Understand Managed and Unmanaged Domains . . . . . . . . . . . . . . . . . . . . . . . . . 225
Understand a Domain Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Use the xm Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Use the virsh Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Automate Domain Startup and Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Exercise 8-3 Automate Domain Startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Objective 5 Understand Xen Networking 232
Understand Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Understand the Xen Networking Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Exercise 8-4 Check the Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Summary 237
7 Version 1
Introduction
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Introduction
The Upgrading to Novell Certified Linux Professional 11 (3100) course covers topics
that are new to the curriculum compared to the Novell Linux Certified Professional
10 curriculum. It covers objectives that have been added, as well as changes in the
SUSE Linux Enterprise Server 11 and SUSE Linux Enterprise Desktop 11 products
compared to the previous version 10.
The course prepares a CLP 10 to take the Novell Certified Linux Professional 11
(Novell CLP11) certification practicum test.
The available material includes the following:
Upgrading to Novell Certified Linux Professional 11 manual (PDF file)
Upgrading to Novell Certified Linux Professional 11 workbook (PDF file)
Upgrading to Novell Certified Linux Professional 11 course DVD (ISO-image)
SUSE Linux Enterprise Server 11 product DVD (ISO-image)
SUSE Linux Enterprise Desktop 11 product DVD (ISO-image)
The Upgrading to Novell Certified Linux Professional 11 course DVD contains a pre-
installed VMware image of SUSE Linux Enterprise Server 11 that you can use with
the Upgrading to Novell Certified Linux Professional 11 Workbook to practice the
skills you need to take the Novell CLP 11 practicum.
NOTE: Instructions for setting up a self-study environment are in the Setup directory on the Course
DVD.
Course Objectives
This course teaches you how to perform the following SUSE Linux Enterprise Server
11 administrative tasks:
Manage Software for SUSE Linux Enterprise
Manage Hardware
Manage NFS
Configure and Use OpenLDAP
Configure and Use Samba
Configure and Use IPv6
Deploy SUSE Linux Enterprise 11
Manage Virtualization with XEN
Version 1 8
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Audience
This course is designed for Novell Certified Linux Professionals 10 who want to
upgrade their certification to Novell CLP11.
Certification and Prerequisites
This course helps you prepare for the Novell Certified Linux Professional 11 (Novell
CLP11) Practical Test, called a practicum. The Novell CLP 11 is an entry-level
certification for people interested in becoming SUSE Linux Enterprise
administrators.
As with all Novell certifications, course work is recommended. To achieve the
certification, you are required to pass the Novell CLP 11 Practicum (050-721).
The Novell CLP 11 Practicum is a hands-on, scenario-based exam where you apply
the knowledge you have learned to solve real-life problemsdemonstrating that you
know what to do and how to do it.
The practicum tests you on objectives from the following courses:
SUSE Linux Enterprise 11 Fundamentals - Course 3101
SUSE Linux Enterprise 11 Administration - Course 3102
SUSE Linux Enterprise Server 11 Administration - Course 3103
The following illustrates the training/testing path for Novell CLP 11:
Figure Intro-1 Certification Path
9 Version 1
Introduction
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NOTE: For more information about Novell certification programs and taking the Novell CLP 11
Practicum, see (http://www.novell.com/training/certinfo/).
SUSE Linux Enterprise Server 11 Support and Maintenance
The copy of SUSE Linux Enterprise Server 11 you receive in your student kit is a
fully functioning copy of the SUSE Linux Enterprise Server 11 product.
However, to receive official support and maintenance updates, you need to do one of
the following:
Register for a free registration/serial code that provides you with 60 days of
support and maintenance.
Purchase a copy of SUSE Linux Enterprise Server 11 from Novell (or an
authorized dealer).
You can obtain your free 60 day support and maintenance code at (http://
www.novell.com/products/server/eval.html).
NOTE: You will need to have a Novell login account to access the 60 day evaluation.
Novell Customer Center
Novell Customer Center is an intuitive, Web-based interface that helps you to manage
your business and technical interactions with Novell. Novell Customer Center
consolidates access to information, tools, and services such as the following:
Automated registration for new SUSE Linux Enterprise products
Patches and updates for all shipping Linux products from Novell
Order history for all Novell products, subscriptions, and services
Entitlement visibility for new SUSE Linux Enterprise products
Linux subscription renewal status
Subscription renewals via partners or Novell
For example, a company might have an administrator who needs to download SUSE
Linux Enterprise software updates, a purchaser who wants to review the order
history, and an IT manager who has to reconcile licensing. With Novell Customer
Center, the company can meet all these needs in one location and can give users
access rights appropriate to their roles.
You can access the Novell Customer Center at (http://www.novell.com/
customercenter).
Version 1 10
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SUSE Linux Enterprise Server 11 Online Resources
Novell provides a variety of online resources to help you configure and implement
SUSE Linux Enterprise Server 11:
(http://www.novell.com/products/server/)
This is the Novell home page for SUSE Linux Enterprise Server 11.
(http://www.novell.com/documentation/sles11/)
This is the Novell Documentation Web site for SUSE Linux Enterprise Server 11.
(http://support.novell.com/linux/)
This is the home page for all Novell Linux support and it includes links to
support options such as Knowledgebase, downloads, and FAQs.
(http://www.novell.com/coolsolutions/)
This Web site provides the latest implementation guidelines and suggestions
from Novell on a variety of products, including SUSE Linux Enterprise.
Scenario
The exercises in this course center around the fictional Digital Airlines Company that
has offices at various airports around the globe.
The Digital Airlines management has made the decision to migrate several back-end
services to Linux servers running SUSE Linux Enterprise Server 11.
You have already installed SUSE Linux Enterprise Server 10 before and are familiar
with administering SUSE Linux Enterprise Server 10. You need to become familiar
with SUSE Linux Enterprise Server 11 and SUSE Linux Enterprise Desktop 11
The migration plan includes the following:
Providing software and patch management
Providing basic networking services as well as file and print services
Introducing IPv6
Installing of desktops and servers using AutoYaST
Virtualizing with Xen
Your task is to set up a test server in the lab to enhance your skills in these areas.
Exercise Conventions
When working through an exercise, you will see conventions that indicate
information you need to enter that is specific to your server.
11 Version 1
Introduction
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following describes the most common conventions:
italicized text: This is refers to your unique situation, such as the hostname of
your server.
For example, supposing the hostname of your server is da50 and you see the
following
hostname.digitalairlines.com
You would enter
da50.digitalairlines.com
172.17.8.xx: This is the IP address that is assigned to your SUSE Linux
Enterprise Server 11.
For example, supposing your IP address is 172.17.8.50 and you see the following
172.17.8.xx
You would enter
172.17.8.50
Select: The word select is used in exercise steps with reference to menus where
you can choose between different entries, such as drop-down menus.
Enter and Type: The words enter and type have distinct meanings.
The word enter means to type text in a field or at a command line and press the
Enter key when necessary. The word type means to type text without pressing the
Enter key.
If you are directed to type a value, make sure you do not press the Enter key or
you might activate a process that you are not ready to start.
Version 1 12
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
13 Version 1
Manage Software for SUSE Linux Enterprise 11
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 1 Manage Software for SUSE Linux Enterprise
11
In this section, you learn how to manage software packages on your SUSE Linux
Enterprise server or desktop using the zypper command.
Objectives
1. Overview of Software Management in SUSE Linux Enterprise 11 on page 14
2. Manage Software with zypper on page 16
Version 1 14
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Overview of Software Management in SUSE Linux
Enterprise 11
SUSE Linux Enterprise 11 uses ZYpp (also called libzypp) as the software
management engine. ZYpp can be accessed on the command line via the command
zypper and graphically via YaST.
Software packages depend on each other in various ways. Packages usually require or
recommend other packages, they can declare that they conflict with other packages,
etc. Packages can also depend on specific hardware. ZYpp utilizes a dependency
solver called SAT solver to find out what packages are needed to be installed
according to the user's request.
ZYpp works with package metadatainformation about packages and their relations
extracted from RPM packages and other data like patch information, pattern
definitions, etc. These data are stored together with the RPM files in folders called
repositories. Repositories can be placed on various media like an HTTP or FTP
server, a DVD, or a directory on a local disc.
ZYpp works with several types of resource objects, called resolvables. Possible
resolvables are:
n Product: A predefined group of packages which are necessary to install a product
(such as SUSE Linux Enterprise Server 11).
n Pattern: A predefined group of packages required or recommended to install
some functionality (such as GNOME pattern).
n Package: A normal RPM package, containing the files needed for a particular
program (such as OpenOffice.org).
n Patch: Update to the system or to an application. A patch can include special
scripts and messages to be run or shown during installation of the update.
Repositories
A repository is basically a directory containing all files which are needed to install
software. These files are not only the RPM files containing the packages but also files
containing a description of the repository and metadata containing information about
packages and their relationships.
These files can be located on local file systems (harddisk, DVD) or on remote file
systems. To create a repository from the installation DVD, simply copy the contents
of the DVD into a directory and make this directory accessible for the other systems
(for instance by setting up a web server).
A repository is accessed through its Uniform Resource Identifier (URI). The
structure of a URI is
protocol://hostname/directory
The protocol describes how the repository is accessed. Examples include:
n dvd: The repository is a local DVD containing the files (for instance, installation
media).
15 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
n http: The repository is accessed via the http protocol.
n ftp: The ftp protocol is used to access the files in the repository.
n cifs: The CIFS (or SMB) protocol is used to access the files in the repository.
n nfs: Files in this repository are accessible via an NFS server.
n dir: The repository is located on a local file system.
When a repository is defined for a system, it can always be enabled and disabled.
Only enabled repositories are available to install software from.
If there are multiple repositories enabled, there priority defines which repositories
will be used first. Each repository is assigned a priority value, the default value is 99.
The lower the priority value, the higher the priority of the repository.
Repositories can always be accessed by a name or an alias so you do not need to type
the full path including the protocol to access files in the repository.
Version 1 16
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Manage Software with zypper
zypper is a command-line interface to the ZYpp system management library. It can
be used to
n Install, update, and remove software
n Manage repositories
n Perform various queries.
This objective will discuss the most important examples for these actions.
The general command syntax for the zypper command is
zypper [--global-options] <command> [--command-options]
[arguments]
More information on how to use the command is displayed by entering
zypper help [command]
In most cases, the command can be used in a long and a short format, e.g.
zypper info apache2
or
zypper if apache2
Repository Management Commands
zypper relies on a list of repositories for its installation and update commands. To
list all repositories known to the system, enter
zypper repos
The most important options for this command are -p (show the priority for each
repository) and -d (show more details for each repository).
To add a new repository, use the command
zypper addrepo [options] <URI> <alias>
da10:~ # zypper repos
# | Alias | Name | Enabled | Refresh
--+-----------------+--------------+---------+--------
1 | SLES-11 11-0 | SLES-11 11-0 | Yes | Yes
da10:~ # zypper repos -d
# | Alias | Name | Enabled | Refresh | Priority | Type
| URI | Service
--+-------------+--------------+---------+---------+---------+------
+---------------------------------------+--------
1 | SLES-11 11-0 | SLES-11 11-0 | Yes | Yes | 99 | yast2
| http://172.17.8.100/install/SLES11GM/CD1/ |
17 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The URI identifies the location of the repository and the alias sets a name which can
be used to access the repository. An example could look like this:
Important options for this command are:
n -d: Add the repository as disabled. Repositories are added as enabled by default.
n -k: Enable RPM files caching for the repository (i.e., RPM packages are kept in
a local directory after being installed).
n -K: Disable RPM files caching.
NOTE: When a repository is added, the existence and accessibility of the repository is not checked.
If there are any errors in the URI these will show up when trying to access the repository later.
In order to remove a repository from the list, use the command
zypper removerepo <alias|#|URI>
To specify the repository, you can use the alias, the sequence number or the whole
URI of the repository.
Existing repositories can be modified by using
zypper modifyrepo <options> <alias|#|URI>
The following are the most important options for this command:
n -e: Enable the repository.
n -d: Disable the repository.
n -p: Set priority of the repository. A priority of 1 is the highest prioritythe
higher the number the lower the priority. The default priority is 99. Packages
from repositories with higher priority will be preferred even in case there is an
installable higher version available in the repository with a lower priority.
Package Management Commands
To find a package in a repository, the search command with a query string is used:
zypper search [option] querystring
The result lists all packages containing the querystring and returns information on the
package:
da10:~ # zypper addrepo http://172.17.8.101/sles11/CD1 sles11
Version 1 18
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To see more details on the packages, the -s option can be used:
To see more information about a package, use the command
zypper info <package>
This command displays detailed information about a package, including the version,
the vendor, a brief description, and whether the package is installed. For an already
installed package it will also display the status of the package, such as whether the
package is up-to-date or needs to be updated.
da10:~ # zypper search apache2
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+-------------+------------------------------------+-----------
i | apache2 | The Apache Web Server Version 2.0 | package
| apache2 | The Apache Web Server Version 2.0 | srcpackage
| apache2-doc | Additional Package Documentation. | package
...
da10:~ # zypper search -s apache2
S | Name | Type | Version | Arch | Repository
--+-------------+------------+-------------+--------+-------------
i | apache2 | package | 2.2.10-2.18 | i586 | SLES-11 11-0
| apache2 | srcpackage | 2.2.10-2.18 | noarch | SLES-11 11-0
| apache2-doc | package | 2.2.10-2.18 | i586 | SLES-11 11-0
...
da10:~ # zypper info apache2
Information for package apache2:
Repository: @System
Name: apache2
Version: 2.2.10-2.18
Arch: i586
Vendor: SUSE LINUX Products GmbH, Nuernberg, Germany
Installed: No
Status: not installed
Installed Size: 2.1 M
Summary: The Apache Web Server Version 2.0
Description:
Apache 2, the successor to Apache 1.
...
19 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
If the package is not installed and you want to install it, use the command
zypper install <package>
If additional packages need to be installed, zypper will do so.
To remove an installed package, the command
zypper remove <package>
is used. If other packages depend on this package, these will be removed as well. In
any case the user is informed of what will be done and can decide not to run the
command.
Patching and Updating Packages with zypper
To guarantee the operational security of a system, you should update packages
frequently by installing patched packages.
There are two different ways to update software using zypper:
n Integrating all officially released patches into your system
n Updating all installed packages with newer available versions
da10:~ # zypper install apache2
Resolving package dependencies...
The following NEW packages are going to be installed:
apache2 apache2-prefork
Overall download size: 1007.0 K. After the operation, additional 2.7
M will be used.
Continue? [YES/no]:
Retrieving package apache2-2.2.10-2.18.i586 (1/2), 745.0 K (2.1 M
unpacked)
Retrieving: apache2-2.2.10-2.18.i586.rpm [done]
Installing: apache2-2.2.10-2.18 [done]
...
da10:~ # zypper remove apache2
Building repository 'sles11' cache [done]
Resolving package dependencies...
The following packages are going to be REMOVED:
apache2 apache2-prefork
After the operation, 8.8 M will be freed.
Continue? [YES/no]:
Removing apache2-prefork-2.2.10-2.18 [done]
Removing apache2-2.2.10-2.18 [done]
Version 1 20
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To integrate all officially released patches into your system, just run:
zypper patch
In this case, all patches available in your repositories are checked for relevance and
installed if necessary. After registering your SUSE Linux Enterprise installation, an
official update repository containing such patches will be added to your system. The
above command is all you need to enter in order to apply them when needed.
To update installed packages with their newer available versions, where possible,
enter:
zypper update
This command does not update packages which would require a change of package
vendor or which would require manual dependency resolution.
To list all needed patches, type
zypper list-patches
You can get a list of available updates with:
zypper list-updates
NOTE: This command lists only installable updates, i.e., updates which have no
dependency problems or which do not change package vendor. This list is what the
update command will propose to install. You can use the --all option if you want to
list all packages for which newer versions are available.
21 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 1-1 Manage RPM Software Repositories with zypper
In this exercise, you will add and remove a repository.
You will find this exercise in the workbook.
(End of Exercise)
Version 1 22
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Overview of Software Management
in SUSE Linux Enterprise 11
Concepts and terminology involved in managing
software with SUSE Linux Enterprise include libzypp,
SATSolver, and RPM.
Packages are distributed as RPM packages, while
libzypp ensures dependencies are resolved and
patches and updates installed as needed.
Manage Software with zypper Zypper allows you to list known repositories, remove,
add, and manage repositories. Packages can be easily
installed, removed and updated.
23 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 2 Manage Hardware
Although most hardware devices can be configured with YaST and are automatically
detected when plugged into the system, you should understand how devices are
managed the background.
In this section, you learn how SUSE Linux Enterprise 11 handles hardware and
device drivers.
Objectives
1. Differences between SLE 10 and SLE 11 on page 24
2. Describe the sysfs File System on page 25
3. Describe how udev Works on page 26
4. Administer udev on page 30
Version 1 24
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Differences between SLE 10 and SLE 11
The way device initialization is done has changed from SUSE Linux Enterprise 10 to
SUSE Linux Enterprise 11.
Managing Hardware in SUSE Linux Enterprise 10
In SUSE Linux Enterprise 10, device configuration files are located in the
/etc/sysconfig/hardware/ directory. These configuration files can be used
to load special drivers to access certain devices. If there is no configuration file for a
device the best matching driver is loaded automatically.
Loading the configuration and initializing the devices is done via a script called
/sbin/hwup. The /sbin/hwstatus script can be used to check the status of a
device and the /sbin/hwdown script to deactivate it. The latter two scripts are in
fact symbolic links to /sbin/hwup.
First, the configuration file /etc/sysconfig/hardware/config is read by
hwup. After this, all configuration files named /etc/sysconfig/hardware/
hwcfg-* are read. An example for the configuration file of a network looks like
this:
Managing Hardware in SUSE Linux Enterprise 11
In SUSE Linux Enterprise 11, there are no configuration files located in the
/etc/sysconfig/hardware/ directory. There is still a script called
/sbin/hwup available, but its content has changed completely. All loading of
kernel modules and configuration of hardware components is now done using the
udev mechanism directly. If another driver for a device is be used, it has to be defined
using a udev rule.
da10:~ # cat /etc/sysconfig/hardware/hwcfg-bus-pci-0000\:00\:19.0
MODULE='e1000'
MODULE_OPTIONS=''
STARTMODE='auto'
25 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Describe the sysfs File System
The sysfs file system is a virtual file system mounted under /sys/. In a virtual file
system there is no physical device that holds the information. Instead, the file system
is generated virtually by the kernel.
sysfs is a mechanism to export information from the kernel to user processes. Kernel
objects, their attributes, and their relationships are represented by directories, files
and symbolic links, respectively.
The top level of the /sys directory contains a number of directories. The most
important of these are:
n /sys/block: This directory contains an entry for each block device that has been
discovered in the system. In SUSE Linux Enterprise 11, these entries are all
symbolic links to entries in the /sys/devices/ directory. Each partition of
the block device is represented as a subdirectory.
n /sys/bus: Each physical bus type is represented by a subdirectory in this
directory. Examples include isa, pci, scsi, and usb. Each bus type has two
subdirectories, devices and drivers. The devices subdirectory contains
entries for every device discovered on that type of bus. These entries are actually
symbolic links pointing to entries in the /sys/devices/ directory. The
drivers directory contains subdirectories for each driver for this bus type
(such as usb, usb-storage, and usbfs for the usb bus).
n /sys/class: This directory contains all device classes that are available. A device
class describes a functional type of device, such as graphics, net, pci_bus.
Again, all entries in these subdirectories are symbolic links to entries in the
/sys/devices directory.
n /sys/devices: The global device hierarchy is contained in this directoryevery
physical device that has been discovered is represented here. Each device is
shown as a subordinate device of the device that it is physically (electrically)
connected to.
n /sys/module: This directory contains subdirectories for each module that is
loaded into the kernel. The name of each directory is the name of the module.
Depending on the module, there are different numbers of files located in the
directory.
To establish the size of the partition /dev/sda2, the following command could be
used:
This partition has a size of 8385930 512-byte blocks (about 4 GB). To see where this
information is actually located, use the command
da10:~ # cat /sys/block/sda/sda2/size
8385930
da10:~ # ls -l /sys/block/sda
Version 1 26
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 3 Describe how udev Works
Before you can use a hardware device, you need to load the appropriate driver
module and set up the corresponding interface. For most devices in SUSE Linux
Enterprise 11, this is done by udev.
In this objective, you learn the following:
n The Purpose of udev on page 26
n How udev Works on page 26
n Persistent Interface Names on page 27
n Modify udev Rules on page 29
The Purpose of udev
udev has three main purposes:
n Create device files: The main task of udev is to create device files under /dev
automatically when a device is connected to the system.
In earlier versions of Linux, the /dev directory was populated with every device
that could possibly appear in the system, even though most of the device files
were actually not used. This led to the /dev directory being very large, complex,
and confusing.
n Persistent device names: udev provides a mechanism for persistent device
names.
n Hotplug replacement: In SUSE Linux Enterprise 11, udev replaces the hotplug
system, which was responsible for the initialization of hardware devices in
previous versions. udev is now the central point for hardware initialization.
How udev Works
udev is implemented as a daemon (udevd), which is started at boot time through the
/etc/init.d/boot.udev script. udev communicates with the Linux kernel
through the uevent interface. When the kernel sends out a uevent message that a
device has been added or removed, udevd does the following, based on the udev
rules:
n Initializes devices.
n Creates device files in /dev.
n Sets up network interfaces with ifup, if necessary.
n Renames network interfaces, if necessary.
n Mounts storage devices which are identified as hotplug in /etc/fstab.
n Informs other applications about the new device.
To handle uevent messages which have been issued before udevd was started, the
udev start script triggers these missed events by parsing the sysfs file system. In
27 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
previous SUSE Linux Enterprise versions, this part of the system initialization was
done by the coldplug script.
Everything that udev does depends on rules defined in configuration files located in
one of the following directories:
n /lib/udev/rules.d/: Files in this directory contain the default rules.
n /etc/udev/rules.d/: Files in this directory contain custom rules.
n /dev/.udev/rules.d/: Files in this directory contain temporary rules.
Rule files are sorted and processed in lexical order, no matter in which of these
directories they are located. Files in /etc/udev/rules.d/ have precedence over
files with the same name in /lib/udev/rules.d/. This can be used to ignore a
default rules file if needed.
A detailed description of udev rules is beyond the scope of this course. In this section,
we will limit our discussion to the following:
n udev rules are spread over several files, which are processed in alphabetical
order. Each line in these files is a rule. Comments can be added with the #
character.
n Each rule consists of multiple key value pairs. An example of a key value pair is
shown below:
kernel==sda
n There are two different key types:
q Match keys: Determine if a rule should be used to process an event.
q Assignment keys: Determine what to do if an event is processed.
There always has to be at least one match and one assignment key in a rule.
n For every uevent, all rules are processed. Processing does not stop when a
matching rule is found.
Persistent Interface Names
The interface files in the /dev directory are created and assigned to the
corresponding hardware device when the device is recognized and initialized by a
driver. Therefore, the assignment between device and interface file depends on:
n The order in which device drivers are loaded.
n The order in which devices are connected to a computer.
This can lead to situations where it is not clear which device file is assigned to a
device. For example, suppose you have two USB devices: a digital camera and a flash
card reader. These devices are accessed as storage devices through the /dev/sdb
and /dev/sdc device files (assuming that /dev/sda is assigned to the hard disk).
Which device is assigned to which device file usually depends on the order in which
they are plugged in. The first device becomes sdb, the second becomes sdc, and so
on. Therefore, in one session, the camera may be /dev/sdb and the card reader /
Version 1 28
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
dev/sdc. In another session, however, the camera may be /dev/sdc and the card
reader /dev/sdb.
udev can help make this process more predictable. With the help of sysfs, udev can
find out which device is connected to which interface file. The easiest solution for
persistent device names would be to rename the interface files, for example from /
dev/sdb1 to /dev/camera.
Unfortunately, interface files can not be renamed under Linux. The only exception to
this rule are network interfaces, which traditionally have no interface files under /
dev.
Therefore, udev uses a different approach. Instead of renaming an interface file, a link
with a unique and persistent name is created to the assigned interface file. By default,
udev is configured to create these links for all storage devices. For each device, a link
is created in each of the following subdirectories under /dev/disk/:
n by-id: The name of the link is based on the vendor and on the name of a
device.
n by-path: The name of the link is based on the bus position of a device.
n by-uuid: The name of the link is based on the serial number of a device.
n by-label: The name of the link is based on the media label.
This means that the association between devices and interface files still depends on
the order in which the drivers are loaded or in which order devices are connected with
the system. With udev, however, persistent links are created and adjusted every time
the device configuration changes.
As mentioned above, network interfaces are treated differently. They do not have
interface files and they can be directly renamed by udev. Persistent network interface
names are configured as udev rules in the /etc/udev/rules.d/70-
persistent-net.rules file. The following is an example:
The matching key in the rule is used to identify a network device by its MAC address.
At the end of the rule, the name of the interface is givenin this example, eth0.
NOTE: In SUSE Linux Enterprise 9 it was possible to configure persistent network interface names
in the interface configuration files in /etc/sysconfig/network. Since SUSE Linux
Enterprise 10 this is no longer supported, because interface names began to be configured in a udev
rule.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:50:56:00:00:37", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth0"
29 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 2-1 Modify udev Rules
In this exercise, you modify a udev rule to rename your Ethernet interface.
The steps for completing this exercise are located in your course workbook.
(End of Exercise)
Version 1 30
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 4 Administer udev
To administer the udev system, the command udevadm is used. The general syntax
of this command is
udevadm <command> [command-options]
Monitoring udev
To monitor udev to see what happens when a new device is activated (such as a USB
stick being plugged in), use the command
udevadm monitor
When a USB device is plugged in, messages like the following are printed:
When the USB device is unplugged, messages like these are printed:
da3:~ # udevadm monitor
monitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent
UEVENT[1243930114.676205] add /devices/pci0000:00/0000:00:1d.7/
usb2/2-3 (usb)
usb2/2-3/2-3:1.0 (usb)
usb2/2-3/2-3:1.0/host8 (scsi)
...
UDEV [1243930115.758311] add /devices/pci0000:00/0000:00:1d.7/
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb (block)
UDEV [1243930115.785893] add /devices/pci0000:00/0000:00:1d.7/
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb/sdb1 (block)
UDEV [1243930115.843017] change /devices/pci0000:00/0000:00:1d.7/
usb2/2-3/2-3:1.0/host8/target8:0:
31 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
More details are available using
udevadm monitor --environment
This prints all environment variables as well:
UEVENT[1243930180.320205] remove /devices/pci0000:00/0000:00:1d.7/
usb2/2-3/2-3:1.0/usb_endpoint/usbdev2.4_ep01 (usb_endpoint)
UDEV [1243930180.320205] remove /devices/pci0000:00/0000:00:1d.7/
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/bsg/8:0:0:0 (bsg)
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/scsi_generic/sg2
(scsi_generic)
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/scsi_device/8:0:0:0
(scsi_device)
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/scsi_disk/8:0:0:0
(scsi_disk)
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb/sdb1 (block)
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/bsg/8:0:0:0 (bsg)
UEVENT[1243930180.321316] remove /devices/virtual/bdi/8:16 (bdi)
usb2/2-3/2-3:1.0/host8/target8:0:0/8:0:0:0/block/sdb (block)
da3:~ # udevadm monitor --environment
monitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent
usb2/2-3 (usb)
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb2/2-3
SUBSYSTEM=usb
MAJOR=189
MINOR=135
DEVTYPE=usb_device
DEVICE=/proc/bus/usb/002/008
PRODUCT=204/6025/100
TYPE=0/0/0
BUSNUM=002
DEVNUM=008
...
Version 1 32
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Messages related to the plugging and unplugging of devices are also written to /
var/log/messages:
When plugging in a USB storage device on SLES 11, the user (if logged into the
graphical interface) is prompted for the root password to have the new device
mounted. On SLED 11, the user is not prompted and the device is mounted into the
file system automatically. This behavior is controlled by a tool called PolicyKit. The
configuration for requesting the root password is located in the file /etc/polkit-
default-privs.restrictive:
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: new high speed USB device
using ehci_hcd and address 8
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: configuration #1 chosen
from 1 choice
Jun 2 10:12:41 linux-tk5h kernel: scsi12 : SCSI emulation for USB
Mass Storage devices
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: New USB device found,
idVendor=0204, idProduct=6025
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: New USB device strings:
Mfr=1, Product=2, SerialNumber=3
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: Product: Flash Disk
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: Manufacturer: CBM
Jun 2 10:12:41 linux-tk5h kernel: usb 2-3: SerialNumber:
161331000B4BB904
...
Jun 2 10:12:42 linux-tk5h kernel: sdb: sdb1
Jun 2 10:12:42 linux-tk5h kernel: sd 12:0:0:0: [sdb] Attached SCSI
removable disk
Jun 2 10:12:42 linux-tk5h kernel: sd 12:0:0:0: Attached scsi generic
sg2 type 0
Jun 2 10:12:42 linux-tk5h kernel: usb-storage: device scan complete
Jun 2 10:12:46 linux-tk5h polkit-grant-helper[5558]: granted
authorization for org.freedesktop.hal.storage.mo
unt-removable to pid 5546 [uid=1000] [auth=root]
Jun 2 10:12:47 linux-tk5h hald: mounted /dev/sdb1 on behalf of uid
1000
Jun 2 10:12:47 linux-tk5h gnome-keyring-daemon[4577]: adding
removable location: volume_uuid_49F0_AC8F at /me
dia/disk
Jun 2 10:13:29 linux-tk5h kernel: usb 2-3: USB disconnect, address 8
Jun 2 10:13:29 linux-tk5h hald[2492]: forcibly attempting to lazy
unmount /dev/sdb1 as enclosing drive was di
sconnected
Jun 2 10:13:29 linux-tk5h gnome-keyring-daemon[4577]: removing
removable location: volume_uuid_49F0_AC8F
Jun 2 10:13:29 linux-tk5h hald: unmounted /dev/sdb1 from '/media/
disk' on behalf of uid 0
...
org.freedesktop.hal.storage.mount-removable auth_admin_keep_always
...
33 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
There is a less restrictive setting available in the file /etc/polkit-default-
privs.standard. Which of these two files is used can be defined in the
POLKIT_DEFAULT_PRIVS variable in /etc/sysconfig/security:
PolicyKit is described in course 3104 SUSE Linux Enterprise Desktop 11
Administration
Querying udev
Using the udevadm info command, information can be requested from udev. The
device for which information is requested has to be specified, for instance by its
name:
This command lists all parameters for the device sdb1.
To get a list of all parameters for the whole device path, the following command
could be used:
POLKIT_DEFAULT_PRIVS="restrictive"
da3:~ # udevadm info --query=all --name=sdb1
P: /devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/host14/
target14:0:0/14:0:0:0/block/sdb/sdb1
N: sdb1
S: disk/by-id/usb-CBM_Flash_Disk_161331000B4BB904-0:0-part1
S: disk/by-path/pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0-part1
S: disk/by-uuid/49F0-AC8F
E: ID_VENDOR=CBM
E: ID_MODEL=Flash_Disk
E: ID_REVISION=5.00
E: ID_SERIAL=CBM_Flash_Disk_161331000B4BB904-0:0
E: ID_SERIAL_SHORT=161331000B4BB904
E: ID_TYPE=disk
E: ID_INSTANCE=0:0
E: ID_BUS=usb
E: ID_PATH=pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0
E: ID_FS_USAGE=filesystem
E: ID_FS_TYPE=vfat
E: ID_FS_VERSION=FAT32
E: ID_FS_UUID=49F0-AC8F
E: ID_FS_UUID_ENC=49F0-AC8F
E: ID_FS_LABEL=
E: ID_FS_LABEL_ENC=
E: ID_FS_LABEL_SAFE=
Version 1 34
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
da3:~ # udevadm info --query=all --name=sdb1 --attribute-walk
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3:1.0/
host14/target14:0:0/14:0:0:0/block/sdb/sdb1':
KERNEL=="sdb1"
SUBSYSTEM=="block"
DRIVER==""
ATTR{start}=="32"
ATTR{size}=="2055136"
ATTR{stat}==" 58 2117 3302 212 1 0 1 4 0 136 216"
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3/
2-3:1.0/host14/target14:0:0/14:0:0:0/block/sdb':
KERNELS=="sdb"
SUBSYSTEMS=="block"
DRIVERS==""
ATTRS{range}=="16"
ATTRS{removable}=="1"
ATTRS{ro}=="0"
ATTRS{size}=="2055168"
ATTRS{capability}=="13"
ATTRS{stat}==" 65 2135 3502 216 1 0 1 4 0 140 220"
...
looking at parent device '/devices/pci0000:00/0000:00:1d.7/usb2/2-3':
KERNELS=="2-3"
SUBSYSTEMS=="usb"
DRIVERS=="usb"
...
ATTRS{speed}=="480"
ATTRS{busnum}=="2"
ATTRS{devnum}=="10"
ATTRS{version}==" 2.00"
ATTRS{maxchild}=="0"
ATTRS{quirks}=="0x2"
ATTRS{authorized}=="1"
ATTRS{manufacturer}=="CBM"
ATTRS{product}=="Flash Disk"
ATTRS{serial}=="161331000B4BB904"
35 Version 1
Manage Hardware
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Describe the sysfs File System sysfs is a virtual file system mounted under /sys/. It
represents all devices and interfaces of a system.
Devices are represented in the directories:
n /sys/bus
n /sys/devices
Interfaces are represented in the directories
n /sys/class
n /sys/block
A device and its interfaces are connected with file
system links.
Describe how udev Works udev has three main purposes:
n Create device files.
n Persistent device names.
n Hotplug replacement.
The start script is /etc/init.d/boot.udev.
udev communicates with the Linux kernel via the
uevent interface.
udev rules are defined in configuration files located in
the /etc/udev/rules.d/ directory
Version 1 36
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
37 Version 1
Configure NFS (Network File System)
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 3 Configure NFS (Network File System)
In this section, you learn how to configure and use Network File System (NFS) on
SUSE Linux Enterprise Server 11.
Objectives
1. Configure NFS (Network File System) on page 38
Version 1 38
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Configure NFS (Network File System)
Network File System (NFS) lets you configure an NFS file server that gives users
transparent access to data and programs files on the server.
To administer NFS successfully, you need to know the following:
n NFS Background on page 38
n NFS Server Configuration on page 41
n NFS Client Configuration on page 47
n Automounter Configuration on page 52
n NFS System Monitoring on page 54
n Set Up and Manage Network File System (NFS) on page 55
NFS Background
In Linux and Unix environments, NFS is a very reliable way to provide users with
file access over the network. As a background to NFS, you need to understand the
following:
n Network File System Basics on page 38
n How NFS Works on page 39
n NFSv4 Features on page 40
n NFS Configuration Overview on page 41
Network File System Basics
NFS is designed for sharing files and directories over a network, and it requires
configuration of an NFS server (where the files and directories are located) and NFS
clients (computers that access the files and directories remotely).
File systems are exported by an NFS server, and they appear and behave on a NFS
client as if they were located on a local machine.
For example, each users home directory can be exported by an NFS server and
imported to a client, so the same home directories are accessible from every
workstation on the network.
Directories like /home/, /opt/, and /usr/ are good candidates for export via
NFS. However, othersincluding /bin/, /boot/, /dev/, /etc/, /lib/, /
root/, /sbin/, /tmp/, and /var/should be available on the local disk only.
Using NFS for home directories makes sense only with a central user management
(for instance OpenLDAP).
39 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following is an example of mounting the directory /home/ (exported by the
NFS Server sun) on the computer earth:
Figure 3-1 NFS
A computer can be both an NFS server and an NFS client. It can supply file systems
over the network (export) and mount file systems from other hosts (import).
The NFS daemon is part of the kernel and only needs to be configured and then
activated. The start script is /etc/init.d/nfsserver. The kernel NFS daemon
includes file locking, which means that only one user at a time has write access to
files.
How NFS Works
NFS is an RPC (Remote Procedure Call) service. An essential component for RPC
services is rpcbind (previously called portmapper) that manages these services and
needs to be started first. The rpcbind utility is activated by default on SUSE Linux
Enterprise Server 11.
When an RPC service starts up, it binds to a port in the system (as any other network
service), but it also communicates this port and the service it offers (such as NFS) to
rpcbind.
Because every RPC program must be registered by rpcbind when it is started, RPC
programs must be restarted each time you restart rpcbind.
Version 1 40
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following lists the services required on an NFS server:
Table 3-1 Services Required by an NFS Server
In SUSE Linux Enterprise Server 11, the NFS lock manager is started automatically
by the kernel. The /sbin/rpc.lockd program starts the NFS lock manager on
kernels that do not start it automatically.
The manual pages for the respective programs contain additional information on their
functionality.
You can use the /etc/init.d/nfsserver command to start the NFS server.
The nfsserver script passes the list of exported directories to the kernel, and then
starts or stops the daemon rpc.mountd and, using rpc.nfsd, the nfsd kernel threads.
The mount daemon (/usr/sbin/rpc.mountd) accepts each mount request and
compares it with the entries in the configuration file /etc/exports. If access is
allowed, the data is delivered to the client.
Because rpc.nfsd can start several kernel threads, the start script interprets the
variable USE_KERNEL_NFSD_NUMBER in the file /etc/sysconfig/nfs. This
variable determines the number of threads to start. By default, four server threads are
started.
NFSv4 support is activated by setting the variable NFS4_SUPPORT to yes in /
etc/sysconfig/nfs.
NFSv4 Features
NFS version 4 comes with several improvements compared to version 3. These
include:
n The mount and lock protocol are now part of the NFS protocol, simplifying
firewall rules for NFS. NFS uses TCP port 2049; UDP is no longer supported.
n Using Kerberos, it is possible to allow access on a per-user basis, not only based
on IP addresses or DNS names as in version 3.
Service Program (daemon) Start Script
rpcbind utility /sbin/rpcbind /etc/init.d/rpcbind
NFS server v3 /usr/sbin/rpc.nfsd
/usr/sbin/rpc.mountd
/usr/sbin/rpc.statd
/etc/init.d/nfsserver
NFS server v4 Same as version 3 plus:
NFSv4 ID <-> name mapping
daemon, /usr/sbin/rpc.idmapd
If encryption is used, /usr/sbin/
rpc.svcgssd (requires Kerberos)
/etc/init.d/nfsserver
41 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
n Encryption is part of the specification. While Secure-RPC allowed encryption
with version 3, it was hardly ever used.
n Additional improvements concern the use of user@computername instead of
numeric IDs to identify users, ACLs, and changes in the way files are locked.
NFS Configuration Overview
The /etc/exports file on the NFS server contains all settings regarding which
directories are exported, how, and to which clients. Client-side configuration is
written to the /etc/fstab file. Both files will be covered in detail later.
Some configuration parameters for the NFS server (for instance, if version 4 and
encryption should be used) are specified in the /etc/sysconfig/nfs file.
Both the NFS server and the clients can be configured with YaST modules. You can
also modify the configuration files directly.
For the NFS server to start automatically when the computer is booted, the
corresponding symbolic links in the runlevel directories must be created. If you
configure the NFS server with YaST, this is done automatically; otherwise, you need
to create them with insserv nfsserver.
NFS Server Configuration
There are several ways you can configure an NFS server:
n Configure an NFS Server with YaST on page 41
n Configure an NFS Server Manually on page 44
n Export a Directory Temporarily on page 46
Configure an NFS Server with YaST
To use YaST to configure the NFS server, start YaST and then select Network
Services > NFS Server. You can also start the NFS Server module directly by
entering yast2 nfs_server in a terminal window as root.
Version 1 42
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following appears:
Figure 3-2 NFS Server Configuration
Select Start in the upper part of the dialog.
The middle part is active only if the firewall is activated. In this case, you can open
the ports necessary for NFS by selecting Open Port in Firewall.
If you want to use NFS version 4, select Enable NSFv4 in the lower part of the
dialog. In this case, you have to enter an NFSv4 domain name, such as your DNS
domain name. If you do not have special requirements, you can use the suggested
localdomain domain.
Checking Enable GSS Security is useful only within an existing Kerberos
infrastructure.
43 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Continue by selecting Next. A Directories to Export dialog appears:
Figure 3-3 NFS Directories to Export
Add a directory to export by clicking Add Directory, typing in or browsing to a
directory, then clicking OK.
The following dialog appears:
Figure 3-4 NFS Export Options
Host Wild Card lets you configure the hosts that should have access to the directory.
You can define a single host, netgroups, wildcards, and IP networks. Under Options,
add options like rw or root_squash for that directory.
For details on the possible host settings, see Configure an NFS Server Manually on
page 44.
Version 1 44
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To add more hosts allowed to access a directory, select the directory and click Add
Host; to edit or delete an existing host entry for a directory, select the directory and
the host entry and click Edit or Delete.
When you finish, save the configuration by clicking Finish.
Configure an NFS Server Manually
You can configure the server from the command line by doing the following:
n Check for service (daemon) availability: Make sure the nfs-kernel-server rpm
package is installed on your NFS server.
n Configure the services to start at bootup: For services to be started by the /
etc/init.d/rpcbind and /etc/init.d/nfsserver scripts when the
system is booted, enter the following commands:
insserv rpcbind (activated by default)
insserv nfsserver
n Define exported directories in /etc/exports: For each directory to export, one
line is needed to define which computers can access that directory with what
permissions. All subdirectories of this directory are automatically exported as
well.
The following is the general syntax of the /etc/exports file:
directory [host[(option1,option2,option3,...)]] ...
Do not put any spaces between the hostname, the parentheses enclosing the
options, and the option strings themselves.
A host can be one of the following:
q A standalone computer with its name in short form (it must be possible to
resolve this with name resolution), with its Fully Qualified Domain Name
(FQDN) or its IP address.
q A network, specified by an address with a netmask, or by the domain name
with a prefixed placeholder (such as *.digitalairlines.com).
Authorized computers are usually specified with their full names (including
domain name), but you can use wildcards like * or ?.
If you do not specify a host or use *, any computer can import the file system
with the given permissions.
n Set permissions for exported directories in /etc/exports: You need to set
permission options for the file system to export in parenthesis after the computer
name. The most commonly used options include the following:
45 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Table 3-2 NFS Export Options
Option Meaning
bind=/path/directory This is an NFS Version 4 option. On the server, this
directory is mounted with the exported directory as mount
point using the bind mount option. On the client, the
content of the directory specified after bind= appears in
the exported directory within the pseudo-root directory
tree.
crossmnt This is an NFS Version 4 option. If you use the bind=/
path/directory option, the option crossmnt needs to
be added to the line that contains the fsid=0 option.
Without it, NFSv4 does not cross file systems.
fsid=0 This is an NFS Version 4 option. In version 4, the client is
presented with one seamless directory tree. The option
fsid=0 (or fsid=root, which is equivalent) indicates
that this exported directory is the pseudo-root of that
directory tree.
no_root_squash Does not assign user ID 65534 to user ID 0, keeping the
root permissions valid.
no_subtree_check (Default since version 1.1.0 of nfs-utils) No subtree_check
is performed.
If you specify neither subtree_check nor
no_subtree_check, a message informs you when
starting the NFS server that no_subtree_check is used.
ro File system is exported with read-only permission (default).
root_squash (Default) This ensures that the root user of the client
machine does not have root permissions on this file
system. This is achieved by assigning user ID 65534 to
users with user ID 0 (root). This user ID should be set to
nobody (which is the default).
rw File system is exported with read-write permission. The
local file permissions are not overridden.
subtree_check If a subdirectory of a file system is exported, but the whole
file system is not, then whenever an NFS request arrives,
the server must check not only that the accessed file is in
the appropriate file system but also that it is in the exported
tree. This check is called subtree check.
sync Reply to requests only after the changes have been
committed to stable storage (this is the default, but if
neither sync or async are specified, a warning appears
when starting the NFS server).
Version 1 46
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following is an example of an edited /etc/exports file for NFS version 3 that
includes permissions:
#
# /etc/exports
#
/home da10(rw,sync,no_subtree_check) \
da20(rw,sync,no_subtree_check)
/srv/ftp *(ro,sync,no_subtree_check)
Whenever you want to specify different permissions for a subdirectory (such as /
home/geeko/pictures/) from an already exported directory (such as /
home/geeko/), the additional directory needs its own separate entry in /etc/
exports.
The following is an example of an edited /etc/exports file for NFS version
4 that includes permissions:
#
# /etc/exports
#
/export *(fsid=0,crossmnt,rw,sync,no_subtree_check)
/export/data *(ro,sync,no_subtree_check,bind=/data)
The /export and /data directories are separate on the server, whereas on the
client, the content of both directories appears within one directory structure. If,
for example, the client mounts the pseudo-root directory on /imports, the
content of /data from the server appears in /imports/data on the client.
n Reload the configuration: The /etc/exports is read by mountd and nfsd. If
you change anything in this file, you need to reload the configuration for your
changes to take effect. You can do this by entering rcnfsserver reload
(rcnfsserver restart works as well).
Export a Directory Temporarily
You can export a directory temporarily (without editing the file /etc/exports) by
using the exportfs command:
For example, to read-only export the /software directory to all hosts in the
network 192.168.0.0/24, you would enter the following command:
exportfs -o ro,root_squash,sync 192.168.0.0/24:/software
To restore the original state, all you need to do is enter the command exportfs -
r. The /etc/exports file is reloaded and any directories not listed in the /etc/
exports file are no longer exported.
After adding directories to export in the /etc/exports file, exportfs -a
exports the additional directories.
The directories that are currently exported are listed in the /var/lib/nfs/etab
file. The content of this file is updated when you use the command exportfs.
47 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NFS Client Configuration
There are two ways you can configure NFS clients:
n Configure NFS Client Access with YaST on page 47
n Configure NFS Client Access from the Command Line on page 49
Configure NFS Client Access with YaST
NFS directories exported on a server can be mounted into the file system tree of a
client. The easiest way to do this is to use the YaST NFS Client module.
To use YaST to configure the NFS client, start the YaST Control Center and then
select Network Services > NFS Client. You can also start the NFS Client module
directly by entering yast2 nfs in a terminal window as root.
The NFS Client Configuration dialog appears:
Figure 3-5 NFS Client Configuration, NFS Shares
Version 1 48
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Add a directory to the list by clicking Add. The following appears:
Figure 3-6 NFS Client Configuration, Add Directory
From this dialog, you can configure how the directory exported on the server is
mounted in your file system tree. Configure the directory by doing the following:
1. Enter the NFS servers hostname, or find and select the NFS server from a list of
NFS servers on your network by selecting Choose.
2. In the Remote Directory field, type the directory exported on the NFS server
you want to mount, or find and select the available directory by selecting Select.
For directories exported using NFSv4, you have to specify the directory relative to
the NFSv4 pseudo-root directory, not the actual path on the server as with NFSv3.
Provided the server exported the pseudo-root directory with the option crossmnt,
subdirectories exported on the server are accessible within the exported tree; they do
not need to be mounted separately.
1. In the Mount Point (local) field, type the mount point in your local file tree to
mount the exported directory, or browse to and select the mount point by
selecting Browse.
2. Select NFSv4 Share if applicable.
3. In the Options field, type any options you would normally use with the mount
command.
For a list of general mount options, in a terminal window enter man 8 mount;
for a list of nfs-specific mount options, enter man 5 nfs.
4. When you finish configuring the directory, select OK.
You are returned to the NFS client configuration dialog.
49 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The NFS Client Configuration dialog also offers an NFS Settings tab:
Figure 3-7 NFS Client Configuration, NFS Settings
Here you can set the NFSv4 Domain Name and open the ports needed for NFS in the
firewall.
Save the NFS client settings by clicking OK. The settings are saved and the exported
directories are mounted in your local file system tree.
Configure NFS Client Access from the Command Line
To configure and mount NFS directories, you need to know how to do the following:
n Import Directories Manually from an NFS Server on page 49
n Mount NFS Directories Automatically on page 51
Import Directories Manually from an NFS Server
You can import a directory manually from an NFS server by using the mount
command. The only prerequisite is a running rpcbind (portmapper), which you can
start by entering (as root) rcrpcbind start.
The mount command automatically tries to recognize the file system (such as ext2,
ext3, or ReiserFS). However, you can also use the mount option -t to indicated the
Version 1 50
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
file system type. For NFS version 3 and earlier, the file system type is nfs; for NFS
version 4, it is nfs4.
In the following example, the file system type nfs is specified:
mount -t nfs -o options host:/directory /mountpoint
Instead of a device file, the name of the NFS server together with the directory to
import is used within the command.
The following are the most important mount options (-o) used with NFS:
n soft (opposite: hard): If the attempt to access the NFS server extends beyond the
default number of tries (or the value set with the retrans= option), the mount
attempt will be aborted.
If the hard option (or neither soft nor hard) is specified, the client attempts to
mount the exported directory until it receives feedback from the server that the
attempt was successful.
If a system tries to mount an NFS file system at boot time, the hard option can
cause the boot process to hang because the process will stop at this point when it
attempts to mount the NFS directory.
For directories that are not essential for the system to function, you can use the
soft option. For directories that must be mounted (such as home directories), you
can use the hard option.
n bg (default: fg): If you use the bg option, and the first attempt is unsuccessful,
all further mount attempts are run in the background.
This prevents the boot process from hanging when NFS exports are
automatically mounted, with attempts to mount the directories continuing in the
background.
n rsize=n: Lets you set the number of bytes (n, positive integral multiple of 1024,
maximum 1,048,576) that NFS reads from the NFS server at one time.
If this value is not set, the client and server negotiate the highest possible value
that they both support.
The negotiated value is shown in /proc/mounts.
n wsize=n: Lets you set the number of bytes (n, positive integral multiple of 1024,
maximum 1,048,576) that can be written to the NFS server.
If this value is not set, the client and server negotiate the highest possible value
that they both support.
The negotiated value is shown in /proc/mounts.
n retry=n: Lets you set the number of minutes (n) an attempt can take to mount a
directory through NFS. The default value for foreground mounts is two minutes;
for background mounts it is 10000 minutes (approximately one week).
n nosuid: Lets you disable any interpretation of the SUID and SGID bits on the
corresponding file system.
51 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
For security reasons, always use this option for any file system that might be
susceptible to tampering.
If you do not use this option, there is a possibility that a user can obtain root
access to the local file system by putting a SUID root executable on the imported
file system.
n nodev: Lets you disable any interpretation of device files in the imported file
system. We recommend that you use this option for security reasons.
Without setting this option, someone could create a device such as /dev/sda on
the NFS export, then use it to obtain write permissions for the hard disk as soon
as the file can be accessed from the client side.
n exec (opposite: noexec): Lets you permit or disallow the execution of binaries
on the mounted file system.
You can use the umount command to unmount a file system. However, you can do
this only if the file system is currently not being accessed.
NOTE: For additional information on nfs, mount options, and the /etc/fstab file, in a terminal
window enter man 5 nfs, man 8 mount, or man 5 fstab.
Mount NFS Directories Automatically
To mount directories automatically when booting (such as the home directories from
a file server), you need to make corresponding entries in the /etc/fstab file.
When the system is booted, the /etc/init.d/nfs start script loads the /etc/
fstab file, which indicates which file systems are mounted, where, and with which
options.
The following is an example of an entry for an NFS mount point in the /etc/
fstab file:
da1:/training/home /home nfs soft,noexec 0 0
In this entry, the first value indicates the hostname of the NFS server (da1) and the
directory it exports (/training/home/).
The second value indicates the mount point, which is the directory in the local file
system where the exported directory should be attached (/home/).
The third value indicates the file system type (nfs). The comma-separated values
following the file system type provide NFS-specific and general mounting options.
At the end of the line, there are two numbers (0 0). The first indicates whether to
back up the file system with the help of dump (1) or not (0). The second number
configures whether the file system check is disabled (0), done on this file system with
no parallel checks (1), or parallelized when multiple disks are available on the
computer (2).
In the example, the system does neither, as both options are set to 0.
Version 1 52
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
After modifying an entry of a currently mounted file system in the /etc/fstab
file, you can have the system read the changes by entering mount -o remount /
mountpoint. To mount all file systems that are not currently mounted and do not
contain the noauto option, enter mount -a. (noauto is used with devices that
are not automatically mounted, like floppy disks.)
Automounter Configuration
When you use the method described in NFS Client Configuration on page 47 to
mount home directories, all home directories on the server are visible on the client
machines. This can make it quite hard for a user to find his own home directory. With
the automounter, only the directory needed by a user is mounted.
Another advantage of the automounter is the reduced number of actual mounts on the
server, as only those directories get mounted by clients that are actually needed.
Unlike with a static configuration in the /etc/fstab file, with the automounter,
directories are mounted automatically when needed and unmounted automatically
when not in use for some time.
The kernel-based automounter is contained in the autofs package which is part of the
default installation.
In the past, the automounter was also used to mount and unmount CD-ROMs;
however, this functionality is now integrated into the KDE or Gnome desktop
environments. The automounter remains very useful to mount and unmount
directories that are exported by file servers.
The automounter configuration consists of the general /etc/auto.master file
and files that are referenced within /etc/auto.master, such as /etc/
auto.home.
To mount the home directories exported from another server, you need the following
entry in the /etc/auto.master file:
/home /etc/auto.home
The first column lists the mount point and the second column lists the file that
contains the configuration details for this mount point.
The /etc/auto.home file could look like the following (for NFSv4 fstype would
be nfs4):
geeko -fstype=nfs,rw da1.digitalairlines.com:/home/geeko
As soon as some process accesses the local /home/geeko directory (the entry in
the first column, geeko, is appended to the directory given in the first column in the
/etc/auto.master file, /home), the local /home/geeko directory is created
and the /home/geeko directory from the server (last column) is mounted. After
some time or when the automounter is stopped, the remote directory is unmounted
and the mount point (/home/geeko in the example above) is deleted.
With several users, you would need an entry for each user. This is cumbersome, but
might be your only choice if home directories reside on several servers.
53 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
As long as all users have their home directories on one server, the automounter allows
you to simplify the configuration with the use of wildcards, as shown in the
following:
* -fstype=nfs,rw da1.digitalairlines.com:/home/&
The * in the first column denotes any directory below /home. The & in the last
column is replaced by whatever directory is accessed.
When the automounter configuration is complete, you start the automounter with
rcautofs start. To stop the automounter, use rcautofs stop. The
chkconfig autofs on command ensures the automounter is started
automatically when the system boots.
The following commands highlight how the automounter works:
When using NFS to import home directories, it is advisable to also use a network-
based user database, like NIS or LDAP. This ensures that a user has the same UID no
matter where he logs in within the network.
Instead of local map files, it is also possible to use NIS (Network Information
System) or LDAP to distribute the automounter information.
da10:~ # rcautofs start
Starting automount da10:~ # ls /home/
da10:~ # mount
...
(no automounts)
da10:~ # ls /home/geeko
.bash_history Documents .gnome2 ...
merkur2:~ # mount
...
da1.digitalairlines.com:/home/geeko on /home/geeko type nfs
(rw,nosuid,nodev,sloppy,addr=10.0.0.254,nfsvers=3,
proto=tcp,mountproto=udp)
Version 1 54
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NFS System Monitoring
Some tools are available to help you monitor the NFS system.
Enter rpcinfo -p to display information about rpcbind (portmapper). The option
-p displays all the programs registered with the portmapper, similar to the following:
The NFS server daemon registers itself to the portmapper with the name nfs. The
NFS mount daemon uses the name mountd.
You can use the showmount command to display information about the exported
directories of an NFS server.
showmount -e da1 displays the directories exported on the machine da1. The
option -a shows which computers have mounted which directories.
da10:~ # rpcinfo -p
program vers proto port service
100000 4 tcp 111 portmapper
100000 4 udp 111 portmapper
100005 1 udp 42763 mountd
100005 1 tcp 49450 mountd
100005 2 udp 42763 mountd
100005 2 tcp 49450 mountd
100005 3 udp 42763 mountd
100005 3 tcp 49450 mountd
100024 1 udp 41731 status
100024 1 tcp 53770 status
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 46880 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 53206 nlockmgr
55 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 3-1 Set Up and Manage Network File System (NFS)
In the first part of this exercise, you create a directory named /export/
documentation, copy documents from /usr/share/doc/manual/ into it,
and export it to others using NFS.
In the second part, you create a directory named /import/docs and use it as
mount point to import the /export/documentation directory from your own
server using NFS. Create an /etc/fstab entry to mount the directory
automatically at boot time.
You wil find this exercise in the workbook.
(End of Exercise)
Version 1 56
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Configure NFS (Network File
System)
Network File System (NFS) lets you configure an NFS
file server that gives users transparent files access over
the network.
Directories to export are specified in /etc/exports. NFS
is an RPC-based service and thus needs the
portmapper (rpcbind) to function properly.
/etc/init.d/nfsserver is the script to start the
NFS server.
Directories from other servers can be imported using
the mount command or during boot according to
entries in the /etc/fstab file.
57 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 4 Configure and Use OpenLDAP
In this section, you learn how to configure the OpenLDAP service on a SLES 11
server and configure it to store user accounts.
Objectives
1. Describe How LDAP Works on page 58
2. Install and Configure OpenLDAP on SLES 11 on page 72
3. Add, Modify, and Delete Entries to the LDAP Directory Tree on page 91
Version 1 58
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Describe How LDAP Works
Before learning how to set up OpenLDAP on your server, you first need to
understand what LDAP is and how it works. In this objective, the following topics are
addressed:
n How Directory Services Work on page 58
n What is LDAP? on page 63
n How the LDAP Directory Tree Is Structured on page 63
How Directory Services Work
Most people are familiar with directory services, such as a telephone directory.
Telephone companies provide a directory of their subscribers names, addresses, and
phone numbers that allows telephone service users to easily contact each other.
All the contact information is in one placethe phone book, which organizes the
information in alphabetical order.
Similarly, a network Directory service provides the location of network resources.
This allows network service users and administrators to easily connect to and use or
manage these network resources.
To understand the need for LDAP (Lightweight Directory Access Protocol), you first
need to understand that by default your Linux system stores its user and group
information locally in the file system.
For example, your user accounts are stored as plain text in the /etc/passwd file. A
section of it is shown below:
wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
geeko:x:1000:100:Geeko Novell:/home/geeko:/bin/bash
tux:x:1001:100:Tux Novell:/home/tux:/bin/bash
Each line represents one user record. Each record is composed of several fields
separated by colons (:).
Your users passwords are not stored in the passwd file. Instead, they are stored in
encrypted format in the /etc/shadow file. The corresponding section of the
shadow file for the passwd file from the example above is shown below (password
hashes are shortened):
wwwrun:*:14306::::::
geeko:$2a$05$Eso3tbJJXTVAjUdRk0L9DODn/pgleI...xyz:14309:0:99999:7:::
tux:$2a$05$mNcSSMBMxF3eZayvZxtyH.RZZjC1WkO/...def:14309:0:99999:7:::
Likewise, your groups are saved in the /etc/group file, as shown below:
trusted:x:42:
tty:x:5:
utmp:x:22:
uucp:x:14:
uuidd:!:104:
59 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
video:x:33:geeko,tux
wheel:x:10:
www:x:8:
xok:x:41:
users:x:100:
As with the passwd file, each line in the group file represents one group record. The
record is composed of several fields separated by colons (:).
Storing your user and group information in the local file system has many
advantages. Its easy to manage and can be secured using file system access controls.
However, storing your user and group information locally also has several
drawbacks. Consider the following:
n The passwd, shadow, and group files store information in a flat format. User and
group accounts cant be organized into a hierarchy that reflects your
organizations geographic locations or functional arrangement.
n The files are stored in the local file system. If you have multiple servers and
workstations in your network and want to use the same users, groups, and
passwords, then you must synchronize these files to all of the other systems.
For years, this has been done by configuring the Network Information Service
(NIS) on your systems. You set up a NIS server that serves as a central repository
for all configuration information.
Other systems are set up as NIS clients that receive user, group, and
configuration information from the NIS server.
This solution functions well. However, it works only with Linux/UNIX systems.
If you have a heterogeneous network with multiple operating systems and a
variety of network services, you cant use NIS to distribute configuration
information.
A better solution would be to configure a centralized repository of user, group, and
configuration information on your network that allows the following:
n A single-point of administration: You need to be able to configure your user
and group information in one location and have it automatically applied to all
systems in your network
n A hierarchical structure: Instead of storing users and groups in an unordered
flat file, you need to be able to organize your information into a hierarchy
grouped and nested according to geographic location, organization, department,
team, and/or function.
n Support for multiple operating systems: The central repository of user and
group information should be compatible with multiple operating systems.
n Support for many types of information: The central repository should be
extensible such that it can store information other than just users and groups.
For example, network services running on servers in your network, such as DNS
and DHCP, should be able to store their configuration information in the central
repository instead of in a file in the local file system.
Version 1 60
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
This allows you to quickly replace a service if its host server goes down. All you
have to do is reinstall the service on a different server and point it to the existing
configuration information in the central repository.
n Support for replication: To prevent the creation of a single point of failure, the
central repository should be able to replicate its information to other servers in
the network. That way, if the server goes down, other servers can handle
information requests.
This is shown in the figure below:
Figure 4-1 Using a Central Repository of User and Group Information
In short, you need to ensure your crucial network information is organized and easily
accessible. This can be done using a Directory service that stores information in a
well structured, quickly searchable form.
All the network resource information is in one placethe Directory tree, which
organizes the physical network into a logical network representation.
A Directory is a compilation of services that provide discovery, security, storage, and
relationship management. A Directory does the following:
n Enables access to resources on the entire network and not just specific servers
n Provides secure access to network resources
n Provides a scalable, indexed, and cacheable database (for performance)
n Manages relationships between Directory entities, such as users and the
resources they access
61 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
With the global direction of the modern economy and current business practices, it is
logical and necessary that Directories, at least in their basic structural form, adhere to
certain standards.
X.500 is an International Organization for Standardization (ISO) and International
Telecommunication Union (ITU) standard that globally defines how Directory
services ought to be structured at the basic level.
To effectively understand and manage a Directory in your network, you need to
understand the components of the X.500 Directory. The following figure illustrates
the components of the X.500 Directory:
Figure 4-2 The X.500 Directory Model
The X.500 Directory standard includes seven essential components:
n Directory Information Database (DIB) on page 61
n Directory Information Tree (DIT) on page 62
n Directory User Agent (DUA) on page 62
n Directory System Agent (DSA) on page 62
n Directory Access Protocol (DAP) on page 62
n Directory System Protocol (DSP) on page 63
n Directory Information Shadowing Protocol (DISP) on page 63
Directory Information Database (DIB)
A Directory is made up of objects that represent physical resources in the real world,
such as users. Collectively, these objects are known as the Directory Information
Database (DIB).
Each object, or entry, in the DIB has a distinguished name that uniquely identifies it.
Each entry consists of one or more attributes and each attribute has a value.
DIB
DSA
DSA
DIB
DSA
DSA
DIB
DSA
DSA
DIB DIB
Directory Information
Base (DIB)
DSA
DSA
DIB
D
i
r
e
c
t
o
r
y

S
y
s
t
e
m
P
r
o
t
o
c
o
l

(
D
S
P
)
DSA
DSA
DIB
DSA
DSA
DSA
DIB
DSA
DSA
DIB
Directory Information
Shadowing Protocol (DISP)
DSA
DSA
DIB
DSA
DSA
DSA
DIB
DSA
DSA
DSA
Directory
System Agent
(DSA)
Directory User Agent
(DUA)
D
i
r
e
c
t
o
r
y

A
c
c
e
s
s
P
r
o
t
o
c
o
l

(
D
A
P
)
Directory Information Tree (DIT)
DSA
DSA
DSA
Version 1 62
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Directory Information Tree (DIT)
The Directory Information Tree (DIT) is a tree structure that logically represents and
describes the collection of objects and the relationship of information in the DIB.
The objects are contained in a hierarchical arrangement in this tree structure. For
example, a person (object/entry) works for a company (object/entry) that is located
within a country (object/entry).
To keep the Directory organized, a set of rules is enforced to ensure that the DIB
remains stable and intact as modifications are made to it over time.
These rules are known as the Directory schema. They prevent entries from having
wrong attribute types and prevent objects from being a member of the wrong object
class.
Directory User Agent (DUA)
The X.500 specification uses a client/server approach in communicating information.
The client interacts with a server to perform specific Directory operations.
The Directory User Agent (DUA), acting as the client, is an application process that
represents each user accessing the Directory. Users are people or programs that can
read, modify, or search the Directory.
The DUA requests information from the Directory and then relays that information to
the user or program.
Directory System Agent (DSA)
The Directory System Agent (DSA) is the server side of the client/server relationship.
The DSA takes a request from a DUA, services the request, and sends replies to the
DUA. If it doesnt have the requested information, it will pass the request on to
another DSA.
The DSA consists of many different pieces, including components that communicate
with other DSAs on behalf of a DUA and components that are responsible for
replication of data between DSAs.
Directory Access Protocol (DAP)
The Directory Access Protocol (DAP) is the protocol that a DUA uses when it
communicates with a DSA to make a request of the DSA. The APIs used to access
eDirectory as well as the Lightweight Directory Access Protocol (LDAP) are
examples of a DAP.
63 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Directory System Protocol (DSP)
If a DSA cannot fulfill the request of a DUA, the DSA passes the request to another
DSA. The Directory System Protocol (DSP) provides the communication between
the two DSAs.
Directory Information Shadowing Protocol (DISP)
The DIB should be replicated to other DSAs. This improves the performance of
requests made to the Directory and provides fault tolerance with a secondary (or
backup) copy of the DIB.
In eDirectory, the process of distributing the DIB is called replication; in the X.500
specification, it is called shadowing. The Directory Information Shadowing Protocol
(DISP) performs the actual exchange of replicated information between DSAs.
In summary, directories are designed to
n Store small amounts of data that doesnt change frequently.
n Provide fast searching capabilities.
n Provide fast read operations.
n Provide cross-platform application support.
n Replicate information between Directory servers.
n Control access to Directory information.
What is LDAP?
Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to
access and maintain information in a Directory. An LDAP Directory can be used to
store many types of information including user, group, and service configuration
settings.
LDAP is a standardized open protocol, which ensures that many different client
applications can access the information stored in the Directory.
While there are a variety of LDAP-compliant directories that you could implement on
a Linux server (including Novell eDirectory), were going to focus on OpenLDAP in
this section.
How the LDAP Directory Tree Is Structured
An LDAP Directory uses a hierarchical tree structure. All entries (called objects) in
the Directory have a defined position within its hierarchy.
The complete path from the root of the tree to a particular entry, including the entrys
name, is called its distinguished name or DN. The DN uniquely identifies an object in
the Directory tree.
Version 1 64
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To designate an entry relative to some point in the tree (not from the root of the tree),
the objects relative distinguished name or RDN is used. Objects can be categorized
into one of two possible types:
n Container objects: Container objects can contain other objects. They are like
branches within the Directory tree. Container object classes include the
following:
q root: The root element of the Directory tree. In LDAP, there is no actual
object that represents the tree root.
NOTE: The tree root is also called the root entry.
q dc (dcObject): Represents an element of your domain. It can represent any
part of a domain name. For example, dc=digitalairlines,dc=com.
q c (country): Represents a country. For example, c=US.
q o (organization): Represents an organization. For example, o=DA.
q ou (organizationalUnit): Represents a division, department, team, or other
functional group within an organization.
n Leaf objects: Leaf objects are like leaves at the end of tree branches. They have
no subordinate objects. Leaf objects usually represent a physical network
resource. Examples include the following:
q InetOrgPerson: Represents a single user.
q groupofNames: Represents a group.
Unlike a real tree, a Directory tree is inverted. The top of the Directory tree is the tree
root. The bottom of the tree are the leaf objects. The tree root can contain one of the
following objects:
n c (country)
n dc (domain component)
n o (organization)
There are two commonly used tree strategies for defining the top of the Directory
tree.
The first uses domain component objects to define the top of the tree hierarchy.
Beneath the domain components are organizational units that define logical
groupings of Directory objects. Consider the following example:
65 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-3 Using Domain Components to Define the Top of the Tree
Notice in the figure above that dc=digitalairlines,dc=com together defines the top
layer of the tree hierarchy, not dc=com by itself.
Alternatively, you could also define the top of the tree hierarchy using country
(optional), organization, and organizational unit objects. If desired, you can create a
country object at the top of the tree and then create one or more organization objects
within the country object. You can also omit the country object and simply create an
organization object at the top of the tree.
An example of this tree design is shown in the figure below:
Figure 4-4 Using an Organization Object to Define the Top Layer of the Tree
Either strategy is acceptable. Generally speaking, administrators who have prior
experience with Microsoft Active Directory tend to favor using domain components
at the top of an OpenLDAP Directory tree.
NOTE: The use of domain components is the default structure used by OpenLDAP.
Those coming from a Novell eDirectory background tend to favor using organization
objects at the top of the tree.
Version 1 66
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When working with an LDAP Directory, you need to be familiar with the following
concepts:
n Objects on page 66
n Context on page 70
n Naming on page 70
Objects
First, you need to be familiar with the schema. The schema defines the types of
objects that can be created in your tree (such as organizationalUnit, inetOrgPerson,
and groupOfNames) and what information is required or optional at the time the
object is created.
An object (also referred to as an entry) is a unit of information about a resource,
comparable to a record in a conventional database. Different types or categories of
objects exist. An object can represent a resource (such as a user or group), service
configuration information (such as DNS records), or an organizational element (such
as a team or department).
Several sample objects are shown in the figure below:
Figure 4-5 Sample LDAP Objects
Directory objects are defined by properties and values. A property (also referred to as
an attribute) is a category of information associated with an object. Each Directory
object consists of properties that can be used to store information about the resource.
A collection of properties defines or makes up the class of an object. For example, a
groupOfNames object differs from an inetOrgPerson object in the properties it
contains and, therefore, in how the object can be used. Object classes and properties
are defined and controlled by the schema.
A value, on the other hand, is the data contained by a specific property. For example,
an inetOrgPerson object has a property called givenName, which in turn has a value,
such as Geeko.
67 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The properties and values of the Geeko inetOrgPerson object is shown in the
following figure:
Figure 4-6 inetOrgPerson Properties and Values
Version 1 68
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The attributes and values of a groupOfNames object named Research are shown in
the following figure:
Figure 4-7 groupOfNames Object Properties and Values
Finally, the properties and values that comprise the people organizationalUnit object
are shown in the following figure:
69 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-8 organizationalUnit Object Properties and Values
Notice in the above figures that not all of the object properties are populated with
values. Some properties are mandatory, such as objectClass or uid, but others are
optional. The schema defines which properties are required and which are optional.
When creating an object, you must supply values for all mandatory properties;
otherwise, you wont be allowed to create the object.
The schema also defines the rules of containment, which specify which containers
can contain which object types.
A schema, therefore, must contain definitions of all object classes and attributes used
in the desired application scenario. There are several common schemas (described in
RFC 2252 and 2256). The LDAP RFC also defines a few commonly used Schemas
(RFC 4519). Additionally there are Schemas available for many other applications
(such as Samba, NIS, DNS, and DHCP).
It is, however, possible to create a custom schema or to use multiple schemas
complementing each other if this is required by the environment the LDAP server
operates in.
Version 1 70
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Context
Context can be defined as an objects position in the LDAP Directory tree. It is a list
of container objects leading from the object to the root of the tree. Locating an object
through the context is similar to locating a file using the directory path.
An LDAP tree cannot have multiple leaf objects with the same name in the same
container. However, a tree can have multiple leaf objects with the same name in
different containers because their context is different.
For example, in the following figure, the difference between the two BJohnson user
objects is their context. The user object on the left is in the SLC organizational unit;
the user object on the right is in the DA organization.
Figure 4-9 Understanding Context
The context for the BJohnson object on the left is ou=SLC,o=DA. The context for the
BJohnson object on the right is o=DA.
Naming
LDAP uses naming conventions to allow you to precisely identify and locate objects
in your tree. You must provide enough information to locate the object in the tree, and
you specify this information in the object name.
For example, in the preceding figure, two user objects named BJohnson exist in
separate containers in the tree. If you log in as BJohnson, which user object should be
used?
An object name identifies an object in the tree. So, in the figure above, the exact
names are different because their object names contain information that identifies
their location in the tree.
The name of each object you create in the tree consists of the following:
n Name attribute type
n Name value
The attribute type of the object name determines if the object will be accessed as a
container or leaf object in the tree. The value of the object is the name you enter for
the object when you create it.
DA
SLC
BJohnson
BJohnson
Login BJohnson?
71 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following name attribute types are assigned to the most common objects:
n c: Country (for example, c=IR for Ireland)
n o: Organization name (for example, o=DA)
n ou: Organizational unit name (for example, ou=SLC)
n cn: Common name of leaf objects (for example, cn=BJohnson)
An objects distinguished name (DN) is a combination of its common name and its
context. This identifies the object all the way to the top, or root, of the tree. An object
is exactly identified with a distinguished name. Two objects in the same tree cannot
have the same distinguished name.
The objects in the name are separated by commas. The names of all objects, from the
tree object to the object being named, are included in the distinguished name.
In the figure below, the distinguished name for the user object BJohnson in the
organizational unit SLC in the organization DA is cn=BJohnson,ou=SLC,o=DA. The
distinguished name for the user object BJohnson in the organization DA is
cn=BJohnson,o=DA.
Figure 4-10 Distinguished Names
A relative distinguished name (RDN), on the other hand, lists the path of objects
leading from the object being named to the container representing the current context,
or current location, in the tree.
For example, if your current context is O=DA, you could refer to each BJohnson user
object as listed below:
n cn=BJohnson
n cn=BJohnson,ou=SLC
When you use a relative distinguished name, LDAP must build a distinguished name
from it. This is accomplished by appending the relative distinguished name to the
current context:
RDN + Current Context = DN
DA
SLC
BJohnson
BJohnson
Login BJohnson?
Version 1 72
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Install and Configure OpenLDAP on SLES 11
With this conceptual information about LDAP in mind, you are now ready to install
and configure an LDAP server on SLES 11. The following topics are addressed in
this objective:
n Install and Configure the LDAP Server on page 72
n Install and Configure the LDAP Client on page 81
Install and Configure the LDAP Server
The first task you need to complete is to install the LDAP service on your SLES 11
server. To do this, complete the following:
1. In YaST, select Network Services > LDAP Server.
2. If the openldap package has not been installed on your server, you will be
prompted to install it.
If you are prompted to install the package, select Install.
When complete the following is displayed:
Figure 4-11 Configuring General LDAP Server Settings
3. In the General Settings screen, configure the following:
a. Under Start LDAP Server, select Yes to start the service.
73 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
b. If you want the LDAP server to register itself with an SLP Service Agent,
select Register at an SLP Daemon.
c. If your servers host firewall is enabled, select Open Port in Firewall.
4. Select Next.
The following screen is displayed:
Figure 4-12 Configuring LDAP Server TLS Settings
You use the TLS Settings screen to enable encryption for your LDAP
transmissions. Transport Layer Security (TLS) is a cryptographic protocol
derived from Secure Sockets Layer (SSL). It is used to encrypt data
transmissions between network hosts at the Transport layer of the OSI model.
5. Under Basic settings, enable encryption using TLS by configuring the following:
a. Verify that Enable TLS is selected.
If this option is selected, you also need to specify the certificate the server
should use for encryption.
b. Verify that Enable LDAP Over SSL (ldaps) Interface is selected.
This enables the LDAP server to accept ldaps connections on port 636.
NOTE: Clear-text LDAP communications use port 389. Secure LDAP communications
occur on port 636.
c. Verify that Use Common Server Certificate is selected.
Version 1 74
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
This certificate was created when SLES 11 was initially installed. If you
want the LDAP server to use a different certificate, specify the appropriate
file names in the CA Certificate File, Certificate File, and Certificate Key
File fields.
NOTE: If the Use Common Server Certificate option is greyed out, click the Launch
CAManagement Module Button and create a CA and a common server certificate.
6. Select Next.
The Basic Database Settings screen is displayed:
Figure 4-13 Configuring LDAP Database Settings
7. Configure your database settings by doing the following:
a. In the Database Type field, select the database you want to use. You can
select from the following:
n bdb: Configures the Berkeley Data Base as the LDAP servers backend.
n hdb (default): Configures the Hierarchical Berkeley Data Base as the
LDAP servers backend. The hdb database is a variant of the bdb
database that uses a hierarchical database layout.
b. For the Base DN, use the default root entry or define a new one.
By default, the Base DN field is populated with your domain name defined
by domain component objects. This will be your root entry of your LDAP
Directory tree.
75 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
For example, in the figure above, the root element is
dc=digitalairlines,dc=com.
c. In the Administrator DN field, enter the cn of your LDAP super user.
By default, cn=Administrator is entered.
d. Next to the Administrator DN field, verify that Append Base DN is selected.
This will place your super user at the root of the tree.
In the example above, selecting this box would yield an administrator DN of
cn=Administrator,dc=digitalairlines,dc=com.
e. In the LDAP Administrator Password and Validate Password fields, type a
password for your LDAP super user.
f. (Conditional) If you want to use this database as the default database for
OpenLDAP client tools, such as ldapsearch, select Use this Database as the
Default for OpenLDAP Clients.
Marking this option causes the SLES 11 servers host name and the base DN
entered in this screen to be written to the OpenLDAP client configuration
file (/etc/openldap/ldap.conf).
8. Select Next.
9. On the Configuration Summary screen, select Finish.
10. In YaST, select LDAP Server again.
11. Expand Global Settings; then select Allow/Disallow Features.
Version 1 76
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following is displayed:
Figure 4-14 Configuring Allow/Disallow Features
12. Under Select Allow Flags, configure the features the LDAP server should allow
(as appropriate for your server and network):
n LDAPv2 Bind Requests: Enables connection requests (bind requests) from
clients using the previous version of the LDAP protocol (LDAPv2).
NOTE: In LDAP, authentication information is supplied in an operation called a bind.
n Anonymous Bind When Credentials Not Empty: Normally the LDAP
server denies any authentication attempts with empty credentials (DN and/or
password). Enabling this option, however, makes it possible to connect with
a password and no DN to establish an anonymous connection.
NOTE: A client that sends an LDAP request without performing a bind operation is
treated as an anonymous client.
n Unauthenticated Bind When DN Not Empty: Allows connecting without
authentication (anonymously) using a DN but no password.
n Unauthenticated Update Options to Process: Allows non-authenticated
(anonymous) update operations. Access is restricted according to ACLs and
other rules
77 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
13. Under Select Disallow Flags, configure the features the LDAP server should not
allow (as appropriate for your server and network):
n Disable Acceptance of Anonymous Bind Requests: Disables acceptance of
anonymous bind requests.
n Disable Simple Bind Authentication: Disables simple bind authentication.
Simple binds use clear-text passwords.
n Disable Forcing Session to Anonymous Status upon StartTLS Operation
Receipt: Disables forcing an authenticated connection back to the
anonymous state when receiving a StartTLS operation.
n Disallow the StartTLS Operation if Authenticated: Disallows the
StartTLS operation on connections that have already been authenticated.
14. Expand Databases > your root entry > Password Policy Configuration.
Figure 4-15 Enabling Password Policies
15. Enable password policy settings for your LDAP server by selecting from the
following settings:
n Enable Password Policies: Allows you to specify a password policy for the
LDAP server.
n Hash Clear Text Passwords: Causes clear text passwords to be hashed
before they are written to the database whenever they are added or modified.
n Disclose "Account Locked" Status: Provides a meaningful error message
to bind requests for locked accounts.
Version 1 78
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NOTE: We recommend that you do not enable this option. The Locked Account error
message provides sensitive information that could be exploited by a potential attacker.
n Default Policy Object DN: By default, YaST creates an object named
Default Policy in your root entry. Change this name as desired.
16. Specify your password policy settings by doing the following:
a. Select Edit Policy.
b. When prompted, type your LDAP administrators password and select OK.
The Password Change Policies tab in the Password Policy Configuration
screen is displayed:
Figure 4-16 Configuring Password Change Policies
c. On the Password Change Policies tab, configure the following:
n Maximum Number of Passwords Stored in History: Determines the
maximum number of passwords stored in the password history. Saved
passwords may not be reused by the user.
n User Must Change Password after Reset: Determines whether users
need to change their password after a reset by the administrator.
n User Can Change Password: Determines whether users can change
their own passwords.
n Old Password Required for Password Change: Requires the old
password for password changes.
n Password Quality Checking: Determines whether, and to what extent,
passwords should be subject to quality checking. You can set a minimum
79 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
password length that must be met before a password is valid in the
Minimum Password Length field.
If you select Accept Uncheckable Passwords, users are allowed to use
encrypted passwords, but quality checks cannot be performed. If you opt
for Only Accept Checked Passwords, only those passwords that pass
the quality tests are accepted as valid.
d. Select the Password Aging Policies tab.
Figure 4-17 Configuring Password Aging Policies
e. Configure the following password aging policies:
n Minimum Password Age: Determines the minimum password age (the
time that needs to pass between two valid password changes).
n Maximum Password Age: Determines the maximum password age.
n Time before Password Expiration to Issue Warning: Determines the
time between a password expiration warning and the actual password
expiration.
n Allowed Uses of an Expired Password: Sets the number of
postponement uses of an expired password before the password expires
entirely.
f. Select the Lockout Policies tab.
Version 1 80
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-18 Configuring Lockout Policies
g. Configure the following lockout policies on the Lockout Policies tab:
n Enable Password Locking: Enables password locking.
n Bind Failures to Lock the Password: Determines the number of bind
failures that trigger a password lock.
n Password Lock Duration: Determines the duration of the password
lock.
n Bind Failures Cache Duration: Determines how long password
failures are kept in the cache before they are purged.
h. Select OK.
17. On the Password Policy Setting screen, select OK.
At this point, the LDAP daemon (ldap) is started on your server. The executable file
that provides this service is /usr/lib/openldap/sldapd. The daemon is
managed using the /etc/init.d/ldap init script (or its corresponding rc link).
You can use the following options with this init script:
n /etc/init.d/ldap start: Starts the LDAP daemon.
n /etc/init.d/ldap stop: Stops the LDAP daemon.
n /etc/init.d/ldap status: Displays the status of the LDAP daemon.
After the installation and configuration is complete, the LDAP daemon is started. It is
configured to run automatically at runlevels 3 and 5.
81 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Install and Configure the LDAP Client
At this point, the LDAP Directory service has been installed on the SLES 11 server.
However, it contains only a few entries. If you were to use the YaST LDAP Browser
module to access your LDAP tree, you would see it contains only the root entry, as
shown below:
Figure 4-19 Minimal LDAP Directory Tree
In addition, your SLES server system is still configured to use only its default
authentication mechanism via PAM, such as the /etc/passwd file.
To fix this, you need to configure the LDAP client on the server and on all other
systems that will use the LDAP service for authentication. To do this, complete the
following:
1. In YaST, select Network Services > LDAP Client.
Version 1 82
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-20 Configuring the System as an LDAP Client
2. To use the OpenLDAP server for user authentication on the system, select Use
LDAP.
When you do, your /etc/nsswitch.conf configuration file will be updated
accordingly.
Prior to enabling the LDAP Client, your server was probably configured to use
the /etc/passwd, /etc/shadow, and /etc/group files to store user
accounts. In this configuration, you servers /etc/nsswitch.conf file
probably appeared similar to the following:
#
# For more information, please read the nsswitch.conf.5
# manual page.
#
# passwd: files nis
# shadow: files nis
# group: files nis
passwd: compat
group: compat
hosts: files dns
networks: files dns
services: files
83 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files nis
publickey: files
bootparams: files
automount: files nis
aliases: files
After enabling the LDAP client, your system will be reconfigured to use either
local files or the LDAP directory service for user authentication. Your /etc/
nsswitch.conf file will be updated in a manner similar to the following:
#
# For more information, please read the nsswitch.conf.5
# manual page.
#
# passwd: files nis
# shadow: files nis
# group: files nis
passwd: compat
group: files ldap
hosts: files dns
networks: files dns
services: files ldap
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files ldap
publickey: files
bootparams: files
automount: files nis
aliases: files ldap
passwd_compat: ldap
3. In the Address of LDAP Servers field, type the IP address of your LDAP server.
If your LDAP service is configured to advertise itself via SLP, you can select
Find to locate it.
4. In the LDAP Base DN field, type the root entry of your LDAP directory.
To retrieve the base DN automatically, you can select Fetch DN. YaST will
check for an LDAP database on the server specified above.
5. If TLS or SSL protected communication with the server is required, select LDAP
TLS/SSL.
6. If the LDAP server still uses LDAPv2, explicitly enable the use of this protocol
version by selecting LDAP Version 2.
Version 1 84
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
7. Select Start Automounter to mount remote directories on your client, such as a
remotely managed /home directory.
8. Select Create Home Directory on Login to have a user's home automatically
created on the first user login.
9. Select Advanced Configuration.
The Client Settings tab is displayed:
Figure 4-21 Configuring Advanced LDAP Client Settings
10. On the Client Settings tab, adjust the following settings according to your needs:
a. If the search base for users, passwords, and groups differs from the global
search base specified in the LDAP base DN, type the appropriate name
contexts in following fields.
n User Map
n Password Map
n Group Map
These values are set in the nss_base, nss_base_shadow, and
nss_base_group attributes in the /etc/ldap.conf file.
b. From the Password Change Protocol drop-down list, specify the password
change protocol.
You can select from the following options:
n clear: Changes passwords using an LDAPModify request, replacing the
userPassword value with the new clear-text password.
85 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
n clear_remove_old: Changes passwords using an LDAPModify request,
first removing the userPassword value containing the old clear-text
password, and then adding the userPassword value with the new clear-
text password. This protocol is necessary for use with Novell NDS and
IBM RACF.
n crypt: Changes passwords using an LDAPModify request, first
generating a one-way hash of the new password using crypt and then
replacing userPassword value with the new hashed password.
n md5: Changes passwords using an LDAPModify request, first
generating a one-way hash of the new password using MD5 and then
replacing userPassword value with the new hashed password.
n nds: This is an alias for clear_remove_old.
n racf: This is an alias for clear_remove_old.
n ad: Changes passwords using an LDAPModify request, using the Active
Directory Services Interface (ADSI) password change protocol.
n exop (default): Changes passwords using the RFC 3062 password
modify extended operation (only the new password is sent).
n exop_send_old: Changes passwords using the RFC 3062 password
modify extended operation (both the old and new passwords are sent).
This setting is configured in the pam_password attribute of the /etc/ldap.conf
file.
c. From the Group Member Attribute drop-down list, select the LDAP group
to use with Group Member Attribute.
The default value is member.
11. Select the Administration Settings tab.
Version 1 86
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-22 Configuring Advanced Administration Settings in the LDAP Client
12. Configure the following settings on the Administration Settings tab:
a. In the Configuration Base DN field, type the base context for storing your
user management data.
b. In the Administrator DN field, type your administrator users DN.
This DN must be identical to the rootdn value specified in /etc/openldap/
slapd.conf to enable this user to manipulate data stored on the LDAP server.
You can enter the full DN (such as cn=Administrator,dc=digitalairlines,
dc=com) or type cn=Administrator and select Append Base DN to have the
base DN added automatically.
c. Select Create Default Configuration Objects to create the basic
configuration objects required to enable user management via LDAP.
d. If your LDAP server should act as a file server for home directories across
your network, select Home Directories on This Machine.
e. Use the Password Policy section to select, add, delete, or modify the
password policies to use.
13. Configure the YaST Group and User Administration modules.
You use the YaST LDAP Client module to adapt the YaST User and Group
Administration modules to support LDAP accounts by doing the following:
a. Select Configure User Management Settings.
87 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
b. When prompted, enter your Administrator users password.
c. When prompted that the ldapconfig organizational unit doesnt exist, select
Yes to created it now.
d. Select New.
e. To create a new user configuration module, select suseUserConfiguration.
f. In the Name of New Module field, type Users; then select OK.
A table is displayed listing all attributes allowed in this module with their
assigned values:
Figure 4-23 Configuring the Users Module
Notice that the template is connected to its module using the
susedefaulttemplate attribute value, which is set to the DN of the template.
g. If you want to change an attribute, select the desired attribute; then select
Edit.
h. If you want to configure the user template, select Configure Template.
Version 1 88
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-24 Configuring the Users Template
i. To change a template attribute, select the desired attribute; then select Edit.
j. To modify the default values for new objects, use the Add, Edit, or Delete
buttons.
k. When done, select OK.
l. On the Module Configuration screen, select New.
m. To create a new group configuration module, select
suseGroupConfiguration.
n. In the Name of New Module field, type Groups; then select OK.
89 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-25 Configuring the Groups Module
Notice that the template is connected to its module using the
susedefaulttemplate attribute value, which is set to the DN of the template.
o. If you want to change an attribute, select the desired attribute; then select
Edit.
p. If you want to configure the groups template, select Configure Template.
Version 1 90
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-26 Configuring the Groups Template
q. To change a template attribute, select the desired attribute; then select Edit.
r. To modify the default values for new objects, use the Add, Edit, or Delete
buttons.
s. When done, select OK.
t. In the Module Configuration screen, select OK.
14. On the Advanced Configuration screen, select OK.
15. On the LDAP Client Configuration screen, select OK.
16. If prompted, install the pam_ldap and nss_ldap packages by selecting Install.
You can repeat this process to configure the LDAP Client on all SLES or SLED
systems that will use the LDAP server for authentication. The configuration of YaST
Group and User Administration modules has to be done only once, not on every
LDAP client.
91 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 3 Add, Modify, and Delete Entries to the LDAP Directory Tree
In the previous objectives in this section, you learned how to install and configure the
OpenLDAP server and client on your SLE systems. However, at this point there are
no user accounts in the LDAP directory tree.
In this objective, you learn how to manage users and groups in the LDAP directory
tree. The following topics are addressed:
n Managing LDAP Users and Groups from the Shell Prompt on page 91
n Managing LDAP Users and Groups in YaST on page 95
Managing LDAP Users and Groups from the Shell Prompt
Just as you can add, delete, and modify local user and group accounts using command
line tools, you can also manage users and groups in the LDAP directory from the
shell prompt.
For accounts stored locally, you use the following commands to manage users and
groups from the shell prompt:
n useradd: Create new user accounts.
n userdel: Delete existing user accounts.
n usermod: Modify an existing user account.
n passwd: Modify a users password.
n groupadd: Create new groups.
n groupdel: Delete existing groups.
n groupmod: Modify an existing group.
If you have installed and configured OpenLDAP on your servers and workstations,
you can still use these utilities to manipulate accounts stored in /etc/passwd, /
etc/shadow, and /etc/group. To use these commands to manage users in the
ldap directory, you have to use the options --service ldap -D binddn (such
as cn=Administrator,dc=digitalairlines,dc=com. You are prompted for the
password of the Administrator.
NOTE: Remember that after installing the LDAP Client, your system is configured (by default) to
use both the local files and the LDAP directory for authentication.
In addition to the above tools to manage LDAP users and groups from the shell
prompt, you can use a special set of utilities. First, you can use the ldapsearch
utility to search for entries within the LDAP directory. The syntax for using
ldapsearch is as follows:
ldapsearch -x -b search_base "(objectClass=*)"
The -b option specifies the context in the tree where the search should be performed.
The -x option enables simple authentication. The (objectClass=*) option
specifies that all objects contained in the directory should be read.
Version 1 92
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
This command option can be used after the creation of a new directory tree to verify
that all entries have been recorded correctly and the server responds as desired. For
example:
ldapsearch -x -b dc=digitalairlines,dc=com
"(objectClass=*)"
When you enter this command, the tree is queried at the specified context and the
results are displayed, as shown below:
Figure 4-27 Viewing the Output of the ldapsearch Command
Notice that the output is formatted using the LDAP Data Interchange Format (LDIF),
which is a plain-text way of describing LDAP directory entries. LDIF is a standard
that defines an ASCII text file format used to import or export data to and from an
LDAP-compliant directory service.
LDIF files are commonly used to initially build a directory database or to add large
numbers of entries to a directory at the same time. LDIF files can also be used to
make changes to existing directory entries. LDIF files consist of one or more entries
separated by a blank line. Each LDIF entry consists of an optional entry ID, a
required distinguished name, one or more object classes, and multiple attribute
definitions.
The basic syntax of an LDIF file is as follows:
dn: distinguished name
changetype: type of change
objectClass: object class
attribute type: attribute value
93 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Only the DN and at least one object class definition are required. Attributes required
by object classes you define for the entry must also be defined. Other attributes and
object classes are optional. You can specify object classes and attributes in any order.
The following describes the LDIF fields shown in the previous example:
Table 4-1 LDIF Fields
For example, you could use the following LDIF file to define a user named geeko:
# geeko LDIF
dn: cn=geeko,ou=People,dc=digitalairlines,dc=com
changetype: add
objectClass: inetOrgPerson
cn: geeko
givenName: Geeko
sn: Chameleon
mail: geeko@digitalairlines.com
uid: geeko
telephoneNumber: 801-861-7000
Understanding LDIF files is important because you can use them in conjunction with
the ldapadd command to add new users to the LDAP directory from the shell
prompt. This command uses the following syntax:
ldapadd -x -D administrator_DN -W -f ldif_file
The -x option switches off SASL authentication. The -D option specifies the user
used to bind to the directory. The -W option prompts you for the administrator users
password. The -f option specifies the name of the LDIF file to import.
For example, to import an LDIF file named geeko.ldif into the LDAP directory, you
would use the following command (in one line):
ldapadd -x -D cn=Administrator,dc=digitalairlines,dc=com
-W -f geeko.ldif
Parameter Value
dn Distinguished name for the entry.
changetype Valid changetype values include add, modify, moddn, and delete.
objectClass Object class to use with this entry. Each object class defines the types of
attributes allowed or required for the entry.
attribute type Attribute to define for the entry.
attribute value Value to be assigned to the attribute type.
Version 1 94
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When done, the entry defined in the geeko.ldif file is imported (as shown on the
previous page). The output from the command is shown in the figure below:
The LDIF file used with ldapadd can contain one or many directory entries defined
within it. This allows you to, if appropriate, populate your entire LDAP directory
with one single ldapadd command.
Just as you use usermod to modify an existing local user account, you use the
ldapmodify command to modify an existing entry in the LDAP directory. As with
the ldapadd command, you run the command from the shell prompt and pass to it the
name of an LDIF file to process.
With the ldapadd command, you use the changetype: add command in the LDIF file
to specify that the entry be added to the directory. With the ldapmodify command,
however, you use the changetype: modify command in the LDIF file to indicate that
an existing entry should be modified using the attributes and values listed in the file.
For example, if you needed to change the geeko users phone number to 801-555-
7001, you could create a file similar to the following:
# geeko modify
dn: cn=geeko,ou=People,dc=digitalairlines,dc=com
changetype: modify
replace: telephoneNumber
telephoneNumber: 801-555-7001
NOTE: Make sure you have no trailing white spaces at the end of the lines, as these can cause
errors.
Then you import the LDIF modify file into the LDAP directory using the following
command (in one line):
ldapmodify -x -D
cn=Administrator,dc=digitalairlines,dc=com -W -f
geeko.ldif
When you do, the following is displayed:
da1:~ # ldapadd -x -D cn=Administrator,dc=digitalairlines,dc=com \
-W -f geeko.ldif
Enter LDAP Password:
adding new entry "cn=geeko,ou=People,dc=digitalairlines,dc=com"
da1:~ #
da1:~ # # ldapmodify -x -D cn=Administrator,dc=digitalairlines,dc=com
-W -f newuser2.ldif
Enter LDAP Password:
modifying entry "cn=geeko,ou=People,dc=digitalairlines,dc=com"
da1:~ #
95 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Finally, you can delete entries from the LDAP directories using the ldapdelete
command. The syntax for this utility is similar to that used by the other LDAP shell
commands. For example, to delete the geeko user we just created, you would enter
the following (in one line):
ldapdelete -x -D
cn=Administrator,dc=digitalairlines,dc=com -W
cn=geeko,ou=People,dc=digitalairlines,dc=com
Managing LDAP Users and Groups in YaST
As with local user accounts, you can manage LDAP users and groups using YaST
modules as well as command line utilities. To do this, complete the following:
1. Start YaST, then select Security and Users > User and Group Management.
2. On the Users tab, select Set Filter > LDAP Users.
3. When prompted, enter your LDAP Administrator users password.
The following screen is displayed:
Figure 4-28 Managing Users in YaST
4. To add a new user, do the following:
a. Select Add.
The User Data tab in the New LDAP User screen is displayed:
Version 1 96
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-29 Creating a New LDAP User
b. Enter the following information about the user:
n First Name
n Last Name
n Username
n Password
c. Select the Details tab.
97 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-30 Configuring New User Details
Notice that the fields on the Details tabs are already populated for the new
user. You defined these defaults when you set up your user and group
templates earlier.
d. Select OK.
Version 1 98
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The new user is added to your list of LDAP users, as shown below:
Figure 4-31 Viewing a New LDAP User
5. To edit an existing LDAP user, select the user to be modified, then select Edit.
6. Make the appropriate changes to the User Data and Details tabs, then select OK.
7. To delete an LDAP user, select the user to be removed, then select Delete.
8. When youre done, select OK.
Managing LDAP groups is done in a similar manner. Do the following:
1. Start YaST, then select Security and Users > User and Group Management.
2. Select the Groups tab, then select Set Filter > LDAP Groups.
3. When prompted, enter your LDAP Administrator users password.
99 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
A list of your LDAP groups is displayed, as shown below:
Figure 4-32 Managing LDAP Groups
4. To add a new group, select Add.
Version 1 100
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-33 Creating a New LDAP Group
5. Enter the following information for the group:
n Group Name
n Group ID (should be automatically populated based on the template you
created earlier)
n Password (optional)
6. In the right column, select the users you want to be members of the group.
7. Select OK.
101 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 4-34 Viewing New LDAP Groups
8. As with LDAP users, you can use the Edit and Delete options on this screen to
modify or remove an LDAP group.
9. When complete, select OK.
You can use the YaST LDAP Browser module to view the contents of your LDAP
tree graphically. To do this, complete the following:
1. Start YaST, then select Network Services > LDAP Browser.
2. (Conditional) If this is the first time you access your LDAP tree, you must
configure an LDAP connection for the LDAP Browser.
a. On the LDAP Connections screen, select Add.
b. Enter a name for the connection, then select OK.
c. Specify the following information for the connection:
n LDAP Server: The IP address or DNS name of your LDAP server.
n Administrator DN: The DN of your LDAP servers Administrator user.
n LDAP Server Password: Your Administrator users password.
n LDAP TLS: If your LDAP server uses TLS, select this option.
Version 1 102
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
An example is shown in the following:
Figure 4-35 Configuring an LDAP Connection
d. Select OK.
Your LDAP tree is displayed.
3. Double-click your root entry in the left pane.
103 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
You should see your first-level container objects, as shown below:
Figure 4-36 Viewing the LDAP Tree
Version 1 104
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
You can use the left pane to navigate through the tree. Whenever you select an
object in the left pane, its attributes and values are displayed in the right pane.
For example, if you were to select uid=tux,ou=People,dc=digitalairlines,
dc=com, you would see the various attributes that comprise the tux user object
and its associated values in the right pane, as shown below:
Figure 4-37 Viewing an Object and Its Attributes
4. If you need to edit an attribute value, do the following:
a. Double-click the attribute in the right pane.
A window similar to the following is displayed:
Figure 4-38 Editing an Attribute Value in the LDAP Browser
b. Make the desired change, then select OK.
5. When youre done, select Close.
105 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 4-1 Configure OpenLDAP on SLE 11
In this exercise, you install and configure an LDAP server on DA1. You then
configure the LDAP client on your DA1 server and on your workstation.
(End of Exercise)
Version 1 106
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Describe How LDAP Works LDAP stands for Lightweight Directory Access
Protocol. Its a set of protocols designed to
access and maintain information in a
Directory. An LDAP Directory can be used to
store many types of information including
user, group, and service configuration
settings. LDAP is a standardized open
protocol, which ensures that many different
client applications can access the information
stored in the Directory.
A Directory is a compilation of services that
provide discovery, security, storage, and
relationship management. A Directory does
the following:
n Enables access to resources on the entire
network and not just specific servers
n Provides secure access to network
resources
n Provides a scalable, indexed, and
cacheable database (for performance)
n Manages relationships between Directory
entities, such as users and the resources
they access
An LDAP Directory uses a hierarchical tree
structure. All entries (called objects) in the
Directory have a defined position within its
hierarchy. The complete path from the root of
the tree to a particular entry, including the
entrys name, is called its distinguished name
or DN. The DN uniquely identifies an object in
the Directory tree.
Objects can be categorized into one of two
possible types:
n Container Objects
n Leaf Objects
When working with an LDAP Directory, you
need to be familiar with the following
concepts:
n Objects
n Context
n Naming
107 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Install and Configure OpenLDAP on SLES 11 SLES and SLED 11 can be configured to use
an LDAP Directory service to store user
accounts and service configuration
information. To do this, you need complete the
following tasks:
1. Configure the LDAP server.
2. Configure the LDAP client.
Add, Modify, and Delete Entries to the LDAP
Directory Tree
If you have installed and configured
OpenLDAP on your servers and workstations,
you can still use your standard comman line
user management utilities to manipulate
accounts stored in /etc/passwd, /etc/
shadow, and /etc/group. To use these
commands to manage users in the ldap
directory, you have to use the options --
service ldap -D binddn
In addition, you can use a special set of user
management utilities:
n ldapsearch
n ldapadd
n ldapmodify
n YaST User Management Module
Objective Summary
Version 1 108
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
109 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 5 Configure and Use Samba
In this section, you will learn how to configure SLES 11 as file and print server for
Linux and Windows workstations using Samba.
Objectives
1. Describe the Role and Function of Samba on page 110
2. Configure a Simple File Server with Samba on page 114
3. Configure Samba Authentication on page 128
4. Use Sambas Client Tools on page 138
Version 1 110
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Describe the Role and Function of Samba
Using Samba, a Linux system can be configured as a file and print server for Linux,
Mac OSX, Windows, and OS/2 workstations. Essentially, Samba allows your Linux
system to emulate a Window server. Users can access shared directories and printers
on the Linux server just as they would on a Windows server. You can configure
Samba as a domain controller. You can even join an Active Directory domain.
The key to making all of this work is the fact that Samba uses the Server Message
Block (SMB) protocol. To fully implement Samba, you need to have a solid
understanding of SMB. In this objective, you learn the following:
n SMB Overview on page 110
n NetBIOS Overview on page 110
n How SMB Communications Work on page 112
SMB Overview
The earliest version of the SMB protocol was developed by IBM in the 1980s. The
protocol was later integrated natively into the Windows desktop and server operating
systems. SMB has also been integrated into Linux/UNIX as well. Using the Samba
package, a Linux server can also support native Windows clients.
The SMB protocol implements sharing. Shared resources, such as directories and
printers, are referenced using the Universal Naming Convention (UNC). UNC uses
the following syntax to identify a share:
\\server_name\share_name
For example, if you had a SLES 11 server named DA1 with Samba configured, you
could create a directory named /home/shared as a place for network users to store
their files. Using Samba, you could share this directory with the share name shared.
To reference the share, you would use a UNC of \\DA1\shared.
You can also use a URL to reference an SMB share, as shown below:
smb://server_name/share_name
SMB operates at the Application and Presentation layers of the OSI model. The role
of SMB is to provide clients with access to the file system and printers on a server.
SMB uses the internal security of the server file system to determine what the client
can and cannot do.
NetBIOS Overview
Because its an upper-layer protocol, SMB cant operate alone. It must be
implemented in conjunction with a middle-layer protocol. The most common
implementation is to use SMB in conjunction with Network Basic Input/Output
System (NetBIOS) protocol on top of IP.
NetBIOS was original developed in the mid-1980s and is used as the basic
networking protocol for the Windows operating system. NetBIOS operates at the
Session layer of the OSI model. As such, it has no routing capabilities. To make
111 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NetBIOS routable, you have to use it in conjunction with a Network-layer protocol,
such as IPX or IP.
This relationship is shown in the figure below:
Figure 5-1 The Relationship between SMB, NetBIOS, TCP, and IP
As you know, IP uses a numerical IP address to uniquely identify each network host.
NetBIOS, on the other hand, uses a 16-byte, 15-character alphanumeric name to
uniquely identify network hosts.
The very last byte of a NetBIOS name (called the NetBIOS Suffix) is not used for the
name value. Instead, it is used to identify the type of host. A workstation will have a
value of 00 (hex). A server will have a hex value of 20. A Primary Domain Controller
(PDC) or a Backup Domain Controller (BDC) will have a hex value of 1C.
Any given system can have both a NetBIOS name and a hostname. These two names
are completely separate. Because NetBIOS works on top of IP, you need to be able to
resolve NetBIOS names into IP addresses, just as you need to resolve hostnames and
DNS names into IP addresses.
In NetBIOS, name resolution is done using a Windows Internet Naming Service
(WINS) server. A WINS server works much like a DNS server. When a NetBIOS
computer is booted on the network, it does the following:
n If a WINS server is detected on the network, the NetBIOS computer registers
itself with the server on startup.
If its NetBIOS name is not already in use, the WINS server puts the systems
name and IP address in its database. All other NetBIOS hosts can send queries to
the WINS server to resolve the NetBIOS name into an IP address.
n If a WINS server is not detected, the NetBIOS computer will simply broadcast its
NetBIOS name on the network when it boots.
Version 1 112
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
If another system is already using that NetBIOS name, an error will be generated
indicating that a name conflict exists.
Hosts still need to be able to resolve NetBIOS names into IP addresses. To do this
without a WINS server, a NetBIOS host that needs to contact another host sends
out a broadcast. The host with the requested NetBIOS name responds back with
its IP address.
How SMB Communications Work
When you attempt to open an SMB connection, the NetBIOS protocol is used to
establish a connection at the Session layer between the sending and receiving
systems. Once a NetBIOS session has been established, clients and servers
communicate with each other at the upper layers of the OSI model with the SMB
protocol, using Server Message Blocks (SMBs).
SMBs contain commands that establish communications and manipulate shared
directories, files, and printers. SMBs work on a command/response model. Consider
the following SMB session.
A user on a workstation needs to create a file on a server, add content to the file, and
save it. The SMB commands and responses required to do this include the following:
1. The client sends an SMBNegProt command to the server. This tells the server
which dialect of SMB it's using.
NOTE: There are many different SMB protocol versions and dialects.
2. The server sends an SMBNegProt response back to the client, agreeing on the
dialect to be used.
3. The client sends an SMBSesssetup command to the server. This SMB contains
the username and password of the user.
4. If the username and password are valid, the server responds with an
SMBSesssetup response reporting that the user is authenticated.
5. The client sends an SMBtcon command. This tells the server which share it
wants to use.
6. The server responds with an SMBtcon response, telling the client that it has been
granted permission to use the share.
7. The client sends an SMBmknew command. This SMB tells the server to create a
new file.
8. The server sends an SMBmknew response after the file has been created.
9. The client sends an SMBopen command that tells the server to open the file that
was just created.
10. The client sends an SMBread command. The server responds with the requested
file.
At this point, the user can work on the open file from the client workstation.
113 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
11. When the editing is complete, the file is saved and closed. The client sends an
SMBwriteclose command.
12. The server system writes the file to disk and closes it.
In addition to the SMBs discussed in the example above, many other commands can
be used when working with shared resources on the server, including the following:
n SMBcopy: Copies files
n SMBmove: Moves files
n SMBsplopen: Opens a print spool for printing
How Samba Works
The Samba service on a SLES 11 system allows Samba clients to connect to shared
directories and printers on your server. You can use Samba for the following
purposes:
n Provide file and print services for Samba clients (such as Windows, OSX, and
Linux workstations).
n Act as a domain controller for Windows clients.
n Integrate into an existing Windows domain for authentication purposes
The server side of Samba consists of two daemons:
n nmbd: Handles all NetBIOS-related tasks. It also can provide a WINS server.
n smbd: Provides file and print services for clients in the network.
In addition, to integrate the Samba server into a Windows environment, Samba also
provides the following services and utilities:
n winbind: Integrates a Linux system into a Windows authentication system, such
as Active Directory. Essentially, it allows Windows domain users to function as
local Linux users.
n nmblookup: Used for NetBIOS name resolution and testing.
n smbclient: Provides access to SMB file and print services.
SLES 11 includes Samba version 3.2.7. Novell is an important contributor of the
Samba project. You can find more information about the Novell/SUSE Samba
packages and the Novell/SUSE Samba team at (http://www.opensuse.org/samba).
Version 1 114
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Configure a Simple File Server with Samba
To set up a simple file server with Samba, you need to be familiar with the following
tasks:
n Installing Samba on the Server on page 114
n Using the Samba Configuration File on page 115
n Configuring Samba in YaST on page 121
Installing Samba on the Server
To configure a file server, the Samba packages need to be installed:
n samba: Main Samba package. It contains the Samba server software.
n samba-client: Contains the Samba client tools.
n samba-doc (optional): Provides additional documentation about Samba.
NOTE: The samba and samba-client packages are installed by default during the installation of
SLES 11.
You can verify that the packages are installed with the rpm -q samba and rpm -
q samba-client commands. If they are installed, rpm displays the installed
version, or an error message informs you that the package is not installed.
115 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
If the packages have not been installed, you can install them using the rpm
command. You can also start YaST on your server and use the Software Management
module to install the File Server pattern, as shown below:
Figure 5-2 Installing the File Server Pattern
After the packages have been installed, you can start the Samba daemons with the
following commands:
rcnmb start
rcsmb start
To start the Samba services automatically when the system is booting, enter the
following commands:
insserv nmb
insserv smb
Using the Samba Configuration File
The Samba service is configured in the /etc/samba/smb.conf file. The options
in the this file are grouped into several sections. Each section starts with a keyword in
square brackets.
In this part of the course, you learn how to set up a simple file server with Samba.
You need to be familiar with the following tasks:
n Configuring General Server Options on page 116
Version 1 116
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
n Sharing Users Home Directories on page 117
n Configuring Shares on page 118
n Sharing Printers on page 119
Configuring General Server Options
The first task you need to be familiar with is configuring general server options in the
smb.conf file. The general server configuration section starts with the keyword
[global]. The following is an example of a basic global section:
[global]
workgroup = DigitalAirlines
netbios name = DA1
security = share
server string = DA1 File Server
The entries of the global section in this example are described below:
n workgroup = DigitalAirlines
Defines the name of the workgroup or domain the Samba server will participate
in.
n netbios name = DA1
Used to manually set the NetBIOS name of the Samba server. If you dont
include this parameter, the NetBIOS name will default to the servers hostname.
n security = share
Determines how a client has to authenticate itself when accessing a share. This
option can have the following values:
q share: Authentication is handled on a per-share basis. Each share in the
system is assigned its own password. Client systems can access the share by
simply providing the shares password. Usernames are not checked.
q user: Authentication is handled on a per-user basis. An SMB client must
first authenticate with a valid username and password to the Samba server
before it is allowed to access shared resources on the server. This is the
default value if the security option isnt explicitly included in smb.conf.
q server: Specifies that the client must provide a username and password
when it connects to the server. Samba contacts another SMB server in the
network to validate the password. This is usually used in a workgroup
configuration.
q domain: All authentication processes are handled by a remote primary
domain controller or a backup domain controller. This value is usually used
in a domain configuration.
q ads: Specifies that Samba acts as domain member of an ADS realm to
validate the username and password.
n server string: Provides a description of the Samba server that will be displayed
in My Network Places for Windows clients. This text string can contain any
117 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
value you want. If you dont include this parameter, smbd will default to a a
description of Samba samba_version_number.
In addition to the above, you can also include the following global server options, if
required for your particular implementation:
n encrypt passwords: Configures smbd to use encrypted passwords. This should
be enabled as every version of Windows since Windows 98 requires encrypted
passwords.
n passdb backend: Identifies where Samba user accounts are stored.
n wins server: Specifies the IP address of your networks WINS server.
n wins support: If your network doesnt already have a WINS server on your
network, set this parameter to yes. This will enable WINS by running the nmbd
daemon on your server.
n username map: Specifies a file that is used to map SMB client usernames to
local server usernames. By default, this is /etc/samba/smbusers.
NOTE: There are many other parameters that you can optionally include in the [global] section
of the smb.conf file. See the smb.conf man page to learn more.
Sharing Users Home Directories
Next, you need to know how to share users home directories. By default, the
smb.conf file is pre-configured to share user home directories in the [homes] section.
An example is shown below:
[homes]
comment = Home Directories
valid users = %S, %D%w%S
browseable = No
read only = No
inherit acls = Yes
This section of the smb.conf file automatically shares the home directories of the
users on your server. A user can access his or her share using the following UNC:
\\server_name\username
Version 1 118
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
For example, if your Linux username were rtracy and you accessed your Samba
server from a Windows workstation, you would see a share named rtracy, as shown
below:
Figure 5-3 Viewing Shared Home Directories
Configuring Shares
In addition to sharing home directories, you can also share other directories in the
servers file system. You do this by adding a share definition to the smb.conf file for
each directory on your file server that will be shared. The following example defines
a simple share:
[data]
comment = Data
path = /srv/data
read only = Yes
guest ok = Yes
The entries in this example are described below:
n [data]: Defines the identifier for the share. The share in this example can be
accessed with the following UNC:
\\da1\data
n comment = Data: Defines a comment that displays additional information about
the share. The comment is displayed when you browse the network with
Windows Explorer.
119 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
n path = /srv/data: Sets the path in the local file system that the share points to.
Verify that the local user accounts who need access to the files in this share have
been granted the appropriate file system rights.
n read only = Yes: Specifies that the client accessing the share is not allowed to
modify, delete, or create any files. This is the default value used if this parameter
is not included in the share definition.
n guest ok = Yes: Specifies that a password is not required to access the share.
There many more configuration options available for defining shares in smb.conf.
Depending upon your needs, you could also include the following:
n browseable: Specifies whether or not the share can be browsed in My Network
Places on Windows systems. If you dont include this parameter, a default value
of yes is assumed.
n writeable: If set to yes, users may create or edit files in the shared directory, as
long as the file system permissions assigned to the directory allow it.
n public: If set to yes, users can connect to the shared directory without a
password using the nobody system user account. This option is used only with
share-level security. The default value for this option is no.
n valid users: Restricts access to the share to a specified list of users. Separate
usernames with a comma (,).
NOTE: There are many other parameters that you can optionally include when defining a share in
the smb.conf file. See the smb.conf man page to learn more.
Sharing Printers
You can also use Samba to share the printers configured on your SLES 11 server. This
is a signification benefit for users who use Windows workstations. By default, the
Windows operating system isnt compatible with network CUPS printers.
Using Samba, however, Windows users can send print jobs to your SLES 11 server
and have them print on your CUPS printers. Samba accepts print jobs from SMB
clients that it spools to a local spool directory. When the entire print job has been
received, Samba runs a local print command and passes the spooled file to it. The
local printing system then processes the print job and sends it to the printer.
By default, the smb.conf file is preconfigured to share all configured printers in the
[printers] section. If this section exists within the smb.conf files, users can
connect to any printer in the Samba host's printcap file. On startup, Samba creates a
printer share for every printer defined in the printcap file. The [printers] section
contains settings that are applied by default to all Samba printers on the server.
A sample [printers] section is shown below:
Version 1 120
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
The options in this file are explained below:
n comment = All Printers: Causes the comment specified to be shown next to the
share in Network Neighborhood (or with the net view command).
n path = /var/tmp: Defines the directory that will be used to spool print jobs.
n printable = Yes: When set to Yes, this option allows client systems to create
spool files for printing in the directory defined above. This value must exist
within [printers], otherwise the Samba daemon wont start.
n create mask: Sets the necessary POSIX permissions to the directory.
n browseable = No: Makes the [printer] share itself invisible in the list of available
shares in Network Neighborhood. Individual shared printers, however are still
visible. This option should always be set to No if printable = yes.
In addition to the above options, you can also use the following options, as
appropriate:
n guest ok = Yes: Allows anonymous guest printing to the printer. No password is
required. The guest account maps to the nobody user account and print jobs are
sent as this user. Otherwise, the user must first authenticate to the Samba service
to send a print job.
n public = Yes: Performs the same function as guest ok = Yes.
n read only = Yes: Allows users to spool print jobs to the directory defined, but
prevents normal write operations in this directory.
n writable = No: Performs the same function as read only = Yes.
In addition to the [printers] section, you can also add several printing-related options
to the [global] section of the smb.conf file. These include the following:
n load printers: If you include this parameter in your smb.conf file, all printers
defined in the /etc/printcap file will automatically be shared. If you use this
parameter, you do not need to define separate shares for your printers. Each
automatically created printer share will use the configuration options found in the
[printers] section of the smb.conf file.
n printing: Defines the type of printing system that will be shared by Samba. The
possible values are CUPS, LPRNG, PLP, SYSV, AIX, HPUX, QNX, SOFTQ,
and BSD. Usually you will use CUPS for this parameter.
n show add printer wizard: If set to Yes, this option causes the Add Printer icon
to appear in the Printers folder of the Samba server's share in Network
Neighborhood. The Add Printer Wizard lets you upload a printer driver to the
[print$] share and associate it with a printer.
121 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
n max print jobs: Sets the maximum number of print jobs that can be active on the
Samba server at any one time.
n printcap name: Tells Samba where to look for a list of available printer names.
By default, this is cups.
n printer admin: Specifies a user or group (identified with @) that are allowed to
add drivers and set printer properties. The root user is always a printer admin.
NOTE: You can configure Samba to support the uploading and downloading of printer drivers. This
is done with the [print$] share in the smb.conf file. See the printing section in the /usr/
share/doc/packages/samba/Samba3-HOWTO.pdf file.
Testing the Samba Configuration
After you have configured your smb.conf file, you need to restart the Samba server
daemons for the changes to take effect. However, before doing so, you should use the
testparm command at the shell prompt to test the syntax of your Samba
configuration file. When you do, you should see output similar to the following:
In this example, no errors are found. If there were any errors in the file, the command
would display the errors grouped by configuration sections.
An interesting option for testparm is --section-name section_name, which
tests only the specified section. This can be very useful when you have a very long
smb.conf.
Configuring Samba in YaST
In addition to manually modifying the smb.conf file with a text editor, you can also
configure your Samba server using YaST.
1. Start YaST and select Network Services > Samba Server.
da1:~ # testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[profiles]"
Processing section "[users]"
Processing section "[groups]"
Processing section "[printers]"
Processing section "[print$]"
Processing section "[data]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
Version 1 122
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
A list of shares defined on the Samba server is displayed, as shown below:
Figure 5-4 Viewing Samba Shares in YaST
2. To configure your Samba servers global options, select the Identity tab.
123 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 5-5 Configuring the Samba Servers Identity
3. Configure the following parameters:
n Workgroup or Domain Name
n NetBios Hostname
n WINS Server Support or Remote WINS Server
n Use WINS for Hostname Resolution
4. If you need more granular control over your Samba servers configuration, select
Advanced Settings > Expert Global Settings.
Version 1 124
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When you do, the following is displayed:
Figure 5-6 Configuring Expert Global Settings
In this screen, you can use the Add, Edit, or Delete buttons to add, modify, or
remove Samba global configuration options. Notice that the options displayed
are the same as those discussed earlier in this section in Configuring General
Server Options on page 116.
When done making changes, select OK.
5. To create a new share, select the Shares tab, then select Add.
125 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 5-7 Defining a New Share
6. Enter the following information in the New Share screen:
n Share Name
n Share Description
n Share Type
n Share Path
7. Select OK.
The share is added to the list of defined shares.
8. To enable or disable an existing share, select it from the list, then select Toggle
Status.
9. To hide system-defined shares, select Filter > Do Not Show System Shares.
When you do, only the [homes] and [groups] shares are displayed along with any
custom shares you have defined.
10. To edit an existing share, select it from the list, then select Edit.
Version 1 126
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When you do, the share definition is displayed, as shown below:
Figure 5-8 Editing an Existing Share
You can use the Add, Edit, and Delete buttons to add, modify, or remove options
from the share definition. Notice that the options displayed are the same as those
discussed earlier in Configuring Shares on page 118.
When done modifying the share, select OK.
11. To delete a share, select it from the list, then select Delete.
127 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 5-1 Create a Basic Samba Share
In this exercise, you learn how to configure a basic samba share.
(End of Exercise)
Version 1 128
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 3 Configure Samba Authentication
In the example presented in the previous objective, the [data] share is accessible on
the Samba server without supplying a username and password. In most cases, this
level of access is inappropriate.
In this objective, you learn how to configure Samba authentication. The following
topics are addressed:
n Configuring the Samba User Database on page 128
n Configuring Samba to Require User Authentication on page 134
n Configure Samba to Use LDAP Authentication on page 137
Configuring the Samba User Database
The first task you need to complete is to determine where Samba user accounts will
be stored. Its important to recognize that Samba maintains its own database of user
accounts that are used to authenticate to the service.
NOTE: The user accounts in your /etc/passwd file are not directly used by Samba. However, they
can be mapped over to your Samba database of user accounts.
You have several options for storing your Samba users, including the following:
n Using /etc/samba/smbpasswd on page 128
n Using LDAP on page 129
Using /etc/samba/smbpasswd
By default, the /etc/samba/smbpasswd file is used by Samba to store user
accounts, but it does not have any users defined. To populate the smbpasswd file
with user accounts, you use the smbpasswd utility at the shell prompt. To do this,
complete the following:
1. Open a terminal session and switch to root using the su - command.
NOTE: If you run smbpasswd as any user other than root, it can be used to mange the
smbpasswd account only for the current user.
2. At the shell prompt, enter smbpasswd -a username.
3. When prompted, enter a password for the Samba user account.
While not required, many administrators prefer to use the same password for the
Samba user account as the Linux user account.
4. Restart the Samba daemon.
129 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Once done, the user account is added to the /etc/samba/smbpasswd file, as
shown below:
# This file is the authentication source for Samba if 'passdb backend'
# is set to 'smbpasswd' and 'encrypt passwords' is 'Yes' in the
# [global] section of /etc/samba/smb.conf
#
# See section 'passdb backend' and 'encrypt passwords' in the manual
# page of smb.conf for more information.
geeko:1000:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:55DB0294BC42D6E1B81AE2B5C
7F2943F:[U ]:LCT-49D5D363:
To remove a user from the file, you use the smbpasswd -x username command
at the shell prompt.
To disable a user, you use the smbpasswd -d username command at the shell
prompt.
To reactivate a disabled account, you use the smbpasswd -e username
command.
To change a users Samba password, you use smbpasswd username at the shell
prompt.
The /etc/samba/smbusers file is used by Samba to map usernames from client
systems to user accounts on the local server. The following syntax is used:
unix_name = smb_name
This file is not included in the default configuration.
Using LDAP
In addition to local files, the Samba service can also be configured to store its users in
an OpenLDAP directory service. To do this, complete the following:
1. Start YaST and select Network Services > Samba Server.
2. Select the LDAP Settings tab.
Version 1 130
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 5-9 Configuring Samba LDAP Settings
3. Select Use LDAP Password Back-End.
4. When prompted that all values will be rewritten, select Yes to continue.
The various fields in this interface are automatically populated for you using the
default values found in your servers /etc/openldap/ldap.conf file.
5. Make any changes that are necessary to the various settings.
6. Type your LDAP administrators password in the Administration Password
fields.
7. Select Test Connection.
8. If the test was successful, select OK.
9. Select OK to apply your settings.
10. Close YaST.
After making your configuration changes, several important changes are made to the
[global] section of your smb.conf file. Instead of using local files for the passwd
backend, your LDAP directory service is specified. An example is shown below:
idmap backend = ldap:ldap://127.0.0.1
ldap admin dn = cn=Administrator,dc=digitalairlines,dc=com
ldap delete dn = No
ldap group suffix = ou=group
ldap idmap suffix = ou=Idmap
131 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
ldap machine suffix = ou=Machines
ldap passwd sync = Yes
ldap replication sleep = 1000
ldap ssl = Start_tls
ldap suffix = dc=digitalairlines,dc=com
ldap timeout = 5
ldap user suffix = ou=people
passdb backend = ldapsam:ldap://127.0.0.1
These configuration changes do the following:
n Identify the URL of the LDAP server
n Identify the dn of the LDAP administrator
n Identify where user, group, and machine objects will be stored in the directory
n Identify the base dn (root entry) of the LDAP directory
Likewise, the appropriate entries are added to your LDAP directory. A sample is
shown below:
Figure 5-10 Viewing Samba Objects in the LDAP Directory
In the above example, Samba was configured to use ou=people to store its user
accounts. This is the same directory where the system user accounts are stored. From
this point on, any users created on the system will automatically be Samba enabled.
Version 1 132
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
For example, in the figure below, the lmorgan user account has been created and
automatically Samba enabled.
Figure 5-11 New Users Automatically Samba Enabled
133 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
However, any user accounts that existed in the LDAP directory prior to configuring
Samba will still need to be Samba enabled. For example, in the figure below, the tux
user account has not been Samba enabled:
Figure 5-12 Samba Enabling an Existing LDAP User
You Samba enable an LDAP user using the smbpasswd command in the same
manner as was done previously. In this example, you enter smbpasswd -a tux
(as root) at the shell prompt and enter a Samba password for the user.
Version 1 134
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
After doing so, the various Samba-related properties are added to the tux user object,
as shown below:
Figure 5-13 Samba Enabled LDAP User Account
Configuring Samba to Require User Authentication
In the [data] share definition presented in the previous objective, guest access was
allowed to the share, as shown below:
[data]
comment = Data
path = /srv/data
read only = Yes
guest ok = Yes
In addition, the security option in the [global] section was set to share, as
shown below:
[global]
netbios name = DA1
security = share
This security level requires a password to be set on a per-share basis. Client system
can access the share by simply proving the shares password. Usernames are not
checked.
135 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
In most situations, you will want to reconfigure this share with a higher level of
security. In this part of this objective, you learn how to reconfigure the share such that
users must supply a valid Samba username and password to access it. The first task is
to change the security option in the [global] section in the smb.conf file to security =
user, as shown below:
[global]
netbios name = DA1
security = user
This forces users to authenticate when a client attempts to connect to the Samba
server. However, once they do, your users have access to every share defined in the
smb.conf file. Usually, this is not acceptable.
More than likely, you will want to restrict access to a given share to a specific set of
users. You can use the valid users option within the share definition to specify which
Samba users are allowed access to the share.
In the following, the guest ok option has been replaced with the valid users
option to restrict access to the [data] share to only the tux user:
[data]
comment = Data
path = /srv/data
read only = no
valid users = tux
You can specify one user or more users with this option. Multiple usernames must be
separated by commas.
Changing the read only option to a value of No makes the share writable.
You can also use groups with the valid users option. Group names must begin with @,
for example @accounting. Remember that all group members must be Samba
enabled with the smbpasswd command.
The following example configures the [data] share such that it is readable and
writable by all members of the accounting group:
[data]
comment = Accounting Data
path = /srv/data
read only = no
valid users = @accounting
force user = tux
force group = accounting
Version 1 136
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
In this example, several options have been modified or added:
n valid users = @accounting: Allows all users who are in the accounting group to
access the share.
n force user = tux: Forces Samba to perform all file operations in the share as the
tux user, which can be very useful. For example, using this option allows you to
set your POSIX permissions in the file system for the tux user and have those
permissions automatically applied to every other user who is allowed to access
the share.
n force group = accounting: Forces the Samba server to perform all file
operations using the accounting group.
137 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 5-2 Configure Samba to Use LDAP Authentication
In this exercise, you learn how to configure Samba to store its user accounts in an
LDAP directory service.
(End of Exercise)
Version 1 138
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 4 Use Sambas Client Tools
Although Samba is commonly used to provide Windows workstations with access to
Linux servers, Linux workstations can also access Samba shares. Samba provides a
variety of tools that you can use to access shares from a Linux system. These tools
can be used to access a Samba server or a native Windows server.
In this objective, you learn how to use these tools. The following tasks are addressed:
n Using nmblookup on page 138
n Using smbclient on page 138
n Mounting Samba Shares in the Linux File System on page 140
Using nmblookup
With the nmblookup tool, you can resolve NetBIOS names into IP addresses. In the
following example, the IP address for the Samba server with the NetBIOS name da1
is looked up:
In the first line of the output, nmblookup states that it is querying the server name
with a broadcast to 172.17.8.255. In the second line of the output, it displays the
result of the query. In this case, the system with a NetBIOS name of DA1 has an IP
address of 172.17.8.101.
NOTE: If the system you are querying is not in the same subnet, the name cannot be resolved with a
broadcast query. Instead, nmblookup must use a WINS server to resolve the name. For more
information, see the man page for nmblookup.
Using smbclient
With the smbclient tool, you can access shares on a Samba server. It's also a very
useful tool for testing your Samba server configuration.
You can perform several tasks with smbclient.:
n Browsing Shares Provided by a Samba Server on page 138
n Accessing Files Provided by a Samba Server on page 139
n Sending Print Jobs to Samba Printers on page 140
Browsing Shares Provided by a Samba Server
The smbclient utility can be used to display a list of shares offered by a Samba server.
To do this, enter the following command at the shell prompt:
smbclient -L //server_name
geeko@DA-SLED:~> nmblookup da1
querying da1 on 172.17.8.255
172.17.8.101 da1<00>
139 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When smbclient asks for your password, press Enter to proceed. The output of
smbclient will appear similar to the following:
The smbclient utility first displays all available shares on the Samba server. The IPC$
share provides information about the other shares available on the SMB server. The
lower part of the smbclient output provides workgroup information.
The smbclient command can be very valuable for testing purposes. After you have set
up a share, you can use smbclient to test the availability of the share.
Some shares are not browseable without authentication. In this case, you can pass a
username to smbclient, as in the following example:
smbclient -L //server_name -U username
With these options, smbclient connects to the server with the username specified and
prompts for the corresponding password.
Accessing Files Provided by a Samba Server
You can also use smbclient to access a share on a server. To do this, you need to
supply the share name along with the server name (without the -L option).
In the following example, smbclient connects to the share data on the Samba server
named da1:
smbclient //da1/data
geeko@DA-SLED:~> smbclient -L //da1
Enter geeko's password:
Domain=[DIGITALAIRLINES] OS=[Unix] Server=[Samba 3.2.7-1.3-2042-SUSE-
CODE11]
Sharename Type Comment
--------- ---- -------
profiles Disk Network Profiles Service
users Disk All users
groups Disk All groups
print$ Disk Printer Drivers
data Disk Data
IPC$ IPC IPC Service (DA1 File Server)
Domain=[DIGITALAIRLINES] OS=[Unix] Server=[Samba 3.2.7-1.3-2042-SUSE-
CODE11]
Server Comment
--------- -------
DA1 DA1 File Server
Workgroup Master
--------- -------
DIGITALAIRLINES
Version 1 140
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
A username can also be supplied with the -U option. After smbclient has connected
to a share, it displays the following prompt:
At this point, smbclient can be used like a command line FTP client. Some of the
most commonly used commands include the following:
n ls: Displays the contents of the current directory.
n cd: Changes to a directory.
n get: Copies a file from the share to the current working directory.
n put: Copies a file to the share. The share must be writable to use this command.
Sending Print Jobs to Samba Printers
You can also use smbclient to send print jobs to shared Samba printers. Use the
following syntax:
smbclient //server_name/shared_printer_name -c
file_to_print
The -c option performs the given command automatically after the connection to the
server has been established. You can also enter the print command on the smb:\
command line after you have connected to the server.
Mounting Samba Shares in the Linux File System
In addition to accessing shared files with smbclient, you can also mount a remote
Samba share into the local file system, much like an NFS export. This is done using
the mount command:
mount -t cifs //server_name/share_name /mount_point
For example:
mount -t cifs //da1/data /mnt/samba
In this example, the data share on the da1 Samba server is mounted into the /mnt/
samba directory. The -t cifs option to specifies that the resource to be mounted is an
SMB share.
If the share requires authentication, you can also supply a username as in the
following:
mount -t cifs -o username=geeko //da1/data /mnt/samba
You will be prompted for the password.
It is also possible to provide the password in the command as in the following:
mount -t cifs -o username=geeko,password=novell //da1/
data /mnt/samba
smb: \>
141 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
However, the password will be visible in the password history. If you use the /etc/
fstab file to mount the file system, the issue is similar, as every user on the system
could view the password. The solution is to provide the password in the /etc/
samba/smbfstab file that is only readable for the system administrator. The
equivalent to the above command line would look similar to the following:
# This file allows you to mount SMB/ CIFS shares during system boot
# while hiding passwords to other people than root. Use /etc/fstab for
# public available services. You have to specify at least a service
# name and a mount point. Current default vfstype is smbfs.
#
# Possible vfstypes are smbfs and cifs.
#
# The options are explained in the manual page of smbmount and
# mount.cifs.
#
# service moint-point vfstype options
//da1/data /mnt/samba cifs username=geeko,password=novell
Version 1 142
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 5-3 Work with Samba Shares
In this exercise, you access a share with smbclient and you mount a Samba share in
the file system of a Linux workstation.
(End of Exercise)
143 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Describe the Role and Function of Samba Using Samba, a Linux system can be
configured as a file and print server for Linux,
Mac OSX, Windows, and OS/2 workstations.
Essentially, Samba allows your Linux system
to emulate a Window server. Users can
access shared directories and printers on the
Linux server just as they would on a Windows
server.
You can configure Samba as a domain
controller. You can even join an Active
Directory domain.
The key to making all of this work is the fact
that Samba uses the Server Message Block
(SMB) protocol.
Configure a Simple File Server with Samba Before you can configure a file server, you
need to verify that the Samba packages have
been installed:
n samba: The main Samba package. It
contains the Samba server software.
n samba-client: Contains the Samba client
tools.
n samba-doc (optional): Provides additional
documentation about Samba.
The Samba service is configured in the /
etc/samba/smb.conf file.
The options in this file are grouped into
several sections. Each section starts with a
keyword in square brackets.
Configure Samba Authentication You need to determine where Samba user
accounts will be stored.
Samba maintains its own database of user
accounts that are used to authenticate to the
service.
The user accounts in your /etc/passwd file
are not directly used by Samba. However,
they can be mapped over to your Samba
database of user accounts.
The options for storing your Samba users
include /etc/samba/smbpasswd and LDAP.
Version 1 144
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Use Sambas Client Tools Linux workstations can access Samba shares.
Samba provides a variety of tools that you can
use to access shares from a Linux system.
These tools can be used to access a Samba
server or a native Windows server.
These tools include nmblookup, smbclient,
and the mount command.
Objective Summary
145 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 6 Configure and Use IPv6
IPv6 (Internet Protocol Version 6) was designed by the Internet Engineering Task
Force (IETF) to replace the current Internet Protocol version, IPv4. IPv6 not only
overcomes the most obvious shortcoming of IPv4, the imminent shortage of available
IP addresses, but also adds improvements in other areas, like routing and network
autoconfiguration.
This section explains IPv6 and its configuration on SUSE Linux Enterprise Server 11.
Objectives
1. Understand IPv6 Theory on page 146
2. Configure IPv6 on SLE 11 on page 151
Version 1 146
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Understand IPv6 Theory
During recent years, the end of IPv4 has often been predicted, but IPv4 has proven
remarkably resilient. The use of private address ranges within private and company
networks made it possible to use the remaining IPv4 addresses in a more efficient
manner, and classless interdomain routing (CIDR) helped to slow the growth of the
size of routing tables.
However, as more and more devices become able to connect to the internet, the
limitations of IPv4 become more and more relevant. It is not a question of if the shift
to IPv6 has to happen, it is only a question of when.
Within the context of IPv6, you need to understand:
IPv6 Features on page 146
IPv6 Addresses on page 146
IPv6 Address Types on page 147
IPv6 Features
IPv6 addresses the shortcomings of IPv4 with features that include the following:
Increased address space. In IPv4, an IP address is 32 bits long, which is allows up
to about four Billion addresses. In IPv6, an IP address is 128 bits long, which
allows for a really huge number of addresses:
340,282,366,920,938,463,463,374,607,431,768,211,456 (or 3.4 * 10
38
or, in the
US system, 340 undecillions).
To give you some idea of what this number means, it in theory allows about
650 * 10
21
addresses for every square meter of the surface of earth. For practical
purposes, as not every address will be used for hosts, certainly more than 1,500
addresses remain for every square meter of earths surface.
Improvements in routing capabilities.
Simplified header.
Quality of Service (QoS) capabilities.
Authentication and privacy capabilities.
Flexible transition from IPv4 to IPv6 over a longer period of time.
IPv6 Addresses
IPv6 addresses consist of 128 zeroes and ones, which is very unwieldy for humans.
To make them somewhat easier to deal with, they are represented in hexadecimal
format, with four bits (a nibble) represented by digits or characters from 0-9 and a-
f (10-15). To improve readability, a colon is inserted after every four hexadecimal
values (representing 16 bits):
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
A possible address could look like the following:
147 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
fe80:0000:0000:0000:0211:11ff:fec2:35f4
For simplification, leading zeroes in each block can be omitted, and one sequence of
16 bit blocks containing only zeroes can be replaced by ::. The above address
could, therefore, be written as follows:
fe80::211:11ff:fec2:35f4
As another example, the localhost address
0000:0000:0000:0000:0000:0000:0000:0001
can be shortened to
::1
IPv6 Address Types
IPv6 addresses can serve different purposes, such as multicast or unicast addresses.
Different leading bits, such as fe80 in one of the examples above, indicate different
types of addresses.
One interface can have more than one IPv6 address.
Similar to IPv4 addresses, IPv6 addresses can be split into network and host parts
using subnet masks. The notation is similar to the CIDR notation used with IPv4:
fe80::211:11ff:fec2:35f4/64
The corresponding network address is
fe80:0000:0000:0000:0000:0000:0000:0000
with a netmask of:
ffff:ffff:ffff:ffff:0000:0000:0000:0000
To be able to differentiate the different IPv6 address types, you need to understand
the following:
Addresses without a Specific Network Prefix on page 147
Network Addresses on page 148
Host Addresses on page 149
Addresses without a Specific Network Prefix
Addresses without a specific network prefix comprise the following:
Localhost on page 147
Unspecified Address on page 148
Localhost
The address for the loopback interface, similar to 127.0.0.1 in IPv4, is
0000:0000:0000:0000:0000:0000:0000:0001
Version 1 148
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Packets with this address as source or destination are not supposed to leave the
machine.
Unspecified Address
This is the IPv6 equivalent to 0.0.0.0 (or any) in IPv4:
0000:0000:0000:0000:0000:0000:0000:0000
or in short:
::
This address is, for instance, seen in the output of netstat:
The third colon in the output above separates the address from the port number.
Network Addresses
The network addresses are used to distinguish the following categories:
Link Local Addresses on page 148
Globally Unique Local IPv6 Unicast Addresses on page 148
Global Address Type global unicast on page 149
Link Local Addresses
Link local addresses are valid only on a link of an interface. A packet with a link local
address would not pass a router. They begin with the following (x is any hex
character, but usually 0):
fe8x (this is the only one currently in use)
fe9x
feax
febx
Such an address can be found on each IPv6-enabled interface after stateless
autoconfiguration. It is used for link communications, for instance, to find out if
anyone else is on this link or to locate a router.
Globally Unique Local IPv6 Unicast Addresses
This address type begins with fdxx. (It could also begin with fcxx, but currently this
prefix is not used.)
A part of the prefix (40 bits) is generated using a pseudo-random algorithm
(described in RFC 4193). While it is not impossible that two generated prefixes are
da10:~ # netstat -atun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 :::80 :::* LISTEN
tcp 0 0 :::22 :::* LISTEN
149 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
equal, it is improbable. Therefore, connecting networks that were formerly
independent is not likely to cause problems, as their prefixes will be different.
The Global ID is followed by a 16-bit Subnet ID as an identifier within a site. The
following illustration, taken from RFC 4193, shows the different parts of a globally
unique local IPv6 Unicast address:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+--------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+--------------------+
NOTE: There used to be a site local address type, starting with fecx, fedx, feex, or fefx. However,
its use is deprecated in RFC 3879 and it is replaced by the above.
Global Address Type global unicast
Addresses delegated to Internet Service Providers (ISP) currently begin with
2001:
The following addresses are reserved for examples and documentations and should
be filtered on border routers to the Internet:
3fff:ffff::/32
2001:0DB8::/32
Addresses for tunneling IPv6 packets in IPv4 packets begin with
2002:
Multicast addresses start with ffxy, where x is hex number and y indicates the scope
(such as y=1: node local, y=2: link local, y=3: site local).
Depending on the host part of the address, different multicast types are addressed
(RFC 4291 / IP Version 6 Addressing Architecture):
All Nodes Address: 1. Addresses all hosts on the local node (ff01:0:0:0:0:0:0:1)
or the connected link (ff02:0:0:0:0:0:0:1).
All Routers Address: 2. Addresses all routers on the local node
(ff01:0:0:0:0:0:0:2), the connected link (ff02:0:0:0:0:0:0:2), or the local site
(ff05:0:0:0:0:0:0:2).
There are other types, like anycast addresses, that are not covered in this course.
Host Addresses
The host address can be automatically computed or set manually.
Automatically Computed Host Address on page 150
Manually Set Host Address on page 150
Version 1 150
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Automatically Computed Host Address
When automatically computed, the MAC address is used and expanded according to
the IEEE-Tutorial Extended Unique Identifier EUI-64 (http://standards.ieee.org/
regauth/oui/tutorials/EUI64.html).
For instance, with a MAC address of 00:11:11:C2:35:D4, the resulting 64-bit
interface identifier is 0211:11ff:fec2:35d4. Together with a network prefix (for
instance, one used for Globally Unique Local IPv6 Unicast Addresses), the following
IPv6 address results:
fd7b:5c7e:40bf:1234:0211:11ff:fec2:35d4
NOTE: The above way of creating the interface identifier has some privacy implications, especially
for mobile devices. When connecting to the Internet using different providers, the network part of
the address changes, while the interface identifier remains the same. This can allow tracking of the
mobile device. RFC 4941 describes ways to mitigate this issue.
Manually Set Host Address
Simpler addresses might be easier to remember and, for instance, for some servers
you might want such an address. It is possible to assign an additional address to the
interface, such as
fd7b:5c7e:40bf:1234::1
In the automatically generally set address, the seventh most significant bit (with the
count starting with 1) of the host address is set to 1 when calculating the automatic
address. It is required to set this bit to 0 when setting a host address manually. The
reason for this is, first of all, convenience, as otherwise the above address would be
fd7b:5c7e:40bf:1234:0200::1
instead of
fd7b:5c7e:40bf:1234::1
Also some other bit combinations are reserved for anycast addresses, such as all host
bits set to 0 for the subnet router.
NOTE: The Linux IPv6 HOWTO (http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/) contains
a lot more information on IPv6.
151 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Configure IPv6 on SLE 11
From the kernel to various applications, SLES 11 and SLED 11 support IPv6.
To configure IPv6 on SLE 11, you need to understand the following:
IPv6 Autoconfiguration on page 151
Setting an IPv6 Address Using YaST on page 153
Managing IPv6 Addresses Using the Command Line Tools on page 155
Connecting to Other IPv6 Addresses on page 155
Configure IPv6 on page 161
IPv6 Autoconfiguration
One design goal of IPv6 was to make IP autoconfiguration easier. Even without a
DHCP server, interfaces can obtain a valid IP address.
In the context of IPv6 autoconfiguration, you need to understand the following:
Link Local Autoconfiguration on page 151
Stateless Autoconfiguration on page 152
Link Local Autoconfiguration
By default, a link local address is configured automatically for every network
interface in SLE 11:
You can use this address to test the link using ping6:
When pinging a link local address, the option -I interface is required, as every
interface has a link local address and the kernel doesnt know which one to use.
da10:~ # ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 100
link/ether 00:19:d1:9f:17:f4 brd ff:ff:ff:ff:ff:ff
inet6 fe80::219:d1ff:fe9f:17f4/64 scope link
valid_lft forever preferred_lft forever
da10:~ # ping6 -I eth0 fe80::219:d1ff:fe9f:1787
PING fe80::219:d1ff:fe9f:1787(fe80::219:d1ff:fe9f:1787) from
fe80::219:d1ff:fe9f:17f4 eth0: 56 data bytes
64 bytes from fe80::219:d1ff:fe9f:1787: icmp_seq=1 ttl=64 time=5.47
ms
Version 1 152
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
You can detect IPv6 active hosts by using ping6 to the link local, all-node multicast
address:
Unlike in IPv4, where replies to a ping to the broadcast address can be disabled using
the /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts file, this behavior cannot be
disabled currently in IPv6, except by local IPv6 firewalling.
Stateless Autoconfiguration
To access the Internet, a host needs an IPv6 address with global scope. The steps to
obtain such an address are as follows:
1. Using its link-local address, the host sends a Solicitation Message to the ff02::2
multicast address (all routers on the local link), asking for an IPv6 prefix.
2. The router answers this Solicitation Message with an Advertisement Message
containing an address prefix for this network.
3. Using this prefix and its MAC address, the host creates an IPv6 address.
4. Using Duplicate Address Detection (DAD, RFC 4862), the host checks if the
address is already in use in the network.
If the address is unused, the host assigns the address to the NIC and activates it.
5. The client can now contact other hosts within the local network using their IPv6
addresses and, depending on the network topology, hosts outside the local
network as well.
The router distributes the network prefix and information on the default route only.
Information that goes beyond this, such as information on DNS or other routes, needs
to be added manually to the configuration or distributed using DHCP6.
da10:~ # ping6 -I eth0 ff02::1
PING ff02::1(ff02::1) from fe80::219:d1ff:fe9f:17f4 eth0: 56 data
bytes
64 bytes from fe80::219:d1ff:fe9f:17f4: icmp_seq=1 ttl=64 time=0.020
ms
64 bytes from fe80::219:d1ff:fe9f:1787: icmp_seq=1 ttl=64 time=5.09
ms (DUP!)
153 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Setting an IPv6 Address Using YaST
To set an IPv6 address manually (which is necessary, for instance, on a router), you
use the same dialog in YaST that is used to set IPv4 addresses. The following shows
the dialog that appears during installation:
Figure 6-1 Network Card Setup
Type the IPv6 address in its usual format and the netmask in the CIDR notation, such
as /64, as shown in the figure above.
Version 1 154
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Select Next. The data you typed appears in the Network Settings Overview:
Figure 6-2 Network Settings Overview
Click OK to close the dialog. YaST writes the configuration information to files in /
etc/sysconfig/network/, such as the ifcfg-eth0 file.
After installation, you can reach the same dialogs by selecting Computer > YaST >
Network Devices > Network Settings.
The settings are written to the /etc/sysconfig/network/ifcfg-ethx file,
as shown below:
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='fd7b:5c7e:40bf:1234::2/64'
MTU=''
NAME='82566DM Gigabit Network Connection'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
NETMASK=''
155 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Managing IPv6 Addresses Using the Command Line Tools
The ip command can be used for both, IPv4 and IPv6 addresses. The following
examples demonstrate the use of the ip command for IPv6. Use the following
command to add an IPv6 address:
The current configuration is displayed using the ip address show command
(address and show can be shortened to their first letter). Adding the option -6
limits the output to IPv6 addresses:
To delete an address, use ip address delete:
The ip command is also used to view, set, and delete routes.
ip -6 route show displays the current routing table:
Connecting to Other IPv6 Addresses
If your Internet Service Provider (ISP) supplies you with an IPv4 as well as an IPv6
address, you can connect to both worlds without problems.
If you get an IPv4 address only, there are two possible approaches to connect to IPv6
addresses:
6to4-Tunneling on page 155
6in4-Tunneling on page 160
6to4-Tunneling
At the time of this writing, ISPs do not yet provide IPv6 addresses as a general
practice. However, as one of the design goals of IPv6 was to make a smooth
transition from IPv4 to IPv6 possible, you start using IPv6 immediately even if you
get only an IPv4 address from your ISP.
da10:~ # ip -6 addr add fd7b:5c7e:40bf:1234::2/64 dev eth0
da10:~ # ip -6 a s
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 100
inet6 fd7b:5c7e:40bf:1234::2/64 scope global
inet6 fe80::219:d1ff:fe9f:17f4/64 scope link
da10:~ # ip -6 add del fd7b:5c7e:40bf:1234::2/64 dev eth0
da10:~ # ip -6 ro sh dev eth0
fd7b:5c7e:40bf:1234::/64 proto kernel metric 256 mtu 1500 advmss
1440 hoplimit 4294967295
fe80::/64 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit
4294967295
Version 1 156
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Following the method outlined in RFC 3056, a site with a globally unique IPv4
address can be assigned a globally unique IPv6 address based on its IPv4 address.
This is considered an interim solution until the ISP assigns a native IPv6 prefix.
IPv6 addresses used for this purpose have the following format (taken from RFC
3056):
| 3 | 13 | 32 | 16 | 64 bits |
+---+------+-----------+--------+--------------------+
|FP | TLA |IPv4 Addr | SLA ID | Interface ID |
|001|0x0002| | | |
+---+------+-----------+--------+--------------------+
All such addresses, therefore, start with 2002. The abbreviations used above have the
following meaning:
FP: Format prefix
TLA: Top level aggregator
IPv4 Addr: Globally unique IPv4 address (converted to Hex format)
SLA ID: Site level aggregator ID
The other end of the tunnel needs to be capable of dealing with the packetstaking
the IPv6 packet out of the IPv4 packet and then routing it within the IPv6 network.
To facilitate the use of IPv6, the IPv4 anycast address 192.88.99.1 is used to reach the
nearest 6to4 relay router.
Depending on your network topology, you need to do one of the following:
Configure a 6to4 Tunnel on a Host on page 157
Connect the Network behind your 6to4 Gateway on page 158
Install and Configure radvd on page 158
Add a Route to Your 6to4 Gateway on page 159
157 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Configure a 6to4 Tunnel on a Host
Assuming a unique IPv4 address of 1.2.3.4, the steps to configure a 6to4 tunnel are as
follows:
1. Make sure there is a sit0 device visible in the output of ip link show; if not,
load the sit kernel module:
2. Calculate the IPv6 address corresponding to your IPv4 address.
The following command can be used:
3. Create a new tunnel device.
In the example below it is called tun6to4, but you could use some other name for
it as well:
4. Bring the interface up and set the MTU:
5. Add your local IPv6 address to the tunnel interface using a prefix length of 16:
da10:~ # ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
qlen 1000
link/ether 00:11:11:c2:35:f4 brd ff:ff:ff:ff:ff:ff
da10:~ # modprobe sit
da10:~ # ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
qlen 1000
link/ether 00:11:11:c2:35:f4 brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
da10:~ # ipv4="1.2.3.4"; printf \
"2002:%02x%02x:%02x%02x::1" ècho $ipv4 | tr "." " "`
2002:0102:0304::1
da10:~ # ip tunnel add tun6to4 mode sit ttl 63 remote any \
local 1.2.3.4
da10:~ # ip link set dev tun6to4 mtu 1280 up
da10:~ # ip -6 addr add 2002:0102:0304::1/16 dev tun6to4
Version 1 158
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
6. Add a route to the global IPv6 network using the IPv4 anycast address for all
6to4 routers:
7. Test the connection using ping6 to an IPv6-enabled site.
(http://www.ipv6.org/) has a link to a list with such sites. (At the time of this
writing www.ipv6.org itself also has an IPv6 address.)
Connect the Network behind your 6to4 Gateway
If you have a second NIC on your host acting as your 6to4 gateway and want to IPv6-
enable the network connected to that NIC, there are a few additional steps you need
to take.
Install and Configure radvd
Add a Route to Your 6to4 Gateway
Install and Configure radvd
When connecting a network to the second NIC of your 6to4 gateway, that host takes
the function of a router. The Router Advertisement Daemon radvd distributes the
autoconfiguration information the clients need to configure their IPv6 addresses
automatically.
The Router Advertisement Daemon is contained in the radvd package, which can be
installed with the command yast -i radvd. Its configuration is contained in the
/etc/radvd.conf file and looks similar to the following:
interface eth0
{
AdvSendAdvert on;
# These settings cause advertisements to be sent every 3-10
# seconds. This range is good for 6to4 with a dynamic IPv4
# address, but can be greatly increased when not using 6to4
# prefixes.
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
# You can use AdvDefaultPreference setting to advertise the
# preference of the router for the purposes of default
# router determination. NOTE: This feature is still being
# specified and is not widely supported!
#
AdvDefaultPreference low;
# Disable Mobile IPv6 support
#
AdvHomeAgentFlag off;
# example of a standard prefix
#
da10:~ # ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4
159 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
prefix 2002:0102:0304:1234:/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};
The above example is suitable for a fixed IPv4 address. The configuration file that is
contained in the radvd package also includes an example on how to deal with
dynamic IP addresses that change every time a new connection is established with the
ISP.
Before starting radvd, it is necessary to turn on IPv6 forwarding. This is done with the
following command:
If you want IPv6 forwarding to be turned on every time the system boots, set the
variable IPV6_FORWARD in the /etc/sysconfig/sysctl file to yes:
## Type: yesno
## Default: no
#
# Runtime-configurable parameter: forward IPv6 packets.
#
IPV6_FORWARD="yes"
After IPv6 forwarding is turned on, you can start radvd using the command
rcradvd start.
Add a Route to Your 6to4 Gateway
For packets to be routed properly, the following route has to be set on your gateway
host:
1234 in the above command (and in the radvd.conf file) is the site level aggregator;
you can choose this according to your local networking needs.
NOTE: After the above steps are complete, all machines in your network can access IPv6 hosts in
the Internet and all machines in your network are accessible from the Internet using IPv6. You
should set appropriate ip6tables filter rules to prevent attacks on the hosts within your network.
In case you are connected to the Internet using a DSL connection, edit the /etc/
radvd.conf file according to the comments in that file that cover dynamic Internet
connections.
da10:~ # echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
da10:~ # ip -6 route add 2002:0102:0304:1234:/64 dev eth0
Version 1 160
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When using DSL, you can include the commands to set up the 6to4 tunnel in the /etc/
ppp/ip-up.local file:
# /etc/ppp/ip-up.local
# Build IPv6 Tunnel
/sbin/modprobe sit
# $4 contains the local IP on the ppp interface.
/sbin/ip tunnel add tun6to4 mode sit ttl 63 remote any \ local $4
/sbin/ip link set dev tun6to4 mtu 1280 up
# $4 contains the local IP on the ppp interface.
/sbin/ip -6 addr add $(printf \ "2002:%02x%02x:%02x%02x::1/16" ècho
$4 | tr "." " "`) \ dev tun6to4
/sbin/ip -6 route add 2000::/3 via ::192.88.99.1 dev \ tun6to4
# Reload Router Advertisement Daemon to make it advertise
# the new prefix.
/usr/sbin/rcradvd reload
# Set IPv6 route accordingly.
ip -6 route add $(printf "2002:%02x%02x:%02x%02x:1234::/64" ècho $4 |
tr "." " "`) dev eth0
The /etc/ppp/ip-down.local file would include the commands to take the tunnel down
when the DSL connection is disconnected:
# /etc/ppp/ip-down.local
# Take down the tun6to4 tunnel
/sbin/ip -6 route flush dev tun6to4
/sbin/ip link set dev tun6to4 down
/sbin/ip tunnel del tun6to4
6in4-Tunneling
Another approach to access IPv6-based Internet hosts is to enlist the services of a
tunnel broker. In this case, a point-to-point connection is established to the IPv6
network using an IPv4 UDP-based tunnel. The advantages of this method are that no
unique IPv4 address is required and it works from behind a NAT gateway as well.
A nonprofit provider that offers IPv6 tunnels and the needed software for various
operating systems including Linux to interested end users is http://www.sixxs.net/
(http://www.sixxs.net/).
There are certainly other providers that offer a similar service.
6in4 tunneling is not covered in this course. Before you use it, make sure that you
have the agreement of your network administrator, as building tunnels through
firewalls often violates existing security policy.
161 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 6-1 Configure IPv6
In this exercise, you configure and use different aspects of IPv6.
(End of Exercise)
Version 1 162
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Understand IPv6 Theory IPv6 addresses are 128 bits long.
Depending on the network prefix, different kinds of
address types exist, such as link local or global unicast
addresses.
The host part of the address can be set automatically,
using the MAC address of the NIC, or manually.
Configure IPv6 on SLE 11 SLE 11 supports IPv6.
In a private network, radvd allows easy assignment of
IPv6 addresses.
Even if your ISP does not assign you a native IPv6
address, 6to4 tunneling allows you to access IPv6
addresses.
163 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 7 Deploy SUSE Linux Enterprise 11
This section explains how to deploy SUSE Linux Enterprise 11 (SLE11), which
refers to both SUSE Linux Enterprise Server 11 (SLES11) and SUSE Linux
Enterprise Desktop 11 (SLES11). Which deployment method you choose will depend
to a large degree on the number of desktops or servers you want to deploy. The
installation of hundreds of machines requires a different approach than the
installation of just one or a few.
Objectives
1. Introduction to AutoYaST on page 164
2. Installation Server: Setup and Use on page 168
3. Set Up PXE Boot for Installations on page 181
4. Create a Configuration File for AutoYaST on page 191
5. Perform an Automated Installation on page 195
Version 1 164
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Introduction to AutoYaST
This objective covers the basic concept of automated installation. Later objectives go
into the details of setting up an environment that makes automated installations easy
and explains how to configure the AutoYaST control file.
To get a better idea what automated installations are about on SUSE Linux Enterprise
11, you need to understand the following:
Autoinstallation Basics on page 164
Installation Options and Deployment Strategies on page 165
Autoinstallation Basics
AutoYaST is the tool for automated installations of SUSE Linux Enterprise 11. All
information needed during installation (e.g., partitioning or software selection) is
provided by a control file in XML format. No manual intervention is necessary
during the installation process.
If you have to install several systems with the same setup, you can save time by
automating the installation. Depending on your requirements, you can ensure all
systems are set up with the same configuration or configure systems individually with
specific control files.
You should not confuse auto installation with cloning or imaging. An automated
installation is a regular installation where answers to questions asked during the
installation are contained in the control file. The hardware detection is still done so
that the same control file can be used on diverse hardware. Imaging or cloning
generally requires identical hardware of source and target of the image.
AutoYaST is optimally used in conjunction with an installation server also providing
a TFTP and a DHCP server. The advantages to this are the following:
To start the installation, you only have to insert a suitable boot disk. If you are
using PXE boot-enabled network interface cards, not even a boot disk is
required.
The computer receives all information necessary for the installation via the
network.
Even on-site attendance of an administrator is unnecessary for the installation if
the network card supports Wake on Lan.
The installation server can be accessed via the NFS, HTTP, FTP, and CIFS/SMB
protocols.
This results in a highly simplified installation of a large number of individually
configured computers.
AutoYaST can also be used to copy additional files into the installed system, and it
can include scripts which are executed at the end of the installation.
It is possible to create a control file at installation time. In the last menu of the
installation process, you can select the Clone This System option. This will create an
165 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
autoinst.xml file in the home directory of the root user (/root). The creation of an
AutoYaST control file using the YaST AutoYaST module is covered later in this
section.
Installation Options and Deployment Strategies
For a single machine, a manual installation using the installation DVD is certainly the
best option. However, alternatives are needed when the number of machines to install
increases.
The installation can be started using the SUSE Linux Enterprise Desktop or Server 11
DVD, a PXE capable network card, or boot floppy disks. The installation source can
be the DVD itself as well as an installation server in the network. The supported
protocols for accessing the repository on the installation server are NFS, HTTP, FTP,
and SMB/CIFS.
To find the optimum solution for your needs, you have to understand the following:
Installation Options on page 165
Deployment Strategies on page 166
Installation Options
SUSE Linux Enterprise 11 can be installed in various ways. There are three aspects
you need to consider:
Boot Media on page 165
Installation Source on page 166
Boot Media
To install a machine, you have to choose a boot medium to boot the machine.
Installation DVD
The installation DVD is bootable and can be used to start the installation or to
boot a rescue system.
Different kernel parameters can be set if there is trouble with the default
parameters. For example, it is possible to disable ACPI or local APIC or to use
safe settings.
PXE capable network card
If the machine is equipped with a PXE capable network card, it can load the boot
image from a TFTP server in the network. If the network card also supports
Wake on Lan, a completely remote installation is possible.
Floppy or USB disk
If your hardware supports it, you can use floppy disks or an USB device to boot
the machine. However, current computers are generally not equipped with floppy
drives any more, and not all BIOSes allow booting from USB devices.
Version 1 166
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To create boot floppy disks or make a USB stick bootable, run the mkbootdisk
command in the boot/i386 directory of the installation DVD. mkbootdisk --
help displays the needed options and syntax.
Installation Source
You can use different installation sources:
Installation DVD
The installation DVD contains all files needed to install SUSE Linux Enterprise
Desktop or Server 11.
Installation Server
The files needed for installation can be stored on a server in the network.
Protocols that can be used are HTTP, FTP, NFS, or SMB/CIFS. SLP can be used
to advertise the installation server in the network.
Deployment Strategies
Your deployment strategy will depend to a large degree on the number of machines to
deploy. Lets consider three different orders of magnitude:
Deploy up to 10 Workstations on page 166
Deploy up to 100 Workstations on page 166
Deploy More than 100 Workstations on page 167
Deploy up to 10 Workstations
If you have to deploy only a few workstations, it might not be worth the effort to set
up an installation server, much less to create an AutoYaST control file.
The approach that takes the least preparation is a manual installation using the
installation DVD. As an installation server is very convenient and does not take long
to set up, you might still consider using one. Additional installations will be
facilitated and also adding software to existing installations later will not require the
installation DVD to be at hand.
Setting up an installation server is covered in Installation Server: Setup and Use
on page 168.
Deploy up to 100 Workstations
If you have to deploy more than 10 workstations, an installation server and the use of
the remote installation capabilities of SUSE Linux Enterprise 11 greatly facilitate the
task.
While physical access to the machines is still required to boot them, you do not need
to sit in front of each machine during the whole installation. Using remote access via
VNC or SSH, the administrator can control the installation of different machines at
the same time from his workstation.
167 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Setting up DHCP and TFTP servers in addition to the installation server makes it
unnecessary to physically access the machines to boot them, provided the hardware
allows booting from the network as well as Wake on Lan. Without AutoYaST, you
would still have to configure them manually via the network.
The more machines you have to install, the more worthwhile it becomes to avoid the
manual configuration. The effort to create and test workable AutoYaST control files
is outweighed by the reduced time spent on configuring individual machines.
Deploy More than 100 Workstations
With so many machines, walking from machine to machine to install them all is no
longer an option. Even remote configuration becomes cumbersome.
The roll-out of a large number of machines is facilitated by AutoYaST. AutoYaST
controls the installation with an XML file which contains the machine specific
information, like IP address, hostname, partitioning, etc. Manual intervention during
the installation process is unnecessary.
AutoYaST allows you to create profiles containing all configuration information. As
the hardware detection of YaST is used during installation, the same file can be used
to install machines with dissimilar hardware.
If the differences in hardware are significant, it is also possible to create rules that
determine which of several AutoYaST files should be used for the hardware found.
Not only the hardware can serve as criteria, but other parameters like IP addresses
can be used as well. You could create different profiles for development workstations
and for workstations used in HR, and then base the decision of which profile to use
for installation on the IP address the workstation gets via DHCP.
Version 1 168
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Installation Server: Setup and Use
An installation server offers the files needed for the installation of SUSE Linux
Enterprise Desktop or Server 11 via the network. To provide such a server in your
network, you need to understand how to do the following:
Set Up an Installation Server on page 168
Use the Installation Server on page 179
Set Up an Installation Server on page 180
Set Up an Installation Server
The installation repository requires the same layout of directories and files as the
layout on the installation DVD.
The most convenient way to set up such an installation repository is to use SUSE
Linux Enterprise Server 11 and its YaST Installation Server module. This module
creates the necessary directory structure, prompts to insert the DVD to copy its
content to the proper directories, and sets up the server (NFS, HTTP, FTP) used to
distribute the files.
NOTE: Using SUSE Linux Enterprise Desktop 11 as an installation server is also possible, but you
have to set up the server manually because there is no YaST module for this purpose included in the
Desktop distribution.
The following steps are required:
Fill the Installation Repository on page 168
Make Add-on-Products Available on page 169
Fill the Installation Repository
First create a directory where you want to store the installation repository, such as /
srv/install-repo/sled11 for SLED11, using the command mkdir -p /
srv/install-repo/sled11.
Filling the repository is very simple: Just insert the SUSE Linux Enterprise Desktop
11 installation DVD and copy all files on it to the repository:
cp -a /media/SUSE_SLED-11-0-0.001/* /srv/install-repo/
sled11
NOTE: The same procedure is used for SUSE Linux Enterprise 11 service packs, as they replace the
original installation media.
169 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Make Add-on-Products Available
In addition to the packages available for installation on the DVD, it is possible to
make further packages available. The directory structure described in the following
can be used for updates, add-on products, or RPM packages of your own.
You can set up the add-on products repository using the YaST Add-On Creator
module or command line commands.
To access the add-on products repository during the automatic installation, you can
either include a pointer to it in the AutoYaST control file or add an
add_on_products.xml file to the root of your product installation repository.
This manual covers the following two approaches:
Yast Add-On-Creator Module and autoinst.xml on page 169
Manual Creation of Repository and add_on_products.xml file on page 175
Yast Add-On-Creator Module and autoinst.xml
The YaST Add-On Creator module guides you through the steps necessary to create a
repository with the correct layout of directories and files. Take the following steps to
create an add-on repository and to modify your control file:
1. (Conditional) If you have not created a gpg key pair, in a terminal window (as
root) enter the command
gpg --gen-key
and follow the prompts to create your own key pair.
2. Copy the RPM files you want to include in your add-on repository to a temporary
directory, such as /tmp/repo-files.
3. Start YaST and select Miscellaneous > Add-On Creator.
Version 1 170
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following dialog appears:
Figure 7-1 Add-On Product Creator
To create an add-on repository from scratch, select Create an Add-On from the
Beginning and click Next.
4. In the Add-On Product Creator dialog that appears, fill in the text boxes with
the name and version of your repository and the directory that holds your RPM
files.
171 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The dialog will look similar to the following.
Figure 7-2 Add-On Product Creator
To continue click Next.
Version 1 172
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
A Product Definition dialog appears, as shown in the following:
Figure 7-3 Product Definition
5. In the Product Definition dialog, select Vendor and click Edit. In the dialog that
appears, enter a vendor name, such as your company name or the name of the
provider of the RPM files.
In the Product Definition dialog click Next.
The Package Descriptions dialog appears.
6. The Package Descriptions dialog lists the packages that are part of your add-on
repository. To continue click Next.
The Editor for Patterns dialog appears.
7. In the Editor for Patterns dialog, you can create Patterns for your add-on
products. To continue click Next.
173 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The Output Settings dialog appears, as shown in the following:
Figure 7-4 Output Settings
8. In the Path to Output Directory text box, type the directory where you want
your add-on product repository to reside.
To continue click Next.
A Signing the Add-On Product dialog appears.
9. In the GPG Key ID text box, type the ID, such as the e-mail address you entered
during the creation of your key pair, of the GPG key you want to use to sign the
content file in the root of the repository.
Type the passphrase to unlock the private key and click Next to continue.
An Overview dialog appears.
10. In the Overview dialog review your settings and click Finish.
Version 1 174
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
An Add-On Creator Overview dialog appears, as shown in the following:
Figure 7-5 Add-On Creator Configuration Overview
11. In the Add-On Creator Overview, click Build.
(Optional) If a message appears that informs you that the obs-productconverter
package needs to be installed, click Install.
The directory structure for the repository is created, the RPMs are copied to their
correct location and content files in the root of the repository are created and
signed.
12. Click Finish to close the Add-On Creator module.
13. Open the AutoYaST profile used to install machines in an editor and add the
following lines below the line starting with <profile ...
<add-on>
<add_on_products config:type="list">
<listentry>
<media_url>nfs://172.17.8.1/srv/install-repo/Add-On</
media_url>
<product>My Add-Ons</product>
<product_dir>/</product_dir>
<name>My Add-Ons</name>
</listentry>
</add_on_products>
</add-on>
14. In the AutoYaST profile, look for the line
<import_gpg_key config:type="boolean">false</import_gpg_key>
175 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Change the value from false to true. The line should look like the following:
<import_gpg_key config:type="boolean">true</import_gpg_key>
Save the file and close the editor.
NOTE: The creation of an AutoYaST profile is explained in Create a Configuration File for
AutoYaST on page 191.
Manual Creation of Repository and add_on_products.xml file
Instead of using YaST, you can also use command line tools to create the repository
layout and files. If you want to use an add_on_products.xml file in the root
directory of the product installation repository, you have to sign a file containing a
checksum of the add_on_products.xml file and to include the GPG public key in the
initial ramdisk used during installation.
NOTE: When you use an add_on_products.xml file as described in the following steps it is
not necessary to add an <add-on> ... </add-on> section to the AutoYaST profile used to
install the individual machines.
Take the following steps to set up your repository and use the add_on_products.xml
file during installation:
1. (Conditional) If you have not created a gpg key pair, in a terminal window (as
root) enter the command
gpg --gen-key
and follow the prompts to create your own key pair.
2. Install the inst-source-utils package if it is not yet installed by entering the
following as root in a terminal window:
rpm -q inst-source-utils || yast -i inst-source-utils
3. Run the following command with the root of your installation repository as
argument:
This will create the updates and yast directories with several subdirectories
and files within your installation repository.
NOTE: Despite the fact that the directory created is named updates, it can be used for add-on
products as well.
4. Using the mkdir -p command, create the updates/suse/
architecture/ directory and copy any RPM files you want to make
available to that directory.
da10:~ # create_update_source.sh /srv/install-repo/sled11/
Creating /srv/install-repo/sled10//updates.....
Version 1 176
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NOTE: The following steps have to be repeated every time you change the content of this
directory (i.e., add or delete files to it).
5. Change to the updates/suse directory and run the following command:
This creates the packages, packages.DU, and packages.en files in the
updates/suse/setup/descr directory.
6. Change to the directory updates/suse/setup/descr and create an
updated directory.yast file:
7. Change back to the updates directory and run the create_sha1sums -x
-n command.
The result is a contents file that contains SHA1 hashes for the files created in
the previous step:
8. Create an add_on_products.xml file in the root of your installation
repository that points to the servers and directories with add-on products:
da10:/srv/install-repo/sled11 # cd updates/suse
da10:/srv/install-repo/sled11/updates/suse #
da10:/srv/install-repo/sled11/updates/suse # create_package_descr
-x setup/descr/EXTRA_PROV
using settings:
datadirs: .
languages: english
output dir: ./setup/descr/
is not a directory: ignoring
extra_provides: setup/descr/EXTRA_PROV
done
processed 1 packages
now recoding to UTF-8: packages packages.DU packages.en
da10:/srv/install-repo/sled11/updates/suse #
da10:/srv/install-repo/sled11/updates/suse/setup/descr # ls > \
directory.yast
da10:/srv/install-repo/sled11/updates/ # create_sha1sums -x -n
da10:/srv/install-repo/sled11/updates/ # cat content
CONTENTSTYLE 11
...
SUMMARY SUSE Linux Enterprise Server
VENDOR SUSE LINUX Products GmbH, Nuernberg, Germany
VERSION 11
META SHA1 b907a3d5593c3a2f0108f9ba27e3c5b8ef0121d5 packages
META SHA1 4a0c3656cd8c61a68cccf2c75ec83f1f132556ec packages.DU
META SHA1 94e8d1bf3d7b53fd7c8ce32d6f6ea70cf47ede87 packages.en
177 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
xmlns:config="http://www.suse.com/1.0/configns">
<product_items config:type="list">
<product_item>
<name>SLED11 Add-on</name>
<url>nfs://172.17.8.1//srv/install-repo/sled11/
updates</url>
<path>/</path>
<ask_user config:type="boolean">false</ask_user>
<selected config:type="boolean">true</selected>
</product_item>

<product_item />
</product_items>
</add_on_products>
9. Create a file containing the SHA1 sum of the add_on_products.xml file.
With SLE 11, every file on the installation source needs a checksum in a content
or a SHA1SUMS file, and those files have to be digitally signed. These
signatures are checked during installation. For your own repositories, you need to
sign them and make the signing key available during installation.
Run the sha1sum command to create the checksum:
10. Sign the SHA1SUMS file with the gpg command:
NOTE: If you have several private keys, use the -u username option to specify the key.
This command creates the SHA1SUMS.asc file that contains the digital
signature.
Every time you change the add_on_products.xml file, you have to create a
new SHA1SUMS file and digitally sign it again.
11. Sign the content file you created in Step 7 with gpg as well.
12. The key to verify the signatures has to be available in the root of the installation
repository. You also have to update the directory.yast file in the root
directory of your installation repository.
da10:/srv/install-repo/sled11/ # sha1sum add_on_products.xml >
SHA1SUMS
da10:/srv/install-repo/sled11/ # cat SHA1SUMS
e13af51a0b1993bf20d597408c457681aea382c0 add_on_products.xml
da10:/srv/install-repo/sled11/ # gpg -b --sign --armor SHA1SUMS
Version 1 178
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Run the following commands:
13. The last step is to include your public key in the initrd.
In addition to the root directory of the installation repository, the key used to
verify the signatures (SHA1SUMS.key from the previous step) has to be
available with a .gpg file extension in the root (/) directory of the initrd used
during installation.
The initrd is in the /boot/i386/loader/ directory on the installation DVD.
Copy the initrd and my-key.gpg to a directory of your choice, such as /
tmp, and add the my-key.gpg file to the initrd as shown in the following:
The modified initrd file can be used on your tftp server for PXE booting.
When your add-on repository is set up, you can specify any RPM file that is
contained in it for installation in an AutoYaST control file.
da10:/srv/install-repo/sled11/ # gpg --export --armor \
your_keyid > SHA1SUMS.key
da10:/srv/install-repo/sled11/ # ls > directory.yast
da10:/srv/install-repo/sled11/ # cp SHA1SUMS.key /tmp/my-key.gpg
da10:/srv/install-repo/sled11/ # cd /tmp/
da10:/tmp/ # mv initrd initrd.gz
da10:/tmp/ # gunzip initrd.gz
da10:/tmp/ # find my-key.gpg | cpio -o -A -F initrd -H newc
da10:/tmp/ # gzip initrd
da10:/tmp/ # mv initrd.gz initrd
179 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Use the Installation Server
To use the installation server, you have to specify the server when the initial boot
screen shows up. With the Down key, move to Installation, then press F4. From the
menu, select the installation server type you want to use:
Figure 7-6 Installation via NFS
Another dialog opens where you have to specify the hostname of the server and the
directory on the server. Depending on the server type, there might be additional
parameters to specify.
Instead of selecting NFS from the menu and specifying the IP address and path in the
dialog, you can type install=nfs://IP_address/path/to/
repository/ in the Boot Options field.
After pressing Enter, the installation system connects to the installation server and
loads all files needed for installation over the network.
Version 1 180
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 7-1 Set Up an Installation Server
In this exercise, you copy the files of the installation DVD to a directory and make
this directory accessible over the network using NFS.
Then you prepare the installation repository to provide additional RPMs that are not
part of the installation media.
(End of Exercise)
181 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 3 Set Up PXE Boot for Installations
PXE (Preboot Execution Environment) is a procedure to boot a computer system over
the network. This is independent of the local storage media or operating system.
The firmware of the network card sends out bootp requests and receives an IP address
as well as information on where to retrieve a boot loader image from a bootp/DHCP
server. It downloads the boot loader image based on that information using TFTP.
The image is transferred from the server and loaded into RAM. The control of the
boot process passes from the network card to the boot loader. This boot loader then
fetches the kernel and initrd from the TFTP server and passes the control to the
kernel.
In addition to a PXE-capable network card on the client side, the following packages
are needed on the server side:
tftp: TFTP Server
syslinux: Contains the bootloader pxelinux
dhcpd: DHCP Server
A DHCP server is available only on SUSE Linux Enterprise Server 11, not on the
Desktop distribution. However, you can add the SUSE Linux Enterprise Server 11
DVD to the installation sources to be able to install a DHCP server on SUSE Linux
Enterprise Desktop 11 as well.
To set up PXE boot, you need to understand how to do the following:
Install and Configure tftp on page 181
Configure pxelinux on page 182
Install and Configure the DHCP Server on page 185
Set Up PXE Boot for Installations on page 190
Install and Configure tftp
To begin, install the tftp package with the yast -i tftp command. The TFTP
server needs a directory for the files it is supposed to distribute, which is created by
the mkdir /tftpboot command.
Version 1 182
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
As the TFTP server is started via xinetd, it is necessary to edit /etc/xinet.d/
tftp. It should look similar to the following example:
To access the TFTP server, it is necessary to start xinetd with the rcxinetd
start command. If a client contacts the TFTP server port (69), xinetd starts the
TFTP server and hands the connection over to that server.
If you want xinetd to start during system boot, add it to the proper runlevel directories
with the insserv xinetd command.
Configure pxelinux
The syslinux package contains the files the client needs to boot via the network. To
configure pxelinux for network boot, you have to understand the following:
pxelinux Files and Directories on page 182
Configure pxelinux on page 183
pxelinux Files and Directories
The first step is to install the syslinux package (if it isnt installed already) using the
yast -i syslinux command. Then copy the /usr/share/syslinux/
pxelinux.0 file to /tftpboot/.
In addition to the files from the syslinux package, the kernel and initrd of the system
you want to install are needed in the /tftpboot directory.
From the SUSE Linux Enterprise Server 11 installation DVD, copy the linux,
initrd, and message files from the /mountpoint/boot/i386/loader/
directory to /tftpboot/. If you want to be able to install different products, like
Desktop and Server, rename the files accordingly (such as initrd_sled11,
initrd_sles11, linux_sled11, etc.) to avoid naming conflicts.
# default: off
# description: tftp service is provided primarily for
# booting or when a router needs an upgrade. Most sites
# run this only on machines acting as "boot servers".
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot -r blksize
# disable = yes
}
183 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Configure pxelinux
pxelinux expects its configuration in the /tftpboot/pxelinux.cfg/ directory.
To configure pxelinux, you have to understand the following:
Configuration Filename Convention on page 183
Configuration File Content on page 183
Configuration Filename Convention
As more than one system may be booted from the same server, the configuration
filename depends on the IP address of the booting machine. In this way, it is possible
to have different configurations for different machines.
pxelinux will search for the configuration file on the boot server in the following
way:
First it will search for a configuration file based on the MAC address of the NIC
of the client in lower hexadecimal notation, and the ARP type (Ethernet: ARP
type 1). For example, if the MAC address is AA:BB:CC:11:22:33, the
corresponding filename will be 01-aa-bb-cc-11-22-33.
Next it will search for the configuration file using the IP address of the client in
hexadecimal notation; the address 172.17.8.1, for example, corresponds to
AC110801. The gethostip program from the syslinux package can be used to
calculate this value.
If that file is not found, it will remove one hexadecimal digit and try again
(AC11080 in the above example). If no success, another hexadecimal digit is
removed with each try, until a file is found (AC1108,AC110, AC11, and so on, in
the above example).
If no file with one of these names is found, pxelinux searches for a file named
default.
Configuration File Content
The content of the file defines which kernel and initrd are loaded. Together with the
message file, it is possible to display a menu on the client side where the
administrator can select which files to load. For example, you can implement such a
menu when you want to offer a choice of which system to install (SLED11, SLES11,
etc.), or for different boot options.
The content of the file could look like the following (the options after append need
to be in one line):
default harddisk
# SLED11
label SLED11
kernel linux_sled11
append initrd=initrd_sled11 ramdisk_size=65536 insmod=e100
netdevice=eth0 install=nfs://172.17.8.1/srv/install-repo/sled11
vga=0x317
# SLES11
label SLES11
Version 1 184
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
kernel linux_sles11
append initrd=initrd_sles11 ramdisk_size=65536 insmod=e100
netdevice=eth0
...
# hard disk (default)
label harddisk
localboot 0
implicit 0
display message
prompt 1
timeout 100
The options that can be used in the file are described in /usr/share/doc/
packages/syslinux/syslinux.txt. Those used here have the following
significance:
default value: The default option defines which label is used in case the user
does not enter anything. In the example above, the computer boots from
harddisk.
label value: Under each label, it is possible to define which kernel to load and
which options to append. The parameters listed after append are kernel
parameters or linuxrc key=value combinations. A list of keys can be found in
/usr/share/doc/packages/linuxrc/README.linuxrc after
installing the linuxrc package from the SUSE Linux Enterprise Server 11 DVD.
The location of files has to be specified relative to the directory where pxelinux.0
resides. In the example above, linux and initrd are in the same directory as
pxelinux.0; therefore, no path has to be set.
implicit 0|1: If the value is 0, a kernel image is not loaded unless it is explicitly
named in a label statement.
display filename: The filename that contains the information to display to the
user.
prompt 0|1: If the value is 1, always display the boot: prompt.
timeout timeout: The number of 1/10 seconds after which the default is loaded
automatically.
In a message file, you can include an explanation of each possible choice, as in the
following example:
To boot from harddisk, just press <return>.
Available boot options:
SLED11 - AutoYaST-Installation of SLED11
SLES11 - AutoYaST-Installation of SLES11
To install SLED11, enter SLED11 at the prompt.
185 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Install and Configure the DHCP Server
This section covers only the main configuration options relevant for an installation
server; it does not cover the DHCP configuration in detail.
To install the DHCP server, select the YaST Software Management module and then
in the Software Management dialog, search for dhcp, select dhcp-server on the
right, and then click Accept.
There are two configuration files that need to be edited:
/etc/sysconfig/dhcpd on page 185
/etc/dhcpd.conf on page 186
/etc/sysconfig/dhcpd
The /etc/sysconfig/dhcpd file contains configuration options which are
submitted as parameters to the DHCP daemon by the /etc/init.d/dhcpd start
script. The first parameter defines the interfaces which the DHCP server listens on for
requests.
For example, if the DHCP server listens on the two interfaces eth0 and eth1, set the
variable DHCPD_INTERFACE to the following
DHCPD_INTERFACE="eth0 eth1"
The DHCP server will listen only to the interfaces specified here.
Two other variables enhance the security of the server:
DHCPD_RUN_CHROOTED="yes"
and
DHCPD_RUN_AS="dhcpd"
The first of these variables configures the DHCP server processes to run in a chroot
environment. The new root directory for all DHCP server related processes is /var/
lib/dhcp.
The second variable defines the user to be used for running the processes. Normally
there is no reason to change the default settings of these variables.
The DHCP server can read additional configuration files that are included in the main
configuration file. As the server processes are running in a chroot environment, these
additional configuration files have to be copied into the chroot environment too. The
files will be copied automatically when the DHCP server is started if they are listed in
/etc/sysconfig/dhcpd.
The following is an example:
DHCPD_CONF_INCLUDE_FILES="/etc/dhcpd.conf.shared /etc/dhcpd.conf.d
As shown here, the name of a directory can also be provided. All files located in this
directory will be included.
Version 1 186
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
/etc/dhcpd.conf
The configuration file for the DHCP server is /etc/dhcpd.conf. Global
definitions are made at the top of the configuration file. The parameters defined here
apply to all subsequent sections unless they are explicitly overwritten in the
respective sections. The entries in the configuration file belong to two categories:
Parameter statements: These describe the following:
How to do something (for example, define the length of time an IP address
remains valid without renewal)
Whether to do something (for example, whether IP addresses should be
assigned to unknown clients)
Which parameters should be provided to clients (for example, the IP address
of the default gateway)
Declarations: Describe the topology of the network, describe the clients, or
provide the address ranges to serve clients from.
Each statement has to be terminated using the semicolon (;).
In the case of an error in the configuration file, dhcpd will not start but will print out
an error message. This message can be used to locate the error in the configuration
file.
SUSE Linux Enterprise Server 11 ships with a sample configuration file for the
DHCP server. You will not need all the configuration statements that are provided
with this sample file. It is better to start with an empty configuration and to enter only
those statements you really need.
Comments can be used at any location in the configuration file. They start with the
hash sign (#). The rest of the line after the hash sign will be ignored.
Starting with DHCP server version 3, dynamic updates of a DNS server are possible.
This means when the DHCP server assigns an IP address to a client, it can update the
corresponding information on the DNS server. The statement describing how to do
this dynamic update (ddns-update-style) is mandatory. If no dynamic update is done
(as in this example), specify none as the parameter to this statement:
#
# /etc/dhcpd.conf
#
ddns-update-style none;
The following are statements regarding the lease times (the validity period for
assigned IP addresses):
#
# specify default and maximum lease time
#
default-lease-time 86400;max-lease-time 86400;
When a client requests an IP address without providing any information on the
desired lease time, the IP address will be assigned for the specified default lease time
(in this example, 86400 seconds, which is one day).
187 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NOTE: You can enter a maximum of 2
31
-1 seconds for the lease time. That is about 68 years.
Shortly before the assigned IP address expires, the client will request a renewal of the
address. Normally, the lease time for this address will be extended.
Depending on its configuration, a client can request a specific lease time. Normally,
this specific lease time request is accepted. You have to distinguish two cases:
If the requested lease time is shorter than the default lease time, the DHCP server
will assign the IP address for the requested time.
If the requested lease time is longer than the default lease time and if no
maximum time has been specified, the DHCP server will accept it. If the max-
lease-time statement is present, this time will be the longest available.
In the example above, both times are the same. Setting a maximum lease time
prohibits clients from requesting an infinite lease time (resulting in a permanent IP
address).
The following section of dhcpd.conf shows how to provide information on the DNS
domain to be used:
#
# What is the DNS domain and where is the name server?
#
option domain-name "digitalairlines.com";
option domain-name-servers 172.17.8.1, 172.17.8.10;
These configuration options start with the keyword option.
If a list of name server addresses (separated by commas) is provided, the list reflects
the order of preference for contacting a name server.
As the last parameter, specify the addresses of routers in the subnet:
#
# This is a router
#
option routers 172.17.8.1;
If several routers are specified here (separated by commas), the list reflects the order
of preference for using these routers. The first router is the default gateway.
There are several options that are needed to enable booting using PXE:
allow bootp;
next-server 172.17.8.1;
server-name "da1.digitalairlines.com";
filename "pxelinux.0";
The bootp flag is used to tell dhcpd whether or not to respond to bootp queries.
next-server specifies the machine to get the boot loader image from, and
filename specifies its name. The server-name statement can be used to inform
the client of the name of the server it is booting from.
Version 1 188
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Finally, define the range of addresses that can be used for assigning IP addresses to
clients. This declaration starts with the keyword subnet and specifies the subnet
and corresponding network mask:
#
# Which IP addresses may be assigned to the clients?
#
subnet 10.0.0.0 netmask 255.255.255.0
{
range 10.0.0.101 10.0.0.120;
}
When a client requests an IP address, it will be assigned a free address from this
range. Starting with version 3 of the DHCP server, assignment will start with the
highest addresses (in the case above, 10.0.0.120). If no parameters are defined inside
this subnet declaration, all globally defined parameters will be used. There can be
more than one range statement inside a subnet declaration.
It is possible to configure specific hosts as well. Hosts are identified by their MAC
address. In the following example, the host with the MAC address specified after
hardware ethernet is assigned the IP address 10.0.0.150:
#
# Host specific configuration
#
host da150 {
fixed-address 10.0.0.150;
hardware ethernet 00:11:22:33:44:55;
}
The man pages for dhcp-options and dhcpd.conf provide more information on the
available configuration options.
After the configuration has been completed, start the DHCP server with the
rcdhcpd start command. If there are any mistakes in your configuration, there
will be error messages pointing you to a line in the configuration file near the
mistake. Fix it and try again to start the server.
If you want the server to start automatically at system start, add the proper links to the
runlevel directories with the insserv dhcpd command.
You are now ready to test your setup. In the same network as your DHCP and TFTP
server, boot a machine that has a PXE-capable network card. (It might be necessary to
change the BIOS of that machine to include the network card as a boot medium.) The
machine should get an IP address from your DHCP server and briefly after that, you
should see the information from your message file.
In this SUSE Linux Enterprise Server 11 Administration course manual, we
explained a simple DHCP configuration that supports PXE. More information on the
configuration of a DHCP server is available at several locations:
The man pages on your local system:
man dhcpd (DHCP server)
189 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
man dhcpd.conf (configuration file)
man dhcp-options (configuration options)
In directories on your local system:
/usr/share/doc/packages/dhcp/
/usr/share/doc/packages/dhcp-server/
On the Web:
http://www.isc.org/software/dhcp/
In books:
The DHCP Handbook by Ralphs Droms and Ted Lemon (Sams Publishing)
Version 1 190
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 7-2 Set Up PXE Boot for Installations
In this exercise, you set up a TFTP server, fill the /tftpboot directory with the files
needed for PXE boot, and set up a DHCP server.
(End of Exercise)
191 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 4 Create a Configuration File for AutoYaST
The easiest way to create a configuration file for AutoYaST is to use the YaST
Autoinstallation module. Select Computer > Yast > Miscellaneous >
Autoinstallation, or log in as root and enter yast2 autoyast in a terminal
window.
This module starts with the following dialog:
Figure 7-7 Autoinstallation Configuration
The left part of the window contains the YaST groups you know from the left frame
of the YaST dialog. The center frame contains the YaST modules available in the
group. The right frame lists the settings made in this module for the autoinstallation.
NOTE: At the beginning, default values based on the current system configuration are listed in the
right frame.
You do not need to configure every single aspect of the machines to be installed,
because the automated installation makes use of the hardware detection capabilities
of YaST. For example, you do not need to provide the type of network card because
the hardware detection will take care of this.
Clicking Edit opens the same YaST configuration dialogs as those you see when
installing or administering SUSE Linux Enterprise 11. However, the configuration
information is written to the AutoYaST control file. Nothing is changed on the
installation you work on.
Version 1 192
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
You would usually define disk layout, software selection, language settings, network
parameters, and root password. Depending on your needs, you can specify other
items, such as users and their passwords, NFS client configuration, or printer
configuration.
If you want to perform completely unattended installations, in the General Options
module in the System group of AutoYaST, select Edit. Click Next in the Mouse
Configuration dialog, and uncheck Confirm Installation in the Other Options
dialog. The default is to confirm installation to avoid recursive installs when the
system schedules a reboot after initial system setup. You should also be aware that
this might cause inadvertent installations under certain circumstances.
After you have completed the configuration, select File > Save as. A dialog box
opens with the default directory for AutoYaST configuration files, /var/lib/
autoinstall/repository/. Type a name for the file (hostname.xml, for
example).
You can change the default directory for AutoYaST configuration files via the File >
Settings menu.
If you do not want to begin from scratch, you can use the current machine as a
template. Select Tools > Create Reference Profile. The following dialog appears:
Figure 7-8 AutoYaST Reference Control File
The reference profile is created by reading information from the system you work on.
To add other necessary information for your machine, select the check boxes in the
main window.
193 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
NOTE: Be sure to examine any resulting control file carefully before using it to autoinstall a new
system.
To view the configuration created, select View > Source:
Figure 7-9 AutoYaST XML Code
After you have completed your configuration, save it by selecting File > Save as as
described above.
You can also create the control file using an editor of your choice. The advantage of
the YaST module is that it saves a lot of typing and the XML syntax of the resulting
file is correct. Another approach is to create a control file with YaST and then use an
editor for minor changes and additions.
On a system that was installed using AutoYaST, the control file used during
installation is stored as /var/adm/autoinstall/cache/
installedSystem.xml.
NOTE: More information on AutoYaST can be found in /usr/share/doc/packages/
autoyast2/html/index.html.
Version 1 194
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 7-3 Create an AutoYaST Control File
In this exercise, you create an AutoYaST control file.
(End of Exercise)
195 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 5 Perform an Automated Installation
To start the automated installation, make the AutoYaST control file available on the
machine to be installed. This can be combined with any installation method, be it
from the installation media or an installation server in the network.
To perform automated installations, you need to do the following:
Provide the Control File on page 195
Boot and Install the System on page 195
Perform an Automated Installation of SUSE Linux Enterprise Server 11 on
page 199
Activate PXE Booting and Install SUSE Linux Enterprise Server (Conditional,
depending on hardware support) on page 200
Provide the Control File
Various ways exist to make the control file available.
One is to copy the file to a floppy disk containing a FAT file system format.
NOTE: Do not use a floppy disk with Ext2 file system format.
If you name the file on the floppy disk autoinst.xml and insert the floppy, it will be
automatically used. If you use a different name, you have to add the following to the
kernel command line at the boot prompt of the installation:
autoyast=floppy:///myconfig.xml
Another way to make the control file available is via the network. That is especially
useful in combination with an installation server. In this case, the kernel command
line would look similar to the following:
autoyast=nfs://172.17.8.1/srv/install-repo/sled11/ay/
myconfig.xml
Boot and Install the System
Once you have your control file created and tested, you have several options to install
machines with it:
Boot and Install from DVD on page 195
Boot from DVD, Install from an Installation Server on page 196
Boot via PXE, Install from an Installation Server on page 196
Boot and Install from DVD
It is possible to use a control file (on a floppy disk or on an exported file system) in
combination with the installation DVD to boot and install the computer.
Version 1 196
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
However, for larger deployment, this is not really efficient. While it saves the typing
of configuration information, you still have to walk from computer to computer,
insert the media, and start the installation manually. Later, you have to come back to
remove the installation media again.
Boot from DVD, Install from an Installation Server
Even when using the DVD or floppy disks to boot, an installation server has the
advantage that you can remove the boot media as soon as the actual installation has
started.
Provided you have a DHCP server running which provides all network information
during installation, the steps are as follows:
1. Insert the installation DVD into your machine and start the boot process.
2. On the first boot screen, select Installation (be sure to do this within 10 seconds;
otherwise, the system starts from harddisk).
3. Provide the necessary information for an automated installation with AutoYaST.
At the boot prompt, enter the following parameters (we assume here that the
installation repository is available via NFS from 172.17.8.1/srv/
install-repo/sled11/, and that the control file is available at the same
location):
autoyast=nfs://172.17.8.1/srv/install-repo/sled11/ay/
autoinst.xml install=nfs://172.17.8.1/srv/install-
repo/sled10 splash=verbose
The last parameter switches to the detailed display during the boot process, so
you can easily look at the boot messages.
After a short time, YaST starts. At this point, you can remove the boot medium. The
installation proceeds as usual but, because of the control file, no user interaction is
necessary. After some checks, the packages are copied from the NFS server.
The system is rebooted at the end of the installation process. After the reboot, you
may log in as root without a password if no password was set in the AutoYaST
configuration file. In this case, you should immediately set a password for root.
Boot via PXE, Install from an Installation Server
The advantage of using PXE for installation is that you do not have to bring a
separate boot medium to the computer. With a suitable configuration, you can offer a
menu to select what to install.
In fact, if the network card supports Wake on Lan, you do not have to walk to the
machine at all.
197 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The setup to support booting via the network is described in Configure pxelinux on
page 182. To integrate AutoYaST, an additional entry is needed in the append line of
the pxelinux configuration file:
...
# SLED11
label SLED11
kernel linux
append initrd=initrd ramdisk_size=65536 insmod=e100 netdevice=eth0
install=nfs://172.17.8.1/srv/install-repo/sled11 autoyast=nfs://
172.17.8.1/srv/install-repo/sled11/ay/autoinst.xml vga=0x317
...
When you now enter SLED11 at the message prompt, the computer is automatically
installed.
You could go one step further and make this entry the default:
default SLED11
# SLED11
label SLED11
...
In this case, the computer gets installed unless a user chooses a different option. This
configuration is probably useful only in initial rollouts in combination with Wake on
Lan, for these reasons:
Until you remove the pxelinux configuration file, there is an installation loop
after each reboot, the installation starts all over again.
If a user turns on the computer, it will get installed from scratch.
Do this as a workaround:
1. Create a file /tftpboot/pxelinux.cfg/default that contains the menu
options that you want to offer in the PXE menu once the computers are installed.
This could be to boot from harddisk only, or also contain additional entries
allowing installations when the user selects them.
2. Create another file, /tftpboot/pxelinux.cfg/install, that contains
the installation as default.
The name of the file is not important, as long it is not a filename pxelinux looks
for as described in Configuration Filename Convention on page 183.
3. Create links within the /tftpboot/pxelinux.cfg/ directory to the /
tftpboot/pxelinux.cfg/install file according to the pxelinux file
name convention. For example for the IP address 10.11.12.13, the command
would be
ln -s install 0A0B0C0D
4. Using Wake on Lan, turn on the machine.
5. Watch the TFTP log file, using the command
Version 1 198
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
tail -f /var/log/xinetd.log
It will show an entry when a computer connects to the TFTP server.
You could also watch /var/log/messages for entries indicating that the
respective client has mounted the installation server directory.
6. When the computer you turned on using Wake on Lan has fetched the necessary
files via TFTP according to the log file, remove the corresponding link in the
directory /tftpboot/pxelinux.cfg/:
rm 0A0B0C0D
When the computer reboots during the installation or later in the course of
normal production, the file fetched by pxelinux is /tftpboot/
pxelinux.cfg/default. As the default in this file is to boot from harddisk,
the computer starts normally unless the user chooses a different option.
199 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 7-4 Perform an Automated Installation of SUSE Linux Enterprise Server
11
In this exercise, you perform an automated installation of SUSE Linux Enterprise
Server 11.
You will find this exercise in the work the workbook
(End of Exercise)
Version 1 200
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 7-5 Activate PXE Booting and Install SUSE Linux Enterprise Server
(Conditional, depending on hardware support)
In this exercise, you work with a fellow student to boot your machine using PXE and
start the installation of SUSE Linux Enterprise Server 11.
(End of Exercise)
201 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Introduction to AutoYaST SUSE Linux Enterprise 11 can be deployed using
manual installation with the installation media or an
installation server, or automated installation with an
AutoYaST control file.
To boot the computer for installation, you can use the
DVD, boot floppies, or PXE-capable network cards in
conjunction with a boot loader image distributed via
TFTP.
Installation Server: Setup and Use Setup of an installation server consists of copying the
content of the installation DVD to a directory and
configuring NFS to provide access to that directory to
clients.
Set Up PXE Boot for Installations To boot a computer via the network using PXE, you
need a boot loader image distributed by TFTP.
The syslinux package contains the pxelinux.0 boot
loader image.
The tftp package contains a TFTP server that is started
by xinetd when a client accesses port 69. The files
needed by the clients are usually stored in the /
tftpboot directory
A DHCP server is contained in the dhcp-server
package.
Create a Configuration File for
AutoYaST
To create a configuration file for AutoYaST, use the
YaST module Autoinstallation:
yast2 > Miscellaneous > Autoinstallation
or start the module directly from the command line with
yast2 autoyast
The default directory for AutoYaST configuration files is
/var/lib/autoinstall/repository/.
Perform an Automated Installation The control file for automated installation can be made
available by various means, including a floppy disk, an
USB device, or a network share.
A DHCP server, which provides all network information,
and an installation server simplify the installation.
If combined with PXE completely, unattended
installations are possible.
Version 1 202
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
203 Version 1
Manage Virtualization with Xen
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
SECTI ON 8 Manage Virtualization with Xen
SUSE Linux Enterprise Server 11 comes with built-in virtualization support through
the Xen virtual machine monitor. In this section, you learn about the Xen
virtualization technology in SUSE Linux Enterprise Server 11.
Objectives
1. Understand How Virtualization with Xen Works on page 204
2. Install Xen on page 208
3. Manage Xen Domains with Virt-Manager on page 219
4. Manage Xen Domains from the Command Line on page 225
5. Understand Xen Networking on page 232
Version 1 204
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 1 Understand How Virtualization with Xen Works
Virtualization technology separates a running instance of an operating system from
the physical hardware. Instead of running on a physical machine, the operating
system runs in a so-called virtual machine. Multiple virtual machines share the
resources of the underlying hardware.
Virtualization allows you to run multiple virtual systems on one physical machine.
Figure 8-1 Physical Machine and Virtual Machines
In comparison with non-virtualized physical hardware, virtualization provides the
following advantages:
Efficient hardware utilization: Often systems are not using the full potential of
their hardware. When multiple virtual machines are run on the same hardware,
the resources are used more efficiently.
Reduced downtime: Virtual machines can be migrated to a new physical host
system. This reduces downtime in case of a hardware failure.
Flexible resource allocation: Hardware resources can be allocated on demand.
When the resource requirements of a virtual machine change, resource allocation
can be adjusted or the virtual machine can be migrated to a different physical
host.
SLES11comes with a virtualization technology called Xen. Xen allows you to run
multiple virtual machines on a single piece of Intel x86-based hardware.
To understand how Xen works, you need to do the following:
Understand Virtualization Methods on page 205
Understand the Xen Architecture on page 206
205 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Understand Virtualization Methods
You should understand the following virtualization methods:
Para-Virtualization: Instead of emulating a full virtual machine, para-
virtualization software provides an Application Programming Interface (API)
which is used by the guest OS to access hardware resources. The guest OS must
be aware that it runs in a virtual machine and must know how to access the API.
Figure 8-2 Para-Virtualization
Para-virtualization provides better performance because it does not emulate all
hardware details. However, the guest OS needs to be modified to run with para-
virtualization; therefore, only open source operating systems like Linux or BSD
can be installed. One exception is NetWare, which has been adjusted by Novell
to run in a Xen virtual machine.
Another advantage of para-virtualization is the flexible resource allocation.
Because the guest OS is aware of the virtual environment, Xen can, for example,
change the memory allocation of a virtual machine on the fly without requiring a
reboot of the virtual machine.
Full Virtualization. In this case, the virtualization software emulates a full
virtual machine, including all hardware resources. The operating system running
in the virtual machine (guest OS) communicates with these resources as if they
were physical hardware. VMware Workstation is a popular full virtualization
software.
Version 1 206
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Figure 8-3 Full Virtualization
Xen supports full virtualization on specialized x86 hardware developed by Intel
and AMD. Intel and AMD extended the x86 Standard to support virtualization.
Full virtualization works with unmodified guest operating systems, including
Microsoft Windows, but generates more overhead, resulting in a weaker
performance.
Understand the Xen Architecture
Xen consists of the following three major components:
Virtual Machine Monitor: The virtual machine monitor forms a layer between
physical hardware and virtual machines. In general, this kind of software is
called a hypervisor.
Xen kernel: The modified Linux kernel for Xen para-virtualization. It can be
used for Domain 0 as well as for Domain U (see below).
Xen tools: The Xen tools are a set of command line and graphical applications
that are used to administer virtual machines.
The virtual machine monitor must be loaded before any of the virtual machines are
started. When working with Xen, virtual machines are called domains.
The Xen virtual machine monitor includes neither any drivers to access the physical
hardware of the host machine nor an interface to communicate directly with an
administrator. These tasks are performed by an operating system running in the
privileged Domain 0 (Dom0).
207 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The following is an illustration of a Xen system with three domains:
Figure 8-4 Xen Domains
Xen plus the privileged Domain 0 can also be referred to as a Virtual Machine Server.
An unprivileged domain is called Domain U (DomU) in the Xen terminology, and is
also known as a Virtual Machine.
A process called xend runs in the Dom0 Linux installation. This process is used to
manage all Xen domains running on a system and to provide access to their consoles.
SUSE Linux Enterprise Server 11 can be used for privileged (Dom0) and
unprivileged (DomU) Xen domains.
Version 1 208
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 2 Install Xen
A complete Xen installation includes the following tasks:
Install a Xen Server on page 208
Install a Xen Virtual Machine on page 210
Install a Xen Server and an Unprivileged Domain on page 218
Install a Xen Server
To set up a Xen server, which is a system capable of hosting Xen virtual machines,
you need to install the Xen kernel and additional Xen packages on top of a SUSE
Linux Enterprise Server 11 installation.
You have two choices:
Install Xen during Installation of SUSE Linux Enterprise 11 on page 208
Install Xen on an Installed SUSE Linux Enterprise Server 11 on page 210
Install Xen during Installation of SUSE Linux Enterprise 11
To install Xen as part of the SUSE Linux Enterprise Server 11 installation, in the
dialog presented in the first stage of the installation, select the Xen Virtual Machine
Host Server pattern. This installation on the physical hardware will be your future
Domain 0 (Dom0).
The other Xen domains (DomUs) are installed later in physical partitions or file
system images. If you plan to use physical partitions, make sure that the initial SUSE
Linux Enterprise Server 11 installation is not using all of the available disc space.
For maximum flexibility, use the logical volume manager (LVM) for a Xen system.
As a general rule, you should run services (such as a Web server, a database, or
Novell services like iFolder) in a DomU, not in Dom0. Therefore, it is not necessary
to select the respective patterns during the installation of Dom0.
The following packages have to be installed in the initial SUSE Linux Enterprise
Server 11 installation:
xen: Contains the Xen virtual machine monitor (Hypervisor).
xen-libs: Contains the libraries used to interact with the Xen virtual machine
monitor.
xen-tools: Contains xend and a collection of command line tools to administer a
Xen system.
vm-install: Contains Python scripts used to define a Xen virtual machine, and to
cause an operating system to begin installing within that virtual machine.
xen-doc-*: (Optional) Contains Xen documentation in various formats.
virt-manager: Provides a graphical interface to manage virtual machines.
209 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
virt-viewer: Provides a graphical console client for connecting to virtual
machines.
bridge-utils: Contains utilities to configure Linux ethernet bridges, which are
used to connect the domains to each other and to the physical network interface.
kernel-xen: Contains a modified Linux kernel that runs in a Xen domain, both
Dom0 and DomU.
Except for the last package, kernel-xen, these are all part of the Xen pattern.
The installation of the kernel-xen package automatically adds an entry like the
following into the /boot/grub/menu.lst bootloader configuration file.
###Don't change this comment - YaST2 identifier:
Original name: xen###
title Xen -- SUSE Linux Enterprise Server 11 - 2.6.27.19-5
root (hd0,1)
kernel /boot/xen.gz
module /boot/vmlinuz-2.6.27.19-5-xen root=/dev/disk/by-id/ata-
ST380815AS_6QZ2FW3T-part2 insmod=e100 resume=/dev/disk/by-id/ata-
ST380815AS_6QZ2FW3T-part1 splash=silent crashkernel= showopts
vga=0x317
module /boot/initrd-2.6.27.19-5-xen
The entry in menu.lst adds a new option to the boot menu of your system. When you
select this entry, the Xen virtual machine monitor is loaded (kernel /boot/
xen.gz) which starts SUSE Linux Enterprise Server 11 in Dom0 (see the lines
starting with module).
Before rebooting your system with the Xen option, you should check if the
automatically generated entry is correct. Make sure that
The line root (hd0,1) points to the partition which contains the Xen virtual
machine monitor and the Kernel of the Linux installation for Dom0. For
example, hd0,1 designates the second partition on the first hard drive in the
system. Also check if the parameter root= in the first module line points to the
root partition of the Dom0 installation.
The Xen version of the Linux kernel and the initrd are loaded in the module lines.
The names of the image files should end in -xen.
After checking the bootloader configuration file, you can reboot your system and
select the Xen option from the bootloader menu. In the early stages of the boot
process, you will see some messages of the Xen virtual machine monitor on the
screen. Then the Dom0 Linux operating system is started.
If the system is not booting properly, you can switch back to a non-virtualized system
by selecting the regular SUSE Linux Enterprise Server 11 boot option.
Version 1 210
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Install Xen on an Installed SUSE Linux Enterprise Server 11
You can easily add Xen to an existing installation of SUSE Linux Enterprise Server
11 using the YaST module created for this purpose.
In YaST, select Virtualization > Install Hypervisor and Tools. The required Xen
packages are installed.
The necessary changes are made to /boot/grub/menu.lst as described in Install Xen
during Installation of SUSE Linux Enterprise 11 on page 208 and a default network
bridge is configured.
Reboot the machine and select the Xen kernel from the boot menu.
To boot the Xen kernel by default, edit the default entry in /boot/grub/menu.lst:
# Modified by YaST2. Last modification on Thu Apr 2 17:27:29 CEST 2009
default 0
timeout 8
gfxmenu (hd0,1)/boot/message
##YaST - activate
###Don't change this comment - YaST2 identifier: Original name: xen###
title Xen -- SUSE Linux Enterprise Server 11 - 2.6.27.19-5
...
default 0 boots the first entry by default, default 1 the second, and so on.
If you want to find out which kernel is currently in use, enter uname -a in a
terminal window:
Install a Xen Virtual Machine
After you have installed Xen and the Xen tools, you can use vm-install to create
unprivileged Xen domains. vm-install can be started directly from the command
line or by starting YaST and selecting Virtualization > Create Virtual Machines.
This tool guides you step by step through the creation of a Xen domain on your
system.
da10:~ # uname -a
Linux da10 2.6.27.19-5-xen #1 SMP 2009-02-28 04:40:21 +0100 i686 i686
i386 GNU/Linux
211 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The first dialog looks like the following:
Figure 8-5 Virtual Machine Installation
This first page gives some information on the creation of a virtual machine. Selecting
Forward opens a dialog where you have a choice between a new installation of an
operating system and the use of an existing image.
Version 1 212
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
If you decide to install an operating system, the following dialog appears:
Figure 8-6 Virtual Machine Installation: OS Type
213 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Your choice of the type of operating system determines the suggested values in the
next dialog:
Figure 8-7 Virtual Machine Installation: Summary
It is necessary to specify the installation medium. Other values, such as the size of the
virtual hard disk, can be changed as needed.
To change a setting, select the blue headline.
We recommend switching to a fixed MAC address for Linux virtual machines.
Version 1 214
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Select Network Adapter on the Summary page to edit the suggested values or to
add another virtual network adapter. Select Edit on the Network Adapters page to
open the following dialog:
Figure 8-8 Virtual Machine Installation: Network Adapter
Selecting Randomly generated MAC address causes a new MAC address to be
created each time the virtual machine is started. With this setting and SLES11 as the
operating system within the virtual machine, the interface name within the virtual
machine changes each time the virtual machine is started.
To avoid this, select Specified MAC address. The vendor string for Xensource is
00:16:3e. Enter hex values in the spaces provided, making sure they are unique
within your network. Click Apply to return to the previous dialog.
215 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
In the Summary dialog, select Disks to change hard disk parameters or to add a hard
disk or a CDROM drive. The following dialog appears:
Figure 8-9 Virtual Machine Installation: Disks
Version 1 216
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Select Edit to change the highlighted entry. The following dialog appears:
Figure 8-10 Virtual Machine Installation: Virtual Disk
Here you can specify a different image file and change its size. When you select
Create Sparse Image File, the image file does not immediately use the specified
amount of disk space on the storage medium, but grows as space is actually used
within the virtual machine. It is also possible to specify a block device like /dev/sda5
instead of a file.
Select OK to return to the Disks dialog. Select Apply in the Disks dialog to return to
the Summary page.
The dialog for the CDROM drive is almost identical.
217 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To specify an installation medium, in the Summary dialog select Operating System
Installation. The following dialog appears:
Figure 8-11 Virtual Machine Installation: OS Installation
In the Network URL text box, you can specify an installation source located in the
network, such as nfs://172.17.8.101/data/install/SLES11.
Select Apply to return to the Summary dialog.
To start the installation, select OK in the Summary dialog. A VNC window appears
that allows you to control and configure the operating system installation.
When you install SUSE Linux Enterprise Server 11 in a virtual machine, the device
name for the first hard disk within the virtual machine is /dev/xvda, the device name
for the second disk is /dev/xvdb, and so on. Apart from this detail, a virtual
installation is almost identical to an installation on real hardware.
Version 1 218
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 8-1 Install a Xen Server and an Unprivileged Domain
In this exercise, you learn how to install Xen and configure Dom0, and how to install
SUSE Linux Enterprise Server 11 in a Xen guest domain using vm-install.
(End of Exercise)
219 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 3 Manage Xen Domains with Virt-Manager
Virt-Manager is a graphical tool used to manage virtual domains. It can be started by
entering the virt-manager command or by selecting Virtualization > Virtual
Machine Manager in YaST.
Figure 8-12 Virt-Manager
Version 1 220
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Double-click a virtual machine entry to open a VNC window:
Figure 8-13 DomU
In the screenshot above, the virtual machine is running. You could pause the machine
or shut it down using the respective buttons. Closing the VNC window as such does
not affect the state of the machine. It continues to run and you can attach to the VNC
session again by double-clicking the respective entry in Virt-Manager.
If you double-click an entry of a virtual machine that is not currently running, the
window appears empty and you can start the machine by clicking the Run button.
To release the mouse cursor from the VNC window, press Ctrl+Alt.
221 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
When you select an entry in the Virtual Machine Manager window with the right
mouse button and then select Details, another dialog appears:
Figure 8-14 DomU: Utilization
The Overview tab shows a graph of CPU and memory usage.
Version 1 222
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The Hardware tab allows you to view and change certain hardware parameters:
Figure 8-15 DomU: Hardware Details
You can add or remove virtual processors, change the memory currently used, or add
and remove hard disks and CDROM/DVD drives.
Removing and adding the CDROM drive is necessary when changing a CDROM in
the drive. Currently, CDROM drives appear as hard disks within the virtual machines
and media changes are not detected automatically.
Due to a bug at the time of this writing, adding and removing CDROM drives in Virt-
Manager is not possible. You have to use the xm command to access the content of a
CDROM/DVD or to change it. (The xm command will be covered in more detail in
Use the xm Tool on page 226.)
To change a DVD or CDROM in a virtual machine, do the following:
1. Put the CDROM or DVD in the DVD drive.
It will be mounted automatically in Dom0.
2. Open a terminal window, su - to root, then add the drive with the command
xm block-attach domainID dev_in_Dom0 dev_in_DomU r
for instance
xm block-attach sles11 phy:/dev/sr0 /dev/xvdb r
223 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
3. Within DomU, mount the device (/dev/xvdb in the example above).
When you want to change the CDROM/DVD, unmount the device in DomU.
4. In Dom0, find out the ID for the CDROM entry and then remove this entry from
the virtual machine with the xm commands as shown below:
5. Change the CDROM/DVD in the drive and attach the device again as explained
in Step 2.
da10:~ # xm block-list sles11
Vdev BE handle state evt-ch ring-ref BE-path
51712 0 0 4 16 8 /local/domain/0/backend/vbd/
1/51712
51728 0 0 4 18 897 /local/domain/0/backend/vbd/
1/51728
da10:~ # xm block-detach sles11 51728
da10:~ #
Version 1 224
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 8-2 Change Memory Allocation of a Guest Domain
In this exercise, you learn how to change the memory allocation of a guest domain
using the Virtual Machine Manager.
(End of Exercise)
225 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 4 Manage Xen Domains from the Command Line
In this objective, you learn how to manage Xen domains at the command line. To do
this, you need to
Understand Managed and Unmanaged Domains on page 225
Understand a Domain Configuration File on page 225
Use the xm Tool on page 226
Use the virsh Tool on page 228
Automate Domain Startup and Shutdown on page 230
Automate Domain Startup on page 231
Understand Managed and Unmanaged Domains
In Xen version 2, all DomUs were configured by a configuration file. You can still
use configuration files with Xen version 3. Virtual domains that are configured by
configuration files only are referred to as unmanaged domains.
Unmanaged domains appear in Virt-Manager or in the output of the xm list
command (covered later in this objective) only when they are running.
With Xen version 3, configuration details can be stored in the Xenstore database
located in /var/lib/xenstored/tdb. One advantage is that the virtual
machines always appear in virt-manager, even when not running, and can be started
as described in the previous objective. Virtual machines that have their configuration
in the Xenstore database are referred to as managed domains.
You can use the xm new configfile command to move configuration
information from a configuration file into the Xenstore database.
Currently it is not possible to export a configuration from the Xenstore database to a
configuration file. To remove configuration information from the Xenstore database,
use the xm delete vm_name command. This command removes only the
configuration information from the database; the disk image files remain unchanged.
When a virtual machine is created with vm-install, the configuration is written to /
etc/xen/vm/vm_name and to the Xenstore database simultaneously. Later
changes to the configuration file have no effect on the information in the Xenstore
database.
To change the configuration in the Xenstore database, delete the configuration from
the database with xm delete vm_name, edit the configuration file in /etc/
xen/vm/, and integrate the new configuration in the database with xm new
configfile.
Understand a Domain Configuration File
The configuration files for domains created with vm-install are located in /etc/
xen/vm/.
Version 1 226
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
A configuration file contains several keywords which configure different aspects of a
Xen domain. A configuration file created by vm-install during the installation of a
virtual machine could look like the following:
Under /etc/xen/examples/, you find example files which can be used to create
a configuration from scratch. The comments in these files (lines starting with a #
sign) give more information on the available options and the required syntax.
NOTE: A good source for detailed documentation and HOWTOs about Xen and the domain
configuration files is the Xen wiki at: http://wiki.xensource.com/ (http://wiki.xensource.com/).
Use the xm Tool
The xm command line uses the following format:
xm subcommand [options] [arguments] [variables]
xm is the administration command line tool for Xen domains. xm communicates with
the xend management process running on the Dom0 Linux installation.
You can get a complete list of the xm subcommands by entering xm help. The xm
manual page contains information on the available options for each of the
subcommands. This manual covers only the more frequently used subcommands.
You can use the create subcommand to start an unmanaged virtual machine:
xm create -c -f /data/xen/SLES11-WebServer.conf
The -c option lets xm connect to the terminal of the started domain, so that you can
interact with the system. To disconnect from the terminal and return to the original
command line, enter the key combination Ctrl-].
The -f option specifies the configuration file of the domain that should be started.
name="sles11"
uuid="3eb65cbd-ae8e-2a79-cf1e-89189489d085"
memory=512
maxmem=512
vcpus=2
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=0
keymap="en-us"
builder="linux"
bootloader="/usr/bin/pygrub"
bootargs=""
extra=" "
disk=[ 'file:/var/lib/xen/images/sles11/disk0,xvda,w', 'phy:/dev/
sr0,xvdb:cdrom,r', ]
vif=[ 'mac=00:16:3e:31:24:13,bridge=br0', ]
vfb=['type=vnc,vncunused=1']
227 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The list command displays information about all managed Xen domains and the
currently running unmanaged Xen domains:
The output of the list command contains the following fields:
name: Name of the domain as specified in the configuration file.
ID: Numeric, consecutive domain ID, which is automatically assigned when the
domain starts.
Mem: Amount of memory assigned to the domain.
VCPUs: Number of virtual CPUs utilized by this domain.
State: Current state of the domain. This could be:
r: Domain is running.
b: Domain has been created but is currently blocked. This can happen when
a domain is waiting for I/O or when there is nothing to do for a domain.
p: Domain is paused. The state of the domain is saved and can be restored.
s: Domain is in the process of being shut down.
c: Domain has crashed due to an error or misconfiguration.
Time: Total run time of the domain as accounted for by Xen.
An alternative to list is the command top, which displays domain information
updated in realtime.
To start a managed domain, use the following command:
xm start vm_name
The console command connects you with the terminal of a running domain:
xm console domain_id
The command takes the domain id as a parameter, which can be determined with the
list command (field: ID). The name (field: Name) works as well. As mentioned
before, use the key combination Ctrl-] to disconnect from a terminal.
With the pause command, you can interrupt the execution of a domain temporarily:
xm pause domain_id
A paused domain is not completely shut down. The current state is saved and the
execution of the domain can be continued with the unpause command:
xm unpause domain_id
da10:~ # xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1481 2 r----- 298.3
sles11 1 512 2 -b---- 23.0
Version 1 228
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
To shut down a domain, use the shutdown command:
xm shutdown domain_id
This is equivalent to using the appropriate command within the virtual machine
(shutdown -h now in Linux).
If the domain is not responding anymore, you can force the shutdown of the domain
with the destroy command:
xm destroy domain_id
This is equivalent to pulling the plug on a physical machine.
To save the state of a domain for a longer time (for example, over a reboot of Dom0)
you can use the save command:
xm save domain_id filename
The domain can be restored from the resulting file with the restore command:
xm restore filename
Another commonly used command is mem-set, which allows you to change the
memory allocation of a domain:
xm mem_set domain_id amount_of_memory
The amount of memory is specified in megabytes.
Block devices can be added to DomUs with the xm block-attach command:.
xm block-attach domainID dev_in_Dom0 dev_in_DomU r/w
To remove the device again, first use xm block-list to find out what DeviceID
to use in the xm block-detach command:
xm block-list domainID
xm block-detach domainID DeviceID
Use the virsh Tool
The virsh command is similar to the xm command. The basic structure of the virsh
command is as follows:
virsh subcommand <domainID> [options]
virsh can be used to administer Xen domains. The options are similar to those of
the xm command, however there are also some options that are different.
You can get a complete list of the virsh subcommands by entering virsh help.
The virsh manual page contains information on the available options for each of the
subcommands. This manual covers only the more frequently used subcommands.
229 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
You can use the create subcommand to start an unmanaged virtual machine, using
a configuration file in xml format:
virsh create /data/xen/da-xen.xml
The console subcommand connects you with the terminal of a running domain:
virsh console domain_id
The command takes the domain id as a parameter, which can be determined with the
xm list command (field: ID). The name (field: Name) works as well. Use the key
combination Ctrl-] to disconnect from a terminal.
The virsh list command displays information about running Xen domains,
however the xm list command gives you more information, as it also lists managed
domain that are not currently running.
To start a managed domain, use the following command:
virsh start vm_name
With the suspend subcommand, you can interrupt the execution of a domain
temporarily:
virsh suspend domain_id
A suspended domain is not completely shut down. The current state is saved and the
execution of the domain can be continued with the resume subcommand:
virsh resume domain_id
To shut down a domain, use the shutdown subcommand:
virsh shutdown domain_id
This is equivalent to using the appropriate command within the virtual machine
(shutdown -h now in Linux).
If the domain is not responding anymore, you can force the shutdown of the domain
with the destroy command:
virsh destroy domain_id
This is equivalent to pulling the plug on a physical machine.
To save the state of a domain for a longer time (for example, over a reboot of Dom0)
you can use the save subcommand:
virsh save domain_id filename
The domain can be restored from the resulting file with the restore subcommand:
virsh restore filename
Another commonly used subcommand is setmem, which allows you to change the
memory allocation of a domain:
virsh setmem domain_id amount_of_memory
Version 1 230
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The amount of memory is specified in kilobytes.
Block devices can be added to DomUs with the disk-attach subcommand:.
virsh attach-disk domainID dev_in_Dom0 dev_in_DomU
To remove the device again, use in the detach-disk subcommand:
virsh detach-disk domainID dev_in_DomU
Automate Domain Startup and Shutdown
When you start, shut down, or reboot the Dom0 of a Xen system, other running Xen
domains are also affected. The other Xen domains cannot operate without a running
Dom0.
SUSE Linux Enterprise Server 11 comes with a start script called xendomains
which is included in the xen-tools package.
The script, which should be installed on Dom0, does the following:
When Dom0 is booted, all domains with configuration files located under /
etc/xen/auto/ are started. It is recommended to create a symbolic link in
this directory pointing to the actual configuration file in /etc/xen/vm/.
When Dom0 is shut down or rebooted, running Xen domains are shut down
automatically.
NOTE: If you have a configuration file for a domain that is also in the Xenstore database, the
automatic start uses the information in the configuration file and ignores the information in
Xenstore, which may be different from that in the configuration file.
To start and stop managed domains automatically you can create a start script based
on the /etc/init.d/skeleton file, using the applicable xm commands, such as
xm start vm_name and xm shutdown vm_name.
The xendomains script has configuration options that can be adjusted in the file /
etc/sysconfig/xendomains. The configuration variables in this file are
explained in accompanying comments.
One interesting option is to migrate domains automatically to a different host when a
Dom0 is shut down. This can be configured in the variable
XENDOMAINS_MIGRATE. The variable has to be set to the IP address of the target
machine. When the variable is empty, no migration is performed. Migration of virtual
machines is not covered in this course, though.
231 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 8-3 Automate Domain Startup
In this exercise, you learn how to start up domains automatically when the system is
booted.
(End of Exercise)
Version 1 232
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Objective 5 Understand Xen Networking
Usually the network connection of Xen domains works out of the box. However, if
you would like to change the configuration, networking with Xen can be a bit tricky.
The following should give you an overview of how Xen domains are connected to the
physical network. You need to
Understand Bridging on page 232
Understand the Xen Networking Concept on page 233
Check the Network Configuration on page 236
Understand Bridging
When you install Xen using the YaST Install Hypervisor and Tools module, the
network configuration is changed by YaST to include a network bridge.
Bridging basically means that multiple network interfaces are combined to one.
Traditionally, this technique is used to connect two network segments.
In the context of Xen, it is the default mechanism to connect virtual and physical
interfaces in Dom0. You can consider the bridge as a kind of virtual switch which
virtual and physical interfaces are connected to. The physical interface connects to
the physical network and the DomUs connect to the virtual interfaces, thus allowing
DomUs to access the physical network.
In a setup without a bridge, the configuration for the eth0 interface is contained in the
/etc/sysconfig/network/ifcfg-eth0 file. With the change to a bridge,
this file is deleted and a /etc/sysconfig/network/ifcfg-br0 file created.
Its content looks similar to the following:
The IP address is no longer assigned to the interface eth0 as before, but to the bridge
(in this case using dhcp). The interface that actually connects to the physical network
is attached to the bridge (BRIDGE_PORTS=eth0) but does not have an IP
address of its own.
da10:~ # cat /etc/sysconfig/network/ifcfg-br0
BOOTPROTO='dhcp'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth0'
BRIDGE_STP='off'
STARTMODE='onboot'
USERCONTROL='no'
233 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
This is reflected in the output of the ip command:
The command to configure network bridges is brctl. It can be used to list the
current setup, as in the following example:
Other brctl commands include the following:
brctl addbr name: Creates a new bridge named name.
brctl delbr name: Deletes the bridge named name. The network interface
corresponding to the bridge must be down before it can be deleted.
brctl addif brname ifname: Adds the interface ifname to the bridge brname.
brctl delif brname ifname: Deletes the interface ifname from the bridge brname.
Understand the Xen Networking Concept
In a Xen setup, the xend management process in Dom0 controls the physical network
interfaces of a host system. When a DomU starts up, the /etc/xen/scripts/
network-bridge script takes care of the virtual interface needed to connect the
new DomU to the physical network via the bridge.
When a new Domain U is created, the following changes to the network
configuration are made (simplified):
1. Xen provides a virtual network device to the new domain. Within that domain,
that device will appear as ethx.
2. xend creates a new virtual interface in Dom0.
da10:~ # ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
...
2: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
pfifo_fast state DOWN qlen 1000
link/ether 00:80:c8:f6:88:9f brd ff:ff:ff:ff:ff:ff
inet6 fe80::280:c8ff:fef6:889f/64 scope link
state UP qlen 100
link/ether 00:19:d1:9f:17:87 brd ff:ff:ff:ff:ff:ff
inet6 fe80::219:d1ff:fe9f:1787/64 scope link
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
inet 172.17.8.1/16 brd 172.17.255.255 scope global br0
da10:~ # brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0019d19f1787 no eth0
Version 1 234
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
3. The virtual interface in Dom0 and the virtual network device in the unprivileged
domain are connected through a virtual point-to-point connection.
4. The virtual interface in Dom0 is added to the bridge with the physical interface.
These steps affect only the general network connectivity. The IP configuration inside
the unprivileged domain is done separately with DHCP or a static network
configuration.
The following graphic illustrates the relationship of the various interfaces involved:
Figure 8-16 Xen Networking
The output of ip a s shows the new interface:
The new interface is added to the existing bridge, as shown in the output of brctl:
da10:~ # ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
...
2: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
pfifo_fast state DOWN qlen 1000
...
state UP qlen 100
...
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
inet 172.17.8.1/16 brd 172.17.255.255 scope global br0
5: vif1.0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UNKNOWN qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
inet6 fe80::fcff:ffff:feff:ffff/64 scope link
da10:~ # brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0019d19f1787 no eth0
vif1.0
235 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
The naming scheme is
vifdomain_number.interface_number
For example, the counterpart for eth0 in domain number 2 is vif2.0.
The /etc/xen/scripts directory contains additional scripts that can be used to set up
NAT or routing instead of the default bridge setup. In the /etc/xen/xend-
config.sxp file you can configure which network scripts are used by xend.
NOTE: Because of the complexity of the Xen network setup, the default firewall (SuSEFirewall2)
is not working correctly in Dom0. We recommend that you disable SuSEFirewall2 and then set up a
customized firewall script if needed.
Version 1 236
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Exercise 8-4 Check the Network Configuration
In this exercise, you learn how to use the brctl show command to view the bridge
setup and changes to it.
(End of Exercise)
237 Version 1
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Summary
Objective Summary
Understand How Virtualization with
Xen Works
Virtualization technology separates a running instance
of an operating system from the physical hardware.
Instead of running on a physical machine, the operating
system runs in a so-called virtual machine. Multiple
virtual machines share the resources of the underlying
hardware.
There are two different kinds of virtualization:
Full virtualization
Para-virtualization
Para-virtualization requires modifications to the
operating system running in the virtual machine.
Install Xen To use Xen, you have to install the Xen hypervisor, a
kernel that is aware of Xen, and the Xen management
tools in the SLES 11 installation running on the physical
hardware (the virtual machine server).
After booting the Xen kernel, you can install virtual
machines using the vm-install tool.
Manage Xen Domains with Virt-
Manager
Virt-Manager can be used to manage Xen domains.
Virt-Manager allows you to start virtual domains, open a
VNC window to view the graphical interface, and
change virtual hardware parameters such as available
RAM or hard disk space.
Virt-Manager displays all managed domains (running or
not) and running unmanaged domains.
Manage Xen Domains from the
Command Line
xm is the command line administration tool for xen
domains.
To start a virtual machine, the create subcommand is
used for unmanaged machines, while start is used for
managed machines:
xm create -c -f /etc/xen/vm/SLES11.conf
xm start sled11
Other frequently used xm subcommands are
shutdown, stop, new, and delete. Use xm help for
a complete list of available commands.
Version 1 238
N
o
v
e
l
l

T
r
a
i
n
i
n
g

S
e
r
v
i
c
e
s

(
e
n
)

1
5

A
p
r
i
l

2
0
0
9
Understand Xen Networking Domain 0 (Dom0) is the central point to configure the
network connections on a Xen system. The
configuration in Dom0 determines what virtual network
hardware is available within a domain U (DomU).
All unprivileged domains are connected with the
physical network through Dom0.
A network bridge in Dom0 is used as a virtual switch.
This bridge is controlled by xend.
The IP configuration of virtual network cards is done
from within the unprivileged domains.
Objective Summary

3100 Manual

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

3100 Manual

Загружено:

Авторское право:

Доступные форматы

www. novel l .

com Novel l Trai ni ng Servi ces

Вам также может понравиться