Red Hat Enterprise Deployment, Virtualization, and Systems Management Guide

RH401
Red Hat Enterprise Deployment,
Virtualization, and Systems Management
RH401-RHEL5-en-2-20070508

Copyright © 2007 Red Hat, Inc.
All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page i
Table of Contents
RH401 - Red Hat Enterprise Deployment,
Virtualization, and Systems Management
Introduction
Copyright ix
Notes on Internationalization x
Welcome xi
Participant Introductions xii
Red Hat Enterprise Linux xiii
Red Hat Enterprise Linux Variants xiv
Red Hat Network xv
Other Red Hat Supported Software xvi
The Fedora Project xvii
Classroom Network xviii
Objectives xix
Unit 1 - Essential System Management
Objectives 2
System Management Tasks 3
Standardization 5
Centralization 6
Scalability 7
Provisioning 8
Automation 9
The "One-off" Trap 10
Red Hat Tools for System Management 11
End of Unit 1 12
Unit 2 - Provisioning with DHCP and PXE
Objectives 14
Bare Metal Provisioning 15
Dynamic Host Configuration Protocol 16
Trivial File Transfer Protocol 17
Booting Anaconda over the Network 18
Accessing the Installer 19
PXE Boot 20
pxelinux.0 21
The pxelinux Configuration File 22
Common pxelinux Directives 23
PXE Boot Menu 24
DHCP Server 25
Essential dhcpd.conf Configuration 26

All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page ii
Reserved IP Addresses 27
Offering Files via DHCP 28
DHCP Scope and Groups 29
The PXE Class 30
Kickstart and DHCP 31
Lab 2: Bare Metal Provisioning 32
Sequence 1: Set up the provisioning network 33
Sequence 2: Configure a TFTP Server to support PXE 34
Sequence 3: Configure DHCP to support PXE 35
Unit 3 - Installing a Red Hat Network Satellite Server
Objectives 42
Features of the Satellite Server 43
Advantages of the Satellite Server 44
Components of the Satellite Server 45
Types of Satellite Server 46
Satellite Server Hardware Requirements 47
Understanding Software Channels 48
Installing Satellite Server: The Base Install 49
Installing Satellite Server: Filesystem Requirements 50
Installing the Satellite Software 51
Populating the Satellite Server: Options 52
Using Channel ISOs to Populate the Satellite Server 53
Understanding Channel Content ISOs 54
Populating the Satellite Server over the Network 55
Troubleshooting 56
End of Unit 3 57
Lab 3: Installing Red Hat Network Satellite Server 58
Sequence 1: Installing the RHN Satellite Server Software 59
Sequence 2: Populating the RHN Satellite Server with the RHEL4 AS
Channel
62
Sequence 3: Populating the RHN Satellite Server with Additional Channels 63
Unit 4 - Building RPMs
Objectives 65
RPM: Rolling Your Own 66
Building Open Source Software 67
Components 68
RPM Macros 69
Spec File: Preamble 70
Spec File: %prep 72
Spec File: %build 74
Spec File: %install 75
Spec File: %clean 77
Spec File: Scriptlets 78

All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page iii
Spec File: %files 79
Spec File: %changelog 81
rpmbuild 82
Signing RPM Packages 83
Guidelines for Custom RPMs 84
End of Unit 4 85
Lab 4: Building Custom RPMs 86
Sequence 1: Practice building Open Source software and building RPMs 87
Sequence 2: Preparing a RPM working environment 91
Sequence 3: Creating a spec file preamble 92
Sequence 4: Easy steps first 93
Sequence 5: %build and %install 95
Sequence 6: %files 97
Sequence 7: Scriptlets 99
Sequence 8: Building the RPM 100
Optional Sequence 9: Applying Patches 102
Unit 5 - Using CVS to Manage Configuration Files
Objectives 106
What is CVS? 107
How CVS Works 108
How CVS Works 109
CVS and System Administration 110
CVS Repository Limitations 111
Selecting a Repository 112
Using CVS 114
Starting a Working Directory 115
Committing Changed Files 116
Updating a Working Directory 117
Merging Conflicting Changes 119
Adding New Files 120
Removing Files 121
Renaming Files 122
Revision History 123
Viewing Repository History 124
Examining Old Revisions 125
Rolling Back to Old Revisions 126
Dealing with Binary Files 127
Dealing with Binary Files 128
The CVS Directories 129
Remote Repository Security 130
Creating an Empty Repository 131
Structuring a CVS Project 132
Starting a CVS Project 133
CVS File Permissions 134
CVSROOT 135

All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page iv
Advanced Features 136
An Alternative: subversion 137
End of Unit 5 138
Lab 5: Using CVS to Manage Configuration Files 139
Sequence 1: Preparing the CVS Repository and Users 140
Sequence 2: Starting a New Project in CVS 142
Sequence 3: Getting and Working With Files 144
Sequence 4: Moving Files 146
Sequence 5: Dealing with Conflicts 148
Optional Sequence 6: Some Additional Exercises 151
Unit 6 - Managing the Red Hat Network Satellite Server
Objectives 153
Preparing a Client to Use Satellite Server 154
Configuring the Client 155
Preparing to Script Client Configuration: Activation Keys 156
Scripting Client Configuration 157
Custom Channels 158
Preparing RPMs for Red Hat Network 159
Creating a Custom Channel 160
Populating a Custom Channel 161
Using a Custom Channel 162
Updating a Custom Channel 163
End of Unit 6 164
Lab 6: Managing the RHN Satellite Server 165
Sequence 1: Configure a Red Hat Network client to use the RHN Satellite
Server
166
Sequence 2: Creating and Populating a Private Channel 168
Optional Sequence 3: Updating a Private Channel 172
Unit 7 - Red Hat Network Management and Provisioning
Objectives 175
Types of RHN Service 176
RHN Update Service 177
RHN Management Service 178
RHN Provisioning Service 179
Elements of a Deployment System 180
Custom Channels 181
Software Channels 182
Configuration Channels 183
Configuring Clients to Use Configuration Channels 184
Macros and Configuration Channels 185
System Groups 186
Emerging Feature: RHN API 187
Putting it All Together, part 1 188

All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page v
Putting it All Together, part 2 189
End of Unit 7 190
Lab 7: RHN Management and Provisioning 191
Sequence 1: Creating a Configuration Channel 192
Sequence 2: Populating a Configuration Channel 193
Sequence 3: Creating a Group 194
Sequence 4: Creating an Activation Key 195
Sequence 5: Associating the configuration channel with the activation key 196
Sequence 6: Sequence 6: Associating the configuration channel with a
system group
197
Sequence 7: Sequence 7: Populating your satellite server with the proper
rhn-tools channel
198
Sequence 8: Create a kickstart file 199
Sequence 9: Configuring the kickstart file 200
Sequence 10: Kickstarting your system 202
Sequence 11: Provisioning a system with configuration files 203
Sequence 12: Using rhncfg-manager 205
Sequence 13: Questions 207
Unit 8 - Red Hat Network Proxy Server
Objectives 209
Prerequisites 210
Hosted RHN Architecture 211
RHN Proxy Server 212
RHN Proxy Server Components 213
Proxy Server Operations 214
Proxy Server Installation Overview 215
Proxy Server Installation Specifics 216
Client Configuration 217
End of Unit 8 218
Unit 9 - Network Kernel Crash Dumps and netdump
Objectives 220
netdump 221
Kernel Crash Signatures 222
Traditional Crash Dumps 223
Network Crash Dumps 224
The netdump Protocol 225
Configuring netdump Servers 226
Configuring netdump Clients 227
netdump Issues 228
kexec and kdump 229
Installing kexec and kdump 230
Introduction to Kernel Debugging With kdump 231
End of Unit 9 232

All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page vi
Lab 9: Kernel Crash Dumps 233
Sequence 1: Configuring the netdump server 234
Sequence 2: Configuring and testing the netdump client 235
Sequence 3: Configuring netconsole 236
Challenge Sequence 4: Challenge Exercises (optional) 237
Unit 10 - Red Hat Virtualization Overview
Objectives 239
Virtualization 240
Red Hat Virtualization 241
Virtualization Modes 242
Paravirtualization Benefits 243
Virtualization Terminology 245
Hardware Considerations 246
Red Hat Virtualization Packages 247
Installation Considerations 248
Dom0 Options 249
End of Unit 10 250
Lab 10: Installing Red Hat Virtualization 251
Sequence 1: Installing the Red Hat Virtualization Environment 252
Sequence 2: Creating a DomU Virtual Machine 253
Unit 11 - Virtual Machine Management
Objectives 257
Identifying Virtual Machines 258
Virtual Machine Management 259
xm 260
xm create 261
xm list 262
Basic xm commands 263
Monitoring Domains with xentop 264
virsh 265
On-The-Fly Resource Management 266
Accessing DomU Consoles 268
Virtual Machine Manager 269
End of Unit 11 270
Lab 11: Exploring Virtual Machine Management 271
Sequence 1: Creating a DomU 272
Sequence 2: Gathering Information about DomUs 273
Sequence 3: On-The-Fly Resource Management 274
Unit 12 - Installing and Configuring Virtual Machines
Objectives 280
Installing Virtual Machines 281

All rights reserved
RH401-RHEL5-en-2-20070508
Table of Contents Page vii
Virtual Machine Configuration 282
Virtual Machine Memory 283
Virtual Machine Storage 284
Virtual Machine Network Devices 286
Virtual Machine CPUs 287
Virtual Machine Consoles 288
Install Source 289
Install Utilities 290
Manual Install 292
End of Unit 12 293
Lab 12: Exploring Virtual Machine Installation and Configuration 294
Sequence 1: Manually Bootstrapping a Kickstarted DomU 295
Unit 13 - Hypervisor Details
Objectives 298
Hypervisor 299
xend 300
xend-config.sxp 301
Logging 302
Management Interfaces 303
Migration Interface 304
Dom0 305
Default vnc Console Access 306
Network Configuration 307
xendomains 308
End of Unit 13 309
Unit 14 - Virtualization: Advanced Techniques
Objectives 311
Advanced Techniques 312
Snapshot Storage 313
Implementing Snapshot Storage 314
Advanced Network Options 315
Creating Private Virtual Networks 316
Masquerading Virtual Machines 317
Physical Network Separation 318
Logical Network Separation 319
Live Migration 320
End of Unit 14 321
Lab 14: Advanced Virtualization Techniques 322
Sequence 1: Snapshot Based Domains 323
Sequence 2: Live Migration 324
Appendix A - Installing Software
Software Installation 329

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page viii
Introduction
Introduction
1
For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may be
photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials
are being improperly used, copied, or distributed please email <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page ix
Copyright
• The contents of this course and all its modules and related materials, including handouts
to audience members, are Copyright © 2007 Red Hat, Inc.
• No part of this publication may be stored in a retrieval system, transmitted or reproduced
in any way, including, but not limited to, photocopy, photograph, magnetic, electronic or
other record, without the prior written permission of Red Hat, Inc.
• This instructional program, including all material provided herein, is supplied without any
guarantees from Red Hat, Inc. Red Hat, Inc. assumes no liability for damages or legal
action arising from the use or misuse of contents or details contained herein.
• If you believe Red Hat training materials are being used, copied, or otherwise improperly
distributed please email training@redhat.com or phone toll-free (USA) +1 866 626 2994
or +1 919 754 3700.
2

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page x
Notes on Internationalization
• Red Hat Enterprise Linux supports nineteen languages
• Default language can be selected:
• During installation
• With system-config-language
• System->Administration->Language
• Alternate languages can be used on a per-command basis:
$ LANG=en_US.UTF8 date
• Language settings are stored in /etc/sysconfig/i18n
3
Red Hat Enterprise Linux 5 supports nineteen languages: English, Bengali, Chinese (Simplified), Chinese
(Traditional), French, German, Gujarati, Hindi, Italian, Japanese, Korean, Malayalam, Marathi, Oriya, Portuguese
(Brazilian), Punjabi, Russian, Spanish and Tamil. Support for Assamese, Kannada, Sinhalese and Telugu are provided
as technology previews.
A system's language can be selected during installation, but the default is US English. To use other languages, you
may need to install extra packages to provide the appropriate fonts, translations and so forth. These can be selected
during system installation or with system-config-packages ( Applications->Add/Remove Software).
The currently selected language is set with the LANG shell variable. Programs read this variable to determine what
language to use for output:
[student@stationX ~]$ echo $LANG
ru_RU.UTF8
A system's default language can be changed with system-config-language ( System+Administration->Language),
which affects the /etc/sysconfig/i18n file.
Languages with non-ASCII characters may have problems displaying in some environments. Kanji characters, for
example, may not display as expected on a virtual console. Individual commands can be made to use another language
by setting LANG on the command-line:
[student@stationX ~]$ LANG=en_US.UTF8 date
Thu Feb 22 13:54:34 EST 2007
Subsequent commands will revert to using the system's default language for output.
SCIM (Smart Common Input Method) can be used to input text in various languages under X if the appropriate
language support packages are installed. Type Ctrl-Space to switch input methods.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xi
Welcome
Please let us know if you have any special needs while at our
training facility.
4
Phone and network availability
Please only make calls during breaks. Your instructor will show you which phone to use. Network access and analog
phone lines may be available; your instructor will provide information about these facilities. Please turn pagers to
silent and cell phones off during class.
Restrooms
Your instructor will notify you of the location of these facilities.
Lunch and breaks
Your instructor will notify you of the areas to which you have access for lunch and for breaks
In case of Emergency
Please let us know if anything comes up that will prevent you from attending.
Access
Each facility has its own opening and closing times. Your instructor will provide you with this information.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xii
Participant Introductions
Please introduce yourself to the rest of the class!
5

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xiii
Red Hat Enterprise Linux
• Enterprise-targeted operating system
• Focused on mature open source technology
• 18-24 month release cycle
• Certified with leading OEM and ISV products
• Purchased with one year Red Hat Network subscription and
support contract
• Support available for seven years after release
• Up to 24x7 coverage plans available
6
The Red Hat Enterprise Linux product family is designed specifically for organizations planning to use Linux in
production settings. All products in the Red Hat Enterprise Linux family are built on the same software foundation,
and maintain the highest level of ABI/API compatibility across releases and errata. Extensive support services are
available: a one year support contract and Update Module entitlement to Red Hat Network are included with purchase.
Various Service Level Agreements are available that may provide up to 24x7 coverage with guaranteed one hour
response time. Support will be available for up to seven years after a particular release.
Red Hat Enterprise Linux is released on an eighteen to twenty-four month cycle. It is based on code developed by the
open source community and adds performance enhancements, intensive testing, and certification on products produced
by top independent software and hardware vendors such as Dell, IBM, Fujitsu, BEA, and Oracle. Red Hat Enterprise
Linux provides a high degree of standardization through its support for five processor architectures five processor
architectures (Intel x86-compatible, AMD AMD64/Intel 64, Intel Itanium 2, IBM POWER, and IBM mainframe on
System z).

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xiv
Red Hat Enterprise Linux Variants
• Two Install Sets available
• Server
• Red Hat Enterprise Linux Server
• Red Hat Enterprise Linux Advanced Platform
• Desktop
• Red Hat Enterprise Linux Desktop
• Workstation Option
• Multi-OS Option
7
Currently, on the x86-compatible architecture, the product family includes:
Red Hat Enterprise Linux Advanced Platform: the most cost- effective server solution, this product includes
support for the largest x86-compatible servers, unlimited virtualized guest operating systems, storage virtualization,
high-availability application and guest failover clusters, and the highest levels of technical support.
Red Hat Enterprise Linux: the basic server solution, supporting servers with up to two CPU sockets and up to four
virtualized guest operating systems.
Red Hat Enterprise Linux Desktop: a general purpose client solution, offering desktop applications such as the
OpenOffice.org office suite and Evolution mail client. Add-on options provide support for high-end development
workstations and virtualization.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xv
Red Hat Network
• A comprehensive software delivery, system management, and
monitoring framework
• Update Module: Provides software updates
• Included with all Red Hat Enterprise Linux subscriptions
• Management Module: Extended capabilities for large deployments
• Provisioning Module: Bare-metal installation, configuration management, and
multi-state configuration rollback capabilities
• Monitoring Module provides infrastructure health monitoring of networks,
systems, applications, etc.
8
Red Hat Network is a complete systems management platform. It is a framework of modules for easy software
updates, systems management, and monitoring, built on open standards. There are currently four modules in Red Hat
Network; the Update Module, the Management Module, the Provisioning Module, and the Monitoring Module.
The Update Module is included with all subscriptions to Red Hat Enterprise Linux. It allows for easy software updates
to all your Red Hat Enterprise Linux systems.
The Management Module is an enhanced version of the Update Module, which adds additional features tailored
for large organizations. These enhancements include system grouping and set management, multiple organizational
administrators, and package profile comparison among others. In addition, with RHN Proxy Server or Satellite Server,
local package caching and management capabilities become available.
The Provisioning Module provides mechanisms to provision and manage the configuration of Red Hat Enterprise
Linux systems throughout their entire life cycle. It supports bare metal and existing state provisioning, storage
and editing of kickstart files in RHN, configuration file management and deployment, multi-state rollback and
snapshot-based recovery, and RPM-based application provisioning. If used with RHN Satellite Server, support is
added for PXE bare-metal provisioning, an integrated network tree, and configuration management profiles.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xvi
Other Red Hat Supported Software
• Global Filesystem
• Directory Server
• Certificate Server
• Red Hat Application Stack
• JBoss Middleware Application Suite
9
Red Hat offers a number of additional open source application products and operating system enhancements which
may be added to the standard Red Hat Enterprise Linux operating system. As with Red Hat Enterprise Linux, Red
Hat provides a range of maintenance and support services for these add-on products. Installation media and software
updates are provided through the same Red Hat Network interface used to manage Red Hat Enterprise Linux systems.
Global Filesystem: an open source cluster file system appropriate for enterprise deployments, allowing servers to share
a common pool of storage.
Directory Server: an LDAP-based server that centralizes directory storage and data distribution, such as user and
group data.
Certificate Server: identity management software, using the Red Hat Directory Server as its back-end LDAP data
repository.
Red Hat Application Stack: the first fully integrated open source stack, supplying everything needed to run standards
based web applications, including Red Hat Enterprise Linux, JBoss Application Server with Tomcat, JBoss Hibernate,
and a choice of open source databases: MySQL or PostgreSQL, and Apache Web Server.
JBoss Middleware Application Suite: a suite of applications that provide a complete middleware solution.
For additional information, see the following web pages:
• Global Filesystem: https://www.redhat.com/solutions/gfs/
• Directory Server: https://www.redhat.com/solutions/directoryserver/
• Red Hat Application Stack: https://www.redhat.com/solutions/rhappstack/
• JBoss Middleware Application Suite: https://www.redhat.com/jboss/

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xvii
The Fedora Project
• Red Hat sponsored open source project
• Focused on latest open source technology
• Rapid four to six month release cycle
• Available as free download from the Internet
• An open, community-supported proving ground for technologies
which may be used in upcoming enterprise products
• Red Hat does not provide formal support
10
The Fedora Project is a community supported open source project sponsored by Red Hat intended to provide a rapidly
evolving, technology-driven Linux Distribution with an open, highly scalable development and distribution model. It
is designed to be an incubator and test bed for new technologies that may be used in later Red Hat enterprise products.
The basic Fedora Core distribution will be available for free download from the Internet.
The Fedora Project will produce releases on a short four to six month release cycle, to bring the latest innovations
of open source technology to the community. This may make it attractive for power users and developers who want
access to cutting-edge technology and can handle the risks of adopting rapidly changing new technology. Red Hat
does not provide formal support for the Fedora Project.
For more information, visit http://www.fedoraproject.org.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xviii
Classroom Network
Names IP Addresses
Our Network example.com 192.168.0.0/24
Our Server server1.example.com 192.168.0.254
Our Stations stationX.example.com192.168.0.X
Hostile Network cracker.org 192.168.1.0/24
Hostile Server server1.cracker.org 192.168.1.254
Hostile Stations stationX.cracker.org 192.168.1.X
Trusted Station trusted.cracker.org 192.168.1.21
11
The server1 system provides a number of services to the classroom network, including:
• A DHCP server
• A web server. The web server distributes RPMs at http://server1.example.com/pub.
• An FTP server. The FTP server distributes RPMs at ftp://server1.example.com/pub.
• An NFS server. The NFS server distributes RPMs at nfs://server1.example.com/var/ftp/pub.
• An NTP (network time protocol) server, which can be used to assist in keeping the clocks of classroom computers
synchronized.
• A sendmail server, which can be used to store e-mail inboxes. The sendmail server does not provide this service to
the classroom by default; the instructor will configure it if it is needed in the classroom.
• An NIS (network information systems) server, which can be used to distribute account information. The NIS
server is turned off by default; the instructor will enable it if it is needed in the classroom.

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xix
Objectives
• Understand large-scale deployment issues
• Deploy DHCP/PXE for bare metal provisioning
• Install and Configure RHN Satellite Server
• Build custom RPM software packages
• Use CVS to manage configuration files
• Understand RHN Proxy Server
• Enable netdump for network kernel crash dumps
• Understand Red Hat Virtualization
• Customize the Red Hat Virtualization environment
• Perform live migrarion of running virtual machines
12

All rights reserved
RH401-RHEL5-en-2-20070508
Introduction Page xx

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 1
Unit 1
Essential System Management
1-1

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 2
Objectives
Upon completion of this unit, you should be able to:
• Identify System Management Tasks
• Ideas for Best Practices
• Standardization
• Centralization
• Sacalibility
• Provisioning
• Automation
• Avoiding the 'One-Off' trap
• Identify Red Hat System Management Tools
1-2

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 3
System Management Tasks
• System startup and shutdown
• Maintenance of
• Filesystem Integrity and Free space
• Configuration Files
• Software Installation
• User Accounts
• Security
• System Monitoring
• Deployment of New Systems
• Decommissioning of Old Systems
1-3
The roll of the System Administrator on a linux or unix like system involves a number of varied and complicated
tasks. A defined and well thought out approach to these tasks is the key to running efficient and reliable systems. The
following is a small list of some of the important duties of the System Administrator.
Filesystem Integrity and Free Space: A breakdown in filesystem integrity means the potential loss of critical data. As
such, the System Administrator must check filesystem integrity on a regular basis and repair any inconsistencies as
soon as they are found.
The availability of free space is also the concern of the System Administrator. Periodic checking, daily, hourly, or as
required is essential in preventing a file system from filling completely and causing downtime.
Configuration Files: Many configuration files will require modification over the lifetime of an installed system. The
System Administrator must document all changes and maintain backup copies of previous revisions.
Software Installs: The System Administrator is responsible for proper installation and operation of all system software.
Additionally, the removal of software is also the responsibility of the System Administrator.
User Accounts: The days when anyone with a little experience could be trusted with administrator level access are
long gone. User accounts must be carefully managed and restricted to the minimum amount of access needed to fulfill
job requirements.
Security: It is incumbent upon the System Administrator to perform all tasks in the most secure manner possible. This
means evaluating every action taken as to its possible impact on system security. Adherence to well thought out and
documented procedures will go a long way in maintaining system security.
System Monitoring: In the simplest terms the System Administrator is responsible for “knowing what is going on.” In
practical terms this means keeping track of the state of each and every installed machine on an ongoing basis. Items to
track include, but are not limited to: cpu load, memory usage, and reboots.
Deployment of New Systems: The more hands on “expert” level work that is required to deploy a new system, the more
chances there are for something to go wrong. The process of taking a system from bare-metal to ready to use should be
as automated as possible to remove the possibility of human error, not to mention a lot of repetitive work!

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 4
Decommissioning of Old Systems: As old systems age beyond usefulness they must be removed and cleared of data.
At all times it is important to be able to determine the status of any installed system.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 5
Standardization
• Develop Procedures
• OS Installation and Upgrades
• Softeware Installation and Upgrades
• Creating Baseline
1-4
Standardization: Standardization is a very important piece of the puzzle of successful system administration.
Generally standardization is a prerequisite of automation, and automation is the ultimate goal. By performing tasks
with the same, well thought out method each and every time you will reduce the possibility of human error and
increase the amount you know about every installed system.
Procedures: A software installation procedure might be a follows:
1. Install new software on lab machines to determine appropriate configuration
2. Create RPM packges for any 3rd party software that does not natively support
RPM.
3. Test RPM packages on lab machines
4. Deploy tested RPM packages to production
5. Verify proper operation of affected systems
6. Rollback to previous configuration if necessary
Baselines: In System Administration a system baseline describes the state of the machine when it is considered
installed and ready for use. Whatever must be done to take the system from brand new to this state must be
documented and preferably automated.
The baseline must include:
• OS package install list
• Filesystem layout
• 3rd party software
• Configuration files
• Anything else!

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 6
Centralization
• Centrally Coordinate
• Policies
• Procedures
• Baselines
• Only One Place To “Look”
1-5
Central Coordination: By centralizing policies, procedures, and baselines into one easily managed system you make
all aspects of system administration more efficient. Having multiple places to search to find answers about your
systems is tedious and should be avoided.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 7
Scalability
• Scalability for System Administrators is the ability to increase (or
decrease) the size or capacity of their deployment with minimal
impact to the amount of work required to maintain all systems.
1-6
Scalability: In defining every project and procedure, scalability must always be an important consideration. A little
extra work up front will pay off in multitudes of saved time and avoided errors.
A Simple Example: OS Installation
If you install each and every one of your systems by hand you will not only spend a lot of time doing it, you will be
very prone to deviation in your install procedure. If instead you install all new machines using kickstart you will be
able to install many more machines at the same time, as well as being sure that it is done correctly each and every
time.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 8
Provisioning
• Provisioning describes the actual process of getting everything
in place to make a system ready to use.
• A provisioning system consists of several pieces of
infrastructure, such as:
• DHCP Server
• Kickstart Files
• Network Installation Server
• RHN Satellite Server
• PXE Capable Hardware
1-7
Provisioning: You may think of provisioning as the action taken to turn a system from bare-metal to installed and
configured to meet the defined baseline. This should be as close to a fully automated process as possible.
Putting The Pieces Together:
DHCP Server: Dispenses IP addresses, PXE images, and a host of other information including the addresses of
network file servers.
Network Installation Server: Stores and shares to the network all the files that make up the OS installation and
possibly in-house or 3rd party software as well.
RHN Satellite Server: Centrally managed server that deploys, maintains, and monitors Red Hat Enterprise Linux
systems.
PXE Capable Hardware: The client side of the PXE protocol. Most systems now include the ability to boot from
network images. Older systems may require upgrading with PXE capable nics.
Kickstart Files: The Kickstart file can be thought of as the complete set of instructions to install a new machine and
bring it to a full state of readiness. This text file includes install settings, options, and scripts.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 9
Automation
• Automation is the key to efficient and accurate system
deployment and management.
• Useful Tools:
• Bash, Perl, Ruby, and Sed
• Many More
1-8
Automation: Instead of repetitive work, automation generally requires more upfront work. Investing time in writing
kickstart files will allow you to install many more systems simultaneously and more quickly than one could ever
install by hand.
Tools: Bash, Perl, and Ruby are all scripting languages that may be used in the %post section of a kickstart file.
Sed is the streaming editor and is useful for making changes to existing files as well as editing the output from other
programs.
In the %post section of a kickstart file, all scripts run in a chrooted environment by default, allowing you to easily use
any interpreter installed on the new system. With the wide variety of tools included in Red Hat Enterprise Linux, there
is virtually no limit to what may be automatically performed for system installation or management.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 10
The "One-off" Trap
• Avoid Unique Installations
• Use Package Management For All Software
• Use Configuration File Management
• Document Everything
1-9
Avoid The "One-off" Trap: One-off systems require special care and extra work to maintain. Generally the longer they
are kept running the worse of a headache they become.
Unique Installations: Every uniquely installed system requires extra work to maintain. Avoid unique installations.
Package Management: Ideally, package management should be pervasive. Every piece of software install outside of
package management will require more work and at the same time be less visible as a potential problem.
Configuration Files: The use of a revisioning system to maintain configuration files, combined with a centralized
system to manage them allows for quick and efficient deployment as well as rollbacks, when needed.
Documentation: Everything should be documented. This includes software versions, baseline definitions,
configuration files, and procedures.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 11
Red Hat Tools for System Management
• RHN, Proxy and Satellite Servers
• RPM Package Manager
• Kickstart
• CVS
• DHCP and PXE
• Red Hat Virtualization
1-10
Red Hat Tools For System Management: The rest of this course is dedicated to the above tools, and more, for the
deployment and management of systems. As the size of a given installation increases so too does the importance of the
proper use of system management tools and techniques.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 1 Page 12
End of Unit 1
• Questions and Answers
• Summary
• System Management Tasks
• Ideas for Best Practices
• Standardization
• Centralization
• Sacalibility
• Provisioning
• Automation
• Avoiding the 'One-Off' trap
• Red Hat System Management Tools
1-11

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 13
Unit 2
Provisioning with DHCP and PXE
2-1

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 14
Objectives
• Understand components of bare metal provisioning
• Set up PXE and TFTP servers
• Implement a bare metal install environment
• Install and configure DHCP
• Configure reserved IP addresses in DHCP
• Understand DHCP scoping
• Use DHCP for the PXE process
2-2

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 15
Bare Metal Provisioning
• Goal
• Out-of-box system configuration with minimal human intervention
• Components
• Bootloader - GRUB, isolinux, syslinux, or pxelinux.0
• Unique machine identifier - MAC or IP address
• Usually provided by DHCP
• Network-capable installer - Anaconda
• Network Repositories
• Yum provide RPMs via http, nfs, or ftp
• Subversion can provide configuration files, incl. kickstart
• RHN Satellite can provide both
2-3
Unbox a new system, cable it, and push a button. From a broad perspective, the goal of bare metal provisioning is to
non-interactively prepare a new computer for use.
RHN Satellite can provide several critical pieces of this infrastructure, serving kickstart files, the installation files, and
configurations. RHN Satellite can help provide cradle-to-grave management for your servers.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 16
Dynamic Host Configuration Protocol
• Port 67/UDP server
• Port 68/UDP client
• Client sends a DHCPDISCOVER along with it's previous IP
address
• Server responds with a DHCPOFFER
• May offer the IP address that the client requested if available and authoritative
• May offer additional options, such as filename and IP of next server
• Client sends DHCPREQUEST
• Server sends DHCPACK
• Client uses offered address
2-4
DHCP allows a server to offer provisioning information to clients in a managed, automated fashion.
DHCP is a superset of BOOTP; dhcpd has been designed to answer requests from BOOTP clients. BOOTP clients will
retain their configuration information indefinitely; there is no notion of a lease in BOOTP.
The DHCP server sends and receives on port 67, and the client uses port 68. Both use UDP.
When the client network is configured for a dynamic IP address, it sends a DHCPDISCOVER packet to the broadcast
destination of 255.255.255.255. This will broadcast to the local physical subnet to find a DHCP server. Routers may
be configured to forward that packet to a DHCP server on a different subnet. The client also sends it's previous IP
address in this packet.
If any DHCP servers are listening on the local subnet (or the router forwarded that request to another subnet), it may
send the client a DHCPOFFER, based on it's configuration. These packets contain the DHCP server's IP address, the
router, the IP address and the subnet that the client should use, and the lease time. The DHCP server may also offer
other information, such as NTP servers, timezones, domains, etc.
The client must send a DHCPREQUEST back to the server, requesting the IP address that the DHCP server offered.
At first glance, this seems redundant. However, there may be multiple DHCP servers on the subnet, or the router may
be forwarding the DHCPOFFER to multiple networks, thus the client must send a DHCPREQUEST that includes the
client IP address, and the DHCP IP address to the broadcast address.
Once the DHCP server gets the DHCPREQUEST, it sends a DHCPACK, acknowledging that the clients has exclusive
rights to the client IP address until the lease time is up.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 17
Trivial File Transfer Protocol
• Features
• Trivial get and put commands similar to ftp
• Small feature set and minimal code
• UDP-only; little or no security
• tftp-server package provides tftpd
• Runs from /etc/xinetd/tftp
• chroots to /tftpboot by default
• tftp package provides client
• Useful for testing configuration
tftp my-tftpd-server -c get /pxelinux.cfg/default
2-5
Memory-constrained clients can use tftp to fetch files as directed by dhcp options.
The limited feature set of tftp enables the client to fit in tiny devices with extreme memory constraints, such as the
boot PROM on a network interface card. Thus tftp is the preferred mechanism for obtaining network boot files for bare
metal provisioning.
The minimal feature set extends to an utter lack of security, so you may need to implement physical security for
your provisioning network. Some organizations simply implement a separate kickstart network for this purpose. The
kickstart network can be physically isolated from other LAN segments to avoid placing insecure protocols on secure
networks. This can also protect sensitive build-time configuration files and in-house software from prying eyes.
tftpd chroots to /tftpboot at startup when using the default Red Hat Enterprise Linux configuration. All files and
subdirectories must be placed within the chroot. For example, suppose a tftp client requests the file /pxelinux.0.
The server will attempt to provide /tftpboot/pxelinux.0 based on the following, typical file tree:
/tftpboot/
|-- boot.msg
|-- pxelinux.0
|-- pxelinux.cfg
| |-- C0A80013
| |-- C0A80014
| `-- default
|-- rhel4u2
| |-- initrd.img
| `-- vmlinuz
`-- rhel5.0
|-- initrd.img
`-- vmlinuz

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 18
Booting Anaconda over the Network
• Must provide via tftp:
• vmlinuz matching the version to be installed
• initrd-*.img appropriate to hardware and kernel
• Available from /media/cd-number-one/images/pxeboot
• Must provide via http, nfs, or ftp:
• RedHat/base/stage2.img installer
2-6
As part of the bootstrap process, pxelinux uses tftp to download and run an initial RAM disk and kernel. The RAM
disk and kernel are specific to the version of Red Hat Enterprise Linux that you wish to install, and are in fact the same
versions that you will boot the installation with. As such, you can copy the kernel from the installation tree or from
another machine running that version of Red Hat Enterprise Linux.
For convenience, Red Hat provides copies of both files in the /images/pxeboot directory of the first installation
disk. If you would otherwise need to provide a driver disk for the installation process, you can use mkinitrd on a
running system of the same version and kernel, then place that initial RAM disk into your /tftpboot tree.
Your completed /tftpboot tree may look similar to:
/tftpboot/
|-- boot.msg
|-- pxelinux.0
|-- pxelinux.cfg
| `-- default
|-- rhel4u2
| |-- initrd.img
| `-- vmlinuz
`-- rhel5.0
|-- initrd.img
`-- vmlinuz
The PXE process also runs Anaconda for installation or for rescue mode, so you need to make
the binary available as part of your installation tree. The easiest way to do this is to include the
/media/cd-number-one/RedHat/base directory available via nfs, http, or ftp. The boot process will look in
that directory for stage2.img to run Anaconda.
One way to provide this installation tree is to create a directory on your server, then recursively copy all files from
each installation CD into the server directory. Red Hat Network Satellite provides this tree automatically.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 19
Accessing the Installer
• Graphical Installation
• Default installation type
• Useful Switches: lowres,resolution, skipddc
• VNC based Installation
• Activate with vnc and protect the session with vncpassword=password
• Set network parameters with ip=IP Address and netmask=Network Mask
• Text based Installation
• Started with the text switch
• Menu-based terminal interface
• Serial Installation
• Used automatically when no graphic card is detected
• Enable with: serial=device
2-7
The graphical interface makes installation easy and intuitive. The graphical interface can be started in lowres mode,
which means it uses lower screen resolution settings for the installation. The resolution switch can be used to specify
a resolution such as 1024x768. If monitor detection does not work properly it can be disabled by using the skipddc
switch.
The VNC interface is identical to the graphical interface. Once the second Stage of the installer is running you can
access it with the vncviewer. Alternatively you can use the vncconnect switch, so that the installer connects to an
listening vncviewer.
The text based installer is useful when the installer has difficulty managing your display adapter. While this is
uncommon, it can be particularly useful on laptops that have proprietary display adapters. The text based installation
does not support all installer features.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 20
PXE Boot
• PXE is Pre-Boot Execution Environment
• PXE provides a stage 1 bootloader
• NIC and BIOS must both support PXE
• The PXE boot process
• NIC requests DHCP information
• DHCP server provides bootloader name and IP of tftp server
• NIC uses tftp to fetch bootloader into RAM
• BIOS executes bootloader
• Bootloader uses tftp to find and retrieve configuration file
• Bootloader follows directives in file
2-8
Preboot eXecution Environment (PXE) is an environment to bootstrap computers using a network card. The network
card must support PXE (and most modern cards do), as well as the BIOS. The network interface card will broadcast
a DHCPDISCOVER packet extended with PXE-specific options. The DHCP server may then reply with an extended
DHCPOFFER passing the client information on the PXE server, as well as a client IP address.
The client sends a DHCPREQUEST, and the server sends back a DHCPACK containing the path to a file to boot that
the client can download via the Trivial FTP (TFTP) protocol. The client connects to the TFTP server (often times the
same machine as the DHCP server), downloads the specified file to RAM and verifies the file using a checksum. Once
verified, it is executed.
This is useful for system maintenance. Ideally, machines are configured in the BIOS to boot from local hard drive
first, and if that fails then to boot from the network. A network boot is set up to trigger an automatic Kickstart. So,
as long as the machine has a valid boot loader on the hard drive, the installation is left alone. If the hard drive has no
boot loader, it is a new machine and it gets Kickstarted. This means that once this is set up, you can start an automatic
re-installation by destroying the hard drive boot loader and rebooting.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 21
pxelinux.0
• Stage 1 network bootloader
• Provided in the syslinux package
• Independent of the OS to be installed
• Searches tftpd for pxelinux.cfg/filename, where
filename is:
1. MAC address using hex and dashes, prefaced with ARP type code
2. IP address expressed in hex
• Strips one digit at a time from the right-hand side of hex IP until file is found
• Use gethostip to translate decimal IP to hex
3. Last attempt is default
2-9
To find pxelinux.0 on your system, run
rpm -ql syslinux | grep pxe
pxelinux.0 is simply a first stage bootloader that is network-aware. Once executed by the client system's BIOS,
pxelinux.0 starts in the same directory from which it was downloaded - usually / - and begins a loop to read its
config file from the pxelinux.cfg/ subdirectory. The loop ends on the first successful get operation. This procedure is
documented in /usr/share/doc/syslinux-*/pxelinux.doc.
Suppose that a particular client's Ethernet address (ARP type code 1) is 12:34:56:AA:BB:CC and that DHCP provided
192.168.0.254 to the client. The stage 1 bootloader would loop through the following filenames and use the first one
retrieved:
pxelinux.cfg/01-12-34-56-aa-bb-cc
pxelinux.cfg/C0A800FE
pxelinux.cfg/C0A800F
pxelinux.cfg/C0A800
pxelinux.cfg/C0A80
pxelinux.cfg/C0A8
pxelinux.cfg/C0A
pxelinux.cfg/C0
pxelinux.cfg/C
pxelinux.cfg/default
Notes on relative file paths
• The tftp server stores files relative to the chroot, so the actual server-side location would be
/tftpboot/pxelinux.cfg/*.
• pxelinux retrieves file paths relative to the directory in which pxelinux.0 is stored on the tftpd.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 22
The pxelinux Configuration File
• Shares a common heritage with isolinux and syslinux
• Contains boot instructions
• Optionally displays a menu
• Supports serial redirection
• Ignores blank lines and uses # as a comment character
• There is no line continuation character
• See /usr/share/doc/syslinux-*/syslinux.doc
2-10
Here is an example /pxelinux.cfg/default configuration:
# pxelinux should download boot.msg and show to user
display boot.msg
# prompt user 60 seconds for a choice, then boot the default label
prompt 1
timeout 600
default quit
# safer to perform normal boot if no user response
label quit
localboot 0
# enter rhel5 rescue mode without answering questions
label r5
kernel rhel5.0/vmlinuz
append rescue ksdevice=link initrd=rhel5.0/initrd.img
ks=http://192.168.0.X/r5.cfg
label web5
kernel rhel5.0/vmlinuz
# mod_dav_svn makes latest copy of my kickstart available via apache
append ksdevice=eth0 initrd=rhel5.0/initrd.img
ks=http://192.168.0.X/svn/ks/latest/web5.cfg
label web4
kernel rhel4u2/vmlinuz
# mod_dav_svn makes latest copy of my kickstart available via apache
append ksdevice=eth0 initrd=rhel4u2/initrd.img
ks=http://192.168.0.X/svn/ks/latest/web4.cfg

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 23
Common pxelinux Directives
• DEFAULT some_label
• TIMEOUT tenths-of-a-second
• DISPLAY path/to/boot-menu-file
• PROMPT 0|1
• LOCALBOOT 0
• LABEL some_label
• KERNEL path/to/version-specific/vmlinuz
• APPEND options for kernel and kickstart
• Must provide tftp path for initrd
2-11
The filename specified after DISPLAY should be a relative path that pxelinux can download via tftp and print to the
console. This file is your PXE boot menu and provides an opportunity to explain the labels to your user.
The DISPLAY option is ignored if the file cannot be downloaded.
If you specify PROMPT 0 in the configuration file, then TIMEOUT is ignored, and pxelinux boots directly into the
DEFAULT label specification.
The KERNEL and APPEND directives work together to specify a path to the correct install-time kernel and options
to be appended to that kernel. The available kernel options for Red Hat Enterprise Linux are documented in
/usr/share/doc/anaconda-*/command-line.txt.
For PXE configurations, you must use the /media/cdrom/images/pxeboot/{vmlinuz,initrd} files that
correlate to the version of Linux you are attempting to install. For example, you must use the version 5.0 copies of the
kernel and ramdisk when installing Red Hat Enterprise Linux version 5.0.
LOCALBOOT 0 directs pxelinux to boot normally. In most cases this means the bootloader currently installed on the
hard drive. This provides a mechanism to abandon the PXE bootloader.
Note: PXE uses pathnames relative to the tftpd directory from which pxelinux.0 was downloaded.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 24
PXE Boot Menu
• Create using console text editor
• Use control characters for special effects
• Ctrl-L to clear screen
• Ctrl-O followed by two-digit code to change colors
• Use insert mode to enter Ctrl characters within vi
• Press Ctrl-v, then press Ctrl-character
• See /usr/share/doc/syslinux-*/syslinux.doc
2-12
To have your boot menu clear the screen before display, enter a Ctrl-L at the top of the file. Change colors using
Ctrl-O (as in OH, not zero) followed by a two-character color code in hex. The first character is the background color;
the second is the foreground.
Normal text should be coded as Ô07 for light grey. Bold white text can be coded as Ô0f. Other codes are listed in
syslinux.doc:
0 = black 8 = dark grey
1 = dark blue 9 = bright blue
2 = dark green a = bright green
3 = dark cyan b = bright cyan
4 = dark red c = bright red
5 = dark purple d = bright purple
6 = brown e = yellow
7 = light grey f = white
Here is a sample boot.msg file that could be used with the sample /pxelinux.cfg/default shown previously:
^LÔ04
____ _ _ _ _ ____ _ _
| _ ___ __| | | | | __ _| |_ | _ ___ ___| | _____| |
| |_) / _ / _` | |_| |/ _` | __| | |_) / _ / __| |/ / __| |
| _ < __/ (_| | _ | (_| | |_ | _ < (_) | (__| <__ _|
|_| ____|__,_|_| |_|__,_|__| |_| ____/ ___|_|____(_)
--------------------------------------------------------------Ô07
Type Ôc7quitÔ07 and press Enter to abandon now.
Ô0fquitÔ07 - Boot normally per BIOS (default)
Ô0fweb4Ô07 - Install a RHEL 4 webserver
Ô0fweb5Ô07 - Install a RHEL 5 webserver
Ô0fr5Ô07 - Rescue RHEL 5
This console is currently in ^Qtext^Rgraphic^Tserial^W mode!

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 25
DHCP Server
• The dhcp package provides dhcpd
• Configure the server in /etc/dhcpd.conf
• Sample configuration provided in
/usr/share/doc/dhcp-*/dhcpd.conf.sample
• There must be at least one subnet block, and it must correspond
with statically-configured interfaces.
• Red Hat Enterprise Linux 5:
• Run service dhcpd configtest to check syntax
2-13
To configure a dhcpd server, first use ip addr ls to verify that a BROADCAST address is specified in your network
configuration; Initial DHCP requests in IPv4 are broadcast and not sent to a specific server.
/etc/sysconfig/dhcpd can be used to configure dhcpd by setting the DHCPDARGS variable. The following
would only run the dhcpd server on eth0:
DHCPDARGS="eth0"
Best Practice: Always run service dhcpd configtest after editing /etc/dhcpd.conf since configuration errors can
prevent dhcpd from starting.
The dhcp package provides an IPv4 DHCP server. The dhclient package provides the IPv4 DHCP client. The
dhcpv6 package provides an IPv6 DHCP server, while the dhcpv6_client provides the IPv6 DHCP client.
The DHCP server is an SELinux restricted service when enforcing the default targeted policy on a
RHEL5 system. The server uses a number of SELinux contexts for its various files as indicated in
/etc/selinux/targeted/contexts/files/file_contexts.
The dhcp package in Red Hat Enterprise Linux 5 installs with an empty /etc/dhcpd.conf having the correct
SELinux context and a sample configuration in /usr/share/doc/dhcp-*. To start with the sample configuration
while preserving the SELinux context, run:
cat /usr/share/doc/dhcp-*/dhcpd.conf.sample > /etc/dhcpd.conf
Gotcha: dhcpd will not start if /var/lib/dhcpd/dhcpd.leases is missing, has the wrong
ownership/permissions, or has the wrong SELinux context.
See man 5 dhcpd.conf for detailed descriptions of options.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 26
Essential dhcpd.conf Configuration
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.254;
option subnet-mask 255.255.255.0;
option domain-name-servers 192.168.0.1;
option time-offset -18000; # EST
# dhcp clients
range 192.168.0.1 192.168.0.100;
default-lease-time 21600; # 6 hours
max-lease-time 43200; # 12 hours
# careful: bootp clients never release IPs
range dynamic-bootp 192.168.0.101 192.168.0.150;
}
2-14
One subnet section must be configured for each configured interface on the dhcp server. Override this requirement
in /etc/sysconfig/dhcpd with the DHCPDARGS variable, which can contain a space-separated list of interfaces
to which dhcpd should bind. Placing DHCPDARGS=eth0 in /etc/sysconfig/dhcpd would only require one
subnet declaration, and that declaration would apply to eth0.
ddns-update-style is the dynamic DNS update style. It should always be specified and may be one of ad-hoc,
interim, or none. Using interim, the DHCP server will send the client hostname to the DNS server.
range vs. range dynamic-bootp
The range line determines the range of IP addresses that the server will pass to DHCP clients only. The range
dynamic-bootp line determines the range of IP addresses that the server will pass to both dhcp and bootp clients.
The difference is that bootp clients do not relinquish their IPs. DHCP clients, on the other hand, recognize and use
lease times in order to better manage the IP range.
If a client does not ask for any particular lease length, the server will use the default-lease-time. The
max-lease-time determines the maximum possible lease time. These values are in seconds. The following
example would have a default lease time of six hours, and a maximum lease time of twelve hours:
default-lease-time 21600;
max-lease-time 43200;
These time values determine the amount of time that the DHCP server will reserve the IP address for the client. In
a QA lab, these lease time may be a few seconds--just enough time to run a few network tests on a certain machine.
Having a small lease time would mean that the DHCP server could rotate through the IP address range fairly quickly.
On the contrary, in an office environment, the lease times could be weeks or months, because the clients might rarely
change.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 27
Reserved IP Addresses
subnet 192.168.0.0 netmask 255.255.255.0 {
...truncated...
range 192.168.0.1 192.168.0.100;
host station151 {
# this IP must be outside dhcp and bootp ranges
hardware ethernet 12:34:56:78:AB:CD;
fixed-address 192.168.0.151;
}
}
2-15
The host declaration can bind a MAC address to an IP address--in essence giving it a static IP address. The
entry after the host parameter (in this case station151) may be passed to the DNS server when using
ddns-update-style interim.
In the example host entry above, we assign a hostname and IP address to a certain MAC address. If a DHCP client
having the MAC address 12:34:56:78:AB:CD attempts to get an IP address from this DHCP server, the DHCP server
will offer it an IP address of 192.168.0.151.
Options and Scope
In the example /etc/dhcpd.conf that we are developing in this unit, the ddns-update-style declaration is
said to be scoped globally. Many option paramaters can be placed in the global scope and will be applied to all other
scopes. However, an option placed in a specific scope, such as the host declaration shown above, overrides any
less-specific scopes. The example option routers is subnet scope; subnet scope is more specific than global but
less specific than host.
In a given scope, option specfications should be placed before (above) any declaration to which the option should
be applied.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 28
Offering Files via DHCP
subnet 192.168.0.0 netmask 255.255.255.0 {
...truncated...
# specify server and file locations
next-server 192.168.0.254; # could be dns name
filename "pxelinux.0" # always use quotes
host station151 {
# this IP must be outside dhcp and bootp range
}
}
2-16
This example adds two lines to the scope in order to offer it a pxelinux bootloader. If station151 is capable of PXE
booting, it will use tftp to get the file pxelinux.0 from 192.168.0.254. The server could also be expressed with a
DNS hostname.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 29
DHCP Scope and Groups
subnet 192.168.0.0 netmask 255.255.255.0 {
...truncated...
filename "other-file"; # subnet scope
next-server 192.168.0.254;
}
subnet 10.100.1.0 netmask 255.255.255.0 {
next-server 10.100.1.254;
...truncated...
}
group {
# this filename and host are in same scope
filename "pxelinux.0"; # overrides subnet scope
host station151 {
# other options matched to appropriate subnet scope
}
}
2-17
Options and Scope
In the example /etc/dhcpd.conf that we are developing in this unit, the ddns-update-style declaration is
said to be scoped globally. Many option paramaters can be placed in the global scope and will be applied to all other
scopes. However, an option placed in a specific scope, such as the host declaration shown above, overrides any
less-specific scopes. The example option routers is subnet scope; subnet scope is more specific than global but
less specific than host.
In a given scope, option specfications should be placed before (above) any declaration to which the option should
be applied.
The group declaration
The group declaration can be used in the global scope to share declarations that should be uniform across multiple
subnets.
In the example above, station151 will receive filename "pxelinux.0" from the group declaration since group is more
specific than subnet. However, the group does not provide a next-server, so dhcpd will point station151 to the
file server at 192.168.0.254, which matches the subnet of the host IP being offered.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 30
The PXE Class
• Some PXE PROMS will not use traditional dhcpd settings
• /usr/share/doc/syslinux-*/pxelinux.doc describes
techniques
• Possible solution in /etc/dhcpd.conf:
option space PXE;
class "PXE" {
match if substring(option vendor-class-identifier, 0, 9) =
"PXEClient";
option vendor-encapsulated-options 01:04:00:00:00:00:ff;
option boot-size 0x1;
filename "pxelinux.0";
option tftp-server-name "tftp.example.com";
option vendor-class-identifier "PXEClient";
vendor-option-space PXE;
}
2-18
The /etc/dhcpd.conf file can contain an additional section specifically for PXELINUX. The class declaration
should be globally scoped.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 2 Page 31
Kickstart and DHCP
subnet 192.168.0.0 netmask 255.255.255.0 {
option domain-name "example.com";
default-lease-time 21600;
max-lease-time 43200;
range 192.168.0.100 192.168.0.200;
filename "/kickstart/ks.cfg";
next-server server1.example.com;
}
option space PXE;
class "PXE" {
match if substring(option vendor-class-identifier, 0, 9) =
"PXEClient";
option tftp-server-name "server1.example.com";
}
2-19
Here we add a filename and next-server directive to tell the DHCP client where the kickstart file is located.
We also include the following lines that will boot the client for an installation.
option space PXE;
class "PXE" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
option tftp-server-name "server1.example.com";
}

All rights reserved
RH401-RHEL5-en-2-20070508
Lab 2 Page 32
Lab 2
Bare Metal Provisioning
Goal: Kickstart using PXE
Estimated Duration: 60 minutes
System Setup: You have two stations, X and Y. The lab assumes that stationX is connected
to the classroom network on eth0, with eth1 being connected via a crossover
cable or switch to eth0 of stationY. The classroom network may be referred
to as the frontend network. The crossover or switched environment between
stationX and stationY may be referred to as the backend, or provisioning,
network.
Lab Setup: The instructor should ensure that the classroom server provides a network
installation tree for Red Hat Enterprise Linux 4 as well as forward and reverse
DNS for the subnet 10.100.X.0/24, where X refers to the station numbers
of the classroom machines. For simplicity, you will begin with a prepared
kickstart file on server1.
Situation: You have been asked to provide a bare metal provisioning environment for
your backend network. You will prepare stationX as the provisioning server,
and you will provision stationY as a Red Hat Enterprise Linux 4 server using
the installation tree and a kickstart file from server1.
Specifications for your provisioning, or backend, network:
• stationX should appear as 10.100.X.254 on the backend and provide DHCP
to 10.100.X.0/24 over eth1 only
• stationY should use DHCP to obtain the reserved IP address 10.100.X.1
from stationX
• stationX should provide tftpd to the 10.100.X.0/24 network
• stationX should forward traffic to the frontent
• server1 at 192.168.0.254 provides DNS for all 10.100.X.0/24 subnets
• server1 provides a network installation tree for Red Hat Enterprise Linux 4

All rights reserved
RH401-RHEL5-en-2-20070508
Lab 2 Sequence 1 Page 33
Sequence 1: Set up the provisioning network
Scenario: In this sequence, you will set up an appropriate networking configuration.
Deliverable: A working backend network on stationX, with stationX acting as a router to
the frontend.
Lab Setup: A system running Red Hat Enterprise Linux 4 with two interfaces, one
connected to the classroom network and the other connected to your private
network.
Instructions:
1. Configure 10.100.X.254 as a static IP on the backend interface.
2. You may not be able to fully test the interface until you power up your other machine.
However, you can do a preliminary test by pinging the interface address.
3. Enable forwarding on stationX.

All rights reserved
RH401-RHEL5-en-2-20070508
Sequence 2: Configure a TFTP Server to support PXE
Scenario: In this sequence you will configure the tftpd environment to support PXE.
Deliverable: An operational TFTP server that can support PXE clients.
System Setup: stationX should be dual-homed to 10.100.X.0/24 and 192.168.0.0/24.
Instructions:
1. Ensure that tftpd is installed on stationX.
2. Start tftpd and ensure it starts at boot-time.
3. Create a PXE tree and populate it with the appropriate kernel and RAM disk for
building a Red Hat Enterprise Linux 4 machine. The files should be available via NFS at
server1:/var/ftp/pub/.
4. Create a simple /tftpboot/boot.msg file that gives the user a choice between normal
boot and a Red Hat Enterprise Linux 4 installation.
5. Create a pxelinux configuration file for 10.100.X.1 that prompts the user for a boot
choice, displays the file boot.msg, and defaults to booting the kickstart available at
http://server1.example.com/workstation.cfg. However, this file should only be used by the
machine with an IP address of 10.100.X.1, where X is your station number.
6. Create /tftpboot/pxelinux.cfg/default such that the machine boots normally if
the user fails to respond to the PXE menu.
7. Use the tftp command to ensure that your files are accessible.

All rights reserved
RH401-RHEL5-en-2-20070508
Sequence 3: Configure DHCP to support PXE
Scenario: You want to install a DHCP server that will give IP addresses, both generally,
and based on MAC address, to your provisioning network.
Deliverable: A DHCP server
Lab Setup: A system running Red Hat Enterprise Linux 4 with two network interfaces,
one connected to the classroom network and the other connected to your
provisioning network. You should have a second system that is connected only
to the provisioning network.
Instructions:
1. Use /usr/share/doc/dhcp-*/dhcpd.conf.sample file as a starting point for the
DHCP server. Change the subnet to the 10.100.X.0/255.255.255.0 subnet. Change the router
to the IP address of your DHCP server. Change the DNS server to 192.168.0.254. Finally,
change the range to 10.100.X.2 through 10.100.X.10.
2. Configure the DHCP service to only give out IP addresses on the ethernet card attached to
the private subnet (this should be eth1 unless your instructor gives other instructions).
3. Open a second shell and follow /var/log/messages.
4. Start dhcpd and configure it to start at boot-time.
5. PXE-boot your second workstation. You may need to press F12 during the boot sequence
to choose network boot. Observe /var/log/messages as well as the boot messages on
your client machine (stationY).
6. Use the MAC address of your second machine as recorded in /var/log/messages
on stationX to add a host IP reservation for 10.100.X.1 to /etc/dhcpd.conf. Restart
dhcpd.
7. PXE-boot the client machine and verify that it gets the new address. It should also display
the PXE boot menu that you created in a previous step. Choose the option to install Red Hat
Enterprise Linux 4.

All rights reserved
RH401-RHEL5-en-2-20070508
Lab 2 Sequence 1 Solutions Page 36
Sequence 1 Solutions
1. Edit /etc/sysconfig/network-scripts/ifcfg-eth1 to configure
10.100.X.254 as a static IP on the backend interface:
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.100.X.254
NETMASK=255.255.255.0
If your file includes the HWADDR line, leave it in the file.
2. You may not be able to fully test the interface until you power up your other machine.
However, you can do a preliminary test by pinging the interface address.
ifup eth1
ping -c1 -s0 -W1 10.100.X.254
3. Edit /etc/sysctl.conf to enable forwarding at boot-time:
net.ipv4.ip_forward = 1
Reload /etc/sysctl.conf into the kernel:
sysctl -p

All rights reserved
RH401-RHEL5-en-2-20070508
1. Ensure that tftpd is installed on stationX.
rpm -q tftp-server
Install tftp-server from server1. Ask the instructor for help if necessary.
2. Start tftpd and ensure it starts at boot-time.
chkconfig tftp on
tftpd is managed by xinetd, so using chkconfig to enable tftpd also reloads the xineted
configuration.
3. Create a directory and mount the export from server1:
mkdir /mnt/server1
mount server1:/var/ftp/pub/4.2.0 /mnt/server1
Create the PXE tree.
mkdir /tftpboot/{rhel4,pxelinux.cfg}
cp /mnt/server1/images/pxeboot/* /tftpboot/rhel4/
Locate pxelinux.0 on stationX and copy it to the PXE tree. Recall that pxelinux is a
version-independent bootloader.
rpm -ql syslinux | grep pxe
/usr/lib/syslinux/pxelinux.0
/usr/share/doc/syslinux-*/pxelinux.doc
cp /usr/lib/syslinux/pxelinux.0 /tftpboot/
4. Create the file /tftpboot/boot.msg. A simple solution is given here, but feel free to
experiment with control characters to add color to your menu.
RH401 PXE Menu
Choose a boot option from the list below:
quit - abandon PXE and boot normally
4 - install Red Hat Enterprise Linux 4
5. Create a pxelinux configuration file for 10.100.X.1 that prompts the user for a boot
choice, displays the file boot.msg, and defaults to booting the kickstart available at
http://server1.example.com/workstation.cfg. However, this file should only be used by the
machine with an IP address of 10.100.X.1, where X is your station number.
First, determine the correct filename. Use the gethostip command to provide the
hexadecimal representation of the IP. For example, the following command would be used
if you are at station1:

All rights reserved
RH401-RHEL5-en-2-20070508
gethostip 10.100.1.1
10.100.1.1 10.100.1.1 0A640101
Create the file /tftpboot/pxelinux.cfg/0A64NN01, where NN is the hexadecimal
representation of your station number.
default quit
prompt 1
timeout 600
display boot.msg
# safety net
label quit
localboot 0
# install using kickstart from server1
label 4
kernel rhel4/vmlinuz
append initrd=rhel4/initrd.img
ks=http://192.168.0.254/rhel4as.cfg ksdevice=link
6. Create /tftpboot/pxelinux.cfg/default such that the machine boots normally
with no prompt or feedback from the user.
Here is one solution:
default normal
prompt 0
label normal
localboot 0
7. Use the tftp command to ensure that your files are accessible. Remember to replace the NN
in 0A64NN01 with the hex representation of your station number.
cd /tmp
tftp localhost -c get /boot.msg
tftp localhost -c get /pxelinux.cfg/default
tftp localhost -c get /pxelinux.cfg/0A64NN01
cat boot.msg default 0A64NN01
...output omitted...

All rights reserved
RH401-RHEL5-en-2-20070508
1. Use the /usr/share/doc/dhcp-*/dhcpd.conf.sample file as a starting point
for the DHCP server. Change the subnet to the 192.168.2.0/255.255.255.0 subnet. Change
the router to the IP address of your DHCP server. Change the DNS server to 192.168.0.254.
Finally, change the range to 10.100.X.2 through 10.100.X.10.
a. Copy /usr/share/doc/dhcp-*/dhcpd.conf.sample to
/etc/dhcpd.conf. Make changes to that file, so that the file looks something like
the following. The X should match the last octet in your IP address.
ddns-update-style interim;
ignore client-updates;
subnet 10.100.X.0 netmask 255.255.255.0 {
option routers 10.100.X.254;
# change to your timezone
option time-offset -18000; # EST
range 10.100.X.2 10.100.X.10
default-lease-time 600; # 10 minutes
max-lease-time 3600; # 1 hour
next-server 10.100.X.254;
}
2. Configure the DHCP service to only give out IP addresses on the ethernet card attached to
the private subnet (this should be eth1 unless your instructor gives other instructions). Start
the dhcpd service and ensure that it starts at boot.
a. Edit /etc/sysconfig/dhcpd to include this line:
DHCPDARGS=eth1
b. chkconfig dhcpd on
c. service dhcpd start
3. Open a second shell and follow /var/log/messages.
tail -f /var/log/messages
Leave this shell open so that you can observe log messages.
Start dhcpd and configure it to start at boot-time.

All rights reserved
RH401-RHEL5-en-2-20070508
4. service dhcpd start
chkconfig dhcpd on
Observe the messages in your other shell.
5. PXE-boot your second workstation. You may need to press F12 during the boot sequence
to choose network boot. Observe /var/log/messages as well as the boot messages on
your client machine (stationY).
Your client machine should receive the IP address 10.100.X.10 since dhcpd offers
addresses beginning with the last address in its range.
Your client machine should have obtained the default PXE configuration and therefore
booted normally according to its BIOS settings. If your client machine has no other
bootloader in the MBR or removable media, and PXE is configured in the list of boot
options, this means your client may enter an endless PXE boot sequence!
In any case, power off the client machine.
6. Use the MAC address of your second machine as recorded in /var/log/messages
on stationX to add a host IP reservation for 10.100.X.1 to /etc/dhcpd.conf. Replace
12:34:56:78:AB:CD with the appropriate MAC address from /var/log/messages. Replace X
with your station number.
subnet 10.100.X.0 netmask 255.255.255.0 {
...options truncated...
host stationY {
fixed-address 10.100.X.1;
}
}
For simplicity, place the host declaration near the bottom of your subnet scope, but before
the closing brace of the subnet scope.
Restart dhcpd.
service dhcpd restart
7. PXE-boot the client machine and verify that it gets the new address. It should also display
the PXE boot menu that you created in a previous step. Choose the option to install Red Hat
Enterprise Linux 4.

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 3 Page 42
Objectives
• Understand the need for the Red Hat Network Satellite Server in
the enterprise
• Understand the interactions among RHN, the satellite server,
and the proxy server
• Know the minimum and recommended requirements for a
satellite server
• Be able to install a satellite server
3-2

All rights reserved
RH401-RHEL5-en-2-20070508
Unit 3 Page 43
Features of the Satellite Server
• Provides RHN service for networks disconnected from the
internet
• Supports tiered RHN Proxy or Satellite Servers
• Manages local software through custom channels
• Bare metal provisioning and hands free installation make large
and small rollouts simple
3-3
The original Red Hat Network solution provided users with the ability to get immediate and easy access to the latest
updated software, thus solving the critically important problem of errata concurrency. With the success of this product
came the problem of data access speeds, particularly in enterprises containing a large number of systems: many
systems were synchronizing with the Red Hat Network servers from a single location, often downloading the same
data.
The RHN Satellite Server was created to solve this problem. The RHN Satellite server provides an onsite server that
feeds updates within an enterprise with minimal (or potentially no) access the the Red Hat Network servers over
the internet. This permits updates to happen over LAN speeds, instead of WAN speeds. Furthermore, tiered with a
number of RHN Proxy or additional Satellite Servers, a large enterprise can distribute updates efficiently across a
geographically dispersed intranet.
Other key features of the RHN Satellite Server include the ability to create custom channels so that you can add your
own software into the system and the ability to do bare metal provisioning, installing across a large number of systems
with relative ease.

Red Hat Enterprise Deployment, Virtualization, and Systems Management Guide

Red Hat Enterprise Deployment, Virtualization, and Systems Management Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Red Hat Enterprise Deployment, Virtualization, and Systems Management Guide

Similar to Red Hat Enterprise Deployment, Virtualization, and Systems Management Guide (20)

Recently uploaded

Recently uploaded (20)

Red Hat Enterprise Deployment, Virtualization, and Systems Management Guide