Vous êtes sur la page 1sur 302

Red Hat Enterprise Deployment and

Systems Management
Student Workbook
Red Hat Enterprise Linux 6
Release en-1-20110713

RED HAT
ENTERPRISE
DEPLOYMENT
AND SYSTEMS
MANAGEMENT

RH401

Red Hat Enterprise Linux 6 RH401


Red Hat Enterprise Deployment and Systems Management
Edition 1
Author
Author
Editor

George Hacker
Forrest Taylor
Steven Bonneville

Copyright 2011 Red Hat, Inc.


The contents of this course and all its modules and related materials, including handouts to
audience members, are Copyright 2011 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 e-mail training@redhat.com or phone toll-free (USA) +1 (866) 626-2994
or +1 (919) 754-3700.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, Hibernate, Fedora, the
Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and
other countries.
Linux is the registered trademark of Linus Torvalds in the United States and other
countries.
Java is a registered trademark of Oracle and/or its affiliates.
XFS is a registered trademark of Silicon Graphics International Corp. or its subsidiaries in
the United States and/or other countries.
All other trademarks are the property of their respective owners.

Document Conventions vii


Notes and Warnings ............................................................................................... vii
Introduction ix
Welcome to class! ................................................................................................... ix
About Red Hat Enterprise Linux ............................................................................... ix
Additional Red Hat Enterprise Linux Software ............................................................ x
Contacting Red Hat Technical Support ..................................................................... xii
About This Course xv
Red Hat Enterprise Deployment and Systems Management ......................................... xv
Structure of the Course .......................................................................................... xv
Orientation to the Classroom Network ..................................................................... xvi
Internationalization xvii
Language Support ................................................................................................ xvii
System-wide Default Language .............................................................................. xvii
Per-user Language Selection ................................................................................. xvii
Input Methods ..................................................................................................... xviii
Language Codes Reference .................................................................................. xviii
1. Essential System Management
Enterprise Management Best Practices ......................................................................
PXE/Kickstart Installation .........................................................................................
Criterion Test ..........................................................................................................

1
2
6
8

2. Installing a Red Hat Network Satellite Server 13


RHN Satellite Server Concepts ................................................................................ 14
RHN Satellite Server Installation .............................................................................. 16
Obtaining Software from Hosted RHN ....................................................................... 21
Importing Initial Software Packages ......................................................................... 25
Criterion Test ........................................................................................................ 29
3. Red Hat Network Organization
RHN Organization Administration ............................................................................
RHN User Administration .......................................................................................
System Groups ......................................................................................................

33
34
36
40

4. Using Subversion to Manage Changes


Revision Control Concepts ......................................................................................
Subversion Administration .....................................................................................
Revision Management with Subversion ....................................................................

45
46
48
52

5. Red Hat Network Client Configuration 63


Client Registration Concepts .................................................................................. 64
Interactive Client Registration ................................................................................ 66
Registration Automation: Activation Keys .................................................................. 71
Registration Automation: bootstrap.sh ..................................................................... 75
Resolving Registration Problems ............................................................................. 77
6. Red Hat Network Software Management 81
Software Channels ................................................................................................. 82
Custom Software Channels ..................................................................................... 83
Loading RPMS into RHN Satellite ............................................................................ 88
Using a Custom Channel ........................................................................................ 92

RH401-6-en-1-20110713

iii

RH401

Software Management Using Cloned Channels ......................................................... 94


Managing Software Updates ................................................................................... 97
7. Building RPMs 101
RPM Package Design/Architecture .......................................................................... 102
Spec File Directives and Sections ........................................................................... 104
Creating a Spec File ............................................................................................. 107
Software Build Process ........................................................................................... 111
Criterion Test ........................................................................................................ 115
8. Configuration File Management with RHN
Configuration Channel Management .......................................................................
Client Configuration ..............................................................................................
Configuration File Management ..............................................................................
Flexible Configuration with Macros .........................................................................

119
120
124
127
130

9. Provisioning with PXE


Provisioning Requirements ....................................................................................
Tuning RHN Satellite for Provisioning .....................................................................
Dynamic Host Configuration Protocol .....................................................................
Cobbler and Koan ................................................................................................

135
136
137
145
150

10. RHN Virtual Machine Management 157


Virtual Host Configuration ..................................................................................... 158
Virtual Machine Provisioning ................................................................................. 163
11. RHN Satellite Server Administration 171
RHN Satellite Database Management ...................................................................... 172
Satellite Server Management ................................................................................. 177
Software Channel Synchronization .......................................................................... 181
High Availability Options ....................................................................................... 183
Troubleshooting Satellite Server Issues ................................................................... 184
12. RHN Application Programming Interface
Application Programming Interface Scripting ...........................................................
RHN Satellite Reporting Tool .................................................................................
Criterion Test .......................................................................................................

189
190
196
197

13. Comprehensive Review 201


Preparations/Do You Still Have Questions? ............................................................. 202
Criterion Test ...................................................................................................... 204
A. Solutions 209
Essential System Management .............................................................................. 209
Installing a Red Hat Network Satellite Server ........................................................... 212
Red Hat Network Organization .............................................................................. 220
Using Subversion to Manage Changes .................................................................... 223
Red Hat Network Client Configuration .................................................................... 230
Red Hat Network Software Management ................................................................ 236
Building RPMs ..................................................................................................... 245
Configuration File Management with RHN .............................................................. 248
Provisioning with PXE .......................................................................................... 252
RHN Virtual Machine Management ........................................................................ 262
RHN Satellite Server Administration ...................................................................... 269

iv

RH401-6-en-1-20110713

RHN Application Programming Interface ................................................................ 273


Comprehensive Review ......................................................................................... 278

RH401-6-en-1-20110713

vi

Document Conventions
Notes and Warnings
Note
"Notes" are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note
should have no negative consequences, but you might miss out on a trick that makes your
life easier.

Comparison
"Comparisons" look at similarities and differences between the technology or topic being
discussed and similar technologies or topics in other operating systems or environments.

References
"References" describe where to find external documentation relevant to a subject.

Important
"Important" boxes detail things that are easily missed: configuration changes that only apply
to the current session, or services that need restarting before an update will apply. Ignoring
a box labeled "Important" will not cause data loss, but may cause irritation and frustration.

Warning
"Warnings" should not be ignored. Ignoring warnings will most likely cause data loss.

RH401-6-en-1-20110713

vii

viii

Introduction
Welcome to class!
Thank you for attending this Red Hat training class. Please let us know if you have any special
needs while at our training facility.
Please ask the instructor if you have any questions about the facility, such as operating hours
of the facility and when you will have access to the classroom, locations of restrooms and break
rooms, availability of telephones and network connectivity, and information about the local area.
As a courtesy to other students, please place your pager or cell phone's ringer on vibrate or
mute, or turn off your devices during class. We ask that you only make calls during break periods.
If you have a personal emergency and are unable to attend or complete the class, please let us
know. Thank you!

About Red Hat Enterprise Linux


This course is taught using Red Hat Enterprise Linux, an enterprise-targeted Linux distribution
focused on mature open source software designed specifically for organizations using Linux in
production settings.
Red Hat Enterprise Linux is sold on a subscription basis, where the subscription gives you
continues access to all supported versions of the operating system in binary and source form,
not just the latest one, including all updates and bug fixes. Extensive support services are
included: a support contract and Update Module entitlement to Red Hat Network are included
for the subscription period. Various Service Level Agreements are available that may provide up
to 24x7 coverage with a guaranteed one hour response time for Severity 1 issues. Support will
be available for up to seven years after a particular major release (ten years with the optional
"Extended Update Support" Add-On).
Red Hat Enterprise Linux is released on a multi-year cycle between major releases. Minor
updates to major releases are released roughly every six months during the lifecycle of the
product. Systems certified on one minor update of a major release continue to be certified for
future minor updates of the major release. A core set of shared libraries have APIs and ABIs
which will be preserved between major releases. Many other shared libraries are provided, which
have APIs and ABIs which are guaranteed within a major release (for all minor updates) but
which are not guaranteed to be stable across major releases.
Red Hat Enterprise Linux is based on code developed by the open source community, which
is often first packaged through the Red Hat sponsored, freely-available Fedora distribution
(http://fedoraproject.org/). Red Hat then adds performance enhancements, intensive
testing, and certification on products produced by top independent software and hardware
vendors. Red Hat Enterprise Linux provides a high degree of standardization through its support
for four processor architectures (32-bit Intel x86-compatible, AMD64/Intel 64 (x86-64), IBM
POWER, and IBM mainframe on System z). Furthermore, we support the 4000+ ISV certifications
on Red Hat Enterprise Linux whether the RHEL operating system those applications are using

RH401-6-en-1-20110713

ix

Introduction

is running on bare metal, in a virtual machine, as a software appliance, or in the cloud using
technologies such as Amazon EC2.
Currently, the Red Hat Enterprise Linux product family includes:
Red Hat Enterprise Linux for Servers: the datacenter platform for mission-critical servers
running Red Hat Enterprise Linux. This product includes support for the largest x86-64 and
x86-compatible servers and the highest levels of technical support, deployable on bare metal,
as a guest on the major hypervisors, or in the cloud. Subscriptions are available with flexible
guest entitlements of one, four, or unlimited guests per physical host. Pricing is based on the
basis of the number of socket-pairs populated on the system motherboard, the number of
guests supported, the level of support desired, and the length of subscription desired.
Red Hat Enterprise Linux for IBM POWER and Red Hat Enterprise Linux for IBM System z are
similar variants intended for those system architectures.
Red Hat Enterprise Linux Desktop: built for the administrator and end-user, Red Hat Enterprise
Linux Desktop provides an attractive and highly productive environment for knowledge
workers on desktops and laptops. Client installations can be finely tailored and locked down for
simplicity and security for any workstation task.
The basic Desktop variant is designed for task workers who have a limited amount of
administrative control over the system, who primarily use productivity applications like Firefox
Evolution/Thunderbird, OpenOffice.org, and Planner/TaskJuggler. The more sophisticated
Workstation variant is designed for advanced Linux users who need a stand-alone development
environment, and who are expected to have local super-user privileges or selected super-user
privileges.
In addition, other variants exist such as Red Hat Enterprise Linux for HPC Head Node and Red
Hat Enterprise Linux for HPC Compute Node (targeted at high-performance computing clusters),
and Red Hat Enterprise Linux for SAP Business Applications. For more information please visit
http://www.redhat.com/.

Additional Red Hat Enterprise Linux Software


Two additional software update channels are provided with Red Hat Enterprise Linux beyond the
core software packages shipped:
Supplementary: the "Supplementary" channel provides selected closed source packages,
built for Red Hat Enterprise Linux as a convenience to the customer. These include things like
Adobe Flash or proprietary Java JVMs.
Optional: the "Optional" channel provides selected open source packages, as a convenience
only. They are generally included in another Red Hat Enterprise Linux variant as a fullysupported package, or are a build requirement for the distribution. These packages are only
available through a Red Hat Network child channel.

RH401-6-en-1-20110713

Additional Red Hat Enterprise Linux Software

Important
Supplementary and Optional packages are provided with limited support, as a customer
convenience only.

Red Hat also offers a portfolio of fully-supported Add-Ons for Red Hat Enterprise Linux which
extend the features of your Red Hat Enterprise Linux subscription. These add-ons allow you to
add capabilities and tailor your computing environment to your particular needs. These Add-Ons
include support for high availability application clustering, cluster file systems and very large file
systems, enhanced system management with Red Hat Network, extended update support, and
more.

Note
Please visit http://www.redhat.com/rhel/add-ons/ for more information about
available Add-Ons for Red Hat Enterprise Linux.
For information about other products which are provided by Red Hat, such as Red Hat
Enterprise Virtualization, JBoss Enterprise Middleware, Red Hat Enterprise MRG, and various
custom consulting and engineering services, http://www.redhat.com/products/ also
has useful information.

The Fedora Project also provides additional packages for Red Hat Enterprise Linux through EPEL
(Extra Packages for Enterprise Linux). EPEL is a volunteer-based community effort to create a
repository of high-quality add-on packages which can be used with Red Hat Enterprise Linux and
compatible derivatives. It accepts legally-unencumbered free and open source software which
does not conflict with packages in Red Hat Enterprise Linux or Red Hat add-on products. EPEL
packages are built for a particular major release of Red Hat Enterprise Linux and will be updated
by EPEL for the standard support lifetime of that major release.
Red Hat does not provide commercial support or service level agreements for EPEL packages.
While not supported officially by Red Hat, EPEL provides a useful way to reduce support costs
for unsupported packages which your enterprise wishes to use with Red Hat Enterprise Linux.
EPEL allows you to distribute support work you would need to do by yourself across other
organizations which share your desire to use this open source software in RHEL. The software
packages themselves go through the same review process as Fedora packages, meaning that
experienced Linux developers have examined the packages for issues. As EPEL does not replace
or conflict with software packages shipped in RHEL, you can use EPEL with confidence that it will
not cause problems with your normal software packages.
For developers who wish to see their open source software become part of Red Hat Enterprise
Linux, often a first stage is to sponsor it in EPEL so that RHEL users have the opportunity to use
it, and so experience is gained with managing the package for a Red Hat distribution.
Visit http://fedoraproject.org/wiki/EPEL/ for more information about EPEL.

RH401-6-en-1-20110713

xi

Introduction

Important
EPEL is supported by the community-managed Fedora Project and not by Red Hat Support.

Contacting Red Hat Technical Support


One of the benefits of your subscription to Red Hat Enterprise Linux is access to technical
support through Red Hat's customer portal at http://access.redhat.com/. If you do not
have a Red Hat account on the customer portal or are not able to log in, you can go to https://
access.redhat.com/support/faq/LoginAssistance.html or contact Customer Service
for assistance.
You may be able to resolve your problem without formal technical support by searching
Knowledgebase (https://access.redhat.com/kb/knowledgebase/). Otherwise,
Red Hat Support may be contacted through a web form or by phone depending on
your support level. Phone numbers and business hours for different regions vary; see
https://access.redhat.com/support/contact/technicalSupport.html for
current information. Information about the support process is available at https://
access.redhat.com/support/policy/support_process.html.
Some tips on preparing your bug report to most effectively engage Red Hat Support:
Define the problem. Make certain that you can articulate the problem and its symptoms before
you contact Red Hat. Be as specific as possible, and detail the steps you can use (if any) to
reproduce the problem.
Gather background information. What version of our software are you running? Are you using
the latest update? What steps led to the failure? Can the problem be recreated and what steps
are required? Have any recent changes been made that could have triggered the issue? Were
messages or other diagnostic messages issued? What exactly were they (exact wording may be
critical)?
Gather relevant diagnostic information. Be ready to provide as much relevant information as
possible; logs, core dumps, traces, the output of sosreport, etc. Technical Support can assist
you in determining what is relevant.
Determine the Severity Level of your issue. Red Hat uses a four-level scale to indicate the
criticality of issues; criteria may be found at https://access.redhat.com/support/
policy/GSS_severity.html.

xii

RH401-6-en-1-20110713

Contacting Red Hat Technical Support

Warning
Bugzilla is not a support tool! For support issues affecting Red Hat Enterprise Linux,
customers should file their bugs through the support channels discussed above in order
to ensure that Red Hat is fully aware of your issue and can respond under the terms of
your Service Level Agreement. Customers should not file bugs directly in the http://
bugzilla.redhat.com/ web interface.

For Red Hat Enterprise Linux, Bugzilla is used by engineering to track issues and changes, and to
communicate on a technical level with Engineering partners and other external parties. Anyone,
even non-customers, can file issues against Bugzilla, and Red Hat does monitor them and review
them for inclusion in errata.
However, Red Hat does not guarantee any SLA for bugs filed directly in Bugzilla (bypassing
normal support channels). A review might happen immediately, or after a time span of any
length. Issues coming through Support are always prioritized above issues of similar impact and
severity filed against Bugzilla. Also, work arounds and hotfixes if possible and appropriate may
be provided to customers by Support even before a permanent fix is issued through Red Hat
Network.
Red Hat considers issues directly entered into Bugzilla important feedback, and it allows us
to provide efficient interaction with the open source development community and as much
transparency as possible to customers as issues are processed. Nevertheless, for customers
encountering production issues in Red Hat Enterprise Linux, Bugzilla is not the right channel.

RH401-6-en-1-20110713

xiii

xiv

About This Course


Red Hat Enterprise Deployment and Systems
Management
RH401 Red Hat Enterprise Deployment and Systems Management is a four-day lab-based course
that explores the concepts and methods necessary for successful large-scale deployment and
management of Red Hat Enterprise Linux systems. Course participants will learn how to install
and use a Red Hat Network Satellite Server to deploy and manage systems.
Subjects covered in the course include: installing and managing a Red Hat Network Satellite
Server; provisioning systems using RHN, DHCP, and PXE; using revision control software to
manage script and configuration file development; and building custom RPMS. Attention will be
given on how to structure RHN organizations and user accounts, modify programs which use the
RHN programming API, and look at routine RHN Satellite Server maintenance functions.

Objectives
Understand large-scale deployment issues
Install, configure, and maintain RHN Satellite Server
Build custom RPM software packages
Use Subversion revision control software to manage changes
Use RHN Satellite for effective software life cycle management
Deploy a PXE infrastructure for bare metal provisioning
Understand and deploy RHN Proxy Server

Audience and Prerequisites


RH401 is aimed at senior Red Hat Enterprise Linux system administrators and other IT
professionals working in enterprise environments.
RH401 requires RHCE-level system administration skills. A current RHCE certification is
recommended, but not required.

Structure of the Course


Red Hat training courses are interactive, hands-on, performance-based, real world classes meant
to engage your mind and give you an opportunity to use real systems to develop real skills. We
encourage students to participate in class and ask questions in order to get the most out of their
training sessions.

RH401-6-en-1-20110713

xv

About This Course

This course is divided up into a number of Units organized around a particular topic area. Each
Unit is divided up into multiple Sections which focus on a specific skill or task. The unit will start
with an introduction to the material, then move on to the first section.
In each section, there will be a presentation led by the instructor. During the presentation, it may
be a good idea to take notes in your student workbook (this book), and the instructor may remind
you to do so. The presentation is followed by a short activity or assessment to give you the
opportunity to practice with the material or review procedures. After a review of the assessment,
the instructor will move on to the next section. At the end of the unit, there will normally be a
hands-on lab exercise of some sort (a "criterion test") which will give you an opportunity to learn
by doing and review your understanding of the unit's content. Please feel free ask questions in
class, or asking the instructor for advice and help during the end-of-unit exercise. We want the
classroom environment to be a "low risk" place where you feel comfortable asking questions and
learning from things that work and things that do not at first.

Orientation to the Classroom Network


Two subnets may be used in this course. The primary classroom network is 192.168.0.0/24, and
belongs to hosts in the DNS domain "example.com". This network will be used for most classroom
activities. Some courses use a second subnet, 192.168.1.0/24, belonging to hosts in the DNS
domain "remote.test". This network can be reached from hosts in example.com, and is used in
lab exercises which require testing services or security settings from machines (theoretically)
outside your administrative control.
Students are each assigned two physical machines (desktopX.example.com on 192.168.0.X)
and (desktopY.example.com on 192.168.0.Y). The first machine will server as the RHN Satellite
Server which will be used to manage the second machine which is the client. When bare-metal
provisioning becomes the focus of the course, the client machine will be cabled to a private
network behind the RHN Satellite Server and will assume the identity (station1.privateX.com on
10.100.X.1).
The instructor controls a number of machines which students may see as well. The
instructor.example.com machine is the classroom utility server, providing default routing services,
DHCP, DNS name service, one or more Yum repositories of software used by the class, and other
network services. It is also connected to the classroom video projector to allow the instructor to
display slides and demonstrations.
Machine name

IP addresses

Role

desktopX.example.com

192.168.0.X

Physical student workstation RHN Satellite Server

desktopY.example.com

192.168.0.Y

Physical student workstation RHN client

station1.privateX.com

10.100.X.1

RHN client on a private


network

instructor.example.com

192.168.0.254

Physical instructor machine


and utility server

Table1.Classroom Machines

xvi

RH401-6-en-1-20110713

Internationalization
Language Support
Red Hat Enterprise Linux 6 officially supports twenty-two languages: English, Assamese, Bengali,
Chinese (Simplified), Chinese (Traditional), French, German, Gujarati, Hindi, Italian, Japanese,
Kannada, Korean, Malayalam, Marathi, Oriya, Portuguese (Brazilian), Punjabi, Russian, Spanish,
Tamil, and Telugu. Support for Maithili, Nepalese, and Sinhala are provided as Technology
Previews.

System-wide Default Language


The operating system's default language is normally set to US English (en_US.UTF-8), but this
can be changed during or after installation.
To use other languages, you may need to install additional package groups to provide the
appropriate fonts, translations, dictionaries, and so forth. By convention, these package
groups are always named language-support. These package groups can be selected during
installation, or after installation with PackageKit (System Administration Add/Remove
Software) or yum.
A system's default language can be changed with system-config-language (System
Administration Language), which affects the /etc/sysconfig/i18n file.

Per-user Language Selection


Users may prefer to use a different language for their own desktop environment or interactive
shells than is set as the system default. This is indicated to the system through the LANG
environment variable.
This may be set automatically for the GNOME desktop environment by selecting a language from
the graphical login screen by clicking on the Language item at the bottom left corner of the
graphical login screen immediately prior to login. The user will be prompted about whether the
language selected should be used just for this one login session or as a default for the user from
now on. The setting is saved in the user's ~/.dmrc file by GDM.
If a user wants to make their shell environment use the same LANG setting as their graphical
environment even when they login through a text console or over ssh, they can set code similar
to the following in their ~/.bashrc file. This code will set their preferred language if one is
saved in ~/.dmrc or will use the system default if one is not:
i=$(grep 'Language=' ${HOME}/.dmrc | sed 's/Language=//')
if [ "$i" != "" ]; then
export LANG=$i
fi

RH401-6-en-1-20110713

xvii

Internationalization

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:
[user@host ~]$ LANG=fr_FR.UTF-8 date
lun. oct. 24 10:37:53 CDT 2011

Subsequent commands will revert to using the system's default language for output. The locale
command can be used to check the current value of LANG and other related environment
variables.

Input Methods
IBus (Intelligent Input Bus) can be used to input text in various languages under X if the
appropriate language support packages are installed. You can enable IBus with the im-chooser
command (System Preferences Input Method).

Language Codes Reference


Language

$LANG value

Language package group

English (US)

en_US.UTF-8

(default)

Assamese

as_IN.UTF-8

assamese-support

Bengali

bn_IN.UTF-8

bengali-support

Chinese (Simplified)

zh_CN.UTF-8

chinese-support

Chinese (Traditional)

zh_TW.UTF-8

chinese-support

French

fr_FR.UTF-8

french-support

German

de_DE.UTF-8

german-support

Gujarati

gu_IN.UTF-8

gujarati-support

Hindi

hi_IN.UTF-8

hindi-support

Italian

it_IT.UTF-8

italian-support

Japanese

ja_JP.UTF-8

japanese-support

Kannada

kn_IN.UTF-8

kannada-support

Korean

ko_KR.UTF-8

korean-support

Malayalam

ml_IN.UTF-8

malayalam-support

Marathi

mr_IN.UTF-8

marathi-support

Oriya

or_IN.UTF-8

oriya-support

Portuguese (Brazilian)

pt_BR.UTF-8

brazilian-support

Punjabi

pa_IN.UTF-8

punjabi-support

Russian

ru_RU.UTF-8

russian-support

xviii

RH401-6-en-1-20110713

Language Codes Reference

Language

$LANG value

Language package group

Spanish

es_ES.UTF-8

spanish-support

Tamil

ta_IN.UTF-8

tamil-support

Telugu

te_IN.UTF-8

telugu-support

Maithili

mai_IN.UTF-8

maithili-support

Nepali

ne_NP.UTF-8

nepali-support

Sinhala

si_LK.UTF-8

sinhala-support

Technology Previews

Table2.Language Codes

RH401-6-en-1-20110713

xix

xx

Chapter1.

UNIT ONE

ESSENTIAL SYSTEM
MANAGEMENT
Introduction
Topics covered in this unit:
Define enterprise management best practices
Standardization
Centralization
Scalability
Provisioning
Automation
Avoid the one-off trap

RH401-6-en-1-20110713

Chapter1.Essential System Management

Enterprise Management Best Practices


Fill in the enterprise best practices below and take notes as your instructor explains them:
1.

2.

3.

4.

5.

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 test machines to determine appropriate configuration
2.

Create RPM packages for third party software that does not natively support RPM

3.

Deploy RPM packages on test machines

4. Deploy tested RPM packages to production machines


5.

Verify proper operation of affected systems

6. Rollback to a 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 bare
metal to this state must be documented and preferably automated.
The baseline must include:
OS package install list
Filesystem layout

RH401-6-en-1-20110713

Centralization

Third party software


Configuration files
Anything else!

Centralization
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.

Scalability
Scalability is growth in capacity with minimal system administrator impact. Goal: increased
production with minimal cost growth.
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
Manual installation of individual machines requires much time to perform and lends itself to
deviation from a corporate standard. In contrast installing new machines using kickstart yields
machines that conform to a standard build specification, require little human interaction to
perform the install process, and allows for many installs to occur simultaneously.

Provisioning
Provisioning is the process 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.
Components of a provisioning environment:
DHCP Server: Dispenses configuration information, for example IP addresses, PXE images, and
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: Most systems now include the ability to boot from the network. Older
systems may require upgrading with PXE capable NICs or software can be used such as gPXE, an
open-source implementation of PXE.
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.

Automation
Instead of repetitive work, automation generally requires more upfront work. Investing time
writing kickstart files allows one to install more systems simultaneously and more quickly than
could be achieved by hand.

RH401-6-en-1-20110713

Chapter1.Essential System Management

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 that 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 chroot'ed 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.

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 version control 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.

RH401-6-en-1-20110713

Centralization

Practice Resequencing Exercise

Enterprise Management Best Practices


For each of the keywords below, write down the number of its definition from the list at the
bottom.
Standardization
Centralization
Scalability
Provisioning
Automation

1.

Growth in capacity with minimal system administrator impact.

2.

Performing tasks with the same, well thought out method each and every time.

3.

The process 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.

4. Generally requires more upfront work. Investing time writing kickstart files allows one to
install more systems simultaneously and more quickly than could be achieved by hand.
5.

Gather policies, procedures, and baselines into one easily managed system.

RH401-6-en-1-20110713

Chapter1.Essential System Management

PXE/Kickstart Installation
PXE Peer Tutoring
Your instructor will split the class into teams. Gather around one of your machines and
determine how to initiate a PXE installation. Write the steps needed to PXE boot below.

RH401-6-en-1-20110713

Centralization

Practice Exercise

PXE Boot
Carefully perform the following steps. Ask your instructor if you have problems or questions.
The purpose of this exercise is to become familiar with the PXE capabilities of the classroom
hardware. You will also look at the menu and capabilities that are provided by the classroom
provisioning environment. You will not be installing your workstations - that is for a later
exercise.
1.

PXE boot one of your two machines, either of your machines will work.

2.

In the PXE menu, edit the Install minimal RHEL 5 for RHN Satellite use option. What are
the two options included for Kickstart?

RH401-6-en-1-20110713

Chapter1.Essential System Management

Test

Criterion Test
Exercise

Provisioning Preview
Before you begin...
You have two servers: desktopX and desktopY. Both servers are currently connected
to the classroom network (192.168.0.0/24) which includes the instructor's machine,
instructor.example.com. desktopX should be equipped with two Ethernet interfaces.
Carefully perform the following steps. Ask your instructor if you have problems or questions.
Let's preview the capabilities and conveniences of a bare-metal provisioning environment. The
instructor's machine, instructor.example.com, has been configured to provide bare-metal
provisioning services. Your task is to configure both of your servers to PXE-boot and kickstart
themselves.
1.

Reboot desktopX and go into the system BIOS configuration screens and make adjustments
so desktopX will attempt to PXE boot from the network. Ask your instructor for help since
this process can vary between various classroom environments.

2.

Reboot desktopX, but this time allow it to PXE boot from the network. If everything is
properly configured, you should be presented with a PXE boot menu similar to the following:

Choose the Install minimal RHEL 5 for RHN Satellite use option without any arguments
to begin the installation. While the installation begins, repeat these steps on your second

RH401-6-en-1-20110713

Centralization

server, desktopY. Be sure to choose the Install minimal RHEL 5 for RHN Satellite use option
without any arguments to begin the installation.

RH401-6-en-1-20110713

Chapter1.Essential System Management

Personal Notes

10

RH401-6-en-1-20110713

Centralization

Unit Summary
Enterprise Management Best Practices
In this section you learned the value of:
Standardization
Centralization
Scalability
Provisioning
Automation
.
PXE/Kickstart Installation
In this section you learned how to:
Initiate a PXE installation
Determine kickstart arguments in an installation
.

RH401-6-en-1-20110713

11

12

Chapter2.

UNIT TWO

INSTALLING A RED HAT


NETWORK SATELLITE SERVER
Introduction
Topics covered in this unit:
Advantages of the RHN Satellite Server
Installing Red Hat Network Satellite software
Downloading channel content ISOs
Importing channel content into a RHN Satellite server
Troubleshooting a Satellite Server installation

RH401-6-en-1-20110713

13

Chapter2.Installing a Red Hat Network Satellite Server

RHN Satellite Server Concepts


Features of RHN Satellite Server
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
on-site server that feeds updates within an enterprise with minimal (or potentially no) access to
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.
Some high security data centers are disconnected from the Internet and cannot access the
services of RHN provided by Red Hat's servers. A Satellite server allows these types of centers to
have RHN software deployment features that their disconnected requirements wouldn't allow for
otherwise.
Another key feature of RHN Satellite is the ability to create custom software channels. This gives
you the ability to add your own software into the RHN Satellite system and the ability to do baremetal provisioning, installing across a large number of systems with relative ease.

Advantages of RHN Satellite Server


Five major advantages of using RHN Satellite server include:
1.

2.

3.

4.

5.

14

RH401-6-en-1-20110713

RHN Satellite Server Components

RHN Satellite Server improves security by ensuring that software updates are rolled out in a
timely manner. The disconnection from the Internet assures that all transactions are performed
within the intranet. Coupled with RHN Proxy servers or with multiple RHN Satellite servers,
highly geographically dispersed environments can get rapid access to updates.
RHN Satellite server allows local administrators (not Red Hat) control over which systems can
access the server with what permissions.
The ability to load third-party or custom software packages into the RHN Satellite server and to
create custom channels permits a high level of customization.

RHN Satellite Server Components


The RHN Satellite Server is a large and complex subsystem, consisting of:
Red Hat Network Satellite Server: the underlying software.
An Oracle Database: the RHN Satellite Server requires a database to store information
about the systems it manages. This database can be an existing Oracle database or it can be
embedded in the Satellite Server software.
Web Interface: much of the management of the RHN Satellite Server happens through the web
interface. This looks very similar to Red Hat's RHN web interface.
RPM Repository: the part of the system taking the most disk space, this repository holds the
software to be distributed by the RHN Satellite Server.
Management Tools: a number of command line and web based management tools permitting
the setup and maintenance of the server. RHN Satellite also has an API for access to Satellite
information and functions.

References
Red Hat Network Satellite Installation Guide
Section 1.1: Red Hat Network
Section 1.2: RHN Satellite

RH401-6-en-1-20110713

15

Chapter2.Installing a Red Hat Network Satellite Server

RHN Satellite Server Installation


Standalone vs. Embedded Database
The RHN Satellite Server requires a database. If you already have an Oracle database with
sufficient disk space and power, you can use it to hold the RHN Satellite Server database
provided that you have a database administrator who can manage the setup of the service. It
is important you do not run the RHN Satellite Server on the same system that runs the Oracle
database.
If you do not have an Oracle database, or if it does not have sufficient disk, RAM, or CPU
resources, you can install the RHN Satellite Server with an embedded database. This database
requires additional disk space. It has the advantage of having a single system acting as both
Satellite Server and database server. Further, the database is already fully configured, requiring
less effort on the part of the database administrator.

Hardware Requirements
RHN Satellite Servers have relatively high hardware requirements since they can run an instance
of the Oracle database (for the embedded version) as well as deliver a large amount of data to
remote systems. Because the Oracle database runs multiple processes, multiple processors can
significantly improve performance.
The RHN Satellite Server uses a considerable amount of disk space and it is time consuming to
repopulate a database should a disk fail. It is strongly recommended to use redundant storage to
hold the underlying data.
The hardware specifications outlined in the Red Hat Network Satellite Installation Guide are
standard minimal and recommended specifications for Red Hat Network Satellite. The following
table shows typical specifications and capacity of RHN Satellite server deployments:
Hardware specifications

RHN client system capacity

32-bit x86 with 2GB of RAM

~500 RHN client systems

32-bit x86 with 4GB of RAM

~2,000 RHN client systems

64-bit x86 with 8-16GB of RAM

~15,000 RHN client systems

Table2.1.RHN Satellite Server Capacity

File System Requirements


The embedded database is installed in /rhnsat and RPM channel content is stored in /var/
satellite. Do not skimp on the hard disk requirements! Red Hat Network Satellite Server
will not run on systems with insufficient disk space. For example, /var/satellite may need
approximately 120 GB of disk capacity to maintain content for Red Hat Enterprise Linux versions
4 through 6 for two architectures.
Furthermore, when populating the database using channel content ISOs you will need
substantially large amounts of temporary disk space. For example the base channel content ISOs
for Red Hat Enterprise Linux 5 Client/Server i386 (11 CD ISOs) originally took almost 7 GB of
storage. As of April, 2011 they have grown to almost 47 GB of storage (11 DVD ISOs) to include
all revisions including RHEL 5.6. To use these ISOs, you will need to mount each one and copy it
over to a temporary location which will take an additional 47 GB of disk space. Therefore, for this

16

RH401-6-en-1-20110713

Installing Satellite Server: The Base Install

one channel, almost 100 GB of temporary space will be needed to expand the channel content to
be synchronized into a RHN Satellite server.
Older versions of RHEL require more space because of their longer history of package updates.
Red Hat Enterprise Linux 5 Server (ia64) + EUS + AMC + RHN Tools + Supplementary (Base
2011-04-13) is published, at the time of this writing, on 7 DVD ISOs.

Installing Satellite Server: The Base Install


The base install of the RHN Satellite Server is substantially similar to other Red Hat operating
system installations. However, note the following:
SELinux: The RHN Satellite Server installer requires SELinux to be enabled. Enable SELinux in
Permissive Mode when installing the base operating system.
Disk space: Refer to the previous information on disk space allocations. Follow or exceed the
guidelines, as the RHN Satellite Server will not install properly without a sufficient amount of disk
space.
Time: The SSL parts of the server installation require proper synchronization of time with the
computers that must communicate with one another. Use UTC for the hardware time and if
possible run the Network Time Protocol daemon on all RHN Satellite Servers, RHN Proxy Servers
and on their client systems.
Software Packages: Only install the @Base package group to avoid RPM dependency conflicts.
The @GNOME package group may also be selected if you want to administer the Satellite Server
locally, but it is not required. Provide additional RPMS to satisfy package dependencies: either
register the Satellite system with Red Hat Network or point to a yum repository with RHEL RPMs.

Installing the Satellite Software


Installing the RHN Satellite Server software is a time consuming process, made faster by
powerful dual processors and a large amount of RAM. To begin the installation, download the
latest RHN Satellite software ISO from Red Hat Network. Note that two versions of the software
are provided: the standalone version and the embedded version. Only one is needed.
The RHN Satellite Server ISO contains an installation script called install.pl. Execute this
script to begin the installation process. install.pl will update some system libraries and
install additional packages required by the Satellite Server software. After installing all relevant
software RPMs, this application prompts the user for the following information:
Administrator's e-mail address: Specify the e-mail address where automated Satellite Server
messages are sent.
RHN connection information: If you intend to operate your Satellite Server so it connects to
Red Hat, you will need to enter your Red Hat Network account name and password. Web proxy
information also must be specified when using a proxy to access the Internet.
RHN Entitlement certificate: Specify the absolute path name to the file that contains the Satellite
Entitlement certificate sent to you by Red Hat.
Database connection information: When installing a standalone Satellite Server, Oracle
authentication information must be provided. This information isn't prompted for when installing
the embedded database version of the Satellite Server software.

RH401-6-en-1-20110713

17

Chapter2.Installing a Red Hat Network Satellite Server

SSL certificate information: All communication between your Satellite Server and its clients will
be done through encrypted tunnels. This requires an SSL certificate. You will have to provide
information about your organization, its location, and a certificate password which you should
record and put in a safe place.
This is a long process, typically taking near an hour to complete, including the time needed to
answer the installer's questions and for the computer to process the data. Installer log messages
can be found in a file called /var/log/rhn/rhn-installation.log.

install.pl Options
Options can be passed to install.pl to modify how it behaves when installing the Satellite
Server software.
The --disconnected option indicates the Satellite Server will operate disconnected from the
Internet. In this case install.pl will not prompt for RHN credentials used to connect to Red
Hat's servers.
An answer file can be specified at install time with the --answer-file option. The user
provides install.pl with the absolute path name to a text file with answers to the installer's
questions which the user created beforehand. This allows the installation process to be
performed in an unattended manner which prevents mistakes from being committed during the
installation process. A sample answers.txt file can be found on the Satellite Server install
media in the install subdirectory.

Note
The --answer-file option requires an absolute path name. When a relative path name is
specified, the RHN Satellite installer will silently ignore this option and start prompting the
user with questions.

The --re-register option causes install.pl to re-register the Satellite Server with Red Hat
Network, even if it is already registered.
--clear-db tells install.pl to clear any existing database schema before installing on a
previously installed server. This is useful when Satellite Server software needs to be reinstalled.
A best practice is to install a RHN Satellite Server in disconnected mode and initially populate
it from local media. The eliminates any dependence upon Internet connectivity and grants best
installation performance. Later the Satellite Server can be registered and reactivated with Red
Hat Network, then channel content can be brought up to date against Red Hat's servers.

References
Red Hat Network Satellite Installation Guide
Chapter 2: Requirements
Chapter 4: Installation

18

RH401-6-en-1-20110713

Installing Satellite Server: The Base Install

Practice Performance Checklist

Installing Red Hat Network Satellite Software


Before you begin...
You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopX.
Install RHN Satellite software on your provisioning server, desktopX.
Copy the sample RHN Entitlement Certificate, redhat-gls-minimal-5.4.cert,
from the instructor's machine to root's home directory (~). This file can be found in the
automounted /misc/instructor/rh401-satellite directory.
Copy the satellite-embedded-*.iso image found on the instructor's machine to /
tmp then mount it using a loopback device to /mnt. Don't execute /mnt/install.pl.
We will use this script shortly. Instead list the contents of /mnt/install and look
for a file called answers.txt. This file can be modified and used with install.pl
to perform an unattended installation of the RHN Satellite Server software. Copy
answers.txt to root's home directory.
Use your favorite text editor to modify root's answers.txt file. Find the following
variable definitions and make all necessary adjustments:
# RHN Satellite Server administrator
admin-email = root@desktopX.example.com
# Satellite Server
ssl-set-org
=
ssl-set-org-unit =
ssl-set-city
=
ssl-set-state
=
ssl-set-country =
ssl-set-email
=
ssl-password
=

CA certificate info
Red Hat Inc.
Training
your city
your state
your two-letter country code
root@desktopX.example.com
a password you can remember

# Location of RHN Satellite Entitlement certificate


satellite-cert-file = /root/redhat-gls-minimal-5.4.cert
run-updater = yes
ssl-config-sslvhost = yes
enable-tftp = yes

Although comments in the file suggest ssl-set-mail defaults to the value of adminemail, that is not the case and the installer will stop and prompt you for the SSL email address. Also the run-updater, ssl-config-sslvhost, and enable-tftp
directives either do not exist or are commented in the sample answers.txt file.
Uncomment them or add them to the file as needed.
Double check your modifications to your answers.txt file because the Satellite Server
install process takes a long time. It is best to catch mistakes sooner than later.
Begin the Satellite Server installation process using your answers file. Be sure to specify
the option to install the software so it will operate without an external connection to
Red Hat Network. Monitor the log files that are created during the installation process to
ensure the installation is functioning properly.

RH401-6-en-1-20110713

19

Chapter2.Installing a Red Hat Network Satellite Server

Once the SSL certificate has been generated and imported into the Satellite Server,
install.pl will restart the Satellite Server then exit. A URI will be displayed which you
can use with a browser to complete the installation process.
Launch a web browser and visit the URI displayed by install.pl: https://
desktopX.example.com. Examine the certificate offered to your browser and see if
you recognize some of the values about the certificate subject and the issuer. Once you
are satisfied with the contents of the certificate, accept it into your browser permanently.
Create a RHN user called satadmin with a password of redhat. The e-mail address
for this account should be root@desktopX.example.com. Provide your name for the
additional account information. You are now logged in as the Satellite Administrator,
satadmin, of a functioning Red Hat Network Satellite Server.
Unmount the ISO image from /mnt since the installation of the RHN Satellite Server
software is complete.
Use yum to install updated packages for the Red Hat Network Satellite Server software.
The classroom kickstart process configures yum to point to repositories provided by the
instructor's server. After the packages have been updated, restart your Satellite Server.

20

RH401-6-en-1-20110713

Obtaining Software from Hosted RHN

Obtaining Software from Hosted RHN


Populating the Satellite Server over the Network
Populating the database over the network takes less administrator time but more clock time
overall. Use the satellite-sync command to perform a network synchronization, specifying
the channel you wish to download:
[root@host ~]# satellite-sync -c rhel-i386-client-vt-5

This single command will perform the task, but it may take several hours for base channels with
thousands of packages.

Channel Content ISOs


Channel Content ISOs contain the information, including RPMs and metadata, needed to
populate a Satellite Server. They are not a package-for-package match to a channel, instead
they are a superset. A particular Channel Content ISO may contain channel data for that base
channel, for its child channels, and even for related, but different, base channels. For example,
a listing of the channels included on the channel content ISOs distributed for RHEL 5 Client/
Server (i386) + vt + cluster + supplementary + workstation might read as follows (from
satellite-sync --list-channels):
Retrieving / parsing channel data
p = previously imported/synced channel
. = channel not yet imported/synced
base-channels:
p rhel-i386-client-5
p rhel-i386-server-5
rhel-i386-client-5:
. rhn-tools-rhel-i386-client-5
. rhel-i386-client-workstation-5
. rhel-i386-client-supplementary-5
. rhel-i386-client-vt-5
rhel-i386-server-5:
. rhn-tools-rhel-i386-server-5
. rhel-i386-server-hts-5
p rhel-i386-server-vt-5
. rhel-i386-server-supplementary-5
. rhel-i386-server-cluster-5
. rhel-i386-server-cluster-storage-5

1807
2411
348
891
27
34
348
4
34
46
39
51

In this example, the Channel Content ISOs include both client and server base channels and
relevant child channels. In this sample listing, an administrator installed both client and server
base channels and virtualization technology packages for the server base channel. Since both
base channels share many packages; the Satellite software understands this and will only load
the differences after the first channel is installed. For example installing rhel-i386-client-vt-5
will take only a few seconds since it shares the same packages as the rhel-i386-server-vt-5 child
channel which has already been imported into the Satellite Server.

RH401-6-en-1-20110713

21

Chapter2.Installing a Red Hat Network Satellite Server

Note
Importing channel content into a RHN Satellite server can take a long time to complete. This
is especially true when a Satellite server is freshly installed. Installing a small base channel
and restarting the Satellite server causes the embedded database to initialize itself so that
further channel installs are much quicker. In the lab exercise, a simple base channel called
one-rpm-channel will be used for this purpose.

Using Channel ISOs to Populate the Satellite Server


To populate the database using the Channel Content ISOs:
1.

Confirm you have sufficient disk space. You will need disk space for the ISOs and the data
to be extracted from the ISOs, in addition to the disk space needed to store the data in the
database.

2.

Download the Channel Content ISOs from Red Hat Network.


Log onto Red Hat Network and click the Software Downloads icon.
Expand the base channel called Red Hat Enterprise Linux (v. 5 for 64-bit x86_64), or the
version of Red Hat Enterprise Linux you are using, by clicking the plus symbol to the left
of the channel name. Then click the link for the latest Red Hat Network Satellite channel.
For example, you might select Red Hat Network Satellite (v5.4 for Server v5 AMD64 /
Intel64).
Click View Base Channel Content ISOs for Satellite to list the Channel Content ISOs. Scroll
down to find the Channel Content ISOs for the channel you wish to download. For example,
scroll down to Red Hat Enterprise Linux 5 Client/Server (i386) + rhn-tools + vt + cluster
+ supplementary + workstation (Base 2009-09-30) to download the content ISOs for
that channel.

3.

For each channel, mount each ISO in turn and copy the data to a temporary directory. If you
intend to use the expanded channel content on more than one Satellite Server (or back it up),
be sure to mount it read only since satellite-sync will attempt to remove the content as
it imports the RPMS.

4. List the channels available from the Channel Content ISOs. For example, if you have copied
the ISO data into a directory called /rhn-sat-import, then list the available channels by
running:
[root@host ~]# satellite-sync -m /rhn-sat-import --list-channels

5.

Run the satellite-sync command to upload the information from this directory into the
Satellite Server. For example, to load the rhel-i386-server-5 channel into the database that
has been copied into /rhn-sat-import, run:
[root@host ~]# satellite-sync -m /rhn-sat-import -c rhel-i386-server-5

22

RH401-6-en-1-20110713

Using Channel ISOs to Populate the Satellite Server

Installing a base channel does not include the child channels or the related channels. They
must be installed separately.

References
Red Hat Network Satellite Installation Guide
Chapter 7: Troubleshooting

RH401-6-en-1-20110713

23

Chapter2.Installing a Red Hat Network Satellite Server

Practice Performance Checklist

Preparing Channel Content for Import


Before you begin...
The RHN Satellite software installation on your desktopX machine should be completed.
Channel content ISOs are available from the instructor's machine, instructor.example.com.
Extract their contents into a common directory on your Satellite server, desktopX, so the channel
content can be imported in a later lab exercise.
The first step to take is make sure you have enough disk space to extract the content
ISOs. They will require over 8 GB of space. Notify your instructor if you don't have
enough room on your machine to extract them.
The content ISOs are published to the classroom in the /misc/instructor/rh401satellite/sat-rhel6-content/ directory. Mount the content ISOs using a loop
interface to /mnt and copy the contents of both ISOs to a directory called /root/satrhel6-content/.

24

RH401-6-en-1-20110713

Importing Initial Software Packages

Importing Initial Software Packages


RHN Software Channels
The Red Hat Network system deploys packages based on the concept of software channels. A
software channel is essentially a collection of packages. The two types of software channels are
base channels and child channels. A base channel is the collection of packages that all systems
using a particular type of software typically will install (it is not always necessary to install all
packages, but a full install would include all of these packages). Child channels provide additional
software related to the base channel.
For example, if you browse Red Hat Network's Channels tab, you will see the latest version of
the Red Hat Enterprise Linux base channel along with its associated child channels. It will look
something like this:
Channel
Red Hat
Red Hat
Red Hat
Red Hat
Red Hat
Red Hat

Name
Enterprise Linux Server 5
FasTrack Server 5
Network Tools Server 5
Productivity Apps Server 5
Supplementary Server 5
Virtualization Server 5

Architecture
IA-32, IA-64,
IA-32, IA-64,
IA-32, IA-64,
IA-32, x86_64
IA-32, IA-64,
IA-32, IA-64,

PPC, s390x, x86_64


PPC, s390x, x86_64
x86_64
PPC, s390x, x86_64
x86_64

The channels are listed in alphabetical order by name, followed by the architectures relevant to
that channel.
The channel listing on a Satellite Server looks a little different. The software channels are
displayed in a way that shows their relationship to each other. The base channel is displayed first
with its child channels appearing immediately below their parent:

Channel Name
-Red Hat Enterprise Linux (v. 5 for 32-bit x86)
|--RHEL Virtualization (v. 5 for 32-bit x86)
...

Packages
3239
67

Systems
10
3

RHN Entitlement Certificate


Entitlement Certificates unlock the services of Satellite Servers. They define how many systems
can register with the Satellite Server and what types of system entitlements they have, such
as Update, Management, Provisioning, or Monitoring. They also define the number and type of
software channels that can be subscribed to.
An Entitlement Certificate can limit which menus appear on the RHN Web Interface of a Satellite
Server. For example a Satellite Server without Provisioning system slots won't present the
Kickstart menu or features that apply only to systems with Provisioning entitlements.
RHN Satellite Entitlement Certificates are issued and digitally signed by Red Hat so they can't be
tampered with. Below is a portion of a sample certificate:
<?xml version="1.0" encoding="UTF-8"?>
<rhn-cert version="0.1">
<rhn-cert-field name="product">RHN-SATELLITE-001</rhn-cert-field>
<rhn-cert-field name="owner">Red Hat GLS Cert</rhn-cert-field>

RH401-6-en-1-20110713

25

Chapter2.Installing a Red Hat Network Satellite Server

<rhn-cert-field name="issued">2011-02-11 00:00:00</rhn-cert-field>


<rhn-cert-field name="expires">2013-02-11 00:00:00</rhn-cert-field>
<rhn-cert-field name="slots">6</rhn-cert-field>
<rhn-cert-field name="monitoring-slots">3</rhn-cert-field>
<rhn-cert-field name="provisioning-slots">3</rhn-cert-field>
<rhn-cert-field name="channel-families" quantity="4" family="rhel-server"/>
<rhn-cert-field name="channel-families" quantity="2" family="rhel-client"/>
<rhn-cert-field name="channel-families" quantity="6" family="rhn-tools"/>
<rhn-cert-field name="channel-families" quantity="1" family="rhn-proxy"/>
<rhn-cert-field name="satellite-version">5.0</rhn-cert-field>
<rhn-cert-field name="virtualization_host_platform">4</rhn-cert-field>
<rhn-cert-signature>
...

Populating the Satellite Server: Options


Once you have set up the RHN Satellite Server, you must populate the server with information
for the various channels you wish to distribute. Red Hat provides two methods to accomplish
this: network and Channel Content ISOs. Neither method is fast, but the network method is
considerably slower, often taking eight hours per channel to download.
Using the network method, your server will download the RPMS and metadata over the Internet.
While relatively simple to implement, this is a fundamentally inefficient method which consumes
a lot of network bandwidth.

Troubleshooting
Troubleshooting tips:
Disk space! This is the number one culprit when having difficulties with the RHN Satellite Server.
At install time, the system may complain of insufficient disk space, but if the Oracle embedded
database has an insufficient amount of disk space, often the only symptom is that it refuses to
start.
Log files: The RHN Satellite Server consists of multiple subsystems: the server itself; the Oracle
database; the web interface; and many other less obvious but still important elements. Therefore,
the entire system uses several log files and log directories, including:
/var/log/rhn/ for the RHN Satellite Server software itself;
/var/log/rhn_database.log for the embedded Oracle database;
/var/log/up2date for the Red Hat Update agent.
Even standard log files contain logging information important to this product, including:
/var/log/messages for taskomatic
/var/log/httpd/ for the web server
Subsystems: Confirm all subsystems are running. On RHN Satellite 5.4, use the following
command to check their status:
[root@host ~]# /usr/sbin/rhn-satellite status

Earlier versions of RHN Satellite software used an init script:

26

RH401-6-en-1-20110713

Troubleshooting

[root@host ~]# service rhn-satellite status

Time: Use the date -u command on all RHN Satellite and Proxy Servers to confirm their time is
closely coordinated.
SSL certificate: Confirm the /etc/sysconfig/rhn/{rhn_register,up2date} files on the
clients are using the newly created RHN-ORG-TRUSTED-SSL-CERT certificate and not the original
RHNS-CA-CERT certificate.

References
Red Hat Network Satellite Installation Guide
Section 6.2: Importing with RHN Satellite Synchronization Tool
Section 6.3: Synchronizing
Red Hat Network Satellite Installation Guide
Chapter 7: Troubleshooting

RH401-6-en-1-20110713

27

Chapter2.Installing a Red Hat Network Satellite Server

Practice Performance Checklist

Populating RHN Satellite with RHEL6 Software


Before you begin...
The RHN Satellite software installation on your desktopX machine should be completed and RHN
channel content from both ISOs should be expanded into the /root/sat-rhel6-content/
directory on that server.
Import the RHN base channel content for the Red Hat Enterprise Linux 6 Server software for 64bit x86 machines into your RHN Satellite server.
The first software channel to be imported into a RHN Satellite 5.4 server takes much
more time to import that subsequent channels. To conserve time, import the onerpm-channel base software channel published in the /misc/instructor/rh401satellite/one-rpm-channel.tar tar archive. Change into root's home directory
on desktopX, extract the archive, import the one-rpm-channel software channel, then
reboot your Satellite server before importing the Red Hat software channels.
Log back into desktopX as root. The sat-rhel6-content directory below root's home
directory contains the software channel content needed to deploy Red Hat Enterprise
Linux 6 Server.
Before you populate the database with RPMs and other information for a particular
channel you must first find out which channels are available. Which software channels
are provided by the content in the sat-rhel6-content directory?
Now that you have determined which channels are available, import the rhel-x86_64server-6 channel data from the sat-rhel6-content directory into your Satellite
Server's database. This process takes a very long time to complete.
Use a web browser to browse https://desktopX.example.com, where X is the
machine number of your Satellite Server. You probably want to bookmark this page since
you will refer to it often in upcoming lab exercises.
Log in as the Satellite Administrator, satadmin. Navigate around the web site,
particularly looking at the Errata, Channels, Users, and Admin tabs.
Your RHN Satellite Server is now installed and will be ready to be used by clients when
the channel content sync is complete. In a later lab you will configure clients to use this
server.

28

RH401-6-en-1-20110713

Criterion Test

Test

Criterion Test
Case Study

Deploying a RHN Satellite Server


Before you begin...
You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopY.
Your department deploys and manages several servers running Red Hat Enterprise Linux. Your
facility is an extremely secure site so you don't have access to hosted Red Hat Network services
via the Internet. Your manager has invested in a Red Hat Network Satellite software to manage
your systems.
Your task is to install the RHN Satellite software on your desktopY machine and load it with
the software channels needed to deploy Red Hat Enterprise Linux 6 Server systems. All of the
material you need to install the system can be found in the /misc/instructor/rh401satellite directory. Use the redhat-gls-minimal-5.4.cert RHN Entitlement Certificate
to activate the server.
When you install the Satellite server, make sure the SSL CA certificate information is specified as
follows:
Organization = Red Hat Inc.
Organization Unit = Training
City = your city
State = your state
Country = your two-letter country code
Also specify root@desktopY.example.com for all e-mail addresses requested during
installation.
The Satellite Administrator should log in as satadmin with a password of redhat.
How would you address the case study described above? Take notes on your process in the
space below and then implement it.

RH401-6-en-1-20110713

29

Chapter2.Installing a Red Hat Network Satellite Server

Personal Notes

30

RH401-6-en-1-20110713

Criterion Test

Unit Summary
RHN Satellite Server Concepts
In this section you learned about the features, benefits, and components of Red Hat
Network Satellite software.
.
RHN Satellite Server Installation
In this section you learned how to:
Install Red Hat Network Satellite Server software
.
Obtaining Software from Hosted RHN
In this section you learned how to:
Get RHN software channel content from Red Hat
Prepare channel content ISOs for use with RHN Satellite
.
Importing Initial Software Packages
In this section you learned how to:
Import Red Hat software content into a Satellite server
.

RH401-6-en-1-20110713

31

32

Chapter3.

UNIT THREE

RED HAT NETWORK


ORGANIZATION
Introduction
Topics covered in this unit:
Red Hat Network organization management
User account management
Purpose and privileges of RHN user roles
Red Hat Network system groups

RH401-6-en-1-20110713

33

Chapter3.Red Hat Network Organization

RHN Organization Administration


Time invested in the initial planning and design of Red Hat Network organizations and system
groups saves time spent on RHN Satellite Server administration later. Organizing Red Hat
Network to fit with the way your company does business will allow your system administrators to
maximize the benefits of using RHN.
Trust relationships between organizations allow them to share custom software channels with
each other. Trust is always bi-directional between two organizations. This feature was introduced
with the release of Red Hat Network Satellite 5.3.
Trust relationships also facilitate the migration of systems between organizations that trust
each other. Note this is not a trivial process that can be handled using the web interface.
Command-line tools must be used to migrate a system profile from one organization to the other.
Remember that organizations were originally created to provide a layer of isolation between
users and systems using Red Hat Network.
A freshly installed Satellite Server starts with a single organization which has a single user the Satellite Administrator. A best practice is to always use organizations on a new Satellite
Server deployment. Even if only one managed organization is created and used, it allows for the
creation of other organizations if and when the need arises.

References
Red Hat Network Satellite Deployment Guide
Chapter 3: Multiple Organizations
Red Hat Network Satellite Reference Guide
Chapter 9: Multiple Organizations

34

RH401-6-en-1-20110713

Practice Exercise

Organization Creation and Entitlement


Before you begin...
Students should have a functioning Red Hat Network Satellite Server, desktopX, installed with
Red Hat Enterprise Linux Server base channel content loaded.
Carefully perform the following steps. Ask your instructor if you have problems or questions.
Log in as the Satellite Administrator of your desktopX Satellite server. Create an organization
called Example Inc. and assign it entitlements for provisioning and managing Red Hat
Enterprise Linux Server systems.

Create an organization in your Red Hat Network Satellite Server named Example
Inc.. The Organization Administrator is Mr. Edward Example and he should log in
as example with a password of redhat. E-mail for this account should be sent to
root@desktopX.example.com.
System entitlements should be assigned to this new organization as follows:
Management: 3
Monitoring: 0
Provisioning: 1
Virtualization: 1
Virtualization Platform: 0
The following quantity of software entitlements should be assigned as well:
Red Hat Enterprise Linux Server (v. 6): 2
Red Hat Network Tools for RHEL (v. 6): 2

RH401-6-en-1-20110713

35

Chapter3.Red Hat Network Organization

RHN User Administration


Red Hat Network Users and Roles
User accounts are managed by the Organization Administrator within each organization. User
names (login) must be at least 5 characters in length and must be unique across the Satellite
Server. For example there can't be two users named wayne even though they belong to two
different organizations.
To create a user, login as an Organization Administrator and select the Users tab. Click create
new user link and assign the user a unique login name, a password, and fill in other pertinent
information about the user's identity. Once the Create Login button is clicked, the account is
created and appears in the list of organization users. On the Details tab of the user's page, check
boxes can be selected for the roles in which they will serve.
The following outline lists the different Red Hat Network roles that can be assigned to a RHN
Satellite user:
Satellite administrative roles
Satellite Administrator
Organization Administrator
Other individual roles
User/System Group User (default/baseline)
System Group Administrator
Activation Key Administrator
Channel Administrator
Configuration Administrator
Monitoring Administrator
Each role's function and capabilities will be covered in more detail below.

Satellite Administrator
The Satellite Administrator account manages the overall function of a Satellite Server. The
unique functions provided by this role include creating and deleting organizations, establishing
trusted relationships between organizations, managing Satellite-wide subscriptions and
entitlements, and other global administrative functions. These functions are available under the
Admin tab which only appears when the Satellite Administrator is using the system.
A new Satellite entitlement certificate can be activated by the Satellite Administrator using
the web interface. Periodically this function has to be performed to keep a Satellite Server
functioning since each certificate issued by Red Hat has a limited life based on its expiration.

36

RH401-6-en-1-20110713

Organization Administrator

Organization Administrator
The Organization Administrator can perform all functions within the scope of the organization
which they manage. Typically they manage user accounts and assign them roles, although
Organization Administrators can perform all of the functions that belong to all of those roles.
Organizations can have multiple Organization Administrators, therefore multiple administrators
don't have to use a common account and share the master organization superuser password.
Lost or forgotten Organization Administrator passwords can be e-mailed to the e-mail
account associated with their RHN account or they can be changed by another Organization
Administrator within their organization. They cannot be recovered or overridden by the
Satellite Administrator so it is wise to have more than one Organization Administrator for each
organization as a safeguard.

System Group and Activation Key Administrators


System Group Administrators can create and delete system groups. They can remove systems
from their system groups and can add systems to additional groups which they control, but they
cannot add systems to any of their groups if there is no initial association with at least one of
the system groups they control. System Group Administrators are automatically assigned control
over the groups they create. An Organization Administrator must assign unassociated systems to
one of the system groups of a Group Administrator to put it under their control, but this can be
automated with the use of activation keys.
Activation Key Administrators create and manage activation keys that are used when registering
a client system to Red Hat Network. They have the authority to associate their keys with one
or more of any of the system groups within their organization. Activation Key Administrators
are also able to manage any activation key within their organization, regardless of which
administrator created the activation key.

Channel and Configuration Administrators


Channel Administrators can create, clone, and delete software channels. They can import RPMS
into and delete packages from custom software channels and assign similar privileges to other
users to specific software channels. All software channels can be administered by any Channel
Administrator within an organization, but other users can only administrate the particular
channels assigned to them. Channel Administrators can also manage errata.
Configuration Administrators serve similar functions as Channel Administrators, but
they manage and control access to configuration channels instead of software channels.
Administrative responsibilities for configuration channels cannot be delegated to users who
aren't Configuration Administrators. Provisioning add-on entitlements must be assigned to
systems before they can be considered as a target system for configuration channels.

Monitoring Administrator and Default User


Monitoring Administrators can schedule probes and administrate other system monitoring
functions. Although this role can be assigned to any user by an Organization Administrator, it
only serves a purpose on Satellite Servers where system monitoring has been enabled by the
Satellite Administrator on a Satellite-wide basis.
All accounts serve as System Group Users when they aren't assigned an additional Red Hat
Network administrative role. Organization Administrators can assign system groups to System

RH401-6-en-1-20110713

37

Chapter3.Red Hat Network Organization

Group Users for administration by going to the System Groups tab within the Users tab. Channel
Administrators can also grant software channel administrative privileges for specific channels to
System Group Users.

References
Red Hat Network Satellite Deployment Guide
Chapter 1: Users

38

RH401-6-en-1-20110713

Organization Administrator

Practice Exercise

Creating User Accounts and Assigning Roles


Carefully perform the following steps. Ask your instructor if you have problems or questions.

Log in to the Satellite server on desktopX as the Organization Administrator for the
Example Inc. organization and create the following users as members of that
organization:
Standard user

Privileged user

Login

normal

grouper

Password

redhat

redhat

Full name

Mr. Norman Normal

Ms. Gladys Grouper

Roles

System Group User

System Group Administrator

Specify root@desktopX.example.com as the e-mail address for both RHN Satellite


accounts.

RH401-6-en-1-20110713

39

Chapter3.Red Hat Network Organization

System Groups
System Groups
The most important organizational unit for massive deployment is the system group. Red Hat
Network can organize systems into groups allowing for a variety of configuration changes to the
group as a whole, including application of new and updated packages and individual files.
Red Hat Network user accounts can be given administrative access to RHN systems by group.
Note that an individual system can belong to multiple system groups.

References
Red Hat Network Satellite Reference Guide
Section 7.4.3: System Groups

40

RH401-6-en-1-20110713

Organization Administrator

Practice Exercise

Managing System Groups


Carefully perform the following steps. Ask your instructor if you have problems or questions.
1.

Log in to the Satellite server on desktopX as the Organization Administrator for the
Example Inc. organization, if necessary, and create a system group called example
servers. Fill the group description with useful information of your choice.
Do not make any security adjustments or assign administrators to the new group. Examine
the initial access privileges for normal and grouper to the example servers group.

2.

Modify the example servers system group so grouper can administrate the group. Sign
in as grouper and normal and observe what access they have to the system group.

3.

Log in as grouper and modify the group so normal can administer systems in that group.
Log in as normal and confirm he has access to the group.

RH401-6-en-1-20110713

41

Chapter3.Red Hat Network Organization

Personal Notes

42

RH401-6-en-1-20110713

Organization Administrator

Unit Summary
RHN Organization Administration
In this section you learned how to:
Create a Red Hat Network organization
Assign base and software entitlements to a RHN organization
.
RHN User Administration
In this section you learned how to:
Create users within a RHN organization
Modify the role of a RHN user
.
System Groups
In this section you learned how to:
Create a system group within an organization
Assign a System Group Administrator control over a system group
Assign a normal user as a system administrator within a system group
.

RH401-6-en-1-20110713

43

44

Chapter4.

UNIT FOUR

USING SUBVERSION TO
MANAGE CHANGES
Introduction
Topics covered in this unit:
Introduction to Subversion
System administration uses for revision control
Creating a new repository and starting projects
Using Subversion to manage files

RH401-6-en-1-20110713

45

Chapter4.Using Subversion to Manage Changes

Revision Control Concepts


What Is Revision Control?
Revision control software is a useful tool for system administrators who write scripts, write
documentation, and develop configuration files. Revision control keeps a record of changes made
to files under its control, but the only changes it can manage are the ones checked into it by the
user. Subversion is a revision control system normally used for software development. We will use
Subversion throughout this course to manage changes and revisions made in later lab exercises.
Subversion maintains a history of the four W's of changes: who committed what changes to
the storage system when and why. The user who commits changes is the who. Subversion
calculates the what - the differences between the previous version of a file and the version being
checked in. The time when the revisions are committed is the when. The log messages entered
by the user explain why the changes were made. Since log messages document the reasons why
changes are made, they are often used when building and releasing errata packages.
Revision control software does not replace communication or good management. It can help
merge changes made by multiple users, but it isn't going to make sure the changes make sense
together -- that is the human's job! Subversion does not check for syntax errors (although it can
be configured to run syntax checkers). However, Subversion can make coordination of changes
and repair of mistakes simple.

How Subversion Works


All the files and directories under Subversion control are stored in a central repository. A
repository is a directory structure that contains a database, lock files, and other administrative
files. The database in the repository stores all the information necessary to recreate any version
of the files and the log messages submitted for all of the revisions. The repository may be stored
in a local directory or it may be accessed remotely using ssh or WebDAV.
Files should never be edited in the repository directly. Instead, each user creates a personal
working directory where changes are made. When a user wants to edit files stored in the
Subversion repository, they check out current copies of those files into a Subversion working
directory. Copies of those files are put into a Subversion working directory and they can be
edited normally. After the changes have been made, the user commits the files back to the
repository so other users can check them out and edit them further.
If a user has old, outdated copies of files from the repository, they can update them before
they start work to get the latest versions of the files and minimize conflicts when they commit
their changed copies. Once a user has files checked out of Subversion, the user typically keeps
modifying them in an update-edit-commit cycle.
Each subdirectory of a Subversion working directory has a .svn directory. This directory
contains important support files for Subversion so it can keep track of changes to the files in the
working directory:
.svn/entries lists each of the Subversion-managed files in the directory and some
information about them.
.svn/text-base contains the latest editions of files that were copied from the repository
when svn update was executed. This allows for comparisons with working copies without
having to access the repository.

46

RH401-6-en-1-20110713

Selecting a Repository

There are other files in this directory that haven't been mentioned. These files should never be
edited by hand! Let Subversion manage them automatically.

Selecting a Repository
Later in this unit you will learn how to use Subversion with files in an existing repository. The
repository could be a directory on the local computer or it may be accessed remotely through
one of several access methods. The repository URL is specified when the project is originally
checked out into a local Subversion working directory. The .svn/entries files in the working
directory contain the repository URL so the URL doesn't have to be specified when working in
the Subversion working directory.
Remote Repositories
Frequently the Subversion repository is hosted on a different machine than the Subversion
working directory. In this case one of Subversion's remote access methods will have to be used to
contact the repository. The available methods depends on which access methods the Subversion
administrator has configured.
A simple method that allows secure read-write access is svn+ssh, which uses the ssh program
for transport. This method requires shell access to the system hosting the Subversion repository.
SSH public key authentication eliminates the need to enter a password multiple times when
accessing the Subversion repository.

RH401-6-en-1-20110713

47

Chapter4.Using Subversion to Manage Changes

Subversion Administration
Initializing a New Repository
The svnadmin create command creates a new repository. This command must be executed by
a user who has write permissions to the directory where the repository will be created. Although
a user can create a private repository, most repositories are used by multiple users on a system
so root usually must create and secure system-wide repositories.
A simple way to set up a repository that will allow secure authentication is to allow Subversion
over SSH (svn+ssh). Make sure the sshd daemon is started and is configured to start on boot.
User accounts will have to be created and passwords assigned for each of the remote users who
will access the repository.

Subversion Security
Once a new Subversion repository is created, determine which users need read-only and readwrite access to the projects that will be added to the repository. The best way to handle this is
to put all of the appropriate users into a group and make the db directory read-write and setgid for that group. When two groups of users have conflicting security requirements, create two
separate repositories for their projects.
[root@host ~]# groupadd -g 20000 svnuser
[root@host ~]# chgrp -R svnuser $REPO_PATH
[root@host ~]# chmod -R g+w $REPO_PATH/db

ACLs on ext3 filesystems can be used to restrict or allow access to a repository by additional
groups or individual users.

Starting a Subversion Project


Starting a project in Subversion is very simple. First, create a directory and populate it with the
initial revisions of files that make up the project. Create and populate subdirectories as needed.
Once you have decided on your project directory structure and created your initial content,
import it into your repository. Change into the top level directory of your new directory tree and
type:
[user@host tmp]$ svn import $REPO_URL/newproject

Notice the name of the original directory used to organize the project and the name of the
project in the repository do not have to be the same. Choose a short, but descriptive, project
name so it is easy to identify it when listing a repository's contents.
The svn import command will recursively search through subdirectories. Like svn commit,
the import command will open the default text editor for an initial log message. Since this is the
original import of a project's content, the log message should briefly describe what the project is.

Other Revision Control Software


RCS is the great-grandfather of open source revision control software. It works on a single
system (it doesn't have network capability) and works on the premise that users have to check

48

RH401-6-en-1-20110713

Other Revision Control Software

out locked copies of files they want to edit. The rcs RPM provides the suite of RCS tools and is
supported with Red Hat Enterprise Linux.
CVS (Concurrent Versions System) is a popular revision control system. Its commands are
accessed using cvs followed by a subcommand then options and arguments. The CVS
subcommands were based upon the RCS commands, except CVS provided functionality over a
network with a central repository. Subversion was designed to function like CVS, but without
some of its limitations.
The cvs RPM provides the CVS revision control system for Linux and is supported by Red Hat
Enterprise Linux. The info pages for CVS are much more useful than the man pages. A good
reference book for CVS is also available online at the following URL: http://cvsbook.redbean.com/cvsbook.html.
Another distributed revision control system is Mercurial. It provides similar functionality to
Subversion, but it is invoked as hg on the command line and it has additional subcommands that
Subversion doesn't provide. Mercurial is written in Python and has an integrated web interface.
Red Hat Enterprise Linux does not provide Mercurial at this time, but it is provided by Fedora.
git is a distributed revision control system that operates on the principle that every working
directory acts as a complete repository managing complete change history. Developers use git
to coordinate and facilitate Linux kernel development. Like Mercurial, git is provided by Fedora,
but not Red Hat Enterprise Linux at this time.

References
Version Control with Subversion book available on-line at http://svnbook.redbean.com
svnadmin(1) man page and svnadmin help Subversion subcommand

RH401-6-en-1-20110713

49

Chapter4.Using Subversion to Manage Changes

Practice Exercise

Preparing the Subversion Repository and Users


Before you begin...
In this lab one of your two machines will be referred to as desktopX and will host the Subversion
repository. This machine should be your RHN Satellite Server since you will reinstall desktopY to
complete later labs.
Your client machine, desktopY, will serve as the remote workstation of one of your Subversion
users. Make sure the clocks on both of your machines are synchronized with each other.
If you need to install packages, yum should already be configured on desktopX and desktopY.
Carefully perform the following steps. Ask your instructor if you have problems or questions.
Your internal DNS servers have had some problems lately. The DNS administrators, Stan and
Oliver, have been modifying configuration files in such a way they have been stepping on each
others' changes. Your task is to deploy a Subversion server which will allow Stan and Oliver to
work together and stop the configuration file conflicts.
Build a Subversion repository on desktopX that will allow two users, oliver and stan, to create
projects and work collaboratively.
1.

Reinstall desktopY with Red Hat Enterprise Linux 6 to prepare it for this and future lab
exercises. PXE boot desktopY and select the Install a standard RHEL 6 workstation option.

2.

Log in as root on desktopX and install Subversion if necessary. Create a repo named /var/
local/svn on desktopX while desktopY reinstalls. After the installation finishes, check if
Subversion is installed on desktopY. If not, then install it on desktopY also.

3.

On desktopX, create a group called svnuser with a group ID of 60000. Modify the
Subversion repository so all users in that group can create and modify projects.

4.

Create user accounts for oliver and stan on both workstations. Assign their accounts the
password of password on both systems.
Make all necessary adjustments to their accounts to allow them to use Subversion from
either host. Both users should be able to commit their changes to the Subversion repository
without typing a password when they are logged into desktopY.

50

RH401-6-en-1-20110713

Other Revision Control Software

Practice Exercise

Starting a New Project in Subversion


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Set up a new project in the Subversion repository for DNS configuration files.
1.

Log in as oliver on desktopX and create a subdirectory in Oliver's home directory


called source. Create etc and var/named subdirectories below ~/source to provide a
temporary DNS chroot hierarchy.

2.

Use anonymous FTP to download all the files in /pub/materials/namedfiles from


instructor.example.com into ~/source. Move the files into the appropriate directories
in the temporary tree. Do not change their names at this time.

3.

Have oliver create a new project called dnsfiles in the Subversion repository. The
project should initially be populated with the files from his ~/source directory.
If the group ownership and permissions assigned to the repository are correct, Oliver should
be able to create the project since he is a member of the svnuser group.

4.

Confirm the files are safely in the repository. Check the dnsfiles project out from the
Subversion repository on desktopX and compare its contents with the files in ~/source.

5.

Remove the ~/source directory from Oliver's home directory once it is confirmed the DNS
files are properly stored in the Subversion repository.

RH401-6-en-1-20110713

51

Chapter4.Using Subversion to Manage Changes

Revision Management with Subversion


Preparing to Use Subversion
When using Subversion with an existing repository, only a few basic commands are needed to
get started. These commands will be introduced in the following pages. Before we examine them,
there are a couple of configuration items that need to be taken care of.
Subversion requires an environment variable specify which text editor to use to enter log
messages. Valid environment variables include EDITOR, VISUAL, or SVN_EDITOR. One of these
environment variables should be defined in a Subversion user's .bash_profile configuration
file.
export EDITOR=vim

In Red Hat Enterprise Linux 6 and recent Fedora versions, the Subversion RPM provides a
configuration file for bash that teaches it how to complete Subversion sub-commands. The
following added to a user's ~/.bashrc would activate this feature:
. /etc/bash_completion.d/subversion

Starting a Working Directory


The svn checkout command copies the files of a project from a repository into your current
working directory. The Subversion administrator must provide the URL to the repository and the
name of the project. Projects can be listed if only the URL to the repository is given:
[user@host ~]$ svn list file:///var/local/svn
myproject/
oneproject/
twoproject/
... Output Omitted ...

A project is usually the relative path to a set of related files stored in the repository. A single
Subversion repository can store several different projects in its database. Given the output
above, the following command would checkout the oneproject project from the repository into
a Subversion working directory called oneproject below your current directory:
[user@host ~]$ svn checkout file:///var/local/svn/oneproject
A
oneproject/index.html
A
oneproject/images
A
oneproject/images/banner.png
A
oneproject/images/logo.png
Checked out revision 7.

The lines that start with an A indicate these files have been added from the repository into your
Subversion working directory.

Committing Changed Files


After one has finished editing files in the Subversion working directory, the new revision needs
to be put into the repository. The svn commit command accomplishes this task. Without

52

RH401-6-en-1-20110713

Updating a Working Directory

arguments, svn commit will recursively check the current directory and all subdirectories for
changed files and commit them to the repository.
Log messages are critically important!
Before the commit completes, a text editor launches and prompts for a log message which will
be associated with this revision. Log messages should be brief descriptions explaining why
the changes were made for future reference. When the log message is brief, the -m option can
specify the log message on the command line:
[user@host myproject]$ svn commit -m 'Restrict cracker.org host access.'
Sending
etc/hosts.deny
Transmitting file data .
Committed revision 15.

Particular files can be committed individually. The following command is an example of


committing a file that is finished when other files are not ready to be committed:
[user@host myproject]$ svn commit filename

Updating a Working Directory


As files are edited in a Subversion working directory and the changes are committed, so are the
changes of co-workers. If the current Subversion working directory was checked out some time
ago, it may not have the latest revision of the files that need to be edited. The svn update
command contacts the repository and updates the Subversion working directory with the latest
revisions committed. It's a good idea to run svn update at the start of the day (before you start
work) and any time a co-worker may have revised a file you plan to edit. Like checkout, update
outputs a line for each file updated starting with a letter to indicate the state of the file:
U: The file in the working directory has been updated from the repository.
G: A file in the working directory was in conflict but Subversion was able to update it and
merge the changes automatically.
A: There is a new file in your Subversion working directory from the repository.
D: A file was deleted from the Subversion working directory and will be marked as deleted
from the repository.
?: A file is in your working directory, but it does not correspond to anything in the repository,
and it is not scheduled for addition to the repository.
M: A file in the repository has local modifications that haven't been saved.
C: There is a modified file with a copy in the repository that has changed and the changes
conflict. The changes need to be resolved manually.

Merging Conflicting Changes


When a file being committed has changed in the repository since the last update, svn commit
will fail. svn update must be executed to merge the changes into the modified working copy.
If the changes conflict (for instance, if the edits are on the same line as the changes in the
repository copy), the conflict must be resolved. The svn update command displays a C in the
first column when conflicts occur.

RH401-6-en-1-20110713

53

Chapter4.Using Subversion to Manage Changes

[user@host sample]$ svn commit -m "fixed michael's last name"


Sending
namelist
svn: Commit failed (details follow):
svn: File '/sample/namelist' is out of date
[user@host sample]$ svn update
C
namelist
Updated to revision 29.

When a conflict occurs, four files can be consulted for a possible fix. In the example above,
namelist.mine is the original working copy of the file that has the changes that were being
committed before the conflict was flagged. namelist.r28 is the pristine version of the file
before any changes were made and namelist.r29 is the new update that came from the
repository. The file, namelist, is modified so all conflicts are delimited by <<<<<<<, =======,
and >>>>>>> markers:
[user@host sample]$ ls
hello
namelist.mine namelist.r29
namelist namelist.r28
sample1
[user@host sample]$ cat namelist
... Output omitted ...
<<<<<<< .mine
michael thomason
=======
michael thompson
>>>>>>> .r29
... Output omitted ...

sample2
sample3

sample4

Once the conflict has been resolved, the svn resolved command will clean up the extra
version files and ready the Subversion working directory for a commit:
[user@host sample]$ svn resolved namelist
Resolved conflicted state of 'namelist'
[user@host sample]$ svn commit -m "fixed michael's last name"
Sending
namelist
Transmitting file data .
Committed revision 30.

File Manipulation
Adding a new file to a Subversion repository is simple. Create the new file, run svn add
filename to schedule it for addition, and then run svn commit. There are two important
things to remember: first, svn add doesn't actually add the file to the repository immediately;
it just schedules it for addition on the next svn commit. Second, svn commit can take one
or more filenames as arguments and commit only those files. This is useful when working on
multiple edits at the same time and a subset of the changes. The svn add command can also be
used to add a directory to the repository.
svn add should not be used to start a new project. When an entire directory tree of files needs
to be added the svn import command is used instead.
Scheduling a file for removal from the repository is very similar to adding a file. svn delete
filename deletes the file from the Subversion working directory and marks it for deletion from
the repository upon commit. However, the file is not completely removed from the repository.
Subversion will record that the file no longer exists, but the repository still stores old revisions
and the change log of the file.

54

RH401-6-en-1-20110713

Viewing Working File Status

Viewing Working File Status


The svn status command displays the current status of files in the Subversion working
directory. The -v option causes this command to list all files, not just those with changes. The u option causes the command to check the repository for more recent updates. Each status line
starts with a letter code indicating if an item was added, deleted, or otherwise changed.
[user@host sample]$ svn status -vu
M
19
19 stan
*
19
19 stan
20
20 oliver
19
19 stan
Status against revision:
21

sample1
sample2
sample3
.

The asterisk on the second line of output means the repository has a newer version of sample2
than the Subversion working directory. Some common letter codes are:
Letter Code

Meaning

File will be added when committed

File has unresolved conflicts

File has been marked for deletion

File has been modified

Space

No modifications

File is not under version control

File is missing (removed by non-Subversion


command)

Table4.1.Common Subversion Status Codes


The svn info command displays detailed information about a specific working file including the
file and repository URL and information about the last commit made to the file.
[user@host sample]$ svn info sample3
Path: sample3
Name: sample3
URL: file:///var/local/svn/sample/sample3
Repository Root: file:///var/local/svn
Repository UUID: b0f33f46-1ad6-4fca-8fb7-0d51367b9b16
Revision: 20
Node Kind: file
Schedule: normal
Last Changed Author: oliver
Last Changed Rev: 20
Last Changed Date: 2009-12-16 14:46:23 -0800 (Wed, 16 Dec 2009)
Text Last Updated: 2009-12-16 14:45:52 -0800 (Wed, 16 Dec 2009)
Checksum: 53375d898de9837e1f9c6565f45f7600

Examining Old Revisions


Rather than being interested in the history of all operations on the repository, you may be
interested in specific changes made to a particular file. There are a few commands that are
useful for this purpose.

RH401-6-en-1-20110713

55

Chapter4.Using Subversion to Manage Changes

svn log filename will output all the log messages recorded for each revision of filename
including when and who committed those revisions.
The svn cat can be used with the -r option to display a specific revision of a file to standard
output. svn cat -rversion filename displays a specific This output can be piped to less
for more controlled viewing or it can be redirected to a file for further review:
[user@host wrappers]$ svn cat -r 23 hosts.deny | less

Another useful command is svn diff which compares an old version in the repository with the
copy of the file in the Subversion working directory:
[user@host wrappers]$ svn diff -r 16 hosts.deny

This command may take many different options to output various diff formats. The diff
subcommand is useful if the comments in the change log aren't sufficiently clear.

Rolling Back to Old Revisions


Sometimes it is necessary to undo all edits made on a file after a particular revision. This can
be accomplished with the svn cat command. First the specific revision number of the file in
its previous state needs to be identified. This can be accomplished with the svn log and svn
diff commands. Use svn cat to display the file in its original, desired state and redirect the
output so it overwrites the copy in the working directory. Commit your changes to the repository
and mention in the log that a rollback has occurred.
The svn revert command discards uncommitted, recent changes to a working copy of a file.
This command restores the files specified to the state they were in when they were last updated
from the repository.

Properties and Keyword Substitution


Subversion maintains additional properties about the files in its repository. You can create and
manipulate your own properties or you can use the built-in Subversion properties that impact
its behavior. For example the svn:executable property will cause a file to be made executable
when checked out of the repository when it is set to a value of 1:
[user@host sample]$ svn propset svn:executable 1 hello

The Subversion subcommands to manipulate properties include propset, propget, proplist,


propdel, and propedit. Note: properties have to be committed to the repository for them to
be persistent.
The svn:keywords property contains a string of keywords separated by spaces the Subversion
should expand when a file is checked out of a repository. By default Subversion doesn't perform
keyword substitution to avoid damaging binary files. Keywords enclosed in dollar signs are
expanded only when the svn:keywords property is set:
[user@host sample]$ svn proplist sample2
Properties on 'sample2':
svn:keywords
[user@host sample]$ svn propget svn:keywords sample2

56

RH401-6-en-1-20110713

Next Steps with Subversion

Author Id
[user@host sample]$ grep Id sample2
# $Id: sample2 19 2010-02-02 17:31:52Z stapleton $

The following table lists the keywords that Subversion expands:


Keyword

Value

Date

The date/time the file was last changed and


committed into the repository

Revision

The revision when the file was last updated

Author

The username of the person who committed


the last change

HeadURL

The URL that points to this specific file in the


repository

Id

A useful combination of the above keywords

Table4.2.Subversion Keyword Expansion

Next Steps with Subversion


This unit introduced you to the most commonly used Subversion commands. Other useful
Subversion subcommands which we won't discuss include:
Subcommand

Use

export

a variant of checkout, to copy the contents


of a project without the .svn subdirectories

annotate

display a file preceding each line of text with


author and revision information

lock

set a lock on a file in the repository so others


cannot commit changes to that file in the
repository

unlock

clear a lock on a file in the repository so


others can commit changes to that file in the
repository

Table4.3.Other useful Subversion subcommands

References
Version Control with Subversion book available on-line at http://svnbook.redbean.com
svn(1) man page and svn help Subversion subcommand

RH401-6-en-1-20110713

57

Chapter4.Using Subversion to Manage Changes

Practice Exercise

Managing Changes with Subversion


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Create working directories and observe how Subversion manages concurrent changes by two
users.
1.

Log in as oliver on desktopX. If the dnsfiles working directory doesn't exist, check out a
working copy of the dnsfiles project below Oliver's home directory.

2.

Change to the top level directory of your Subversion working directory and modify etc/
named.conf. Find the comments that read REPLACE FIX HERE WITH YOUR STATION
NUMBER and change all occurrences of the string FIX in the zone declarations to the last
octet of desktopX's IP address.
Note: This changes the files that DNS will try to reference. There are comments in the file
noting that the actual files must be renamed for consistency. For now disregard those
comments since you will fix the repository files to match the new names in a later lab
exercise.
Commit Oliver's changes with a log message of Replaced FIX with station's IP.

3.

In another window, log in as Stan on desktopY. Create a Subversion working directory in


Stan's home directory and have Stan checkout a copy of the dnsfiles project. Examine
named.conf. The changes made by Oliver should appear in that file.

4.

As Stan, edit var/named/192.168.0.FIX.zone in the Subversion working directory and


replace every occurrence of FIX with the last octet of desktopX's IP address. Be sure to
update the serial number to YYYYMMDD00 using the digits of the current date. Commit
Stan's changes with the same log message that Oliver used previously.

5.

On desktopX update Oliver's Subversion working directory so Stan's revisions are


incorporated into Oliver's files.

58

RH401-6-en-1-20110713

Next Steps with Subversion

Practice Exercise

Moving Files in a Subversion Project


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Previously Stan modified the contents of a file. Modify file names and observe how Subversion
manages the changes.
1.

Using Stan's account on desktopY, use Subversion to change the name of the
192.168.0.FIX.zone file so FIX is replaced with the last octet of desktopX's IP address.
Commit the changes into the Subversion repository with a descriptive log message.

2.

Review the log messages of the 192.168.0.X.zone file.


Rename the file domainFIX.example.com.zone so FIX is replaced with the last octet of
desktopX's IP address. Make sure the changes are committed into the Subversion repository.

3.

Examine Oliver's Subversion working directory on desktopX. Use Subversion to update his
working files and see what happens.

RH401-6-en-1-20110713

59

Chapter4.Using Subversion to Manage Changes

Practice Exercise

Subversion Conflict Resolution


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Observe how Subversion behaves when two users modify the same file, sometimes with
conflicting changes.
1.

As Stan on desktopY, open domainX.example.com.zone in a text editor. Modify the SOA


line of the file so all occurrences of FIX are changed to the last octet of desktopX's IP
address. For example the student whose Satellite Server is station3.example.com would
modify the line to look like the following:
@ IN SOA desktop3.domain3.example.com.

root.desktop3.domain3.example.com. (

Save, exit, and commit the changes to the Subversion repository.


2.

Without updating first, as Oliver on desktopX open domainX.example.com.zone in a text


editor. Fix the NS resource record by replacing each FIX with the last octet of desktopX's
IP address. Save, exit, and have Oliver commit the changes. This shouldn't require too much
effort since Oliver's changes do not conflict with Stan's.

3.

Have Stan on desktopY update his Subversion working directory and get Oliver's changes.
As Stan, edit domainX.example.com.zone and change each FIX in the MX line to the
last octet of desktopX's IP address. Update the serial number with the current date followed
by a two digit sequence number. Commit Stan's changes to the Subversion repository.

4.

As Oliver on desktopX, make the same changes that Stan made but also change the MX
record priority to 15. Attempt to commit your changes. This will fail since Oliver's Subversion
working directory is not updated. Also update the zone file serial number to be greater than
the previous value.
Commit Oliver's changes into the repository since his changes are more complete than
Stan's changes.

5.

60

As either Oliver or Stan, update the remaining resource records in


domainX.example.com.zone that contain FIX with desktopX's number. Update the
serial numbers in the .zone zone files. Commit the changes into the Subversion repository.

RH401-6-en-1-20110713

Next Steps with Subversion

Personal Notes

RH401-6-en-1-20110713

61

Chapter4.Using Subversion to Manage Changes

Unit Summary
Revision Control Concepts
In this section you learned:
The benefits of using revision control
How Subversion works at a high level
How to select a Subversion repository
.
Subversion Administration
In this section you learned how to:
Create a new Subversion repository
Secure a Subversion repository
Start a project in Subversion
.
Revision Management with Subversion
In this section you learned how to:
Check out a Subversion working directory
Commit changes made to files in a project
Update a Subversion working directory with changes made by others
Merge and resolve changes that conflict
Adding, deleting, and changing file names in a project
Roll back to a previous edition of a file
.

62

RH401-6-en-1-20110713

Chapter5.

UNIT FIVE

RED HAT NETWORK CLIENT


CONFIGURATION
Introduction
Topics covered in this unit:
Configure a client system to use an RHN Satellite Server
Use SSL encryption for secure communications
Register systems using Activation Keys and bootstrap scripts
Troubleshoot client registration problems

RH401-6-en-1-20110713

63

Chapter5.Red Hat Network Client Configuration

Client Registration Concepts


Objective: register client systems with Red Hat Network
Steps to take
1.

Update Red Hat Network software tools

2.

Point to relevant Red Hat Network server

3.

Install SSL CA certificate (Satellite/Proxy only)

4. Register the RHN client system


Authenticate as valid Red Hat Network user, or
Register with an activation key
In this unit the various methods of registering a client machine with Red Hat Network will be
examined. It is assumed the client machine is installed and functioning before the registration
process begins.
The steps above outline the overall procedure needed to register a client system with Red Hat
Network. Each of the steps will be examined in more detail as we go through the rest of this unit.

When a Client Registers Multiple Times


The default RHN host profile name is defined as the host name of the client system that
registered. When a client system registers multiple times (often this requires additional work
to do), multiple system profiles with the same name will appear. The key to determining which
profile is the current one in use is to identify the RHN system ID of the client and compare it to
each of the RHN system profiles in the Satellite server. The system ID of the client is found in the
/etc/sysconfig/rhn/systemid file:
[root@host ~]# grep ID /etc/sysconfig/rhn/systemid
<value><string>ID-1000010027</string></value>

The numeric part of the string found on the client should match the RHN Satellite System ID
displayed in the Overview page within the Details tab of the system profile.

References
Red Hat Network Satellite Client Configuration Guide
Chapter 6: Manually Scripting the Configuration

64

RH401-6-en-1-20110713

Practice Quiz

RHN Registration Steps


List the four steps (in order) that are taken when a client workstation registers with a RHN
Satellite server.
1.
2.
3.
4.

RH401-6-en-1-20110713

65

Chapter5.Red Hat Network Client Configuration

Interactive Client Registration


Update RHN Client Software
Before registering a client with Red Hat Network, it is important to bring the registration
and package updating software up to date. Sometimes newer packages are needed because
of features provided by the updated tools or changes in their configuration. In practice the
registration process will perform this function for you, but you may wish to do this yourself if you
are scripting the installation.
Publish the latest versions of the software packages listed below on your RHN Satellite Server's
web site. The best place to provide these files is under the http://satellite.fqdn/pub
directory. Have the client systems download and freshen these packages before they register
with Red Hat Network. For example, a command similar to the following should be run for each
package:
[root@host ~]# rpm -Fvh http://satellite.fqdn/pub/yum-version.i386.rpm

Install the latest version of RHN-related packages


Red Hat Enterprise Linux 5 and later packages
rhn-setup
rhn-setup-gnome
yum
Pre-Red Hat Enterprise Linux 5 packages
rhn_register
rhn_register-gnome
up2date
up2date-gnome

Red Hat Network Server Selection


When a system is installed with Red Hat Enterprise Linux, it is configured to point to hosted Red
Hat Network by default. The assumption is that the new system will talk directly with Red Hat's
servers over the Internet (https://xmlrpc.rhn.redhat.com/XMLRPC).
/etc/sysconfig/rhn/up2date is the primary configuration file for Red Hat Network client
tools. Many of the registration programs modify settings in that file or the changes can be
scripted or made manually. For example, the serverURL directive defines which RHN server
should be queried for updates:
serverURL=https://satellite.fqdn/XMLRPC

Additionally, HTTP/HTTPS proxy settings can also be defined by assigning the following values in
/etc/sysconfig/rhn/up2date:

66

RH401-6-en-1-20110713

Secure Communication with SSL

enableProxy=1
httpProxy=hostname:port

Note
Always use fully qualified domain names when specifying Red Hat Network Satellite and/or
Proxy servers.

Secure Communication with SSL


A best practice is to have all Red Hat Network communication secured using SSL encryption.
SSL server certificates must be considered trustworthy before a secure communication tunnel
is created. Certificate authority (CA) certificates are used to confirm the authenticity of a host's
SSL server certificate. The CA certificate used to verify Red Hat's server certificates can be
found in a file called /usr/share/rhn/RHNS-CA-CERT. Red Hat installation media deploys an
RPM called rhn-client-tools that installs this CA certificate on all Red Hat Enterprise Linux
hosts by default.
The Red Hat Network Satellite Server and Proxy Server installers generate a CA certificate,
an RPM package which includes the CA certificate, and an SSL server certificate signed by
the CA certificate. Installing the RPM package with the CA certificate causes clients to trust
the server's SSL certificate. This RPM is normally distributed through the Satellite Server's
web site in the /pub directory and the RPM is typically called: rhn-org-trusted-sslcert-1.0-1.noarch.rpm. This RPM must be installed on every client who connects to a
Red Hat Network Satellite or Proxy server using SSL. This is defined by sslCACert in /etc/
sysconfig/rhn/up2date.

Red Hat Network Authentication


User accounts are unique on Red Hat Network Hosted and on a Red Hat Network Satellite Server.
On a RHN Satellite Server each user account, and systems registered using that account, belong
to the organization the account was originally created in. Unless there is a universal default
activation key, the newly registered system does not belong to any system groups.
Users must authenticate using a RHN user account. User accounts used to register systems do
not have administrative privileges to administer those systems by default. To enable RHN users
to administer clients they register, the client systems will have to join a system group the users
have permissions to administer. An Organization Administrator can modify user accounts so that
systems they register automatically join default system groups for that account.
Each registration consumes one Red Hat Network entitlement. Minimally this includes a base slot
and a base software channel entitlement. Optionally add-on and child channel entitlements could
be included.
Another option is to create a universal default activation key that associates newly registered
systems to a generic system group that every RHN user can access. Note that activation keys
override default system group assignments associated with a user account.

RH401-6-en-1-20110713

67

Chapter5.Red Hat Network Client Configuration

References
Red Hat Network Satellite Reference Guide
Chapter 2: The rhn_register Client
rhn_register(8) man page

68

RH401-6-en-1-20110713

Secure Communication with SSL

Practice Performance Checklist

Graphical Red Hat Network Registration


You will register a system with a Red Hat Network Satellite using rhn_register in a graphical
environment. Since SSL encryption will be used, the organization CA certificate will have to be
located and used when registering the client system.
Your client workstation, desktopY.example.com, should already be installed to
provide a graphical environment. The classroom installation configures yum to point
to the instructor's server for additional RPMS. Remove the /etc/yum.repos.d/
dvd.repo configuration file and reset yum by executing the following command as
root:
[root@desktopY ~]# yum clean all
[root@desktopY ~]# rm /etc/yum.repos.d/dvd.repo

Browse http://desktopX.example.com/pub and locate the CA certificate for the


local organization provided by the Satellite Server. Download the CA certificate to the /
tmp directory on desktopY.
Log in as root on desktopX and monitor your Satellite server's Apache log files. Use
tail -f to monitor them continuously.
Open a terminal window on desktopY and execute rhn_register so it
displays a graphical dialog box. Configure the client to use the Satellite Server,
desktopX.example.com, for software updates. Use the SSL certificate you previously
downloaded and authenticate as the Red Hat Network user normal. Once the client is
configured, use yum repolist to verify it is talking with the Satellite Server.
Use a web browser to log into the Satellite server web user interface as normal and see
if the newly registered system shows up in the system list. Do the same for the Red Hat
Network user grouper. Finally log in as the Organization Administrator, example, and
see if the client shows up in his system list.

RH401-6-en-1-20110713

69

Chapter5.Red Hat Network Client Configuration

Practice Performance Checklist

Text-based Red Hat Network Registration


Register a system with a Red Hat Network Satellite using rhn_register in a text-based
environment. You should already have the CA certificate copied to the filesystem on the client
machine.
Log into a text-based virtual console (Ctrl+Alt+F2) as root on desktopY and
execute rhn_register to re-register your client with your Satellite server. When
rhn_register asks for RHN authentication information, provide the login of normal
with the password redhat.
Log into the Satellite server web interface as example. There should be two system
profiles labeled desktopY.example.com.

70

RH401-6-en-1-20110713

Registration Automation: Activation Keys

Registration Automation: Activation Keys


One major benefit of activation keys is they remove the requirement to authenticate as a Red
Hat Network user when registering a client system with RHN. This greatly facilitates automation
of system registration.
Activation keys also automate other Red Hat Network functions such as subscribing to child
software channels, joining system groups, installing specific packages or including add-on
entitlements such as Provisioning, monitoring, virtualization, virtualization platform, etc.
Multiple activation keys can be used when registering a system with RHN, so there are a couple
of approaches that can be taken when using them. One approach uses a single activation
key to perform multiple actions on the RHN Satellite server. The other approach involves
several activation keys, with each key performing a single, simple action on the Satellite server.
When systems are registered using this approach, multiple keys are used together in various
combinations depending on what needs to be accomplished for a given client system. This
approach has more flexibility in terms of activation key maintenance.
One activation key can be designated as the universal default activation key for an
organization. Each organization has its own universal default and only one activation key can
be designated as the universal default. The actions and associations assigned to the universal
default are taken for hosts that register with an organization without an activation key. It is a
best practice to assign a universal default activation key that assigns a newly registered system
to a system group as a minimum.
Activation keys are an essential component to Red Hat Network client registration automation.
Use the procedure below to generate an activation key. Each activation key has five attributes:
1.

Description of what the key is for

2.

Usage limit - number of times the key may be used for activation

3.

Base software channel the client should subscribe to when activated

4. Add-on entitlements such as Provisioning, Monitoring, Virtualization, or Virtualization


Platform
5.

A flag indicating whether a key is the universal default

After an activation key is created, additional attributes can be associated with the key such as:
Child software channels
Packages to install at registration time
One or more system groups to join
Clients may only subscribe to relevant software channels. For example a Red Hat Enterprise
Linux 5 Server host cannot subscribe to the Red Hat Enterprise Linux AS 4 channel.
Use the activation key to register a system with the Satellite server at client installation time.

Activation Key Creation


Generate an activation key on the RHN Satellite server:

RH401-6-en-1-20110713

71

Chapter5.Red Hat Network Client Configuration

Login as an Organization or Activation Key Administrator


Click on the Overview tab
Select the Manage Activation Keys task
Follow the create new key link
Provide a key description, a key name, usage limit, base software channel and whether it is
the universal default for the organization
Click Create Activation Key

RHN Registration Using an Activation Key


An activation key can be used without the necessity of RHN authentication. Use the following
command to invoke rhnreg_ks with the essential options needed to specify the target RHN
server, the needed CA certificate for SSL encryption, and the activation key:
rhnreg_ks
--serverUrl=https://satellite.fqdn/XMLRPC \
--sslCACert=/path/to-ca-cert \
--activationkey=activation-key-name

To interactively register a system to a satellite server, run rhn_register [--nox] and


answer all questions posed. You can also modify /etc/sysconfig/rhn/up2date and update
serverURL and sslCACert values before running rhn_register to provide some default
answers.
Since Red Hat Network Satellite Server version 5.2, the activation key has a numeric prefix
(for example, 2-webserver). This prefix represents the organization ID that prefixes every
activation key created and associated within that organization.
To specify multiple activation keys with the rhnreg_kscommand, a single --activationkey
option is specified followed by a comma-separated list of activation key names. Specifying
multiple --activationkey options does not work like one might expect: the last option
specified is the only activation key that is applied.
To re-register a system already registered with Red Hat Network, perform the following steps:
1.

Delete the original system profile from Red Hat Network to reclaim entitlements

2.

Use the --force option with rhn_register or rhnreg_ks

72

RH401-6-en-1-20110713

RHN Registration Using an Activation Key

References
Red Hat Network Satellite Reference Guide
Section 7.4.6: Activation Keys
Section 4.5: Registering with Activation Keys
Red Hat Network Satellite Client Configuration Guide
Section 2.2.1: Registering with Activation Keys
rhnreg_ks(8) man page

RH401-6-en-1-20110713

73

Chapter5.Red Hat Network Client Configuration

Practice Exercise

Automating Registration with Activation Keys


Carefully perform the following steps. Ask your instructor if you have problems or questions.
The previous exercises demonstrated how to register a machine with a Red Hat Network Satellite
Server using interactive utilities. Automate the registration process by creating an activation key
that registers with the Example RHN organization and use it to re-register your client.
1.

Log into your Satellite server as example and create an activation key named exampleservers. It should have a description of Example Servers, not have a usage limit, and
subscribe the client to the default RHN Satellite base channel for the system being installed.
This activation key should not consume any add-on entitlements and do not use it as the
universal default.
All systems registered with this activation key should automatically join the example
systems system group.

2.

Log in as root on the client, desktopY.example.com, and use rhnreg_ks to register


your system using the activation key you just created. If the registration doesn't work
immediately, diagnose what the problem is and fix it.
The Satellite Server host name and information about the CA certificate already have useful
default values. Normally they would have to be specified, but the previous registrations
modified /etc/sysconfig/rhn/up2date so it points to valid values so the defaults can
be taken.

3.

74

Check the system profile of your client system in the Satellite Server. Is it a member of
the example servers system group? If not, make the necessary adjustments to your
activation key and re-register the client again. When you are finished with this exercise,
delete all of the system profiles in the Satellite Server.

RH401-6-en-1-20110713

Registration Automation: bootstrap.sh

Registration Automation: bootstrap.sh


Many steps must be taken to register client machines with a RHN Satellite Server. The
bootstrap.sh script can be used to fully automate this process. By default, this script contains
a few useful commands, but you can expand it to do whatever you wish. It may be used in a
kickstart %post section or it can be manually executed on a freshly installed Red Hat Enterprise
Linux host.
If rhnreg_ks is invoked with an activation key from the bootstrap.sh script, a system can be
registered with Red Hat Network before its first boot.
The following steps outline the process of creating the bootstrap.sh script using the RHN
Satellite web interface:
Login as the Satellite Administrator (not an Organization Admin)
On the Overview tab, select Configure RHN Satellite
Select the Bootstrap Script tab
Make any adjustments, then click Update
bootstrap.sh is disabled by default (contains exit 1 shell command). It is a good starting
point/template, and can be used with activation keys.
To create bootstrap.sh:
Use web interface as Satellite Admin (not Organization Admin)
Use the rhn-bootstrap command on the Satellite Server
Result is http://satellite.fqdn/pub/bootstrap/bootstrap.sh

References
Red Hat Network Satellite Client Configuration Guide
Chapter 5: Using RHN Bootstrap
Appendix A: Sample Bootstrap Script
rhn-bootstrap(1) man page

RH401-6-en-1-20110713

75

Chapter5.Red Hat Network Client Configuration

Practice Exercise

Registering Clients with a Bootstrap Script


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Red Hat Network Satellite software can create a template shell script, called a bootstrap script,
that can register a client system with the Satellite server. Customize and use a bootstrap script to
register a freshly installed system with your Satellite server.
1.

Reinstall your client workstation, desktopY, with a minimal footprint installation. Initiate
a PXE boot and choose the Install a minimal RHEL 6 installation option without any
arguments to begin the installation. While desktopY is installing, continue to the next step.

2.

A Satellite Server provides bootstrap scripts to all of its clients, not just to a specific
organization, so they must be created and managed by the Satellite Administrator.
While the client workstation installs, log in as the Satellite Administrator, satadmin, and in
the web interface create a bootstrap script template as a starting point. The script should
enable SSL and client GPG checking. It should not enable remote configuration and remote
commands. These options will be introduced later in the course.
Optional - Use Subversion to manage the changes you make to the bootstrap script you
develop. Create a new Subversion project and check in the original version before you make
any changes.

3.

Edit your bootstrap script on your Satellite Server. Disable the exit 1 line and modify the
ACTIVATION_KEYS shell variable to point to the activation key you created earlier in this
lab.

4.

Once the client machine has finished installing, log in as root, download the bootstrap
script, and execute it manually. Normally this step would be performed in the %post section
of a kickstart installation for full automation.
Sign into the Satellite Server web interface as normal and confirm the system is registered
and belongs to the example-servers system group.

76

RH401-6-en-1-20110713

Resolving Registration Problems

Resolving Registration Problems


To begin resolving RHN registration issues, start with network connectivity issues:
Can the RHN server be pinged?
Does DNS work properly?
Having an HTTP/HTTPS proxy or firewall issue?
Do all references to the Satellite server use its FQDN?
From the client, use rhn_check and rhn-profile-sync -vv to view errors. The following are
the most common Error Class Codes:
9 - client not registered
70 - no entitlements available
Once basic connectivity issues are resolved, there are a couple of other areas that should be
checked concerning Red Hat Network client/server communication. First, the fully qualified
domain name should always be used when referring to the Red Hat Network server, whether it
is hosted RHN, a RHN Satellite Server, or a RHN Proxy Server. The fully qualified domain name
should resolve to the appropriate IP address for the server. If DNS isn't functioning, a temporary
entry could be made in /etc/hosts for testing purposes. Ultimately any long-term solution
would fix DNS name resolution.
When using SSL encryption for secure communication, the clocks of the Red Hat Network hosts
(both client and server) need to be accurate and synchronized. A good solution for this is to use
NTP to keep all the system clocks set to an accurate time to enable SSL to work. Also make sure
the fully qualified host name of the Satellite server is being used since the subject of the host
certificate is the FQDN of the server.
Red Hat Network creates a new host profile when a system re-registers with RHN (for example
using rhn_register with the --force option). When multiple profiles exist for a specific host,
its old, unused profiles should be removed to free up system and software entitlements. First,
determine the current system ID of the RHN client:
[root@host ~]# grep ID /etc/sysconfig/rhn/systemid
<value><string>ID-1234567890</string></value>

Navigate to each of the system profiles for the matching hosts and note the value of the RHN
Satellite System ID field for each profile. This field can be found by selecting the Overview subtab within the Details tab of each system profile.

RH401-6-en-1-20110713

77

Chapter5.Red Hat Network Client Configuration

Personal Notes

78

RH401-6-en-1-20110713

Resolving Registration Problems

Unit Summary
Client Registration Concepts
In this section you learned:
RHN client registration concepts
.
Interactive Client Registration
In this section you learned how to:
Update RHN Client Software
Select the Red Hat Network Servers
Secure Communication with SSL
.
Registration Automation: Activation Keys
In this section you learned how to:
Create an activation key
Use an activation key to automate RHN registration
.
Registration Automation: bootstrap.sh
In this section you learned how to:
Automate registration using bootstrap.sh
.
Resolving Registration Problems
In this section you learned how to:
Resolve RHN registration issues
.

RH401-6-en-1-20110713

79

80

Chapter6.

UNIT SIX

RED HAT NETWORK SOFTWARE


MANAGEMENT
Introduction
Topics covered in this unit:
Software channel relationships
Custom software channels
Loading RPMS into RHN Satellite
Cloned software channels
Change notifications using errata

RH401-6-en-1-20110713

81

Chapter6.Red Hat Network Software Management

Software Channels
Software channels are a collection of RPM packages. RPMS are the packages that are deployed
on systems managed by Red Hat Network and software channels define which packages a given
system has access to.
Base channels contain packages which are grouped together by a combination of Red Hat
release (RHEL5 Server, RHEL5 Client, RHEL4ES) and architecture (32-bit x86, 64-bit x86). When
a system registers with Red Hat Network, it is subscribed to a base channel consistent with its
operating system version. Systems may only subscribe to one base channel at a time.
Extended Update Support (EUS) channels, also called z-channels, are base channels for
administrators who need to stay on a specific major release of Red Hat Enterprise Linux (for
example RHEL5.3 Server). The RPMS released by Red Hat to these channels are limited to critical
bug fixes and security updates. These software channels are typically used where applications
certified to run on specific versions of Red Hat Enterprise Linux are used.
Child channels are usually associated with a base channel and provide extra packages. For
example RPMS that provide virtualization support for Red Hat Enterprise Linux 5 on 32-bit x86
machines are included in the rhel-i386-server-vt-5 channel, which is a child of the rheli386-server-5 base channel. Systems can subscribe to multiple child channels.

References
Red Hat Network Satellite Channel Management Guide
Chapter 2: Introduction to RHN Channels

82

RH401-6-en-1-20110713

Custom Software Channels

Custom Software Channels


Red Hat provides base and child channels for each release of Red Hat Enterprise Linux.
Additional custom child channels can be associated with Red Hat's base channels. With a RHN
Satellite or Proxy Server an organization can create their own custom software channels, making
them child channels to Red Hat's base channels.
Custom software channels are entirely self-administered. Red Hat does not provide support
for them and since the channels reside on the RHN Satellite or Proxy server they are never
shared with Red Hat. Organizations have complete control over the packages provided by their
custom channels. They aren't required to share their custom RPMS with anyone outside of their
organization, including Red Hat.
Custom channels can be created using the Satellite Server's web interface. Users with Channel or
Organization Administrator roles have the ability to create and delete custom channels.
When creating a software channel, be sure to associate this new channel with the proper base
channel. Use a meaningful channel label and description so the purpose of the channel is clear:
neither overly general so as to be meaningless nor overly specific so as to limit usefulness.
Security settings for the new software channel need to be assigned including access level and
GPG key information.
Navigate to the Create Software Channel form
Select the Channels tab
Choose Managing Software Channels from the navigation menu at the left
Click on the create new channel link at the upper right
Fill out the Create Software Channel form giving special attention to:
Parent channel and channel label
GPG information
One of three access levels must be assigned to the custom software channel. Private access
makes the software channel available only to systems within the current organization. Protected
access additionally makes the channel available to other organizations which have a trusted
relationship with the current one. Public access grants access to the software channel to all Red
Hat Network organizations hosted by the Satellite Server.
A good security practice is to have RPMS provided by all software channels digitally signed with
GPG. All of the RPMS from Red Hat are signed and in a similar manner RPMS provided by a
custom channel should be signed as well. The Details tab of each custom channel has fields for
GPG information which include the URL where an ASCII armored version of the public key can be
found, the eight-digit hexadecimal GPG key ID, and the hexadecimal GPG fingerprint.
Once the channel is created, select the Managers tab to assign management privileges to other
RHN users within the organization. Users who aren't Channel Administrators can import RPMS,
add and remove packages from a channel, and change a channel's details, but they cannot create
or delete channels.

RH401-6-en-1-20110713

83

Chapter6.Red Hat Network Software Management

Preparing RPMs for Red Hat Network


RPM packages are normally digitally signed so that users can verify that a package actually came
from the preparer it claims to belong to. This helps to block forged packages from being installed
if a yum repository is compromised in some way. The next few steps detail how to create your
own signing key.
To create a custom channel, you must take some preliminary steps:
1.

Generate a GPG key for the user account who manages RPMS and will load them into the
Satellite Server.

Note
You must have a graphical session open to run gpg --gen-key. It uses a graphical box
to accept your input for the passphrase.

[user@host ~]$ gpg --gen-key


gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? Enter
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) Enter
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) Enter
Key does not expire at all
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: My Name
Email address: user@host.example.com
Comment: Enter
You selected this USER-ID:
"My Name <user@host.example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
Enter passphrase
Passphrase: testing123

84

RH401-6-en-1-20110713

Preparing RPMs for Red Hat Network

Please re-enter this passphrase.


Passphrase: testing123
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: /home/student/.gnupg/trustdb.gpg: trustdb created
gpg: key 54AF5285 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
pub
2048R/54AF5285 2010-12-09
Key fingerprint = 315F E90B 1745 2288 EBAE 4E7B 4BC6 4568 54AF 5285
uid
My Name <user@host.example.com>
sub
2048R/D08B2951 2010-12-09

2.

Find the public key ID from the output of gpg --gen-key, or run gpg --fingerprint
then export the public key into an ASCII armored file.
[user@host ~]$ gpg --fingerprint
/home/user/.gnupg/pubring.gpg
-------------------------------pub 2048R/54AF5285 2010-12-09
Key fingerprint = 315F E90B 1745 2288 EBAE 4E7B 4BC6 4568 54AF 5285
uid
My Name <user@host.example.com>
sub
2048R/D08B2951 2010-12-09

The public key ID is the string of eight hexadecimal characters after pub 2048R/
(54AF5285 in the example above).
[user@host ~]$ gpg --export --armor 54AF5285 > /tmp/MYORG-GPG-KEY

As root, publish the public key from the RHN Satellite web server so the RHN clients can
access it.
[root@host ~]# cp /tmp/MYORG-GPG-KEY /var/www/html/pub/

3.

Create or modify ~/.rpmmacros so that %_gpg_name is set to the GPG key ID of the key
that was previously created. For example:
[user@host ~]$ echo '%_gpg_name 54AF5285' >> ~/.rpmmacros

4. Resign the packages that will be imported into the custom channel using this new GPG key.
[user@host ~]$ rpm --resign rpm_file_names.rpm

It is a best practice to use a non-root account for RPM creation and package signing.

RH401-6-en-1-20110713

85

Chapter6.Red Hat Network Software Management

References
Red Hat Network Satellite Channel Management Guide
Chapter 4: Custom Channel and Package Management

86

RH401-6-en-1-20110713

Preparing RPMs for Red Hat Network

Practice Exercise

Custom Software Channel Administration


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Create Linux and RHN Satellite accounts for the responsible person who is in charge of managing
custom channel content. Create a GPG key for signing trusted third-party packages. Once the
pieces are in place, create a custom software channel for Example, Inc. third-party software
packages.
1.

Create Linux and RHN Satellite accounts on desktopX.example.com for Charles


Channelman, the person responsible for managing software channels on the Satellite Server.
The login/user name for his accounts should be channelman with passwords of redhat.
His Red Hat Network account on the Satellite Server should permit him to manage software
channels and the systems in the example servers system group.

2.

Log into a shell account on desktopX as channelman and create a GPG key. The key
should be a 2048-bit RSA key used for signing packages only. It shouldn't expire and
should be protected with a passphrase of redhat. The owner of the key should be Charles
Channelman <channelman@desktopX.example.com>.
Export an ASCII-armored version of the public key and copy it to /var/www/html/pub/
EXAMPLE-GPG-KEY.
What is the GPG key id and fingerprint of the key you just created?

3.

Create a custom child software channel named Example custom with a label of examplecustom and configure it to advertise Charles Channelman's GPG key for verifying package
signatures. It should be a child channel of the Red Hat Enterprise Linux Server
(v.6 for 64-bit x86_64) base software channel.

RH401-6-en-1-20110713

87

Chapter6.Red Hat Network Software Management

Loading RPMS into RHN Satellite


The satellite-sync and rhnpush commands import RPMS into a Red Hat Network Satellite
Server. satellite-sync loads multiple RPMS, SRPMS, channel metadata, and kickstart trees
into the server. This command is typically used with Red Hat content. The rhnpush command is
used to import individual RPMS and SRPMS. This command is used with custom packages/thirdparty software.
Both of these tools are used from the command-line so shell access is required. The Red Hat
Network web interface does not provide a way to import software into a Satellite Server or RHN
Proxy.

Using satellite-sync
Software channel content can be transferred and loaded from Red Hat's servers via the Internet.
This is the default behavior of the satellite-sync utility. Without special options, it interacts
with the local Satellite Server and Red Hat's hosted RHN servers to try to keep the local Satellite
server in sync.
Channel content ISOs can be downloaded from Red Hat Network. Each ISO in a set is mounted
and its contents are copied into a temporary directory. satellite-sync is used with the -m
option to load the extracted content into the Satellite Server. The content is deleted from the
temporary directory as it is imported into the Satellite Server.
Using the above two methods to import channel content into a RHN Satellite Server was
discussed in more detail earlier in this course in the Installation unit. A third method to get
channel content is from a channel dump created from another Satellite Server using the rhnsatellite-exporter command. Creating channel dumps will be covered later in this course,
but importing channel dump content into a RHN Satellite Server is the same as importing
content extracted from ISOs, the satellite-sync command is used with the -m option to point
to the channel dump content. This is what you did earlier in the course when you installed your
Satellite Server and imported channel content.
The satellite-sync command is used from the command line on the Satellite Server. It
doesn't require Red Hat Network authentication, but it does require root access on the Satellite
Server to work.

Warning
satellite-sync removes packages from the channel content it is importing to help
conserve disk space. If the channel content will be reused for other Satellite servers or will
be kept as a backup, then the media it is stored on should be mounted read-only.

Other useful options to satellite-sync include -l which lists the available channels, and -c
channel-to-sync which specifies the channel name to sync.

Using rhnpush
The rhnpush command is used to import individual binary and source RPMS into a Satellite
Server. It is a command-line utility that doesn't require root privileges and it doesn't have to

88

RH401-6-en-1-20110713

Using rhnpush

be executed from the RHN Satellite Server. The rhnpush RPM provides this utility and can be
installed on any system that is subscribed to the Red Hat Network Tools software channel.
When a channel is specified, the RPM is imported into that channel and its corresponding
organization. An RPM can be imported into multiple channels when multiple -c options are
specified. When the channel is omitted, the RPM is loaded into the No Channels section of the
organization specified with the -o option.
The default configuration file for rhnpush is located at /etc/sysconfig/rhn/rhnpushrc.
It can be copied to ~/.rhnpushrc and modified with preferred settings for a particular user/
RPM administrator. Command-line options override any of the values specified in these files. The
following are a couple useful directives:
server
username

= https://satellite.fqdn/APP
= RHN-login

The rhnpush command imports RPM content into RHN Satellite Servers. There is another tool
that imports content into RHN Proxy Servers, but that utility will be introduced in a later unit.
Option

Function

--server=https://hostname/APP

push packages into the RHN Satellite server


specified

-l

list the specified channels

-c channel-label

channel to list or import packages into

-o org-ID

associate a package with an organization


(when -c is not specified)

--source

indicates the package being pushed is a


source RPM

Table6.1.Useful rhnpush Options


To use the rhnpush command, you must authenticate as one of the following:
System Group User with channel management privileges
Channel Administrator
Satellite or Organization Administrator

References
Red Hat Network Satellite Deployment Guide
Section 2.5: RPM Building
Red Hat Network Satellite Channel Management Guide
Chapter 3: Building Custom Packages
Section 6.2: Uploading Packages to RHN Satellite Server
rhnpush(8) and satellite-sync(8) man pages

RH401-6-en-1-20110713

89

Chapter6.Red Hat Network Software Management

Practice Exercise

Loading Red Hat Content into RHN Satellite


Carefully perform the following steps. Ask your instructor if you have problems or questions.
All Red Hat base software channels have a child channel called Red Hat Network Tools. This
channel provides useful packages for machines that are clients of a RHN Satellite Server.

90

Log in as root on desktopX. In root's home directory you will find a subdirectory called
sat-rhel6-content. Examine its contents and import the channel that provides the Red
Hat Network Tools which pertain to the base channel content you already loaded in your
Satellite Server.

RH401-6-en-1-20110713

Using rhnpush

Practice Performance Checklist

Loading Third-party Content into RHN Satellite


As channelman, take a third-party RPM provided by the instructor, sign it, and import it into the
RHN Satellite Server and associate it with the example-custom software channel.
Log in as Charles Channelman, channelman, on desktopX.example.com.
Copy the example-1.0-1.noarch.rpm RPM from /misc/instructor/RPMS to
Charles' home directory, and sign it with his GPG key.
Import the RPM into the Satellite Server so it is associated with the example-custom
software channel.

RH401-6-en-1-20110713

91

Chapter6.Red Hat Network Software Management

Using a Custom Channel


Once created and populated, the channel can then be associated with particular systems.
Subscribe client systems to the channel. The yum list available command can be used to
confirm the client is subscribed to the custom channel. For example, the following command will
confirm whether a client is subscribed to a custom channel with a channel label of exampleextras:
[root@host ~]# yum list available | grep example-extras

Once the channel subscription is verified, use yum to install packages on particular systems or
schedule the installation of the software using the Satellite Server's web interface.
Log into RHN Satellite Server web interface as
System Group User who can manage the target system, or
Organization Administrator
Navigate to the Alter Channel Subscriptions link
Select the Systems tab
Choose the Systems link in the navigation bar to the left
Select the target host's link by its profile name
Click the Alter Channel Subscriptions link
Check desired channels, click Change Subscriptions
Use yum to list available software from this channel

References
Red Hat Network Satellite Channel Management Guide
Section 2.2: Subscribing to Channels

92

RH401-6-en-1-20110713

Using rhnpush

Practice Performance Checklist

Subscribing to a Custom Channel


Associate your client system, desktopY.example.com, with your custom software channel and
install the example RPM on the client host.
Subscribe your client system to the example-custom custom software channel.
Import the GPG key used to sign the packages provided by the custom channel into the
RPM database on the client system. Install the example RPM on the client machine using
the yum command.

RH401-6-en-1-20110713

93

Chapter6.Red Hat Network Software Management

Software Management Using Cloned Channels


Cloning Channels
Cloning software channels is another way to create custom software channels. Typically, cloning
is used to create a custom software channel populated with packages from Red Hat rather than
third party software or custom RPMS.
Cloned channels can be customized to fit the administrator's needs. For example, unneeded
RPMS can be deleted from the list of available packages. Note this only affects the clone, not the
original channel from Red Hat. If a mistake is made, RPMS can easily be added back to the clone.
Also specific versions of packages can be merged into a cloned channel. In other words, both the
width and the depth of a cloned channel can be customized with respect to the packages that are
offered.
Cloned channels do not provide kickstart installation trees. Installations can use standard Red
Hat channels for builds then subscribe to cloned channels for more controlled RPM releases.
Cloning provides complete control over release of packages. Updates from Red Hat can be
merged back by Channel Admins. Although this requires more work to set up initially, you have
complete control over package releases.

Software Management Life Cycle


The primary goal of the software management life cycle is to control which packages and
updates are available for installation on the client systems. Cloned software channels allow
system administrators to publish a subset of packages originally from a Red Hat channel. Also
errata can be cloned and published after they have been thoroughly tested.
One possible use of cloned channels involves three types of systems: development, QA, and
production. Development machines use packages directly from Red Hat. Programmers and
prototype systems have the latest and greatest releases of packages available to them. Once
a solution has been built, specific versions of RPMS can be merged with the QA channels for
testing purposes and software validation. Once QA verifies the soundness of the updates, they
are merged into the production channels.
A variation on the above scheme uses a cloned channel for development purposes instead
of using pristine Red Hat channels. This provides an additional level of control over software
deployed to development machines.
Software channel cloning controls which packages are made available to the client systems, but
how the packages are deployed is another consideration. RHN client machines can be configured
to automatically install errata so there is no manual effort required to propagate updates. This
could be accomplished by periodically invoking yum -y update from a cron job. Other Red Hat
Network users prefer to install available errata manually during a scheduled downtime.

Creating a Cloned Channel


To clone a software channel, log into RHN Satellite Server web interface as a Channel
Administrator or an Organization Administrator. Select the Channels tab, Manage Software
Channels from the menu at the left, then click the clone channel link. Use the pull-down menu
to choose the original channel to clone from then pick which errata to include. A channel can be
cloned from its original state, its current state, or specific errata can be selected to be included

94

RH401-6-en-1-20110713

Updating a Custom Channel RPM

in the clone. Once the basis for the clone has been determined, the remaining screens are similar
to those that appear when a custom software channel is created - a channel name and summary
are chosen and user and organization access are assigned.
Cloning a base software channel does not clone its child channels automatically. Each of the
software channels in related family of channels must be cloned individually.

Updating a Custom Channel RPM


Packages that belong to custom channels will eventually need to be updated. Build the updated
RPM in the usual way, being sure to increment the version or release. Then you use rhnpush to
import the new package into the Satellite Server. The Satellite Server will recognize it as a more
recent version of the package and will automatically make it available to systems subscribed
to the software channel which contains the update. If the custom channel has been cloned, the
update will not propagate automatically - it must be merged with the cloned channels.
Once the new package is ready for distribution, an errata notification can be published to send an
e-mail making system administrators aware of the update. This step isn't required, but it is a best
practice to group related packages that fix a related problem together with an errata.

References
Red Hat Network Satellite Channel Management Guide
Section 4.7: Cloning Software Channels

RH401-6-en-1-20110713

95

Chapter6.Red Hat Network Software Management

Practice Performance Checklist

Managing Updates with Cloned Channels


Create clones of standard Red Hat channels and custom channels to control how software
updates are rolled out to client systems.
Create clones of standard Red Hat software channels (both base and child channels)
and the custom software channel in your Satellite Server. These channels will be
Production versions of their original counterparts so assign them labels identical to
the original channels with a prod- prefix. Use the default values provided for the access
controls of the cloned channels.
Change the subscriptions of your client machine, desktopY, so it subscribes to the new
cloned channels. Include production versions of the base channel and the Example
custom child channel.
Remove, then reinstall, the example RPM and confirm it comes from one of the cloned
channels just created.

96

RH401-6-en-1-20110713

Managing Software Updates

Managing Software Updates


All errata management is handled by Organization Administrators and/or Channel Administrators
since it is a software management function. Selecting the Errata tab will bring up a menu to
the left that includes Manage Errata and Clone Errata links. This is where errata management
occurs.
When creating an erratum, an advisory field needs to be specified. Note that customer generated
advisories cannot begin with the letters RH. These are reserved for Red Hat generated advisories.
Cloned errata derive their advisory names from the original and replace the RH* prefix with CLA,
which stands for CLoned Advisory. Also the severity of the erratum need to be selected, whether
for a software enhancement, a bug fix, or a security related issue.
Once an erratum is created and packages are assigned to it, the final step is to publish the
erratum. Optionally an e-mail notification can be sent to the administrators of relevant systems.
It usually takes a few minutes for published errata to become available to client systems. This
delay allows for all pieces of each erratum to be in place before client systems try to access
them.
Errata can be cloned, but it is restricted to channels cloned from the channel of the original
errata.
Best practice: Always clone errata instead of the updated RPMS individually. This approach to
cloning updates preserves errata data.

References
Red Hat Network Satellite Channel Management Guide
Chapter 5: Custom Errata Management

RH401-6-en-1-20110713

97

Chapter6.Red Hat Network Software Management

Practice Exercise

Update Notifications with RHN Errata


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Sign and import a newer (fixed) RPM into the Satellite Server. Create an errata to notify client
system administrators that a fix has been published. Observe its impact on the client systems.
1.

Log in as Charles Channelman, channelman, on desktopX.example.com. Copy the


improved RPM, example-1.0-2.noarch.rpm, from /misc/instructor/RPMS to
Charles' home directory and sign it with his GPG key. Import the new RPM into the Satellite
Server so it is associated with the example-custom software channel.

2.

Create and publish an errata notification that announces the availability of the
example-1.0-2.noarch.rpm package. The errata synopsis should read, example - file
ownerships fixed. Advisory EXBA2010:0001 release 1 is a bug fix advisory.

3.

Browse the Satellite Server's web UI and verify that the Errata is published. Notice that the
client system is not impacted because we changed its software channel subscriptions to the
Production channels.

4.

Clone the errata and make it available to the prod-example-custom channel. Log into
the client system, desktopY, as root and confirm the new RPM is available for installation.
Note: The update may take up to 10 minutes to become available for installation because
the default yum settings cause metadata to expire after 10 minutes. Use yum clean all to
clear the caches and verify you can view the update.

98

RH401-6-en-1-20110713

Managing Software Updates

Personal Notes

RH401-6-en-1-20110713

99

Chapter6.Red Hat Network Software Management

Unit Summary
Software Channels
In this section you learned how to:
Describe the base/child relationship between software channels
.
Custom Software Channels
In this section you learned how to:
Create and manage custom software channels
.
Loading RPMS into RHN Satellite
In this section you learned how to:
Use satellite-sync to import Red Hat channel content
Use rhnpush to import custom channel content
.
Using a Custom Channel
In this section you learned how to:
Subscribe a client to a custom software channel
.
Software Management Using Cloned Channels
In this section you learned how to:
Create and manage cloned software channels
.
Managing Software Updates
In this section you learned how to:
Create, clone, and manage errata
.

100

RH401-6-en-1-20110713

Chapter7.

UNIT SEVEN

BUILDING RPMS
Introduction
Topics covered in this unit:
rpm-build package
~/rpmbuild directory structure
Syntax of SPEC file
rpmbuild command

RH401-6-en-1-20110713

101

Chapter7.Building RPMs

RPM Package Design/Architecture


Managing software in the form of RPM packages is much simpler than working with software
which has simply been extracted into a file system from an archive. It lets you track which files
were installed by the software package, which ones need to be removed if it is uninstalled, and
check to ensure supporting packages are present when it is installed. Therefore, it is useful to
know how to create RPM packages for your own software. For the remainder of this unit, we will
look at how to create a basic RPM package and point you to resources which will help you learn
how to create more complex packages as your skills grow.

Design and Structure of an RPM


Each RPM package is made up of three basic components:
metadata - Data about the package: the package name, version, release, builder, date,
dependencies, etc.
files - archive of files provided by the package (including file attributes)
scripts - these execute when the package is installed, updated, and/or removed
When building an RPM package, the metadata about the package needs to be specified, the
files in the archive need to be provided, and the scripts that should be run when the package is
installed or uninstalled need to be embedded.

Note
Internally, files are stored as a cpio archive inside the package file. The rpm2cpio
command can be used to extract them to the current working directory without installing the
package:
rpm2cpio package-1.2.3-4.el6.x86_64.rpm | cpio -id

The Midnight Commander (mc) text tool or the Archive Manager (file-roller) GUI tool
can be used to browse through an RPM package.

The following rpm queries are useful for investigating the structure of an RPM package:
rpm -qd - list documentation files (%doc)
rpm -qc - list configuration files (%config)
rpm -q --scripts - list %pre, %post, %preun, and %postun scripts
To construct an RPM package, you will need a build specification file or spec file. A spec file is
simply a text file that contains information on how to build the installable RPM package. You can
think of it as being roughly divided into five parts:
The introduction or preamble, listing metadata about the package (name, version, license, etc.)
The build instructions, which specify how to compile and prepare the software

102

RH401-6-en-1-20110713

Design and Structure of an RPM

The scriptlets, which specify commands to run on install, uninstall, or upgrade


The manifest, a list of files to package and their permissions on package installation
The changelog, which tracks changes made to this RPM package

References
Red Hat Enterprise Linux Deployment Guide, Section 3.2.6: Querying RPM
rpm(8), rpm2cpio(8), and cpio(1) man pages

RH401-6-en-1-20110713

103

Chapter7.Building RPMs

Spec File Directives and Sections


Important Preamble Directives
Name - The name of the package, usually chosen by the developers. For detailed guidance, look
at the Fedora Naming Guidelines, at http://fedoraproject.org/wiki/Packaging:NamingGuidelines
Version - The version of the package (usually numeric), usually chosen by the developers.
Release - The release of the package, chosen by the packager. This should increase each time
you release a new package for distribution if you still use the same Version of the software.
Group - The group to which the package belongs. See /usr/share/doc/rpm-*/GROUPS for
the default set of groups, or use one of your own. This field is semi-obsolete and is not related
to yum package groups.
URL - The web page of the open source software
License - The Short License identifier of the license used for the software. Detailed
guidance on how to set this in a standard way can be found at http://fedoraproject.org/wiki/
Packaging/LicensingGuidelines
Summary - A short one-line description of the software. (Keep to about 50 characters or less.)
Source - The file to be used as the source code. If there are more than one file used as source,
add a number. E.g., Source0, Source1, Source2, etc.
BuildArch - The architecture to use when building the package. Defaults to the system
architecture. A common argument is noarch, which means that the package is architecture
independent (often these packages consist of scripts or data files).
Requires - A list of explicit requirements this package depends on. This could be a list of files
or other packages. rpmbuild can generally autodetect most library dependencies, but there
are some cases where you may need to list an explicit dependency. See http://fedoraproject.org/
wiki/Packaging/Guidelines#Requires for additional guidance on Requires.
BuildRequires - A list of requirements that are needed to build this package. This is a list
with similar syntax to that of Requires, for example BuildRequires: /usr/bin/gcc,
gimp-libs >= 2.6.11. See the link in Requires above for information on how to tell if you
need missing BuildRequires.

Spec File Sections


%description section - A long description of the software. No line should be more than 80
characters long, but you may have multiple lines.
%prep section - Uncompress and unarchive files in the BUILD directory. Prepare for the build
phase.
%build section - Build the software (optional). Compile the software if needed.

104

RH401-6-en-1-20110713

Spec File Sections

%install section - Install the files in the correct location. The make command usually
uses the DESTDIR=$RPM_BUILD_ROOT. If you copy or install files, the destination is
usually prepended with $RPM_BUILD_ROOT so the software will be placed in the chroot'ed
environment in preparation for packaging.
%clean section - Post build cleanup. This section usually includes: rm -rf
$RPM_BUILD_ROOT to clean the chroot environment.
%files section - All files should be included here. You may mark files as %config or %doc
which are presented with rpm -qc and rpm -qd, respectively.
%changelog section - A log of changes made to the software. Include the bug tracking
numbers if used. This information can be displayed with rpm -q --changelog.

References
Fedora RPM Guide http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
Fedora Packaging Guidelines http://fedoraproject.org/wiki/Packaging:Guidelines

RH401-6-en-1-20110713

105

Chapter7.Building RPMs

Practice Quiz

RPM Spec File


1.

The package
is usually derived from the
open source project while the package
is the
packager's version.

2.

The name of the tarball containing the files used to build


the package is specified with the
directive.

3.

The
directive specifies the target architecture the
package is being built for.
will be its value when
the package can be installed on any architecture.

4.

The
directive specifies the one-line description
of a package while the
section provides a more
thorough explanation of what that package is for.

5.

The
in the

6.

The
section defines which files and directories to
package into the RPM.

7.

The
,
,
and
sections
contain shell code used to assemble a package and clean
up after it has been built.

106

section contains the code used to place files


chroot directory structure.

RH401-6-en-1-20110713

Creating a Spec File

Creating a Spec File


On Red Hat Enterprise Linux 6, vim has a macro that helps to create a specification file. Simply
pass a file name that ends in .spec:
[user@host ~]$ vim sample.spec

The Red Hat Enterprise Linux 6 version of vim will use the spec template to provide some
common entries for RPM building.

Note
When an RPM package is built, a source RPM (SRPM) package is also created, with an
architecture of src. Another way to get a spec file is to install a source package by running
rpm -ivh package-1.2.3-4.src.rpm as a non-root user. The spec file for the package
will be in ~/rpmbuild/SPECS.

Example Spec File


An annotated example of a spec file follows.
%define
%define
%define
%define
%define
%define

debug_package %{nil}
product_family Red Hat Enterprise Linux
release_name Santiago
base_release_version 6
full_release_version 6.0
beta Beta

Name:

redhat-release

Version:

%{base_release_version}

Release:

6.0.0.24%{?dist}

Summary:
Group:
License:

%{product_family} release file


System Environment/Base
GPLv2

Obsoletes:

rawhide-release redhat-release-as redhat-release-es redhat-release-ws

Source0:

redhat-release-6-4.tar.gz

%description
%{product_family} release files
%prep
%setup -q
%build
echo OK
%install
rm -rf $RPM_BUILD_ROOT

RH401-6-en-1-20110713

107

Chapter7.Building RPMs

# create /etc
mkdir -p $RPM_BUILD_ROOT/etc
# create /etc/system-release and /etc/redhat/release
echo "%{product_family} release %{full_release_version}%{?beta: %{beta}}
(%{release_name})" > $RPM_BUILD_ROOT/etc/redhat-release
ln -s redhat-release $RPM_BUILD_ROOT/etc/system-release
# write cpe to /etc/system/release-cpe
echo "cpe:/o:redhat:enterprise_linux:%{version}:%{?beta:%{beta}}%{!?beta:GA}" >
$RPM_BUILD_ROOT/etc/system-release-cpe
# create /etc/issue and /etc/issue.net
cp $RPM_BUILD_ROOT/etc/redhat-release $RPM_BUILD_ROOT/etc/issue
echo "Kernel \r on an \m" >> $RPM_BUILD_ROOT/etc/issue
cp $RPM_BUILD_ROOT/etc/issue $RPM_BUILD_ROOT/etc/issue.net
echo >> $RPM_BUILD_ROOT/etc/issue
# copy yum repos to /etc/yum.repos.d
mkdir -p $RPM_BUILD_ROOT/etc/yum.repos.d
for file in *.repo; do
install -m 644 $file $RPM_BUILD_ROOT/etc/yum.repos.d
done
# copy GPG keys
mkdir -p -m 755 $RPM_BUILD_ROOT/etc/pki/rpm-gpg
for file in RPM-GPG-KEY* ; do
install -m 644 $file $RPM_BUILD_ROOT/etc/pki/rpm-gpg
done
# set up the dist tag macros
install -d -m 755 $RPM_BUILD_ROOT/etc/rpm
cat >> $RPM_BUILD_ROOT/etc/rpm/macros.dist << EOF
# dist macros.
%%rhel %{base_release_version}
%%dist .el%{base_release_version}
%%el%{base_release_version} 1
EOF
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%doc EULA GPL autorun-template
%attr(0644,root,root) /etc/redhat-release
/etc/system-release
%config %attr(0644,root,root) /etc/system-release-cpe
%config(noreplace) %attr(0644,root,root) /etc/issue
%config(noreplace) %attr(0644,root,root) /etc/issue.net
%config %attr(0644,root,root) /etc/yum.repos.d/*
%dir /etc/pki/rpm-gpg
/etc/pki/rpm-gpg/*
/etc/rpm/macros.dist
%changelog
* Mon Mar 29 2010 Dennis Gregorovic <dgregor@redhat.com> - 6-6.0.0.24
- Add beta debuginfo repos
- Resolves: rhbz#572308

108

RH401-6-en-1-20110713

Example Spec File

Macros (like variables) that can be used in the spec file


The name of the package
The version of the package. Notice it uses the %{base_release_version} macro
defined above.
The release of the package
A short summary
A list of package names that this package makes obsolete. If you had one of these packages
installed on your machine, an update of this package would remove that package.
A source file
A long description
The %prep section. Unfortunately, the RPM spec file uses % for sections as well as macros.
%prep is a section, %setup is a macro.
The %build section
The %install section. $RPM_BUILD_ROOT is a variable that expands to the build root.
Files are copied from the build directory to $RPM_BUILD_ROOT, as if $RPM_BUILD_ROOT
was / on the file system the software will be installed in. Then the contents of
$RPM_BUILD_ROOT listed in %files will be packaged into the final RPM file. You must
create all necessary directories in $RPM_BUILD_ROOT before copying files to that
location. Source files can be referenced using a relative path from the top-level %{name}%{version} source directory. For example, if you wanted to have a file placed in /
root/bin/ (found in the %{name}-%{version}/bin directory) , you would need to do
something like the following:
mkdir -p $RPM_BUILD_ROOT/root/bin
cp bin/my-script $RPM_BUILD_ROOT/root/bin

The %clean section. Normally clean only has the rm command above.
The list of files to be included in this package. Note that %defattr sets the default
permissions the files will have, %attr can override that on a file-by-file basis.
%config and %doc mark configuration files and documentation respectively.
%dir marks a directory owned by the package. See http://fedoraproject.org/wiki/
Packaging:Guidelines#File_and_Directory_Ownership and http://fedoraproject.org/wiki/
Packaging:Guidelines#Configuration_files for more information.
The %changelog section is for the packager to list items that changed in this release.
Newest entries to the changelog go at the start of the section. Each entry has the format
seen in the example and entries are separated by a blank line.
The example above does not use any scriptlets. For more information on scriptlets, see the draft
Fedora RPM Guide referenced below.

RH401-6-en-1-20110713

109

Chapter7.Building RPMs

References
Fedora RPM Guide http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
Fedora Packaging Guidelines http://fedoraproject.org/wiki/Packaging:Guidelines

110

RH401-6-en-1-20110713

Software Build Process

Software Build Process


The five steps for building an RPM package:
1. Tarball
Get the tar file containing the source. By default rpmbuild assumes the top-level directory
of the archive is named %{name}-%{version}. Place this file in the ~/rpmbuild/
SOURCES/ directory.
2.

Spec file
Create a spec file and populate the required fields. Place this file in the ~/rpmbuild/
SPECS/ directory.

3.

rpmbuild
Use the rpmbuild command to build the package(s). For example,
[user@host BUILD]$ rpmbuild -ba ../SPECS/demo.spec

4. Sign
Use a GPG key to sign the RPM package. After you build the package, use rpm --resign
demo-1.0-1.x86_64.rpm to add (or change) a GPG signature.
5.

Test
Test the package by installing it on a development system to ensure the correct payload,
scripts, etc.

Example RPM Package Build


The following shows an example of building an RPM package. The name of the package is test,
version is 1.0 and release is 1. It will provide a single file, /usr/local/bin/myscript, which
simply runs the date command.
First, create a non-root user called student on your RHEL 6 workstation, desktopY. You will use
this account to safely build your RPM packages.
[root@desktopY ~]# useradd student
[root@desktopY ~]# passwd student

Log in as student and create the source directory, file and tarball:
[student@desktopY ~]$ mkdir test-1.0
[student@desktopY ~]$ cat << EOF > test-1.0/myscript
#!/bin/bash
date
EOF
[student@desktopY ~]$ tar czvf test-1.0.tar.gz test-1.0

Create a spec file using vim in your home directory:

RH401-6-en-1-20110713

111

Chapter7.Building RPMs

[student@desktopY ~]$ vim test.spec

Note
In Red Hat Enterprise Linux 6, vim will automatically create a template spec file when you
open a new file with a name that ends in .spec.

Fill in the fields as follows.


Name:
Version:
Release:
Summary:

test
1.0
1%{?dist}
A test package

Group:
License:
URL:

Testing
GPL
http://www.example.com/testing

Source0:
BuildRoot:

%{name}-%{version}.tar.gz
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)

BuildArch: noarch
BuildRequires:
Requires:

/bin/rm, /bin/mkdir, /bin/cp


/bin/bash, /bin/date

%description
A testing package meant to deploy a single file.
%prep
%setup -q
%build
#configure
#make %{?_smp_mflags}

%install
rm -rf $RPM_BUILD_ROOT
#make install DESTDIR=$RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
cp myscript $RPM_BUILD_ROOT/usr/local/bin
%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root,-)
#%doc
%attr(0755,root,root)/usr/local/bin/myscript
%changelog
* Thu Dec 09 2010 Forrest <forrest@redhat.com> 1.0-1
- Initial RPM

112

RH401-6-en-1-20110713

Example RPM Package Build

- Added /usr/local/bin/myscript

The %{name} and %{version} macros are defined from the Name: and Version: lines
above. Alternately, you could have used test-1.0.tar.gz.
Since the RPM contains only a shell script which will work on all architectures, specify the
BuildArch as noarch.
rm, mkdir and cp all come from the coreutils package, so you could have specified that
package instead of the commands. These are the commands that are used in the %install
section.
There are some macros that run even if they are commented, and %configure is one of
them. If you comment %configure like: #%configure, it will complain about not finding
./configure. Remove the %configure line entirely or remove the % from configure.
The %attr was added to force the permission to 0755. Notice that the %defattr has a in the permissions place. This means that the files will get the same permissions that they
have inside the tarball. An alternate means to produce the same result would be to run
chmod 755 test-1.0/myscript and rebuild the tarball.
Install the rpm-build package as root:
[root@desktopY ~]# yum install -y rpm-build

Run rpmbuild as student. The first time you run it, you will get an error. You will fix the error
shortly. Running the rpmbuild command will create the directory structure needed to build the
RPM package.
[student@desktopY ~]$ rpmbuild test.spec
error: File /home/student/rpmbuild/SOURCES/test-1.0.tar.gz: No such file or directory

Note
In Red Hat Enterprise Linux 6, running rpmbuild against a spec file automatically creates
your ~/rpmbuild build environment.

Warning
You should always run rpmbuild to build packages as a non-root user. Do not build packages
as root. The reason for this is that mistakes in the spec file, especially in the %install and
%clean sections, are more likely to damage your build machine's installation if run as root.

Copy the files to the correct location:


[student@desktopY ~]$ cp test-1.0.tar.gz rpmbuild/SOURCES/
[student@desktopY ~]$ cp test.spec rpmbuild/SPECS/
[student@desktopY ~]$ cd rpmbuild/SPECS/

RH401-6-en-1-20110713

113

Chapter7.Building RPMs

Build and sign the package:


[student@desktopY ~]$ rpmbuild -ba test.spec
[student@desktopY ~]$ rpm --resign ~/rpmbuild/RPMS/x86_64/test-1.0-1.el6.x86_64.rpm
Enter pass phrase: testing123
Pass phrase is good.
...

Look for errors in the output of rpmbuild and fix any issues you find. If there are no errors, you
should find:
...
Wrote: /home/student/rpmbuild/SRPMS/test-1.0-1.el6.src.rpm
Wrote: /home/student/rpmbuild/RPMS/x86_64/test-1.0-1.el6.x86_64.rpm
...

Test the package by installing the key, installing the package and running the command:
[root@desktopY ~]# rpm --import /home/student/RPM-GPG-KEY-student
[root@desktopY ~]# cd /home/student/rpmbuild/RPMS/x86_64
[root@desktopY ~]# yum localinstall test-1.0-1.el6.x86_64.rpm
[student@desktopY ~]$ /usr/local/bin/myscript
Thu Dec 09 10:21:53 EST 2010

Note
When reviewing a completed package for release, you may find the formal Fedora Package
Review Guidelines (in the References below) to be useful.

References
Fedora RPM Guide http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
Fedora Packaging Guidelines http://fedoraproject.org/wiki/Packaging:Guidelines
Fedora Package Review Guidelines http://fedoraproject.org/wiki/Packaging:ReviewGuidelines
rpmbuild(8) man page

114

RH401-6-en-1-20110713

Criterion Test

Test

Criterion Test
Performance Checklist

Building an RPM Package


Before you begin...
If you haven't already done so, create a non-root user called student on your RHEL 6
workstation, desktopY. You will use this unprivileged account to build your RPM packages for
RHEL 6 systems.
In this exercise you will create an RPM for a package called hello. It should have version 1.0
with a release of 1 and it should be able to be installed on multiple architectures.
Log in as root on desktopY and create a student account with a password of student.
Login as student on desktopY and make a directory called hello-1.0. Download the file
ftp://instructor.example.com/pub/materials/hello.sh and save it in that directory.
Create a simple RPM that installs hello.sh in /usr/local/bin. Make sure hello.sh
is installed with a mode of 755 and is owned by root on machines it is installed on. Also
make sure the RPM can be installed on all architectures.
Copy the binary and source RPMs to channelman's account on desktopX so he can sign
the package and publish it via the Satellite server.
Log into desktopX as channelman and sign the hello binary and source RPMS. Import
both packages into the example-custom channel on your Satellite server.

RH401-6-en-1-20110713

115

Chapter7.Building RPMs

Personal Notes

116

RH401-6-en-1-20110713

Criterion Test

Unit Summary
RPM Package Design/Architecture
In this section you learned how to:
Use rpm to explore the structure of a package file
.
Spec File Directives and Sections
In this section you learned how to:
Include preamble directives in an RPM software package
.
Creating a Spec File
In this section you learned how to:
Include preamble directives in an RPM software package
.
Software Build Process
In this section you learned how to:
Use rpmbuild to build a new RPM package file
.

RH401-6-en-1-20110713

117

118

Chapter8.

UNIT EIGHT

CONFIGURATION FILE
MANAGEMENT WITH RHN
Introduction
Topics covered in this unit:
Red Hat Network configuration channel vs. software channel
Managing and populating configuration channels
Configure client systems for RHN configuration provisioning
rhncfg-client
rhncfg-manager
RHN configuration file macros

RH401-6-en-1-20110713

119

Chapter8.Configuration File Management with RHN

Configuration Channel Management


Red Hat Network Configuration Channels provide an easy way to deploy configuration files in an
enterprise environment. They were primarily designed to deliver text files to client systems, but
they also handle binary files.
Configuration channels deploy individual files using a web interface to provide content.
Permissions and user/group ownership can also be specified.
The configuration file processes performed on a Red Hat Network Satellite Server includes the
following steps:
Create configuration channel(s)
Create and manage configuration files
Schedule deployment of updated configuration files
A high-level view of the actions taken on a Red Hat Network client that receives configuration
files from RHN include:
Client system subscribes to configuration channel
Configuration files may be deployed at client registration
Scheduled config file updates deploy when the client checks in
Most configuration channel setup and management is accessed via the Configuration top-level
tab within the RHN web interface. There is a different Configuration tab that appears in the
system profile screen of systems that are subscribed to one or more configuration channels. It
exposes configuration file management functions that can be performed on each system.

Note
Configuration channels are a RHN provisioning feature; the clients must have a provisioning
add-on entitlement.

Configuration vs. Software Channels


It is important to know the similarities and differences between configuration channels and
software channels and what their purpose is. Configuration channels are designed to deploy
individual text and binary configuration files. Software channels are used for deploying
whole RPM packages. File ownerships and permissions have to be specified for each files in a
configuration channel. RPM packages have file ownership and permission metadata bundled
within the package. They also include shell code used to make adjustments to the system (such
as configure a service to start at boot time). Configuration channels don't have any sort of
scripting capability.
A single system can subscribe to multiple channels. Only a single Provisioning system
entitlement is required despite the number of subscribed channels. When multiple configuration
channels are involved, the highest ranking channels win when the same file is provided by two or

120

RH401-6-en-1-20110713

Managing Configuration Channels

more channels. Centrally-managed configuration files are files in a configuration channel that are
available to all of the systems that subscribe to that channel. Single systems can have custom
configuration files that apply only to them called locally-managed configuration files. When there
are conflicts, locally-managed configuration files will override and be installed over centrallymanaged files.
Systems with Provisioning entitlements can be subscribed to configuration channels using the
Red Hat Network web interface. This is done by selecting the Configuration tab within the system
profile screen (not the top-level Configuration tab). Select the Manage Configuration Channels
tab then click the Subscribe to Channels sub-tab to assign available configuration channels to
the system being viewed. Configuration channel subscription can also be accomplished using
activation keys.

Managing Configuration Channels


Configuration channel management functions are accessed within the Red Hat Network web
interface by selecting the top-level Configuration tab then selecting the Configuration Channels
menu item. A screen will appear listing the current configuration channels available within the
current organization and new channels can be created by clicking the create new config channel
link. The Configuration tab appears only for Organization and Configuration Administrators and
only when Provisioning system entitlements have been assigned to the organization.
When a new configuration channel is created, the channel name, a label, and a description must
be specified. The channel name is displayed when browsing content using the RHN web interface.
Command-line tools, which will be discussed later, use the channel label to specify configuration
channels.
Once the configuration channel has been created and its profile is displayed, click the Add Files
tab to assign files to the channel. Files can be uploaded from the local hard drive, they can be
imported from another configuration channel, or they can be created using a web-based form/
editor. When creating or uploading configuration files, the following attributes must be specified
for each file:
Absolute path where the file will be deployed on the target system
Whether the file is text or a binary file
User and group ownership
Numeric permissions
Which delimiter characters to use for macro expansion
The default maximum configuration file size is 128KB. It can be changed if necessary. For
example, to allow 1MB files and smaller to be managed by the Satellite Server, make the following
adjustments. Edit /etc/rhn/rhn.conf and add the following line:
web.maximum_config_file_size=1048576

Also edit /etc/rhn/default/rhn_server.conf and locate the


maximum_config_file_size setting and adjust it as follows:
maximum_config_file_size=1048576

RH401-6-en-1-20110713

121

Chapter8.Configuration File Management with RHN

Note that both values are specified in bytes and the RHN Satellite Server software must be
restarted to make the changes go into effect.

References
Red Hat Network Satellite Reference Guide
Section 7.7.3: Configuration Channels

122

RH401-6-en-1-20110713

Managing Configuration Channels

Practice Performance Checklist

Creating and Populating a Configuration Channel


Use your RHN Satellite Server to deploy configuration files. In this exercise you will create a
Configuration Administrator account, create a configuration channel, and populate it with a
custom configuration file for Example Inc.
Create a Configuration Administrator account for the Example Inc. organization on your
RHN Satellite Server. The account is for Ms. Janice Configurator and should have the
login of configurator with a password of redhat. RHN Satellite generated e-mail for
her should go to root@desktopX.example.com. Also she should be able to administer
systems in the example servers system group.
Log in to your RHN Satellite Server as configurator and create a configuration
channel called Example Configs with the label example-configs.
Add a configuration file to the example-configs configuration channel. The file
should provide a custom login banner for Example Inc. servers. The file to add to
the configuration channel should be /etc/issue. It should be have user and group
ownership of root in both cases and should have permissions of -r--r--r--. The file
contents should be:
*** Example Inc. ***
blank line

RH401-6-en-1-20110713

123

Chapter8.Configuration File Management with RHN

Client Configuration
When a client subscribes to Red Hat Network Tools channel, the rhncfg-actions package
is available (rhncfg and rhncfg-client are also installed as dependencies). The rhncfgactions package provides the rhn-actions-control command.
The rhn-actions-control command is used to display and control the actions that are
permitted to occur on the client system as a result of a command from a Red Hat Network server.
It can be used to:
Display current settings: rhn-actions-control --report
Enable an action: rhn-actions-control --enable-feature
Disable an action: rhn-actions-control --disable-feature
The table below lists the features controlled by rhn-actions-control:
Feature?

Permissions Granted

--enable-deploy

Allow rhncfg-client to deploy files.

--enable-diff

Allow rhncfg-client to diff files.

--enable-upload

Allow rhncfg-client to upload files.

--enable-mtime-upload

Allow rhncfg-client to upload mtime.

--enable-run

Allow rhncfg-client the ability to execute


remote scripts.

--enable-all

Allow rhncfg-client to do everything.

When a system is provisioned with a kickstart profile from Red Hat Network and configuration file
deployment is enabled, the client system is configured with the --enable-all capability. This
has obvious security implications.
The rhncfg-client utility runs on the client and does the actual work of RHN configuration
file administration on the local machine. The table below summarizes the various functions
performed by this utility:
Subcommand

Function

verify

Compare the local config files with the RHN


server's versions.

get [file-path]

Download the most current version of


the config files, overwriting any local
modifications.

list

List the config files provided by the RHN


server.

elist

Perform an extended (ls -l) listing of the


config files provided.

channels

List the config channels the client is


subscribed to.

124

RH401-6-en-1-20110713

Client Configuration

References
Red Hat Network Satellite Reference Guide
Section 7.7.1: Preparing Systems for Configuration Management
rhncfg-client(8) and rhn-actions-control(8) man pages

RH401-6-en-1-20110713

125

Chapter8.Configuration File Management with RHN

Practice Performance Checklist

Deploying Configuration Files to a RHN Client


Configure your client server so it will pull custom configuration file content from the
configuration channel you created on your RHN Satellite Server.
Entitle your client server, desktopY, to be able to install the tools necessary to provision
it from your Satellite Server.
Install all necessary RHN configuration client software on desktopY. Configure your
client system so it will permit configuration files to be deployed on it.
Modify the desktopY.example.com system profile so it subscribes to the exampleconfigs configuration channel. Execute commands on the client system so it downloads
the configuration files provided by example-configs. Verify the new /etc/issue file
successfully deploys.

126

RH401-6-en-1-20110713

Configuration File Management

Configuration File Management


rhncfg-manager is a command-line management tool used to manage Red Hat Network
configuration channel content (included in the rhncfg-management package). This command
can create, remove, and list configuration channels. It is also used to manage files within a
configuration channel, and works like Subversion.
The rhncfg-manager subcommand is always specified first, followed by any required options.
The following table lists the most frequently used rhncfg-manager subcommands:
File Subcommand

File Subcommand

list channel-name

diff file ...

add file ...

remove file ...

get file ...

update file ...

Channel Subcommand

Channel Subcommand

list-channels
download-channel -t tld ch-label

upload-channel ch-label

create-channel ch-label

remove-channel ch-label

Table8.1.rhncfg-manager Subcommands
Many rhncfg-manager commands require options. The most common options used include:
-c ch-label: config channel of interest
-t top-level-directory: this option is used most frequently with channel-related
commands
-d destination-path: used to specify the absolute path name of a file on the target system
--help: display context sensitive help
The channel-related subcommands create and use directories which act as chroot environments
for the files that are managed for the target system. The -t option specifies a top-level directory
where all channel content is stored. Subdirectories hang off of that directory with the channel
labels as their names.
Take care when using the create-channel subcommand. It expects the channel name and
the directory containing the files to be the same, so the original directory name will become the
channel label for the new channel. The channel label cannot be changed.
When root uses rhncfg-manager, the command communicates with the Red Hat Network
the system is registered as a client with. An unprivileged account can use this tool if a file called
~/.rhncfgrc is created with the following content:
[rhncfg-manager]
server_url = https://satellite.fqdn/CONFIG-MANAGEMENT-TOOL
sslCACert = /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
username = RHN_config_admin_login

RH401-6-en-1-20110713

127

Chapter8.Configuration File Management with RHN

References
rhncfg-manager(8) man page

128

RH401-6-en-1-20110713

Configuration File Management

Practice Performance Checklist

Command-line Configuration File Management


Red Hat provides tools that allow and administrator to manage configuration channel content
from the command-line. Use commands from the shell to update the configuration file content in
your RHN Satellite Server.
Install all necessary software on desktopY to perform configuration file management
from the command-line. Create a directory called ~/config-mgmt where configuration
files can be downloaded, modified, and uploaded back into the RHN Satellite Server.
Use the RHN command-line management tools to download the files for the exampleconfigs configuration channel below ~/config-mgmt. Modify the configuration
channel's /etc/issue file so it contains the following content:
*** Example Inc. ***
No trespassing allowed.
blank line

Use the command-line management tools to upload your change into your RHN Satellite
Server.
Pull configuration files from the Satellite Server down to desktopY. Verify the most
current version of /etc/issue has been deployed.

RH401-6-en-1-20110713

129

Chapter8.Configuration File Management with RHN

Flexible Configuration with Macros


Red Hat Network configuration file macros permit string substitutions to occur when
configuration files are deployed on a particular system. This helps with standardization since
a generic template can be used for multiple hosts instead of maintaining locally-managed
configuration files for each system. The default delimiters for macro references are {| and |},
but these can be changed for a particular config file if these strings are used literally in the
configuration file.
The following is a list of standard configuration file macros provided by Red Hat Network:
rhn.system.sid
rhn.system.profile_name
rhn.system.description
rhn.system.hostname
rhn.system.ip_address
rhn.system.net_interface.ip_address(eth_device)
rhn.system.net_interface.netmask(eth_device)
rhn.system.net_interface.broadcast(eth_device)
rhn.system.net_interface.hardware_address(eth_device)
rhn.system.net_interface.driver_module(eth_device)
Custom macros are created/referenced with the rhn.system.custom_info(key_name)
macro. How to define values and use custom macros will be discussed in more detail later.

Sample Configuration File


The following is a sample /etc/hosts file that uses RHN Configuration file macros:
# Do not remove the following 2 lines, or programs
# that require network functionality will fail.
127.0.0.1
localhost.localdomain localhost
::1
localhost6.localdomain6 localhost6
{| rhn.system.net_interface.ip_address(eth0) |} {| rhn.system.hostname |}
192.168.0.254
instructor.example.com instructor
# This system is located in the {| rhn.system.custom_info(rackcolor) |} rack

The above example demonstrates the use of standard built-in Red Hat Network configuration file
macros rhn.system.hostname and rhn.system.net_interface.ip_address. They are
enclosed in the default macro delimiters {| and |}. These macros will be expanded to the host
name and the IP address of the eth0 interface of the system on which this configuration file gets
deployed.

130

RH401-6-en-1-20110713

Sample Configuration File

The example is interesting because it also shows a macro that uses a custom key, in this
particular example a key called rackcolor. The parameter to the rhn.system.custom_info
macro is a custom key label. To create a custom configuration file key, select the Systems toplevel tab then choose the Custom System Info menu item from the menu that appears. Follow
the create new key link, provide a key label and description, then click the Create Key button to
confirm your specifications and create a new configuration file key.
Once the configuration file key label is created, it can be assigned an arbitrary value for the hosts
that use that label. To use/define a custom key for a system, navigate to the system profile, select
the Details tab then the Custom Info sub-tab. Select the link for an existing defined key value or
click the create new value link to assign a value to one of the custom variables defined for this
organization.
Custom keys are simply used for macro replacement - RHN does not currently provide logic or
math operations for them. The Red Hat Network API can be used to assign values to custom
keys so scripts can perform calculations and store the results in custom keys and therefore
configuration files. The relevant API method to use is setCustomValues which is defined in the
system namespace.

References
Red Hat Network Satellite Reference Guide
Section 7.7.5.1: Including Macros in your Configuration Files

RH401-6-en-1-20110713

131

Chapter8.Configuration File Management with RHN

Personal Notes

132

RH401-6-en-1-20110713

Sample Configuration File

Unit Summary
Configuration Channel Management
In this section you learned how to:
Describe the uses for RHN configuration channels
Create and manage configuration channels
.
Client Configuration
In this section you learned how to:
Use RHN to deploy configuration files to client machines
.
Configuration File Management
In this section you learned how to:
Manage configuration channel content from the command-line
.
Flexible Configuration with Macros
In this section you learned how to:
Create templates using RHN config file macros
.

RH401-6-en-1-20110713

133

134

Chapter9.

UNIT NINE

PROVISIONING WITH PXE


Introduction
Topics covered in this unit:
Components of bare metal provisioning
Kickstart profile management
Deployment of DHCP services
Use Cobbler and Koan

RH401-6-en-1-20110713

135

Chapter9.Provisioning with PXE

Provisioning Requirements
There are three kinds of provisioning: bare-metal, virtual machine deployment, and rebuilding.
The goal of bare metal provisioning is to non-interactively prepare a new computer for use unpack a new system, cable it, and push a button. In this unit you will learn how to build the
network infrastructure to facilitate the deployment of Red Hat Enterprise Linux servers.
The following shows the order network services are used to accomplish bare metal provisioning
in a PXE-boot environment. We will look at each of these services in the following pages from
highest level to lowest rather than chronological sequence:
1.

DHCP server provides:


General networking information
next-server: name of tftp server
filename: file to retrieve from tftp server (usually pxelinux.0)

2.

TFTP server provides:


Network boot loader (pxelinux.0 with menu.c32)
PXE configuration files (location of kernel, initrd, kickstart file)
Anaconda stage 1 (vmlinuz, initrd)

3.

Kickstart/installation file server provides:


Anaconda stage 2 from kickstart tree
HTTP provides kickstart file to Anaconda
Install server provides RPM packages

Red Hat Network Satellite can provide several critical pieces of this infrastructure, managing
kickstart profiles and packages needed to install Red Hat Enterprise Linux. TFTP services will be
provided by the Cobbler component of RHN Satellite.

References
Red Hat Network Satellite Reference Guide
Section 11.1: Cobbler Requirements

136

RH401-6-en-1-20110713

Tuning RHN Satellite for Provisioning

Tuning RHN Satellite for Provisioning


Kickstart Profiles
Kickstart profiles act as blueprints for the systems being provisioned. They define the disk
partitioning for the new system, the network configuration, and other system attributes such
as time zone and authentication methods. Package groups and individual packages determine
which software gets installed on the system. The base software channel defines which Red Hat
Enterprise Linux distribution on the Satellite Server the software will come from.
Kickstart profiles facilitate system recovery and replication. Each organization within a Satellite
Server manages their own kickstart profiles. The URI used to access a profile includes the
profile's name, so difficult to guess names should be used when the Satellite Server can be
accessed from an insecure network.
Provisioning in an enterprise environment starts with defining kickstart profiles that build
systems suited for the IT needs of the organization. Additional steps must be taken to build the
network infrastructure in place to deliver the kickstart profiles and installation media to the
target systems.
RHN Satellite operations can be performed in the kickstart %post section. These include:
Child software channel subscriptions
System group assignments
Activation keys

Creating a Kickstart Profile


Red Hat Network requires provisioning add-on entitlements for machines that will be
installed using the resources of the Satellite Server. If these entitlements aren't available, the
Kickstart and Provisioning tabs and menus will not appear in the web interface. Organization
Administrators are responsible for kickstart management so proper authentication is required to
see these functions as well.
First a unique kickstart profile label must chosen and specified. The Base Channel determines
which packages and package groups are available at install time. These packages and package
groups can be listed in the Package Groups form below the Software tab once the kickstart
profile is created.
The base software channel determines which choices will be presented by the Kickstartable
Tree pull-down menu. The specific tree chosen defines which install media must be used at build
time. The install trees correspond to subdirectories found below the /var/satellite/rhn/
kickstart directory. These directories contain the necessary ISO and PXE images used to begin
kickstart installations.
The resulting kickstart file generated, including scripts, can be found beneath the Kickstart File
tab. It can be viewed on the screen or downloaded to a file using a web browser. Pre-existing
kickstart files can be imported into a Satellite Server by selecting the upload new kickstart file
link instead of create new kickstart profile.
Kickstart profiles can be tested without other components of a provisioning infrastructure in
place. The URI of a particular kickstart profile can be found by selecting the Kickstart Details tab

RH401-6-en-1-20110713

137

Chapter9.Provisioning with PXE

followed by the Bare Metal Kickstart tab. The URI begins with http://satellite.fqdn in the
Bare Metal Kickstart section towards the top of the page.
To create a kickstart profile in the Satellite Server, navigate to the Create Kickstart Profile form
and select the Systems tab. Choose Kickstart from the navigation menu at the left. Click on the
create new kickstart profile link at the upper right. Fill out the Create Kickstart Profile form.
Note that the Base channel chosen will determine which kickstart trees are presented.

Kickstart Profile Extras


File Preservation
Red Hat Network Satellite Server provides a file preservation feature that allows files and
directories to be saved and restored when a system is reinstalled. The target system must be
already managed by the Satellite Server and a file preservation profile must be enabled for the
host. File preservation only works when kickstarts are initiated within the Satellite Server web
interface.
A file preservation list is created by going to the Systems Kickstart File preservation page
and selecting the create new file preservation list link. Give the list a unique label and specify
the list of files and directories, one per line, to be preserved by this list. Click the Create List
button to complete the list creation process. One or more file preservation lists can be applied
to a kickstart profile by selecting System Details File Preservation when editing a specific
kickstart profile.
SSL and GPG Key Provisioning
SSL certificate authority certificates and GPG keys can be provisioned by kickstart as well.
These permit secure communication with the Satellite Server and RPM signatures to be verified.
Certificates and keys are managed in the Systems Kickstart GPG and SSL Keys page.
When editing a specific kickstart profile, keys can be selected for inclusion by selecting GPG &
SSL sub-tab below the System Details tab. Satellite Server kickstart profiles install the RHNORG-TRUSTED-SSL-CERT CA certificate by default, but the GPG key which verifies the signatures
of Red Hat's production packages, RPM-GPG-KEY-redhat-release is not.

Example Template
Templates: Variables and Snippets
Scripts can be defined in the %pre and %post sections of a kickstart file. When scripts are
defined using the Red Hat Network Satellite web interface, there is a Template mode that
permits variables and code snippets to be substituted into the scripts.
Variables can be defined in a couple of places: the kickstart profile or a system definition. The
Kickstart Details Variables tab is used to define kickstart profile variables when editing a
kickstart profile. Variables for a particular system are defined by selecting the Kickstart Details
Variables tab is used to define kickstart profile variables when editing a kickstart profile.
Variables for a particular system are defined by selecting the Provisioning Kickstart
Variables tab when editing a system profile. More local variable definitions will override general
definitions. For example if a kickstart profile definition of a variable called pet is cat and the
same variable is defined as dog in the system profile, then the variable reference $pet in the
scripts will evaluate to dog.

138

RH401-6-en-1-20110713

PXE Boot

Since $ and # are special characters when a script is created as a template, these characters
must be escaped with a backslash when template variable substitution should not occur. Large
blocks of code can be enclosed with the #raw and #endraw directives to disable template
variable substitution for that section of code. In fact when the Template checkbox is left
unchecked, these directives are automatically added so they surround the entire contents of the
user's script.
Snippets are macros that expand multiple lines of predefined code. They make maintenance
of reusable code more manageable since correcting a bug in a snippet corrects the code in
every kickstart profile that references the snippet. They also simplify kickstart scripts and make
them easier to read. They can be viewed and managed by going to the System Kickstart
Kickstart Snippets page. There are several predefined, default snippets you can use in
your scripts. Including $SNIPPET('koan_environment') in a %post kickstart script will
generate code that creates a couple system profile files that define a shell variable called
COBBLER_SERVER that points to the Satellite Server performing the kickstart.
$SNIPPET('koan_environment')

expands to:
# Start koan environment setup
echo "export COBBLER_SERVER=$server" > /etc/profile.d/cobbler.sh
echo "setenv COBBLER_SERVER $server" > /etc/profile.d/cobbler.csh
# End koan environment setup

PXE Boot
Preboot eXecution Environment (PXE) is an environment to bootstrap computers using a
network card. The network card must support PXE (many modern cards do) as well as the BIOS.
Motherboards with integrated NICs often have PXE functionality.
The network interface card broadcasts a DHCPDISCOVER packet extended with PXE-specific
options. A DHCP server replies with a DHCPOFFER giving the client information about the PXE
server and offering it an IP address. Once the client responds with a DHCPREQUEST, the server
sends back a DHCPACK containing the path to a file to boot the client can download via the
Trivial FTP (TFTP) protocol.
The client connects to the TFTP server (frequently 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. With this type of configuration, an automatic re-installation can be started by
destroying the hard drive boot loader and rebooting.

Cobbler Setup and pxelinux.0


To find pxelinux.0 on your system, run

RH401-6-en-1-20110713

139

Chapter9.Provisioning with PXE

[user@host ~]$ rpm -ql syslinux | grep pxelinux

pxelinux.0 is a network-aware boot loader. Once executed by the client system's BIOS,
pxelinux.0 searches the same directory from which it was downloaded for a configuration file
in the pxelinux.cfg/ subdirectory. The loop ends on the first successful get operation. This
procedure is documented in /usr/share/doc/syslinux-*/pxelinux.doc.
Additional files from the syslinux package are required by pxelinux.0 to support the menu
configurations created by Cobbler. The RHN Satellite installer, install.pl, can be used to
deploy Cobbler when a Satellite server is installed, but the cobbler-setup can also install
Cobbler and enable tftp services post installation. The cobbler-sync command performs
the additional step of deploying menu.c32 and pxelinux.0 to support menus in the x86
environment.

References
Red Hat Network Satellite Deployment Guide
Chapter 5: Provisioning with Satellite

140

RH401-6-en-1-20110713

PXE Boot

Practice Exercise

Automating RHN Satellite Client Configuration


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Use an activation key to register newly installed machines to your Red Hat Network Satellite
Server. It should subscribe the systems to useful software channels and join the Example
Servers system group.
1.

Create an activation key with a label of example-web. When clients are registered with this
activation key, the following actions should be performed:
Subscribe to the Red Hat Enterprise Linux Server (v. 6 for 64-bit
x86_64) base software channel
Subscribe to the related Red Hat Network Tools and Example custom child
software channels
Provide a provisioning entitlement
Subscribe to the Example Configs configuration channel
Deploy configuration files provided by the Example Configs configuration channel
Associate with the Example Servers system group

2.

Since signed packages will probably be deployed when the new systems are provisioned,
the GPG keys used to verify their signatures need to be deployed as well. Import the
GPG key used to verify custom packages built for Example, Inc. and the GPG key used
to verify standard Red Hat released RPMS. These keys are found in /var/www/html/
pub/EXAMPLE-GPG-KEY and /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
respectively.

RH401-6-en-1-20110713

141

Chapter9.Provisioning with PXE

Practice Exercise

Creating a Web Server Kickstart Profile


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Create a kickstart profile to build a web server that is ready to use immediately after it is
installed from bare metal.
1.

Create a kickstart profile labeled web-server that uses Red Hat Enterprise Linux 6 Server
to install a new machine. This profile will be used for bare-metal installations without any
use of virtualization. The most recent kickstart tree available should be used to perform the
installation. The initial root password for systems built with this profile should be redhat.

2.

The kickstart profile should create three native disk partitions. The first partition should
contain a 256MB ext3 file system mounted as /boot. A swap partition should be created
2048MB large. The final native disk partition should be a 17GB LVM physical volume.
Create a volume group named vol0 that includes the 17GB physical volume. Two logical
volumes should be created within the vol0 volume group. The first logical volume should be
named home and it should be 512MB in size. It will contain the /home filesystem. The second
logical volume should be named root and it should consume the rest of the unused storage
in vol0. It will be used for the / filesystem.
Choose the appropriate time zone for your locale. Systems in this organization have
hardware clocks which keep time using UTC instead of local time.
The kickstart should install the GPG keys used to verify package signatures for RPMS
released from Red Hat and custom packages provided by Example, Inc.

3.

Systems built with this kickstart profile are web servers, but they are also used with
graphical utilities and Subversion. Ensure the subversion RPM and the following package
groups are installed: x11, basic-desktop, and web-server.

4.

Update the kickstart profile so systems built with this profile register with the Red Hat
Network Satellite Server using the Example Web Server activation key.

5.

Create a post script in the kickstart profile that performs the following tasks:
Create a user named oliver with a password of password
Install the example RPM provided by the custom software channel
Update all system software to its most current release
Configure the web server to start at boot

142

RH401-6-en-1-20110713

PXE Boot

Practice Exercise

Set up the Provisioning Network


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Before desktopX provides any network services, it must be configured to communicate with and
act as a gateway for its backend network. Also configure the Cobbler component of Red Hat
Network Satellite Server to provide tftp and pxelinux capabilities for provisioning. Make sure
Cobbler is installed and functioning properly.
1.

Physically disconnect your client workstation, desktopY, from the classroom network. Cable
desktopY so it is connected to the second NIC of desktopX. This can be accomplished with
either cross-over cables or with a small switch with two patch cables. Your instructor should
have provided you with all necessary hardware to accomplish this task.

2.

Configure the backend interface of desktopX to have a static IP address of 10.100.X.254/24.


You will not be able to fully test the backend interface until you power up and configure
desktopY. Do a preliminary test by pinging the interface address.

3.

Enable IPv4 packet forwarding on desktopX. Make sure this feature is persistent across
reboots.

4.

The following diagram represents the configuration of your lab environment when you finish
this sequence:

RH401 Student Network Configuration


===================================
-----+-------------------- Classroom intranet
| eth0
| 192.168.0.X
,---+---.
|
| desktopX.example.com (desktopX)
|
|
`---+---'
| eth1
| 10.100.X.254
|
| eth0
| 10.100.X.1
,---+---.
|
| station1.privateX.com (desktopY)
|
|
`-------'

5.

When installing Red Hat Network Satellite Server, the installer asks if Cobbler should be
used to provide provisioning services. If it isn't already installed, use the cobbler-setup
command to install Cobbler and enable tftp services.

6.

Run cobbler sync as root to install the necessary files to support PXE network
bootloading.

RH401-6-en-1-20110713

143

Chapter9.Provisioning with PXE

7.

144

Confirm xinetd and tftp are configured to run at boot time and that xinetd is currently
running.

RH401-6-en-1-20110713

Dynamic Host Configuration Protocol

Dynamic Host Configuration Protocol


Dynamic Host Configuration Protocol, DHCP, allows a server to offer provisioning information
to clients in a managed, automated fashion. DHCP is a superset of the BOOTP protocol; 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 UDP port 67 and the client uses UDP port 68.
When a client network interface is configured for a dynamic IP address, it sends a
DHCPDISCOVER packet to the broadcast destination of 255.255.255.255. The broadcast packet
will be handled by either a DHCP server connected to the local physical network or routers may
be configured to forward the packet to a DHCP server on a different subnet. The client also sends
its previous IP address in this packet.
The first DHCP server to receive the broadcast packet from the client will respond by sending the
client a DHCPOFFER packet based on its configuration. DHCPOFFER packets contain the DHCP
server's IP address, the router, the IP address and subnet mask the client should use, and the
lease time. The DHCP server may also offer other information such as NTP servers, DNS servers,
timezones, domain names, etc.
The client then broadcasts a DHCPREQUEST back to the server, requesting the IP address the
DHCP server offered. At first glance this seems redundant, but there may be multiple DHCP
servers on the subnet, or the router may be forwarding the DHCPOFFER to multiple networks. In
this case the client's DHCPREQUEST packet includes the client's IP address and the IP address of
the DHCP server the client received its address from.
Once the DHCP server gets the DHCPREQUEST, it sends a DHCPACK acknowledging the client
has exclusive rights to the client IP address until the lease time is up.
The DHCP server may offer additional options such as filename and the IP address of next server
for PXE boot.
To configure a DHCP server, first use ip addr 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.
The dhcp package provides an IPv4 DHCP server and the dhcpv6 package provides an IPv6
DHCP server. We will concentrate on the installation and configuration of an IPv4 DHCP server
in this course. The DHCP client packages, dhclient for IPv4 and dhcpv6_client for IPv6, are
normally installed by default.
/etc/sysconfig/dhcpd can be used to configure dhcpd by setting the DHCPDARGS variable.
The following line in that file would cause dhcpd to listen on eth0 only:
DHCPDARGS=eth0

Best Practice: Always run service dhcpd configtest after editing /etc/dhcpd.conf
since configuration errors can prevent dhcpd from starting.
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.

RH401-6-en-1-20110713

145

Chapter9.Provisioning with PXE

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:
[root@host ~]# cp /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 the dhcpd.conf and dhcpoptions man pages for detailed descriptions of options.
Run service dhcpd configtest to check syntax. There must be at least one subnet block
defined in /etc/dhcpd.conf for the dhcpd service to start. The subnet must correspond with
statically-configured interfaces.

Essential dhcpd.conf Configuration


authoritative;
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
}

One subnet section must be defined 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's network.
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 host
name to the DNS server.
range versus range dynamic-bootp
The range line determines the range of IP addresses the server will assign to DHCP clients only.
Another option would be to specify range dynamic-bootp instead of range. Such a command
would determine the range of IP addresses the server will pass to both DHCP and BOOTP clients.
The difference between the two is that BOOTP clients do not relinquish their IP addresses. 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-leasetime. The max-lease-time determines the maximum possible lease time. These time values
are expressed in seconds and they determine the amount of time the DHCP server will reserve
the IP address for the client. In a QA lab these lease times may be a few seconds--just enough

146

RH401-6-en-1-20110713

Reserved IP Addresses

time to run a few network tests on a certain machine. Having a small lease time would mean the
DHCP server could rotate through the IP address range fairly quickly. In an office environment
the lease times could be hours or days since the clients might rarely change.

Reserved IP Addresses
authoritative;
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.254;
...truncated...
range 192.168.0.1 192.168.0.100;
}
host station151 {
hardware ethernet 12:34:56:78:AB:CD;
# this IP must be outside DHCP and BOOTP ranges
fixed-address 192.168.0.151;
}

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 host name 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 server will offer it an IP address of 192.168.0.151.

Offering Files via DHCP


subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
...truncated...
# specify server and file locations
next-server 192.168.0.254; # could be DNS name
filename "pxelinux.0"; # always use quotes
}
host station151 {
hardware ethernet 12:34:56:78:AB:CD;
# this IP must be outside DHCP and BOOTP range
fixed-address 192.168.0.151;
}

This example adds two lines to the subnet stanza in order to offer it a pxelinux boot loader. If
station151 is capable of PXE booting and it contacts the DHCP server via its 192.168.0.0/24
subnet NIC, station151 will use tftp to get the file pxelinux.0 from host 192.168.0.254. The
server could also be identified with a DNS host name instead of an IP address.

RH401-6-en-1-20110713

147

Chapter9.Provisioning with PXE

References
/usr/share/doc/dhcp-*/replaceable>/README
dhcpd.conf(5) and dhcp-options(5) man pages
Red Hat Network Satellite Reference Guide
Section 11.1.2: Cobbler and DHCP

148

RH401-6-en-1-20110713

Reserved IP Addresses

Practice Exercise

Configure DHCP to Support PXE


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Install a DHCP server that will issue IP addresses, both generally and based on MAC address, to
your provisioning network.
1.

Install the dhcp package on desktopX.

2.

Use the /usr/share/doc/dhcp-*/dhcpd.conf.sample file as a starting point for the


DHCP server.
Change the subnet to 10.100.X.0/255.255.255.0.
Change the router to the IP address of the backend network interface of your DHCP
server.
Set the DNS server to 192.168.0.254.
Set the default DNS search domain to example.com.
Issue IP addresses in the range from 10.100.X.2 to 10.100.X.10.
Deploy the network boot loader to support PXE booting.
Configure your DHCP service to only issue IP addresses on the Ethernet card attached to the
backend subnet.

3.

In another terminal window or virtual console follow /var/log/messages. In your original


shell start dhcpd and configure it to start at boot-time.
PXE boot your client workstation. You may need to press a function key during the boot
sequence to choose network boot. Observe /var/log/messages as well as the boot
messages on desktopY. Record desktopY's MAC address for future reference:

4.

Use the MAC address of your second machine as recorded in /var/log/messages on


desktopX to add a host IP reservation for 10.100.X.1 to /etc/dhcpd.conf. The name of
the client host will be station1.privateX.com. Restart the dhcpd service.
PXE boot the client machine and verify that it gets the new address. It should also display
the Cobbler PXE boot menu.

RH401-6-en-1-20110713

149

Chapter9.Provisioning with PXE

Cobbler and Koan


Cobbler
Cobbler is a great tool for building and maintaining a network infrastructure that supports
kickstart installations. Red Hat Network Satellite Server uses Cobbler to facilitate all types of
provisioning: bare-metal, virtual machine, and reinstallation. Cobbler was written by Michael
DeHaan for the purpose of taking many separate technologies used for provisioning and
managing them with a single tool. Cobbler is used to manage distributions (distros), kickstart
profiles (profiles), and system provisioning configurations (system).
Distributions, or distros define the locations for the installation kernel, its initial ramdisk
image, and other installer parameters. Each kickstart tree in a RHN Satellite Server defines a
standard installer distribution and a distribution that works with Xen. Also when base channels
are cloned, Satellite creates distributions for the installation trees used with the cloned channels.
Cobbler profiles define the location of the kickstart file associated with the profile and the
distribution to be used. They also contain other metadata such as RHN Satellite organization.
When a Cobbler kickstart profile is associated with a provisioned virtual guests, fields within the
profile define the virtual machine's characteristics such as number of virtual CPUs and memory
size.
When systems are provisioned, Cobbler creates a system definition that defines which kickstart
profile should be used to build the system. Other information such as the installation media path
and network settings are kept in the system definition. Note the media path in system definitions
created by RHN Satellite contain a hashed pathname that expires. So you will need to refresh the
system profile by using the Satellite web interface to initiate the kickstart (select the system then
click on the Provisioning tab, then Kickstart sub-tab, then the Schedule tab).
Cobbler provides a network boot infrastructure:
Installs and configures a TFTP server
Deploys and configures pxelinux
Links to RHN Satellite kickstart profiles
Does not implement DHCP services
Cobbler can be executed from the shell on the system which hosts it, typically the Satellite
Server. The cobbler command is immediately followed by the Cobbler sub-command to be
executed. Options are specified last and some options are required for certain commands. Builtin help messages appear when the -h option is specified on a partial command line.
The default configuration allows only root to successfully execute Cobbler commands. The
cobbler aclsetup command controls Cobbler access for other users.
The cobbler list command displays a list of all known distros, their associated kickstart
profiles, and the system definitions which are configured to use those profiles. The cobbler
report command produces a detailed list of the settings associated with each distro,
profile, and system in that order. Cobbler also has distro, profile, and system subcommands. For example, the following command displays detailed information about the
guest2:2:Example profile:

150

RH401-6-en-1-20110713

Provisioning with Cobbler

[root@host ~]# cobbler profile report --name=guest2:2:Example

Cobbler Installation
Cobbler should be installed when a Red Hat Network Satellite Server will be used for
provisioning. The RHN Satellite installer prompts and asks if Cobbler should be installed. When
Cobbler is chosen, the tftp-server package and its dependencies are installed and configured
to provide pxelinux support on the network. It generates the necessary pxelinux menus and
configuration to provide network installation services. Sometimes a few adjustments have to be
made to the server running RHN Satellite to support Cobbler.
After Cobbler is installed, the cobbler check command should be used to checks its current
operating environment. This command displays suggestions for making adjustments to get
Cobbler to work. Some of the suggestions should be implemented but there may be others that
are not relevant to a particular installation.
Cobbler should be restarted and synchronized whenever its configuration file, /etc/cobbler/
settings, is modified:
[root@host ~]# service cobblerd restart
[root@host ~]# cobbler sync

Cobbler can be used to:


Inspect and modify its own configuration
Generate a custom installation ISO
Reprovision systems using kickstart
Control power management functions

Provisioning with Cobbler


Changing a kickstart profile of a system allows for easy reprovisioning. The following command
changes the kickstart profile of station3.example.com to the template used to install FTP
servers:
[root@host ~]# cobbler system edit --name=station3.example.com:2 --profile=ftpserver:2:Example --netboot-enabled=1

The :2 in the names above represent the organization ID number of the organization which
created them. To begin the installation station3.example.com needs to be rebooted, then the
changes will go into effect.
When using Red Hat Network Satellite, Cobbler is typically used behind the scenes. Many of the
provisioning adjustments made in the Satellite web interface make changes to Cobbler's profiles.
For example, importing additional content using satellite-sync creates additional distros.
Changing kickstart profiles for a system can be accomplished using a few mouse clicks. Cobbler
provides a command-line interface to provisioning tasks.
To PXE provision a system using cobbler, set the client system BIOS to boot from network first
then the hard drive. Enable the Cobbler pxe_just_once global setting and use the netbootenabled flag on each system to control installation.

RH401-6-en-1-20110713

151

Chapter9.Provisioning with PXE

Warning
RHN Satellite uses Cobbler as a back-end provisioning engine. It should not be used as a
standalone tool. Do not use Cobbler subcommands and features that are outside of the
scope of RHN Satellite documentation.

The cobbler buildiso command creates a bootable ISO CD image for use with machines that
don't have PXE support. Each ISO is customized to fit the current Cobbler configuration of the
Satellite Server they are created on. Because of their custom nature, these images need to be
rebuilt whenever additional kickstart profiles are created within the Satellite Server.

Koan
Koan allows remote access to Cobbler. The $SNIPPET('koan_environment') macro
expands to shell code that creates files on kickstarted machines which define a shell variable,
COBBLER_SERVER. Its value is the host name of the Satellite Server used to provision the client
and Koan uses this variable as the default Cobbler server to access. COBBLER_SERVER can be
temporarily overridden by specifying the --server option when using the koan command.
Koan can query Cobbler settings on a Red Hat Network Satellite Server. For example, the
following command displays a list of distributions provided by Cobbler:
[user@host ~]$ koan --list=distros --server=satellite.fqdn

The following command lists the kickstart profiles provided by the Satellite Server used to install
the client machine:
[user@host ~]$ koan --list=profiles

Koan can cause Cobbler to initiate a kickstart installation. This type of action requires root
shell access. The following command changes Cobbler's configuration so the local client will be
reinstalled when it is rebooted:
[root@host ~]# koan --replace-self

Specifying the --profile option causes Koan to select a different kickstart profile than the
current one for reinstalling a system.
Koan can also be used to provision virtual guests. The following koan command installs a virtual
guest on the current host according to the kickstart file specified by the --profile option:
[root@host ~]# koan --virt --profile=virt_guest_profile

Koan can interact with Cobbler to update its configuration. Koan is provided by the koan RPM
(rhn-tools channel)

152

RH401-6-en-1-20110713

Koan

References
Red Hat Network Satellite Reference Guide
Chapter 11: Cobbler
Red Hat Network Satellite Deployment Guide
Section 5.9: Advanced Topics
cobbler(1) koan(1) man pages

RH401-6-en-1-20110713

153

Chapter9.Provisioning with PXE

Practice Exercise

PXE Installation of a Web Server


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Now that all the pieces are in place, kickstart a client system as a web server within the Example,
Inc. organization.
1.

Delete all previous system profiles from the Satellite Server. This is required to free up all
entitlements needed for the new web server that will be kickstarted.

2.

Power on or reboot the client machine and select PXE boot. How PXE boot is selected varies
between various hardware vendors. Notice the Cobbler menu that appears has a new menu
item:
web-server:orgID:ExampleInc

Use the arrow keys and choose this menu item to begin the installation of your web server.
3.

Once the installation completes, confirm the new web server is built according to
specification. If anything didn't work properly, ask your instructor for help and troubleshoot
your RHN Satellite configurations.

4.

Completely automate the PXE installation of your web server. Delete the existing system
profile to free up entitlements before you being the automated installation. Configure the
system BIOS to PXE boot first then boot from the local hard drive.
Create a Cobbler system profile for your system called station1 based on the machine's
IP address. Configure Cobbler to PXE boot only once by default and use the netbootenabled flag within the system profile to control installation.
After you install your system and confirm everything worked correctly, delete the station1
Cobbler system profile so it doesn't conflict with later lab exercises.

154

RH401-6-en-1-20110713

Koan

Personal Notes

RH401-6-en-1-20110713

155

Chapter9.Provisioning with PXE

Unit Summary
Provisioning Requirements
In this section you learned how to:
Define components of bare metal provisioning
.
Tuning RHN Satellite for Provisioning
In this section you learned how to:
Tune RHN Satellite for Provisioning
.
Dynamic Host Configuration Protocol
In this section you learned how to:
Install and configure DHCP
Implement a bare metal install environment with DHCP
.
Cobbler and Koan
In this section you learned how to:
Implement a bare metal install environment with Cobbler/Koan
Use Cobbler and Koan to support kickstart
.

156

RH401-6-en-1-20110713

Chapter10.

UNIT TEN

RHN VIRTUAL MACHINE


MANAGEMENT
Introduction
Topics covered in this unit:
System entitlements: Regular, Inherited Guest, Flex Guest
Add-on entitlements: Virtualization and Virtualization Platform
Virtual host and guest provisioning
Virtual guest destruction

RH401-6-en-1-20110713

157

Chapter10.RHN Virtual Machine Management

Virtual Host Configuration


RHN Virtualization
Virtualization technology is becoming more common in the datacenter. Red Hat Network
software, including Satellite Server, is virtualization aware. Virtual guest machines are handled
differently and don't consume system entitlements if they are properly registered.
The Red Hat Network web interface can manage virtual guests without the user having to
authenticate into the physical system hosting the guests, called the virtualization host. The
virtual guests can be booted or shutdown remotely, or they can be suspended from using CPU
resources or resumed.
Red Hat Network Satellite can provision virtualization hosts from bare metal. KVM and Xen
guests virtual machines can be provisioned as well. In this course we will examine how to manage
virtualization hosts and guests that utilize KVM virtualization technology since Xen is only
supported in Red Hat Enterprise Linux 5.

Types of Entitlements
Regular entitlements are consumed when physical systems register with Red Hat Network.
These are defined as slots in the Satellite entitlement certificate. Physical systems cannot
successfully register with Red Hat Network if no regular entitlements are available.
Virtualization and Virtualization Platform add-on entitlements should be assigned to
physical systems serving as virtualization hosts that supports virtual guest machines. These
entitlements are respectively defined by the values for the virtualization_host and
virtualization_host_platform fields in the Satellite entitlement certificate.
Guest virtual machines hosted on properly entitled virtualization hosts consume Inherited
Guest entitlements. When Inherited Guest entitlements are exhausted, regular entitlements are
consumed. Inherited Guest entitlements are calculated based on the type of entitlement the
hosting server has. A virtualization host with a Virtualization add-on entitlement provides 4
Inherited Guest entitlements. A host with a Virtualization Platform add-on entitlement provides
an unlimited number of Inherited Guest entitlements for the guests it hosts.
Flex Guest entitlements are consumed by virtual machines that are hosted by a machine that
isn't registered with Red Hat Network. They are also consumed by guests of host machines
that do not have Virtualization nor Virtualization Platform add-on entitlements. Currently Flex
Guest and regular entitlements are combined together on the Satellite server and the Satellite
Certificate.

Virtual Host RHN Configuration


Register the virtualization host to RHN normally
Ensure it has Virtualization or Virtualization Platform add-on entitlement
Ensure it is registered to appropriate RHN Tools child channel
Install the virtualization, virtualization-platform, and virtualization-client package groups
Install the rhn-virtualization-host package

158

RH401-6-en-1-20110713

Bridge Network Interface Configuration

Install osad and start the service


Allows RHN Satellite to push management commands to clients
With VMs running, run rhn_check; rhn-profile-sync
To allow management of a virtualization host's guest machines through RHN, it must be properly
configured in advance.
The virtualization host should be registered normally to RHN, with either the Virtualization
or Virtualization Platform add-on entitlement; these come with Red Hat Enterprise Linux and
RHEL Advanced Platform, and Virtualization is available as an add-on to Red Hat Enterprise
Linux Desktop. The virtualization host should also be registered to use the RHN Tools child
channels for the version of RHEL that it is running.
Three package groups must be installed for a server to act as a KVM virtualization host. Each of
them are listed below with the functionality they provide:
virtualization - provides the qemu hardware emulation functionality used by KVM
virtualization-platform - provides the libvirt virtualization library used to manage
virtual machines
virtualization-client - provides applications sed to interact with libvirt such as virsh
and virt-manager
The rhn-virtualization-host RPM needs to be installed on the, as well as the osad service
(if running RHN Satellite and the ability to immediately push commands is desired). The osad
service should be configured to start at boot and started up.
Finally, on the virtualization host with its virtual guests running, the command rhn_check
should be run, then the virtualization host should have its profiles updated by running rhnprofile-sync. Any virtual guests running at this time should show up in the RHN web
interface.

Bridge Network Interface Configuration


A network bridge must be created on a virtualization host for virtual guests to be reachable from
the external network. A private network called virbr0 is created by default that allows virtual
machines to connect to the outside using the virtualization host as a NAT firewall.
To create a bridge interface called br0 that uses the eth0 physical network card, two files have
to be created and/or modified: /etc/sysconfig/network-scripts/ifcfg-br0 and /
etc/sysconfig/network-scripts/ifcfg-eth0. Before you modify these files, disable
NetworkManager to keep it from manipulating them and undoing your changes:
[root@host ~]# chkconfig NetworkManager off
[root@host ~]# service NetworkManager stop

Next, create /etc/sysconfig/network-scripts/ifcfg-br0 with the following contents:


DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
DELAY=0

RH401-6-en-1-20110713

159

Chapter10.RHN Virtual Machine Management

ONBOOT=yes

The BOOTPROTO directive in the example indicates the virtualization host should get its network
assignments from DHCP. Static assignments can be specified instead with the IPADDR and
NETMASK directives when BOOTPROTO is defined as static. After the ifcfg-br0 is created,
modify the ifcfg-eth0 network interface file to look like the following:
DEVICE=eth0
BRIDGE=br0
HWADDR=mac-address-of-eth0
ONBOOT=yes

Once these files are in place, use the service network restart command to apply your
changes or reboot the system. The br0 bridge should be specified when virtual guests are
created to allow them direct access to the external network.

References
Red Hat Network Satellite Reference Guide
Section 10.1: Setting Up the Host System for Your Virtual Systems

160

RH401-6-en-1-20110713

Bridge Network Interface Configuration

Practice Exercise

Converting a Server to a Virtualization Host


Before you begin...
Your client machine, station1.privateX.com, will be transformed into a server that will host
virtualization guest machines.
Carefully perform the following steps. Ask your instructor if you have problems or questions.
Example, Inc. has existing machines registered with their Red Hat Network Satellite Server.
Virtualization is being introduced to their server room so existing hosts need to be converted
into virtualization hosts running virtual guests.
1.

First the network needs to be configured to provide a bridge network interface for virtual
guests. Disable the NetworkManager service to prevent network configuration files from
automatic modifications:
[root@station1 ~]# chkconfig NetworkManager off
[root@station1 ~]# service NetworkManager stop

Create/modify the network configuration files on station1 to support a network bridge. /


etc/sysconfig/network-scripts/ifcfg-br0 should contain the following lines:
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
DELAY=0
ONBOOT=yes

Modify /etc/sysconfig/network-scripts/ifcfg-eth0 so it contains the following


lines:
DEVICE=eth0
BRIDGE=br0
HWADDR=mac-address-of-eth0
ONBOOT=yes

Once the files have been modified, restart the network service and confirm station1 has a
working network with br0 bridge.
2.

Install additional software needed to support virtualization. Install the virtualization,


virtualization-client, and virtualization-platform package groups. Once all
the software is installed, reboot your client system.

3.

Copy the install-vserver script from the instructor's machine to your client
system, station1, and execute it. It will use kickstart to install a virtual guest called
vserver on the local machine. The script can be found at the following URL: ftp://
instructor.example.com/pub/materials/install-vserver.

RH401-6-en-1-20110713

161

Chapter10.RHN Virtual Machine Management

Practice Exercise

Red Hat Network Registration of Virtual Machines


Before you begin...
A virtualization host (station1.privateX.com) running RHEL 6 registered to your RHN
Satellite Server and a vserver virtual machine installed with RHEL 6 running as a guest.
Carefully perform the following steps. Ask your instructor if you have problems or questions.
In this sequence, you will register vserver with Red Hat Network under station1's
entitlement. Note the first couple steps of this exercise can be completed on the Satellite server
and virtualization host while vserver finishes installing.
1.

Log into your RHN Satellite using an account that can manage station1.privateX.com,
and ensure it is entitled to Virtualization service and its software channel subscriptions
include RHN Tools for RHEL.

2.

Log in as root on the virtualization host. Use yum to install the rhn-virtualizationhost and osad packages. Start the osad service and ensure it will start automatically at
boot. This enables remote management of virtual machines from the RHN web interface.

3.

After the virtualization guest has finished installing, make sure the vserver domain is
running. On the virtualization host run rhn_check and rhn-profile-sync as root.

4.

Log into the virtualization guest and download the bootstrap.sh script you completed in
a previous lab from your Satellite Server. Use it to register the guest with your RHN Satellite
Server.

5.

In the RHN web interface, select the Systems tab. You should see your newly-registered
vserver virtual machine listed under its host name. Note the different system icon.
Now click on your station1.privateX.com host name link, then on the system
detail page find its Virtualization link/tab and click on that. You should see the list of
the virtual machines running on station1 when you updated its RHN profile. If any
of them are not registered with Red Hat Network, you will see Unregistered System
instead of a host name for its profile name. Click on the hostname link for vserver (e.g.
station9.privateX.com) to see its RHN profile.

162

RH401-6-en-1-20110713

Virtual Machine Provisioning

Virtual Machine Provisioning


Provisioning Virtualization Hosts Using RHN
Prepare an activation key for registration
Subscribe to base + rhn-tools + vt channels as a minimum
Virtualization or Virtualization Platform add-on entitlement
Creation of kickstart profile
Important - virtualization type should be None for a KVM virtualization host, Xen Virtualized
Host for Xen only
Incorporate activation key in previous step
Install osad and rhn-virtualization-host RPMS in %post
Create necessary network bridges in %post
The best way to automate the provisioning of a virtualization host using Red Hat Network
involves an activation key and a kickstart profile. The primary purpose of the activation key is
to assign entitlements to the freshly installed virtualization host. It should subscribe to the base
channel for Red Hat Enterprise Linux and the related RHN Tools child channel. The Virtualization
or Virtualization Platform add-on entitlement can also be assigned to the new host using the
activation key. This activation key can be modified or used with other activation keys to assign
the new system to a system group for administration.
Create a kickstart profile that uses the activation key described above. Although Xen Virtualized
Host is presented as a Virtualization Type as part of the first step of creating the profile, select
None when creating a KVM-based virtualization host. Xen Virtualized Host is used on Xen-based
Red Hat Enterprise Linux 5 virtualization hosts and it enables capabilities and default selections
in the kickstart profile that aid the building of a virtualization host, such as selecting the VT
installation repository to be available during installation.
Although the activation key subscribes the host to the RHN Tools child channel, the kickstart
profile can perform that step as well. These channels can be selected in the kickstart profile
by clicking the Kickstart Details tab then selecting the Operating System sub-tab. Note the
kickstart profile child channel selection is overridden by activation keys, so consider this as a
backup child channel assignment.
Finally, create a kickstart %post script to install the osad and rhn-virtualization-host
RPMS. This will permit administration of guest machines using the RHN web interface. You can't
include these packages in the kickstart package list because the RHN Tools child channel isn't
available during the installation of the core operating system. The relevant code in the %post
section could be as follows:
yum -y install rhn-virtualization-host osad
chkconfig osad on

RH401-6-en-1-20110713

163

Chapter10.RHN Virtual Machine Management

Provisioning Guest Machines Using RHN


Prepare an activation key for registration
Creation of kickstart profile
Important - virtualization type should be one of 3 types of guests:
KVM Virtualized Guest
Xen Fully-Virtualized Guest
Xen Para-Virtualized Guest
Specify virtual machine characteristics
Virtual memory and virtual CPU resources
Virtual disk space to be allocated
Network bridge interface
Use web interface to initiate guest kickstart
Provisioning a virtualized guest is simpler than provisioning a virtualization host in some ways,
but it requires more decisions in others. Registering with an activation key isn't really necessary,
but is still useful for subscribing to other software channels and joining specific system groups.
Create a kickstart profile and select one of the three virtual guest types when specifying the
virtualization type. After kickstart location and the root password has been provided, tabs will
appear that allow for further customization of the kickstart profile. Click the Kickstart Details
tab then select the Details sub-tab. It is here you can change the virtualization type or determine
virtual machine characteristics, such as:
virtual machine memory (default 512MB)
virtual CPUs (default 1)
virtual disk space (default 3GB)
network bridge
The virtual disk will be allocated as a file on the virtualization host located in the /var/lib/
libvirt/images directory. The network bridge can be external facing, such as br0, or virbr0
(for a connection to the private, memory-based network provided by libvirt).
Once all settings have been determined, use the web interface to initiate a kickstart of a guest
machine. Navigate to the system profile of the virtualization host. Click on the Virtualization tab
then select the Provisioning sub-tab. Click a radio button to select the guest kickstart profile to
use and choose a unique name for the guest (it will serve as its Xen domain name). The final step
is to schedule when the kickstart will occur.

Virtual Guest Deletion


Deleting a virtual guest requires a few steps:

164

RH401-6-en-1-20110713

Virtual Guest Deletion

Shut down the virtual guest


Delete the virtual guest system profile from RHN
Remove the virtual guest configuration on the host
Remove the virtual storage image file
Red Hat Network doesn't have a turn-key way to delete a virtual guest machine. Deleting a virtual
guest involves a few steps to make sure it is thoroughly removed from the virtualization host and
all disk space is reclaimed.
First, shut down the guest machine. The Red Hat Network web interface can be used to shut
down the virtual guest. Another option is to log into the virtualization host and use virsh
destroy or virsh shutdown to shut down the guest VM. ssh can be used to log into the guest
directly and use the shutdown.
The next step is to delete the virtualization guest system profile from Red Hat Network. Log into
RHN as a user who can administrate the virtual guest system, navigate and pull up the system
profile of the virtual guest, then click the delete system button and confirm.
Delete the domain configuration files from the virtualization host. Use the following command to
remove the virtual system information out of the libvirt database:
[root@host ~]# virsh undefine domainname

Finally, reclaim the disk space used as the disk image for the virtual guest. The following
command should work on the virtualization host:
[root@host ~]# rm -f /var/lib/libvirt/images/domainname

References
Red Hat Network Satellite Reference Guide
Section 10.2: Setting Up Your Virtual Systems
Red Hat Network Satellite Deployment Guide
Section 5.8.3: Virtualized Guest Provisioning

RH401-6-en-1-20110713

165

Chapter10.RHN Virtual Machine Management

Practice Exercise

Provisioning a Virtualization Host


Carefully perform the following steps. Ask your instructor if you have problems or questions.
In previous exercises you converted an existing host to a virtualization host. Use RHN Satellite
kickstart capabilities to provision a virtualization host from bare metal.
1.

Create a kickstart profile called kvm-host in your Satellite Server to build a virtualization
host. The installing system should use the Red Hat Enterprise Linux Server (v. 6
for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the root password to redhat.

2.

Once the kvm-host kickstart profile is created, adjust the timezone to use the local
timezone and installed systems use UTC in their hardware clocks. Automate installation
of the standard Red Hat release GPG key. The @virtualization, @virtualizationclient, and @virtualization-platform package groups should be installed.
Use the %post script of the kickstart file to install the rhn-virtualization-host and
osad packages. Configure the osad service to start at boot time. Also provide some shell
code to configure the network to use a bridged network interface.

3.

Use the Satellite Server to schedule station1.privateX.com to kickstart install itself


using the kvm-host kickstart profile. The kickstart should be initiated immediately.
While the client system installs, use Cobbler to determine the system profile name of the
kickstarting system. Delete all other Cobbler system profiles then disable the netboot
feature for the installing system.

166

RH401-6-en-1-20110713

Virtual Guest Deletion

Practice Exercise

Provisioning a Virtualized Guest


Carefully perform the following steps. Ask your instructor if you have problems or questions.
With the virtualization host built, now it is time to use Red Hat Network Satellite to provision the
virtual guests running on the host.
1.

Create a kickstart profile called kvm-guest in your Satellite Server to build a virtual guest.
The installing system should use the Red Hat Enterprise Linux Server (v. 6
for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the initial root password to redhat.

2.

Modify the virtual machine network configuration to use the br0 bridge interface of the
virtualization host and send console messages to ttyS0. Adjust the timezone to use the
local timezone and installed systems use UTC in their hardware clocks.

3.

Use the RHN Satellite to provision a virtual guest on station1.privateX.com. Schedule


a guest system to install using the kvm-guest kickstart profile. The guest name should be
named vserver and initiate the kickstart installation immediately.

4.

After the installation of the virtual guest completes, use the Satellite web interface to
confirm that it has registered with the Satellite server.

RH401-6-en-1-20110713

167

Chapter10.RHN Virtual Machine Management

Personal Notes

168

RH401-6-en-1-20110713

Virtual Guest Deletion

Unit Summary
Virtual Host Configuration
In this section you learned how to:
Manage RHN entitlements in a virtualized environment
Convert an existing Red Hat Enterprise Linux system into a KVM-based virtualization
host
Create a network interface bridge
.
Virtual Machine Provisioning
In this section you learned how to:
Use RHN Satellite to provision a KVM-based virtualization host
Use RHN Satellite to provision a virtual guest
Delete a virtual guest and reclaim its resources
.

RH401-6-en-1-20110713

169

170

Chapter11.

UNIT ELEVEN

RHN SATELLITE SERVER


ADMINISTRATION
Introduction
Topics covered in this unit:
db-control
rhn-satellite-activate
rhn-ssl-tool and rhn-ssl-dbstore
rhn-satellite-exporter
High-availability options
Troubleshooting

RH401-6-en-1-20110713

171

Chapter11.RHN Satellite Server Administration

RHN Satellite Database Management

The /usr/sbin/rhn-satellite script is a wrapper that launches, checks the status, or


shutdowns the various daemons that provide the Red Hat Network Satellite service. It works
like an init script except it is executed directly. All of the daemons that make up RHN Satellite
Server are installed and configured to start at boot. The rhn-satellite command immediately
controls the current status of those daemons.
RHN Satellite Server components:
Component

Function

rhn-satellite

wrapper that holds everything together

oracle

database engine

osa-dispatcher

push events to client systems

jabberd

transport layer for osa-dispatcher


messages

Apache/httpd

web interface for users and xmlrpc

tomcat/catalina

Java support, implements Java Servlets and


JSP

taskomaticd

handles scheduled jobs

rhnsearchd

RHN search engine

cobblerd

RHN provisioning engine

172

RH401-6-en-1-20110713

Embedded Database Management

Embedded Database Management


The db-control utility is used to manage the Oracle database on Red Hat Network Satellite
Servers that use the embedded database. SQL manipulation of the embedded database is not
supported by Red Hat and is discouraged. db-control is a wrapper provided by Red Hat to
perform basic database system administration functions.
[root@host ~]# db-control status
Error: please run this command as the oracle user ('su - oracle').
[root@host ~]# su - oracle
-bash-3.2$ db-control stop
Shutting down database... done.
-bash-3.2$ db-control status
The database is in the process of shutting down.
-bash-3.2$ db-control status
The database is offline.
-bash-3.2$ db-control start
Starting database... done.
-bash-3.2$ db-control status
The database is running and accepting connections.

The db-control utility must be executed as the oracle user.

Table Maintenance
The db-control command can be used to manage the size of the database tables. After
approximately 3 base software channels are imported into the Satellite Server an increase
is needed, but the need for space only becomes known through strange tracebacks. The
tables cannot expand themselves due to possible exponential growth, so the Satellite system
administrator must expand them manually. Usually the tables that need some attention are the
DATA_TBS and/or the UNDO_TBS tables.
[root@host ~]# su - oracle
-bash-3.2$ db-control report
Tablespace
Size
Used
Avail
DATA_TBS
3.9G 609.2M
3.3G
SYSAUX
500M
64.1M
435.8M
SYSTEM
400M 242.6M
157.3M
TEMP_TBS
1000M
0B
1000M
UNDO_TBS
1000M
87.4M
912.5M
USERS
128M
64K
127.9M
-bash-3.2$ db-control extend UNDO_TBS
Extending UNDO_TBS... done.
-bash-3.2$ db-control report
Tablespace
Size
Used
Avail
DATA_TBS
3.9G 609.2M
3.3G
SYSAUX
500M
64.1M
435.8M
SYSTEM
400M 242.6M
157.3M
TEMP_TBS
1000M
0B
1000M
UNDO_TBS
1.4G
88.5M
1.3G
USERS
128M
64K
127.9M

Use%
15%
13%
61%
0%
9%
0%

Use%
15%
13%
61%
0%
6%
0%

If necessary, run db-control extend multiple times to extend further, since size cannot be
specified.
Internal tables can be:
Inspected: db-control {report|tablesizes}

RH401-6-en-1-20110713

173

Chapter11.RHN Satellite Server Administration

Analyzed: db-control {gather-stats|report-stats}


Expanded: db-control extend TABLE
Shrunken: db-control shrink-segments

Database Backup and Restore


The db_control backup location command saves the contents of the database to disk. It is
a cold backup that requires the database to be offline during the backup, db_control does not
stop the database automatically.
-bash-3.2$ mkdir backup-YYYYMMDD
-bash-3.2$ db-control stop
Shutting down database... done.
-bash-3.2$ db-control backup backup-YYYYMMDD
Initiating cold backup of database rhnsat...
/opt/apps/oracle/config/10.2.0/lkRHNSAT -> backup-YYYYMMDD/lkRHNSAT.gz ... done.
... Output omitted ...
Full cold backup complete.

An alternate method for performing backups of the Satellite Server database includes the
following steps:
1.

Stop the database

2.

Snapshot the /rhnsat partition

3.

Start the database

4. Backup /rhnsat and remove the snapshot when finished


To restore a Satellite Server from backups, first reinstall the base operating system. Install the
same version of the Satellite Server software. An answer file would help automate this process
and make sure the server is built consistently. Once the Satellite Server finishes installing, do not
go to the web page and create the Satellite Administrator account.
Instead, stop the Satellite Server software and restore the filesystem backups for /rhnsat and /
var/satellite. Make the most recent backup of the database available and restore the backup
with the following command:
-bash-3.2$ db-control restore path-to-backups

Restore the SSL key and certificate for the Satellite Server (more on that a little later) then start
the RHN Satellite Server software.
You can check the state of the backups by running db-control {examine|verify}.

174

RH401-6-en-1-20110713

Database Backup and Restore

References
Red Hat Network Satellite Installation Guide
Section 8.4: Using RHN DB Control
Red Hat Network Satellite Deployment Guide
Section 2.2.1: Backing up the Embedded Database
Section 2.2.3: Restoring the Embedded Database
db-control(1) man page

RH401-6-en-1-20110713

175

Chapter11.RHN Satellite Server Administration

Practice Exercise

RHN Satellite Embedded Database Maintenance


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Perform basic RHN Satellite embedded database maintenance functions such as extending an
internal table space and making a backup of your RHN Satellite database.
1.

Sometimes RHN Satellite embedded database performance can suffer when an internal table
becomes full. Determine the current size and utilization of the UNDO_TBS table then extend
it. Record both its original and new size and utilization below:

2.

Perform a backup of your Red Hat Network embedded database. Save the backup in a
directory called rhn-sat-backup-YYYYMMDD below the home directory of the oracle
account. How much disk space does the backup take?

3.

Confirm the integrity of the RHN Satellite embedded database backup you just created.

176

RH401-6-en-1-20110713

Satellite Server Management

Satellite Server Management


RHN Certificate Management
Entitlement certificates have to be updated for a couple of reasons. Each certificate issued by
Red Hat has an expiration date so they must be renewed and reactivated. Also a new certificate
will need to be activated when additional capabilities are purchased - perhaps more slots or
different software entitlements are needed.
Entitlement certificates are generated by Red Hat customer service. Check the expiration of
your current certificate and be sure to call well ahead of the expiration when renewing. When a
certificate expires there is a 7-day grace period, then the Satellite Server stops functioning until
a new certificate is activated.
Check the new certificate for correctness. It must match the version of Red Hat Network Satellite
Server and always double check the number of system entitlements and software channel
entitlements. Excess systems are unsubscribed by taskomatic and systems are unsubscribed
based on taskomatic's queue which is random. When a system gets unsubscribed in this manner
it loses its association with all channels including configuration channels. Once an entitlement
because available it must be resubscribed manually which is a time consuming process.
The tool of choice for RHN certificate management is rhn-satellite-activate. Use the -rhn-cert=PATH option to rhn-satellite-activate to specify the RHN certificate. This
option verifies the integrity of the certificate, inserts it into the local Satellite Server database
and then inserts it into the Red Hat database on RHN. The --disconnected option to rhnsatellite-activate prevents the remote insertion.

Disconnected to Connected Operation


Many Red Hat consultants prefer to install Red Hat Network Satellite in disconnected mode then
connect to hosted RHN once the server is running and has much of the software channel content
loaded. This approach saves bandwidth and the installation process doesn't require Internet
availability.
First, the Satellite Server must be registered as a client of hosted Red Hat Network. It is
very important that the server be registered with the RHN account that meets the following
requirements:
it has an available RHN Satellite software entitlement
the Entitlement certificate is associated with it
Next /etc/rhn/rhn.conf must be modified to point the Satellite Server back to hosted RHN's
servers:
server.satellite.rhn_parent = satellite.rhn.redhat.com

Finally, reactivate the Satellite Server with the RHN entitlement certificate using rhnsatellite-activate:
# rhn-satellite-activate --rhn-cert=PATH-TO-CERT

RH401-6-en-1-20110713

177

Chapter11.RHN Satellite Server Administration

SSL Certificate Management


The RHN Satellite installer generates SSL keys and certificates. Original copies of CA and host
certificates are stored in the /root/ssl-build directory. At the top-level directory is the
certificate authority key and certificate. There is a subdirectory with the Satellite Server's host
name that has the SSL key and certificate used by the RHN Satellite Apache daemon. Both
directories also have source and binary RPMS used to deploy the keys.
In /root/ssl-build the certificate authority certificate is store in a file called RHN-ORGTRUSTED-SSL-CERT. This file is embedded in an RPM called rhn-org-trusted-sslcert-1.0-1.noarch.rpm and both are published to RHN clients of the Satellite Server. RHNORG-PRIVATE-SSL-KEY is the certificate authority private key and it should be carefully
guarded.
/root/ssl-build/hostname contains the SSL host key and certificates used by the Satellite
Server. The host certificate is signed by the CA in the top-level directory. The rhn-org-httpdssl-key-pair-hostname-1.0-1.noarch.rpm RPM contains all of the SSL files used by the
Red Hat Network daemons that run on the Satellite Server. Here is the list of files provided by
such an RPM:
[root@host ssl-build]# rpm -qlp host/rhn-org-httpd-ssl-key-pair-host-1.0-1.noarch.rpm
/etc/httpd/conf/ssl.crt/server.crt
/etc/httpd/conf/ssl.csr/server.csr
/etc/httpd/conf/ssl.key/server.key
/etc/pki/spacewalk/jabberd/server.pem

The rhn-ssl-tool generates SSL keys/certs (and RPM) for Satellite use. Certificates are
installed in ~/ssl-build. You must include either the --gen-server or the --gen-ca option
to rhn-ssl-tool. When CA certificate changes it must be imported into Satellite database
(rhn-ssl-dbstore).

Satellite Host Name Change


Occasionally a Red Hat Network Satellite server's host name is changed to accommodate
network changes. When the IP address changes, but there is no change in host name, existing
SSL host certificates can be used without any changes. But when the host name changes, new
SSL host certificates must be created to match the new Satellite host name.
The spacewalk-hostname-rename command takes a single argument, the new IP address,
and generates new SSL host certificates for the RHN Satellite server. This tool does not update
any RHN Proxy or client system configurations. Their configurations will have to be updated to
point to the new Satellite server host name.

178

RH401-6-en-1-20110713

Satellite Host Name Change

References
Red Hat Network Satellite Installation Guide
Section 5.3: Managing the RHN Certificate with RHN Satellite Activate
Red Hat Network Satellite Client Configuration Guide
Section 3.2: The RHN SSL Maintenance Tool
rhn-satellite-activate(8), rhn-ssl-tool(1), rhn-ssl-dbstore(8), and
satellite-hostname-rename(8) man pages

RH401-6-en-1-20110713

179

Chapter11.RHN Satellite Server Administration

Practice Exercise

Activating a New Satellite Entitlement Certificate


Carefully perform the following steps. Ask your instructor if you have problems or questions.
There are a couple of reasons a new RHN Satellite entitlement certificate is issued to a Red
Hat customer: expanded capabilities or an extension on the certificate expiration date. In
this exercise you will activate a new Satellite entitlement certificate that will provide more
capabilities.

On the instructor's server there is a more robust RHN Satellite entitlement certificate
available for your use. You can access the certificate using the following pathname
on your Satellite Server: /misc/instructor/rh401-satellite/redhat-glsmaximum-5.4.cert. Reactivate your Satellite Server using this certificate.
Log in as your Satellite Administrator, satadmin, and inspect the system and software
entitlements available for deployment.

180

RH401-6-en-1-20110713

Software Channel Synchronization

Software Channel Synchronization


Exporting Software Packages
The rhn-satellite-exporter utility writes software channel information to the file system
including packages, errata, kickstart trees, and metadata. Channel dumps created with this
tool can be used to update disconnected Satellite servers. It can also be used to backup custom
software channel content.
Child channels cannot be exported by themselves. rhn-satellite-exporter will create
an archive, but satellite-sync cannot use the child channel content by itself - it must be
associated with a base channel. The following process properly exports a child channel so
satellite-sync will use it:
[root@host
[root@host
... Output
[root@host
... Output

~]# mkdir export-tmp


~]# rhn-satellite-exporter --step=short -d export-tmp -c base-channel-label
omitted ...
~]# rhn-satellite-exporter -d export-tmp -c child-channel-label
omitted ...

The --step=short option causes only the metadata to be dumped, no packages, no kickstart
trees, no errata, just essentials.
Useful rhn-satellite-exporter options:
--list-channels - shows available channels
--channel=LABEL - channel to include in dump
--dir=DIRECTORY - preexisting directory to put content into

Note
The Inter-Satellite Sync (ISS) feature allows Satellite servers that are connected to each
other to synchronize software channel content with each other. Normally there is a master/
slave relationship between servers, but bi-directional synchronization between two servers is
also possible.

References
rhn-satellite-exporter(8) man page
Red Hat Network Satellite Installation Guide
Section 6.4: Inter-Satellite Sync
Section 6.5: Using Inter-Satellite Sync

RH401-6-en-1-20110713

181

Chapter11.RHN Satellite Server Administration

Practice Exercise

Exporting Custom Child Software Channel Content


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Backing up the RHN Satellite embedded database does not preserve custom software channel
content. Use rhn-satellite-exporter to backup your custom software channel content.
1.

Log in as root on desktopX and display the list of software channels currently in your RHN
Satellite Server. Take note of the labels of the channels you want to save and the names of
their parent channel.

2.

Create a directory called custom-dump. Export the software channel content for the
example-custom channel into custom-dump so it can be taken and imported into another
disconnected Satellite Server.

3.

Confirm the channel content is usable with the satellite-sync command. Check
carefully and be sure the example-custom channel appears in the output of satellitesync.

182

RH401-6-en-1-20110713

High Availability Options

High Availability Options


Some companies demand high availability Red Hat Network services within their datacenters.
The following solutions maintain high availability at differing expense levels in terms of cost and
maintenance.
One solution would be to implement RHN Satellite services on a high availability cluster. The
services could be gracefully migrated to another node in the cluster during scheduled downtimes
and would failover in the event of a crash.
Larger corporations which have multiple Satellite servers can configure them in a horizontally
tiered topology. Section 3.2 of the Red Hat Network Satellite 5.4 Installation Guide provides more
details on this approach. It would require more maintenance to keep the content of the peers
synchronized. Client machines would be configured to get updates from multiple servers. The
servers are prioritized according to the order they appear in /etc/sysconfig/rhn/up2date:
serverURL[comment]=Remote server URL
serverURL=https://primary.satellite.fqdn/XMLRPC; https://backup.satellite.fqdn/XMLRPC

Another possible solution would be to clone a Satellite Server with an embedded database
and keep a hot spare available. This process involves installing a second Satellite Server and
synchronizing the database of the primary Satellite with the backup on a daily basis. Section 8.5
of the Red Hat Network Satellite 5.4 Installation Guide provides more details on this approach.

References
Red Hat Network Satellite Installation Guide
Section 8.5: Cloning the Satellite with Embedded DB
Section 8.6: Establishing Redundant Satellites with Stand-Alone DB

RH401-6-en-1-20110713

183

Chapter11.RHN Satellite Server Administration

Troubleshooting Satellite Server Issues


Before we have seen that the rhn-satellite command is used to start and stop all of
the daemons that implement Red Hat Network Satellite services. This tool can also display
general status information about those daemons as well when passed the status argument.
Additionally the status of the individual components of Red Hat Network can be checked using
init scripts:
[root@host ~]# service oracle status
Oracle Net Listener (pid 2842) is running...
Oracle DB instance rhnsat (pid 2854) is running...
[root@host ~]# service httpd status
httpd (pid 3514) is running...
[root@host ~]# service taskomatic status
RHN Taskomatic is running (3886).

Once a service has been identified as having problems, examining its log files is the next logical
step in troubleshooting. Since RHN Satellite has many components, there are a variety of log
files that could contain useful information. Debugging can be made more verbose by defining
a debug value in /etc/rhn/rhn.conf. The possible values for debug range from 0 (disables
most debug statements) to 6 (this is as verbose as it gets).
Although some daemons write log messages in the system-wide log file, /var/log/messages,
many RHN daemons have their own log files:
db-control operations and messages - /var/log/rhn/rhn_database.log
Messages related to push events to client systems - /var/log/rhn/osa-dispatcher.log
Log files for the Apache component - /var/log/httpd/*
Messages pertaining to Java support - /var/log/tomcat5/catalina.out
Messages concerning RHN scheduled tasks - /var/log/rhn/
rhn_taskomatic_daemon.log
Messages relevant to provisioning - /var/log/cobbler/*
Red Hat Network also uses e-mail notifications. Make sure the traceback_mail variable in /
etc/rhn/rhn.conf points to the e-mail address that should receive error message e-mails
from the Satellite Server.
E-mail messages that originate from the Satellite Server appear to come from the user devnull@satellite.fqdn. Define a value for web.default_mail_from in /etc/rhn/
rhn.conf to have a legitimate e-mail address appear in notifications.
DNS issues
If you see host not found on the clients, make sure DNS is working and the host name of the
Satellite Server resolves. If the web server on the Satellite server produces Could not determine
the server's fully qualified domain name, check /etc/hosts and make sure the entry for
127.0.0.1 only refers to localhost entries.
Connection errors

184

RH401-6-en-1-20110713

Troubleshooting Satellite Server Issues

Make sure the clients and server are using the same time (best to synchronize with NTP). Also
make sure the SSL certificate for the Satellite server hasn't expired:
[root@host ~]# openssl x509 -dates -noout -in FILE

where FILE is /etc/httpd/conf/ssl.crt/server.crt on the Satellite Server and /usr/


share/rhn/RHN-ORG-TRUSTED-SSL-CERT on the errant client.
Update agent (yum/up2date) errors
Sometimes the problem may be corrupt jabberd logs. Perform the following steps to resolve
this particular issue:
[root@host ~]# service jabberd stop
Shutting down Jabber router:
[ OK ]
[root@host ~]# rm -f /var/lib/jabberd/_db*
[root@host ~]# service jabberd start
Starting Jabber services
[ OK ]

It is recommended that you do not install extra software and you avoid subscribing to other
channels (such as Red Hat Developer Suite, Application Server, Extras, etc.) on the Satellite
Server. This will avoid installing incompatible RPM packages.
Some common problems
Not using FQDN for Satellite server URIs
Disk full?
DNS issues?
Connection errors
yum/up2date or push failing?

References
Red Hat Network Satellite Installation Guide
Chapter 7: Troubleshooting

RH401-6-en-1-20110713

185

Chapter11.RHN Satellite Server Administration

Personal Notes

186

RH401-6-en-1-20110713

Troubleshooting Satellite Server Issues

Unit Summary
RHN Satellite Database Management
In this section you learned how to:
Maintain the RHN Satellite embedded database
.
Satellite Server Management
In this section you learned how to:
Activate a new RHN Entitlement Certificate
Manage SSL certificates for secure communication
Connect a disconnected Satellite server to Hosted RHN
.
Software Channel Synchronization
In this section you learned how to:
Export software channel content
.
High Availability Options
In this section you learned how to:
Configure a hot-spare Satellite Server
.
Troubleshooting Satellite Server Issues
In this section you learned how to:
Troubleshoot common Satellite server issues
.

RH401-6-en-1-20110713

187

188

Chapter12.

UNIT TWELVE

RHN APPLICATION
PROGRAMMING INTERFACE
Introduction
Topics covered in this unit:
Uses for Red Hat Network API
Basic API program structure
Sample API scripts
RHN Satellite reporting tool

RH401-6-en-1-20110713

189

Chapter12.RHN Application Programming Interface

Application Programming Interface Scripting


Red Hat Network API
The Red Hat Network Application Programming Interface (API) provides a mechanism that allows
programmers to write programs which interact with a RHN Satellite Server. Many tasks that can
be performed through the web user interface can also be accomplished by the methods provided
by the RHN API.
The API extends the functionality of RHN because it allows scripts to replace repetitive tasks that
would be extremely difficult to do using the web interface This added functionality facilitates
automation and scalability within the enterprise.

Supported Programming Languages


XML-RPC is a client/server remote procedure call communications protocol that uses XML tags
to encode its messages. It uses the HTTP protocol as its transport mechanism.
Perl scripts that interact with the Red Hat Network API typically use the Frontier::Client
modules provided by the perl-Frontier-RPC package. The perl-Frontier-RPC RPM is not
provided as part of the standard Red Hat Enterprise Linux channels. It is provided as part of the
Red Hat Network Satellite software channel.
The python RPM provides, xmlrpclib, a library that implements XML-RPC client support. Since
it is part of the standard Python installation, no additional packages are required to write Python
scripts that use the Red Hat Network API.

RHN API Program Structure


Before calling any Red Hat Network API methods, an XML-RPC connection must be established
with the RHN server. This is the scripted parallel to using a URL with a browser to connect to the
server.
Next the login method in the auth namespace is called with a valid RHN login and password
to authenticate into the RHN server. The session key returned by the method is passed as an
argument to other method calls. This session key represents an authenticated user's access to
the RHN server and determines which privileges and access is given to the other methods. For
example, many of the user namespace methods will only work with a session key generated by
the successful authentication by the Satellite Administrator or Organization Administrator to
access information about other RHN users on the system. Also queries and changes will be made
within the organization of the authenticated user.

API Namespaces and Methods


api
Provides getVersion and systemVersion methods
preferences
Methods for locale and timezone configuration
proxy

190

RH401-6-en-1-20110713

API Namespaces and Methods

Provides methods to manage RHN Proxies


satellite
Provides RHN Satellite management methods
auth
Provides login and logout methods
org
Provides methods for Organization management
user
Provides methods for RHN user administration
channel
Provides methods for managing Software Channels
configchannel
Provides methods for Configuration Channel management
errata
Provides methods to manage RHN errata
packages
Methods that search for and deletes packages within RHN
activationkey
Provides methods for managing Activation Keys
kickstart
Provides methods to manage kickstart profiles
schedule
Methods to search and manage scheduled events
system
Provides methods for queries and management of registered systems
systemgroup
Provides methods for System Group administration

RH401-6-en-1-20110713

191

Chapter12.RHN Application Programming Interface

Sample Python Script


#!/usr/bin/python
import xmlrpclib
URL = "https://satellite.example.com/rpc/api"
user = "rhn-username"
pswd = "rhn-password"
client = xmlrpclib.Server(URL, verbose=0)
session = client.auth.login(user, pswd)
list = client.user.list_assigned_system_groups(session, user)
for group in list:
print group.get('name')
client.auth.logout(session)

The Python script above lists the system groups that the user rhn-username can manage.
It connects to the Satellite Server and authenticates as rhn-username with the password
of rhn-password. The listAssignedSystemGroups method in the user namespace is
called to generate a list of system groups that rhn-username (passed as the variable user)
can administrate. The for loop prints the name field of each of the values in the list of system
groups.
This script should work as long as rhn-username is a valid Red Hat Network user. Permissions
aren't an issue since the user authenticating is accessing his own system group information. If
this script were used to inspect the system groups of other users, it would have to authenticate
as an Organization Administrator.

Sample Perl Script


#!/usr/bin/perl
use Frontier::Client;
my $URL = 'https://satellite.example.com/rpc/api';
my $user = 'rhn-username';
my $pass = 'rhn-password';
my $client = new Frontier::Client(url => $URL);
my $session = $client->call('auth.login', $user, $pass);
my $systems = $client->call('system.listUserSystems',
$session);
foreach my $system (@$systems) {
print $system->{'name'}."\n";
}
$client->call('auth.logout', $session);

The Perl script above lists the systems the user named rhn-username can manage. It connects
to the Satellite Server and authenticates as rhn-username with the password of rhnpassword. The listUserSystems method in the system namespace is called to generate a
list of systems that rhn-username can administrate. The foreach loop prints the name field of
each of the values in the list of systems.

192

RH401-6-en-1-20110713

Sample Perl Script

This script should work as long as rhn-username is a valid Red Hat Network user. Permissions
aren't an issue since the user authenticating is accessing his own system group information.
The listUserSystems method can take a second argument which would be a user's login
name, but since it is omitted in this example it lists the systems managed by the authenticated
RHN user. If this script were used to list the systems owned by other users, then it would have to
authenticate as an Organization Administrator.

References
Red Hat Network Satellite API Documentation
http://satellite.fqdn/rhn/apidoc/

RH401-6-en-1-20110713

193

Chapter12.RHN Application Programming Interface

Practice Exercise

Getting Started with the Red Hat Network API


Carefully perform the following steps. Ask your instructor if you have problems or questions.
This exercise will introduce you to the Red Hat Network API. Modify two versions of a script
written in Perl and Python so that they successfully query your RHN Satellite Server.
1.

There is a Perl script, list-users.pl, and a Python script, list-users.py, which list all
the users within an Red Hat Network organization. The scripts can be found in the /misc/
instructor/materials/rhn-api directory.
Log in as stan on desktopX, copy the scripts, and modify them so they will successfully
query your Satellite Server and list the users in the Example Inc. organization.
Optional - Use revision control software to log and manage the changes you make to your
copies of the scripts.

2.

194

Modify one of your working scripts to authenticate as the Satellite Administrator. How does
this affect the behavior of the script?

RH401-6-en-1-20110713

Sample Perl Script

Practice Exercise

Using the Red Hat API to Produce Reports


Carefully perform the following steps. Ask your instructor if you have problems or questions.
Modify one of the provided scripts to produce a useful report by using the Red Hat Network API
to get more detailed information about the users from your Satellite Server.

Write a script, list-user-roles.pl or list-user-roles.py, that lists all of the users


within the Example Inc. organization. Print the following information about each user: their
login name and the list of their RHN administrative roles.
Copy one of your working scripts as a starting point for your new script. Optionally maintain
your script with revision control software.

RH401-6-en-1-20110713

195

Chapter12.RHN Application Programming Interface

RHN Satellite Reporting Tool


Satellite Reporting Tool
The Satellite Reporting Tool, spacewalk-report, is a command-line tool that produces a
handful of CSV reports with information found in the RHN Satellite server database. This tool
must be executed from a shell by root on the Satellite server. spacewalk-report has a useful
--help option that lists the reports it provides when executed without an argument:
[root@host ~]# spacewalk-report --help
usage: /usr/bin/spacewalk-report [options] [report_name]
... Output omitted ...
[root@host ~]# spacewalk-report
errata-list
entitlements
inventory
users-systems
errata-systems
users

This reporting tool queries the Satellite database directly and bypasses the RHN API
which means it has access to all of the data stored in the database. Red Hat Network user
authentication isn't required and the reports aren't confined to a single user or an organization's
view of the data. Each report prints a header on the first line of output and the --listfields-info option provides a brief description of each of the fields:
[root@host ~]# spacewalk-report inventory | head
server_id,profile_name,hostname,ip_address,registered_by,...
1000010000,station139.example.com,station139.example.com,192.168.0.139,satadmin,...
... Output omitted ...
[root@host ~]# spacewalk-report --list-fields-info inventory | head -n 5
server_id: System identifier
profile_name: Profile name, as stored on server
hostname: Hostname, as reported by the system
ip_address: IP address, as reported by the system
registered_by: User under which the system is registered

The Satellite Reporting Tool was a later feature added because of customer demand so it is
not provided as part of the standard RHN Satellite 5.3.0 installation media. The spacewalkreports RPM is provided by the redhat-rhn-satellite software channel and can be
installed after a Satellite server is installed and registered with Red Hat Network.

References
spacewalk-report(8) man page

196

RH401-6-en-1-20110713

Criterion Test

Test

Criterion Test
Exercise

Using the RHN API to Perform Satellite


Administration
Carefully perform the following steps. Ask your instructor if you have problems or questions.
Write a couple Red Hat Network API scripts that perform RHN Satellite administration functions.
1.

Write two scripts that use the Red Hat Network API to administrate users. The userdisable.pl, or user-disable.py, script should deactivate a RHN user account. Its
positive counterpart, user-enable.pl or user-enable.py, should reactivate an existing
user account. Use a program variable for the RHN login to be enabled/disabled.
These programs don't have to be fancy, they just have to be functional. There is no need to
process command-line arguments or do extensive error checking.
Optionally use revision control software to manage the changes you make to your new
script.

2.

Use one of your scripts to disable the channelman account. Go into the RHN Satellite web
interface and verify his account has been disabled. Execute the other script to reactivate his
account and verify that channelman can log into your Satellite Server.
Optionally commit your changes to Subversion once your scripts are working and debugged.

RH401-6-en-1-20110713

197

Chapter12.RHN Application Programming Interface

Personal Notes

198

RH401-6-en-1-20110713

Criterion Test

Unit Summary
Application Programming Interface Scripting
In this section you learned how to:
Write simple reports with the Red Hat Network API
Use the RHN API to perform Satellite administration
.
RHN Satellite Reporting Tool
In this section you learned how to:
Perform queries with the RHN Satellite Reporting Tool
.

RH401-6-en-1-20110713

199

200

Chapter13.

UNIT THIRTEEN

COMPREHENSIVE REVIEW

RH401-6-en-1-20110713

201

Chapter13.Comprehensive Review

Preparations/Do You Still Have Questions?


This unit is the final, comprehensive review for this course. Hopefully it will give you an
opportunity to see see how much you have learned and to solidify the content that was learned.
To prepare for the hands-on comprehensive review, cable both of your workstations to the
classroom network. PXE provision desktopX with a minimal RHEL 5 installation and desktopY
as a RHEL 6 workstation. Once desktopY finishes installing, cable it back to the second NIC of
desktopX.
As the machines reinstall, let's spend a few minutes reviewing any of the topics introduced in this
course that you feel uncomfortable with.

202

RH401-6-en-1-20110713

Practice Resequencing Exercise

Provisioning with a RHN Satellite Server


Below are the steps you will take to deploy a provisioning Red Hat Network Satellite server. Take
5-10 minutes to prioritize and order the following steps. We will discuss them as a class before
you begin to implement them.
Configure desktopX to serve as a Subversion repository.
Clone the RHEL 6 Server base channel and all of its child channels.
Create a kickstart profile.
Import the relevant Red Hat software channels into the Satellite server.
Install desktopX with Red Hat Network Satellite software.
Prepare software channel content for import into the RHN Satellite.
Deploy DHCP on desktopX and configure it to support PXE.
Build and sign a custom RPM package on desktopY.
Configure desktopX as a routing gateway for the backend network.
Create a RHN system group.
Create an activation key to automate system registration.
Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel.
Provision the client system using PXE menu.
Create RHN user accounts, assign appropriate roles, and allow them to administrate a
common system group.
Import GPG keys into the Satellite server for deployment.
Create a Red Hat Network organization and assign it system and software subscriptions.
Import the open source project code into the Subversion repository.

RH401-6-en-1-20110713

203

Chapter13.Comprehensive Review

Test

Criterion Test
Case Study

Red Hat Network Satellite Server Deployment


Requirements
The following are the specifics for setting up your Red Hat Network Satellite server and client
machine. desktopX should already be installed with a minimal RHEL 5 installation and desktopY
will serve as your client server and should be installed with RHEL 6 server.
The requirements for this review are specified in more detail below. They aren't necessarily listed
in the order they are to be performed.
Install desktopX as a Red Hat Network Satellite software. The materials you need to perform
the installation can be found in the /misc/instructor/rh401-satellite directory on
desktopX. The installation ISO is named satellite-embedded-oracle-5.4.0-20101025rhel-5-x86_64.iso. Activate the Satellite server using the certificate named redhatgls-maximum-5.4.cert.
After the Satellite server is installed, create a satellite administrator account with a login of
rhnsatadm and a password of redhat.
Prepare software channel content for import into the RHN Satellite. The content ISO's are in
the rh401-satellite directory in a sub-directory called sat-rhel6-content.
Import the Red Hat software channels into the Satellite server that will support provisioning of
RHEL 6 Servers.
Configure desktopX as a routing gateway for the backend network. The network addresses will
be in the 10.100.X.0 subnet with a netmask of 255.255.255.0. The second network interface
of desktopX should have a static address of 10.100.X.254. Ensure IPv4 packet forwarding is
enabled persistently in the kernel.
Deploy DHCP on desktopX and configure it to support PXE provisioning. Determine the MAC
address of desktopY and have DHCP consistently assign it the 10.100.X.7 IP address. Continue
to use 192.168.0.254 for DNS services.
Build a custom RPM package on desktopY for the bubbles application. Consult the README
and Makefile for information about building the package. Make sure both the binary
executable and README are provided by the binary RPM that you create. The README should
be classified as documentation by RPM.
Generate a GPG key pair and sign the package.
Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel. Set
the channel name to Custom Software with a label of custom-software. Specify the GPG
key information you will use to verify the signature of RPMS you create.

204

RH401-6-en-1-20110713

Create a Red Hat Network organization called Review Inc.. The organization administrator
should log in as review with a password of redhat. Assign all available entitlements to this
organization.
Create a RHN system group in the Review Inc. organization called Review Systems. Put
some meaningful text in the Description field.
Configure desktopX to serve as a Subversion repository. The top-level URL to access the
directory should be svn+ssh://desktopX/var/local/svn. Create a group called
svnusers and set permissions on the repository that allows all users in that group to create
new projects and modify files.
Create a user called builder on both systems. This user should be a member of the
svnusers group on desktopX. Also create ssh keys on desktopY and deploy them so builder
can check in files to the repository without providing a password.
Create RHN user accounts, assign appropriate roles, and allow them to administrate systems in
the Review Systems system group according to the following table:
Login

swadmin

cfgadmin

Password

redhat

redhat

Roles

Channel Administrator

Configuration Administrator

Import the open source project code for the "bubbles" program into the Subversion repository.
The source code for this program can be found at the following URL: http://instructor/
pub/materials/bubbles-1.0.tar.gz.
Clone the RHEL 6 Server base channel and all of its child channels. Prefix the channel names
with "Development" and the channel labels should have a "dev-" prefix.
Create an activation key to automate system registration. The key ID should be review-reg.
It should register systems in the Review Inc. organization. Systems should join the Review
Systems system group. They should also subscribe to cloned base software channel and rhntools and custom cloned channels. Also allow for configuration file provisioning and subscribe
to the Review Configurations configuration channel.
Create a kickstart profile. It should register the provisioned system with the review-server
activation key for Review Inc. It should install the web-server package group and update all
available errata during its installation. The bubbles custom package should be installed and
any available configuration files should be deployed.
Create a configuration channel called Review Configurations with a label of reviewconfigs. It provides /etc/issue which should contain the following text:
Red Hat Enterprise Linux Server release 6.0 (Santiago)
Kernel \r on an \m
Review Inc.

Import GPG keys into the Satellite server for deployment. Import the standard Red Hat key,
RPM-GPG-KEY-redhat-release, and the GPG key used to verify custom packages.

RH401-6-en-1-20110713

205

Chapter13.Comprehensive Review

Provision the client system using PXE menu provided by Cobbler. Confirm that it installed
properly and is properly configured.
How would you address the case study described above? Take notes on your process in the
space below and then implement it.

206

RH401-6-en-1-20110713

Personal Notes

RH401-6-en-1-20110713

207

208

AppendixA.Solutions
Essential System Management
Fill in the enterprise best practices below and take notes as your instructor explains them:
1.

Standardization

2.

Centralization

3.

Scalability

4.

Provisioning

5.

Automation

Practice Resequencing Exercise

Enterprise Management Best Practices


For each of the keywords below, write down the number of its definition from the list at the
bottom.
2
5
1
3
4

Standardization
Centralization
Scalability
Provisioning
Automation

1.

Growth in capacity with minimal system administrator impact.

2.

Performing tasks with the same, well thought out method each and every time.

3.

The process 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.

4. Generally requires more upfront work. Investing time writing kickstart files allows one to
install more systems simultaneously and more quickly than could be achieved by hand.

RH401-6-en-1-20110713

209

AppendixA.Solutions

5.

Gather policies, procedures, and baselines into one easily managed system.

Practice Exercise

PXE Boot
The purpose of this exercise is to become familiar with the PXE capabilities of the classroom
hardware. You will also look at the menu and capabilities that are provided by the classroom
provisioning environment. You will not be installing your workstations - that is for a later
exercise.
1.

PXE boot one of your two machines, either of your machines will work.
Initiating a PXE installation usually involves pressing one of the F-keys. F12 is often the key
that will allow you to choose which method to boot.

2.

In the PXE menu, edit the Install minimal RHEL 5 for RHN Satellite use option. What are
the two options included for Kickstart?
Use the arrow keys to select the Install minimal RHEL 5 for RHN Satellite use option and
press Tab. The options used for Kickstart are:

ksdevice=eth0

This option forces the Kickstart installation to use the eth0 network device.

ks=http://instructor.example.com/satellite.cfg

This option shows that the Kickstart file comes from the instructor web server.

Test

Criterion Test
Exercise

Provisioning Preview
Before you begin...
You have two servers: desktopX and desktopY. Both servers are currently connected
to the classroom network (192.168.0.0/24) which includes the instructor's machine,
instructor.example.com. desktopX should be equipped with two Ethernet interfaces.
Let's preview the capabilities and conveniences of a bare-metal provisioning environment. The
instructor's machine, instructor.example.com, has been configured to provide bare-metal
provisioning services. Your task is to configure both of your servers to PXE-boot and kickstart
themselves.

210

RH401-6-en-1-20110713

1.

Reboot desktopX and go into the system BIOS configuration screens and make adjustments
so desktopX will attempt to PXE boot from the network. Ask your instructor for help since
this process can vary between various classroom environments.

2.

Reboot desktopX, but this time allow it to PXE boot from the network. If everything is
properly configured, you should be presented with a PXE boot menu similar to the following:

Choose the Install minimal RHEL 5 for RHN Satellite use option without any arguments
to begin the installation. While the installation begins, repeat these steps on your second
server, desktopY. Be sure to choose the Install minimal RHEL 5 for RHN Satellite use option
without any arguments to begin the installation.

RH401-6-en-1-20110713

211

AppendixA.Solutions

Installing a Red Hat Network Satellite Server


Advantages of RHN Satellite Server
Five major advantages of using RHN Satellite server include:
1.

Security

2.

Efficiency

3.

Control

4.

Customization

5.

Scalability

Practice Performance Checklist

Installing Red Hat Network Satellite Software


Before you begin...
You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopX.
Install RHN Satellite software on your provisioning server, desktopX.
Copy the sample RHN Entitlement Certificate, redhat-gls-minimal-5.4.cert,
from the instructor's machine to root's home directory (~). This file can be found in the
automounted /misc/instructor/rh401-satellite directory.
[root@desktopX ~]# cd /misc/instructor/rh401-satellite
[root@desktopX rh401-satellite]# cp redhat-gls-minimal-5.4.cert ~

Copy the satellite-embedded-*.iso image found on the instructor's machine to /


tmp then mount it using a loopback device to /mnt. Don't execute /mnt/install.pl.
We will use this script shortly. Instead list the contents of /mnt/install and look
for a file called answers.txt. This file can be modified and used with install.pl
to perform an unattended installation of the RHN Satellite Server software. Copy
answers.txt to root's home directory.
[root@desktopX rh401-satellite]# cp satellite-*.iso /tmp

212

RH401-6-en-1-20110713

[root@desktopX rh401-satellite]# mount -o loop /tmp/satellite-*.iso /mnt


[root@desktopX rh401-satellite]# cp /mnt/install/answers.txt ~

Use your favorite text editor to modify root's answers.txt file. Find the following
variable definitions and make all necessary adjustments:
# RHN Satellite Server administrator
admin-email = root@desktopX.example.com
# Satellite Server
ssl-set-org
=
ssl-set-org-unit =
ssl-set-city
=
ssl-set-state
=
ssl-set-country =
ssl-set-email
=
ssl-password
=

CA certificate info
Red Hat Inc.
Training
your city
your state
your two-letter country code
root@desktopX.example.com
a password you can remember

# Location of RHN Satellite Entitlement certificate


satellite-cert-file = /root/redhat-gls-minimal-5.4.cert
run-updater = yes
ssl-config-sslvhost = yes
enable-tftp = yes

Although comments in the file suggest ssl-set-mail defaults to the value of adminemail, that is not the case and the installer will stop and prompt you for the SSL email address. Also the run-updater, ssl-config-sslvhost, and enable-tftp
directives either do not exist or are commented in the sample answers.txt file.
Uncomment them or add them to the file as needed.
Double check your modifications to your answers.txt file because the Satellite Server
install process takes a long time. It is best to catch mistakes sooner than later.
[root@desktopX rh401-satellite]# vi ~/answers.txt

Begin the Satellite Server installation process using your answers file. Be sure to specify
the option to install the software so it will operate without an external connection to
Red Hat Network. Monitor the log files that are created during the installation process to
ensure the installation is functioning properly.
[root@desktopX rh401-satellite]# /mnt/install.pl --disconnected --answer-file=/
root/answers.txt

install.pl installs all necessary RHN software, imports Red Hat's RHN entitlement
certificate, then creates and populates its database. The installation should be totally
hands free when an answer file is provided. The installer will prompt the user for
questions when either the answer file name is misspelled or one of the answers in the file
is misspelled or omitted.
Log information can be found in /var/log/rhn/*. Use watch ls -l /var/log/rhn
in another window to view the logs that get created by install.pl. As log files in this
directory get created or grow you may want to use tail -f to briefly observe what gets
written to them.

RH401-6-en-1-20110713

213

AppendixA.Solutions

Once the SSL certificate has been generated and imported into the Satellite Server,
install.pl will restart the Satellite Server then exit. A URI will be displayed which you
can use with a browser to complete the installation process.
Launch a web browser and visit the URI displayed by install.pl: https://
desktopX.example.com. Examine the certificate offered to your browser and see if
you recognize some of the values about the certificate subject and the issuer. Once you
are satisfied with the contents of the certificate, accept it into your browser permanently.
Create a RHN user called satadmin with a password of redhat. The e-mail address
for this account should be root@desktopX.example.com. Provide your name for the
additional account information. You are now logged in as the Satellite Administrator,
satadmin, of a functioning Red Hat Network Satellite Server.
Unmount the ISO image from /mnt since the installation of the RHN Satellite Server
software is complete.
A URI will be displayed which you can use with a browser to complete the installation
process. Launch a web browser and visit the URI displayed by install.pl and fill in the
following fields:
Field

Value

Desired Login

satadmin

Desired Password

redhat

First, Last Name

Provide your name

E-mail

root@desktopX.example.com

Click the Create Login button to confirm your selections. You are now logged in as the
Satellite Administrator, satadmin, of a functioning Red Hat Network Satellite Server.
Unmount the ISO image from /mnt:
[root@desktopX rh401-satellite]# umount /mnt

Use yum to install updated packages for the Red Hat Network Satellite Server software.
The classroom kickstart process configures yum to point to repositories provided by the
instructor's server. After the packages have been updated, restart your Satellite Server.
[root@desktopX ~]# yum -y update

Restart your Satellite Server after the Satellite software has been updated. For now,
reboot the server. You will learn more graceful ways of controlling the Satellite Server in
a later unit.
[root@desktopX rh401-satellite]# reboot

214

RH401-6-en-1-20110713

Practice Performance Checklist

Preparing Channel Content for Import


Before you begin...
The RHN Satellite software installation on your desktopX machine should be completed.
Channel content ISOs are available from the instructor's machine, instructor.example.com.
Extract their contents into a common directory on your Satellite server, desktopX, so the channel
content can be imported in a later lab exercise.
The first step to take is make sure you have enough disk space to extract the content
ISOs. They will require over 8 GB of space. Notify your instructor if you don't have
enough room on your machine to extract them.
[root@desktopX ~]# df -h

The content ISOs are published to the classroom in the /misc/instructor/rh401satellite/sat-rhel6-content/ directory. Mount the content ISOs using a loop
interface to /mnt and copy the contents of both ISOs to a directory called /root/satrhel6-content/.
[root@desktopX
[root@desktopX
[root@desktopX
*-01.iso /mnt
[root@desktopX
[root@desktopX

~]# mkdir sat-rhel6-content


~]# cd /misc/instructor/rh401-satellite/sat-rhel6-content/
sat-rhel6-content]# mount -o loop rhn-export-rhel-x86_64-6sat-rhel6-content]# rsync -aPv /mnt/* /root/sat-rhel6-content
sat-rhel6-content]# umount /mnt

Repeat the above steps for the second channel content ISO.
[root@desktopX sat-rhel6-content]# mount -o loop rhn-export-rhel-x86_64-6*-02.iso /mnt
[root@desktopX sat-rhel6-content]# rsync -aPv /mnt/* /root/sat-rhel6-content
[root@desktopX sat-rhel6-content]# umount /mnt

Practice Performance Checklist

Populating RHN Satellite with RHEL6 Software


Before you begin...
The RHN Satellite software installation on your desktopX machine should be completed and RHN
channel content from both ISOs should be expanded into the /root/sat-rhel6-content/
directory on that server.
Import the RHN base channel content for the Red Hat Enterprise Linux 6 Server software for 64bit x86 machines into your RHN Satellite server.
The first software channel to be imported into a RHN Satellite 5.4 server takes much
more time to import that subsequent channels. To conserve time, import the onerpm-channel base software channel published in the /misc/instructor/rh401satellite/one-rpm-channel.tar tar archive. Change into root's home directory

RH401-6-en-1-20110713

215

AppendixA.Solutions

on desktopX, extract the archive, import the one-rpm-channel software channel, then
reboot your Satellite server before importing the Red Hat software channels.
[root@desktopX sat-rhel6-content]# cd
[root@desktopX ~]# tar xvf /misc/instructor/rh401-satellite/one-rpm-channel.tar
one-rpm-channel/
one-rpm-channel/rpms/
... Output omitted ...
[root@desktopX ~]# satellite-sync -m one-rpm-channel --list-channels
09:24:17 Red Hat Network Satellite - file-system synchronization
09:24:17
mp: /root/one-rpm-channel
09:24:17
db: rhnsat/<password>@rhnsat
09:24:17
09:24:17 Retrieving / parsing channel-families data
09:24:17 channel-families data complete
09:24:17
09:24:17 Retrieving / parsing channel data
09:24:17
p = previously imported/synced channel
09:24:17
. = channel not yet imported/synced
09:24:17
base-channels:
09:24:17
. one-rpm-channel
1
09:24:17
Import complete:
Begin time: Fri Jun 10 09:24:17 PDT 2011
End time:
Fri Jun 10 09:24:17 PDT 2011
Elapsed:
0 hours, 0 minutes, 0 seconds
[root@desktopX ~]# satellite-sync -m one-rpm-channel -c one-rpm-channel
... Output omitted ...
[root@desktopX ~]# reboot

Log back into desktopX as root. The sat-rhel6-content directory below root's home
directory contains the software channel content needed to deploy Red Hat Enterprise
Linux 6 Server.
Before you populate the database with RPMs and other information for a particular
channel you must first find out which channels are available. Which software channels
are provided by the content in the sat-rhel6-content directory?
Run the following command to identify which software channels are provided by the
content in the sat-rhel6-content directory:
[root@desktopX ~]# satellite-sync -m /root/sat-rhel6-content --list-channels
09:38:39 Red Hat Network Satellite - file-system synchronization
09:38:39
mp: /root/sat-rhel6-content
09:38:39
db: rhnsat/<password>@rhnsat
09:38:39
09:38:39 Retrieving / parsing channel-families data
09:38:40 channel-families data complete
09:38:40
09:38:40 Retrieving / parsing channel data
09:38:40
p = previously imported/synced channel
09:38:40
. = channel not yet imported/synced
09:38:40
base-channels:
09:38:40
. rhel-x86_64-client-6
2911
09:38:40
. rhel-x86_64-server-6
3583
... Output omitted ...
09:38:40
rhel-x86_64-server-6:
09:38:40
. rhel-x86_64-server-fastrack-6
0

216

RH401-6-en-1-20110713

Criterion Test

... Output omitted ...


09:38:40
. rhn-tools-rhel-x86_64-server-6
... Output omitted ...

21

Now that you have determined which channels are available, import the rhel-x86_64server-6 channel data from the sat-rhel6-content directory into your Satellite
Server's database. This process takes a very long time to complete.
[root@desktopX ~]# satellite-sync -m /root/sat-rhel6-content -c rhel-x86_64server-6

Use a web browser to browse https://desktopX.example.com, where X is the


machine number of your Satellite Server. You probably want to bookmark this page since
you will refer to it often in upcoming lab exercises.
Log in as the Satellite Administrator, satadmin. Navigate around the web site,
particularly looking at the Errata, Channels, Users, and Admin tabs.
Your RHN Satellite Server is now installed and will be ready to be used by clients when
the channel content sync is complete. In a later lab you will configure clients to use this
server.

Test

Criterion Test
Case Study

Deploying a RHN Satellite Server


Before you begin...
You should have a Red Hat Enterprise Linux 5 Server with a minimal installation on desktopY.
Your department deploys and manages several servers running Red Hat Enterprise Linux. Your
facility is an extremely secure site so you don't have access to hosted Red Hat Network services
via the Internet. Your manager has invested in a Red Hat Network Satellite software to manage
your systems.
Your task is to install the RHN Satellite software on your desktopY machine and load it with
the software channels needed to deploy Red Hat Enterprise Linux 6 Server systems. All of the
material you need to install the system can be found in the /misc/instructor/rh401satellite directory. Use the redhat-gls-minimal-5.4.cert RHN Entitlement Certificate
to activate the server.
When you install the Satellite server, make sure the SSL CA certificate information is specified as
follows:
Organization = Red Hat Inc.
Organization Unit = Training
City = your city

RH401-6-en-1-20110713

217

AppendixA.Solutions

State = your state


Country = your two-letter country code
Also specify root@desktopY.example.com for all e-mail addresses requested during
installation.
The Satellite Administrator should log in as satadmin with a password of redhat.
1.

First, mount the RHN Satellite software installation DVD and copy the answers.txt file
from the install subdirectory. Modify the answers.txt file to allow for an automated
installation.
[root@desktopY ~]# cd /misc/instructor/rh401-satellite
[root@desktopY rh401-satellite]# cp redhat-gls-minimal-5.4.cert ~
[root@desktopY rh401-satellite]# rsync -aPv satellite-*.iso /tmp
... Output omitted ...
[root@desktopY rh401-satellite]# cd
[root@desktopY ~]# mount -o loop /tmp/satellite-*.iso /mnt
[root@desktopY ~]# cp /mnt/answers.txt ~
[root@desktopY ~]# vim /root/answers.txt

Add/change the following in answers.txt:


admin-email = root@desktopY.example.com
ssl-set-org
= Red Hat Inc.
ssl-set-org-unit = Training
ssl-set-city
= your city
ssl-set-state
= your state
ssl-set-country = your two-letter country code
ssl-set-email
= root@desktopY.example.com
ssl-password
= a password you can remember
satellite-cert-file = /root/redhat-gls-minimal-5.4.cert
run-updater = yes
ssl-config-sslvhost = yes
enable-tftp = yes

2.

Run the install.pl script with the --disconnected and --answer-file options. Make
sure you specify the absolute path name of your answers.txt file.
[root@desktopY ~]# /mnt/install.pl --disconnected --answer-file=/root/answers.txt

3.

After the RHN Satellite installer completes, access the URL printed by the installer
and create a RHN account for the Satellite Administrator. Open a browser and point to
https://desktopY.example.com. Create a user called satadmin with a password of
redhat. Use your name as the full name and provide root@desktopY.example.com for
the e-mail address.

4.

Update all of the Satellite packages and reboot desktopY.


[root@desktopY ~]# umount /mnt
[root@desktopY ~]# yum update -y
[root@desktopY ~]# reboot

218

RH401-6-en-1-20110713

Criterion Test

5.

Use satellite-sync to import the one-rpm-channel base channel then reboot


desktopY again. Remember the import of larger channels to work more quickly when this
step is taken first.
[root@desktopY ~]# tar xvf /misc/instructor/rh401-satellite/one-rpm-channel.tar
one-rpm-channel/
one-rpm-channel/rpms/
... Output omitted ...
[root@desktopY ~]# satellite-sync -m one-rpm-channel -l
10:17:53 Red Hat Network Satellite - file-system synchronization
10:17:53
mp: /root/one-rpm-channel
10:17:53
db: rhnsat/<password>@rhnsat
... Output Omitted ...
[root@desktopY ~]# satellite-sync -m one-rpm-channel -c one-rpm-channel
... Output Omitted ...
[root@desktopY ~]# reboot

6.

Extract both of the RHN Satellite content ISOs into a local directory on desktopY.
[root@desktopY ~]# mkdir /root/sat-rhel6-content
[root@desktopY ~]# cd /misc/instructor/rh401-satellite/sat-rhel6-content
[root@desktopY sat-rhel6-content]# mount -o loop rhn-export-rhel-x86_64-6-*01.iso /mnt
[root@desktopY sat-rhel6-content]# rsync -aPv /mnt/* /root/sat-rhel6-content
... Output omitted ...
[root@desktopY sat-rhel6-content]# umount /mnt
[root@desktopY sat-rhel6-content]# mount -o loop rhn-export-rhel-x86_64-6-*02.iso /mnt
[root@desktopY sat-rhel6-content]# rsync -aPv /mnt/* /root/sat-rhel6-content
... Output omitted ...
[root@desktopY sat-rhel6-content]# umount /mnt
[root@desktopY sat-rhel6-content]# cd

7.

Run satellite-sync to list the software channels provided by the content ISOs. Identify
the base channel that provides the Red Hat Enterprise Linux 6 Server software and use
satellite-sync to import that channel into your Satellite server.
[root@desktopY ~]# satellite-sync -m /root/sat-rhel6-content --list-channels
[root@desktopY ~]# satellite-sync -m /root/sat-rhel6-content -c rhel-x86_64-server-6

RH401-6-en-1-20110713

219

AppendixA.Solutions

Red Hat Network Organization


Practice Exercise

Organization Creation and Entitlement


Before you begin...
Students should have a functioning Red Hat Network Satellite Server, desktopX, installed with
Red Hat Enterprise Linux Server base channel content loaded.
Log in as the Satellite Administrator of your desktopX Satellite server. Create an organization
called Example Inc. and assign it entitlements for provisioning and managing Red Hat
Enterprise Linux Server systems.

Create an organization in your Red Hat Network Satellite Server named Example
Inc.. The Organization Administrator is Mr. Edward Example and he should log in
as example with a password of redhat. E-mail for this account should be sent to
root@desktopX.example.com.
System entitlements should be assigned to this new organization as follows:
Management: 3
Monitoring: 0
Provisioning: 1
Virtualization: 1
Virtualization Platform: 0
The following quantity of software entitlements should be assigned as well:
Red Hat Enterprise Linux Server (v. 6): 2
Red Hat Network Tools for RHEL (v. 6): 2
Log into the Satellite Server as the Satellite Administrator by opening a web browser
and navigating to https://desktopX.example.com. Provide satadmin for the RHN
Satellite Login and redhat for the Password. Go to the Admin tab and click the create new
organization link at the upper right-hand corner of the screen. Fill in the appropriate fields
in the Create New Organization form then click the Create New Organization button when
the form is complete.
The next screen to appear is the Subscriptions System Entitlements tab. Enter values for
the appropriate entitlement fields according to the specifications above. Click the Update
Organization button when the fields are filled in correctly.
Click on the Software Channel Entitlements tab and enter values according to the
specifications above. Click the Update Organization button when the fields are filled in
correctly.

220

RH401-6-en-1-20110713

Criterion Test

Practice Exercise

Creating User Accounts and Assigning Roles

Log in to the Satellite server on desktopX as the Organization Administrator for the
Example Inc. organization and create the following users as members of that
organization:
Standard user

Privileged user

Login

normal

grouper

Password

redhat

redhat

Full name

Mr. Norman Normal

Ms. Gladys Grouper

Roles

System Group User

System Group Administrator

Specify root@desktopX.example.com as the e-mail address for both RHN Satellite


accounts.
You must sign out of the satadmin account and log in as the Organization Administrator,
example, to associate the accounts with the Example Inc. organization. Select the Users
tab and click the create new user link displayed in the upper right-hand corner of the
screen. Fill in the fields for each user according to the above table and click Create Login
each time the form is completed.
No additional changes need to be made for the normal account because a System Group
User is a user without additional privileges or roles. Click on the login name/link for
grouper to bring up her account's detailed user information page. In the Details tab, check
the System Group Administrator check box in the Roles section then click the Submit
button to assign her additional privileges.

Practice Exercise

Managing System Groups


1.

Log in to the Satellite server on desktopX as the Organization Administrator for the
Example Inc. organization, if necessary, and create a system group called example
servers. Fill the group description with useful information of your choice.
Do not make any security adjustments or assign administrators to the new group. Examine
the initial access privileges for normal and grouper to the example servers group.
Select the Systems tab and click the System Groups menu item in the menubar at left. Click
the create new group link at the upper right and click the Create Group button after filling
the form with useful information.
Examine the initial access privileges for example servers group. Log in as normal and
grouper and examine what menus and system groups are available to them. Both users
should find no system groups for the organization.

2.

Modify the example servers system group so grouper can administrate the group. Sign
in as grouper and normal and observe what access they have to the system group.

RH401-6-en-1-20110713

221

AppendixA.Solutions

Log into the example account, select the Systems tab and click the System Groups menu
item at the left. Click on the example servers link to bring up the system group details page
then click the Admins tab. Check the check box by grouper and click the Update button to
assign her group administrative privileges.
This time when the system group access of grouper and normal is checked, grouper can
see the system group but normal cannot.
3.

Log in as grouper and modify the group so normal can administer systems in that group.
Log in as normal and confirm he has access to the group.
Perform the same steps as in the task above, except check the box by normal instead. Log
in as normal and confirm he has access to the group.

222

RH401-6-en-1-20110713

Using Subversion to Manage Changes

Using Subversion to Manage Changes


Practice Exercise

Preparing the Subversion Repository and Users


Before you begin...
In this lab one of your two machines will be referred to as desktopX and will host the Subversion
repository. This machine should be your RHN Satellite Server since you will reinstall desktopY to
complete later labs.
Your client machine, desktopY, will serve as the remote workstation of one of your Subversion
users. Make sure the clocks on both of your machines are synchronized with each other.
If you need to install packages, yum should already be configured on desktopX and desktopY.
Your internal DNS servers have had some problems lately. The DNS administrators, Stan and
Oliver, have been modifying configuration files in such a way they have been stepping on each
others' changes. Your task is to deploy a Subversion server which will allow Stan and Oliver to
work together and stop the configuration file conflicts.
Build a Subversion repository on desktopX that will allow two users, oliver and stan, to create
projects and work collaboratively.
1.

Reinstall desktopY with Red Hat Enterprise Linux 6 to prepare it for this and future lab
exercises. PXE boot desktopY and select the Install a standard RHEL 6 workstation option.

2.

Log in as root on desktopX and install Subversion if necessary. Create a repo named /var/
local/svn on desktopX while desktopY reinstalls. After the installation finishes, check if
Subversion is installed on desktopY. If not, then install it on desktopY also.
First, log in as root on desktopX and perform the following commands:
[root@desktopX ~]# yum install -y subversion
[root@desktopX ~]# svnadmin create /var/local/svn

After desktopY finishes reinstalling, log in as root and repeat the above yum command.
3.

On desktopX, create a group called svnuser with a group ID of 60000. Modify the
Subversion repository so all users in that group can create and modify projects.
[root@desktopX ~]# groupadd -g 60000 svnuser
[root@desktopX ~]# chgrp -R svnuser /var/local/svn
[root@desktopX ~]# chmod -R g+w /var/local/svn/db

4.

Create user accounts for oliver and stan on both workstations. Assign their accounts the
password of password on both systems.
Make all necessary adjustments to their accounts to allow them to use Subversion from
either host. Both users should be able to commit their changes to the Subversion repository
without typing a password when they are logged into desktopY.

RH401-6-en-1-20110713

223

AppendixA.Solutions

Use the following commands on both systems to create accounts for oliver and stan and
assign them passwords of password. Replace $user with each of their usernames:
[root@desktopX ~]# useradd $user
[root@desktopX ~]# echo password | passwd --stdin $user

Make all necessary adjustments to both their accounts to allow them to use Subversion
from either host. Their accounts must be members of the svnuser group on the Subversion
repository. Note the following command needs to be performed for both users on desktopX:
[root@desktopX ~]# usermod -a -G svnuser $user

It is useful to define a default editor for Subversion so it can run the editor when changes
are committed to the repository. Modify Oliver and Stan's ~/.bash_profile on both
desktopX and desktopY so the EDITOR environment variable points to your preferred text
editor. The following snippet of shell code should be defined in the ~/.bash_profile of
both of their accounts on both systems, (note the example below uses vi, but you can use
your preferred editor instead):
export EDITOR=vi

Both users should be able to commit their changes to the Subversion repository without
typing a password when they are logged into desktopY. Generate ssh keys for both users
and propagate their public keys to desktopX, the Subversion repository. The solution below
shows how to set the keys up for oliver. The same commands need to be performed for
stan.
[oliver@desktopY ~]$ ssh-keygen
... Output omitted ...
[oliver@desktopY ~]$ ssh-copy-id desktopX.example.com
... Output omitted ...

Practice Exercise

Starting a New Project in Subversion


Set up a new project in the Subversion repository for DNS configuration files.
1.

Log in as oliver on desktopX and create a subdirectory in Oliver's home directory


called source. Create etc and var/named subdirectories below ~/source to provide a
temporary DNS chroot hierarchy.
[oliver@desktopX ~]$ mkdir -p source/{etc,var/named}

2.

224

Use anonymous FTP to download all the files in /pub/materials/namedfiles from


instructor.example.com into ~/source. Move the files into the appropriate directories
in the temporary tree. Do not change their names at this time.

RH401-6-en-1-20110713

Using Subversion to Manage Changes

[oliver@desktopX
[oliver@desktopX
[oliver@desktopX
[oliver@desktopX

3.

~]$ cd source
source]$ wget ftp://instructor.example.com/pub/materials/namedfiles/*
source]$ mv named.conf etc/
source]$ mv *.zone var/named/

Have oliver create a new project called dnsfiles in the Subversion repository. The
project should initially be populated with the files from his ~/source directory.
If the group ownership and permissions assigned to the repository are correct, Oliver should
be able to create the project since he is a member of the svnuser group.
[oliver@desktopX source]$ cd ~
[oliver@desktopX ~]$ svn import source file:///var/local/svn/dnsfiles

When the text editor appears, insert DNS configuration files as the log message, save your
changes, then quit the editor. You should see output similar to the following:
Adding
source/var
Adding
source/var/named
Adding
source/var/named/127.0.0.zone
... Output omitted ...
Committed revision 1.

4.

Confirm the files are safely in the repository. Check the dnsfiles project out from the
Subversion repository on desktopX and compare its contents with the files in ~/source.
[oliver@desktopX ~]$ svn checkout file:///var/local/svn/dnsfiles

Compare the dnsfiles content with the files in ~/source. The only differences you should
be the .svn subdirectories below dnsfiles.
[oliver@desktopX ~]$ diff -r dnsfiles source
Only in dnsfiles/etc: .svn
... Output omitted ...

5.

Remove the ~/source directory from Oliver's home directory once it is confirmed the DNS
files are properly stored in the Subversion repository.
[oliver@desktopX ~]$ rm -r source

Practice Exercise

Managing Changes with Subversion


Create working directories and observe how Subversion manages concurrent changes by two
users.
1.

Log in as oliver on desktopX. If the dnsfiles working directory doesn't exist, check out a
working copy of the dnsfiles project below Oliver's home directory.

RH401-6-en-1-20110713

225

AppendixA.Solutions

If the dnsfiles working directory doesn't exist, run the following command:
[oliver@desktopX ~]$ svn checkout file:///var/local/svn/dnsfiles

2.

Change to the top level directory of your Subversion working directory and modify etc/
named.conf. Find the comments that read REPLACE FIX HERE WITH YOUR STATION
NUMBER and change all occurrences of the string FIX in the zone declarations to the last
octet of desktopX's IP address.
Note: This changes the files that DNS will try to reference. There are comments in the file
noting that the actual files must be renamed for consistency. For now disregard those
comments since you will fix the repository files to match the new names in a later lab
exercise.
Commit Oliver's changes with a log message of Replaced FIX with station's IP.
[oliver@desktopX ~]$ cd ~/dnsfiles
[oliver@desktopX dnsfiles]$ vi etc/named.conf
[oliver@desktopX dnsfiles]$ svn commit -m "Replaced FIX with station's IP."

3.

In another window, log in as Stan on desktopY. Create a Subversion working directory in


Stan's home directory and have Stan checkout a copy of the dnsfiles project. Examine
named.conf. The changes made by Oliver should appear in that file.
[stan@desktopY ~]$ svn checkout svn+ssh://desktopX.example.com/var/local/svn/dnsfiles
[stan@desktopY ~]$ cd dnsfiles
[stan@desktopY dnsfiles]$ less etc/named.conf

4.

As Stan, edit var/named/192.168.0.FIX.zone in the Subversion working directory and


replace every occurrence of FIX with the last octet of desktopX's IP address. Be sure to
update the serial number to YYYYMMDD00 using the digits of the current date. Commit
Stan's changes with the same log message that Oliver used previously.
[stan@desktopY dnsfiles]$ vi var/named/192.168.0.FIX.zone
[stan@desktopY dnsfiles]$ svn commit -m "Replaced FIX with station's IP."

5.

On desktopX update Oliver's Subversion working directory so Stan's revisions are


incorporated into Oliver's files.
svn update without arguments checks if the current working directory is under control
of Subversion. It uses information found in the .svn subdirectory to identify the repository
and it recurses down the current directory looking for updates. It is best to change to the top
level directory of the Subversion working directory to ensure all changes to the project are
updated:
[oliver@desktopX dnsfiles]$ svn status -u
[oliver@desktopX dnsfiles]$ svn update
[oliver@desktopX dnsfiles]$ less var/named/192.168.0.FIX.zone

226

RH401-6-en-1-20110713

Using Subversion to Manage Changes

Practice Exercise

Moving Files in a Subversion Project


Previously Stan modified the contents of a file. Modify file names and observe how Subversion
manages the changes.
1.

Using Stan's account on desktopY, use Subversion to change the name of the
192.168.0.FIX.zone file so FIX is replaced with the last octet of desktopX's IP address.
Commit the changes into the Subversion repository with a descriptive log message.
[stan@desktopY dnsfiles]$ cd var/named
[stan@desktopY named]$ svn mv 192.168.0.FIX.zone 192.168.0.X.zone
[stan@desktopY named]$ svn commit -m 'Moved 192.168.0.FIX.zone to 192.168.0.X.zone'

2.

Review the log messages of the 192.168.0.X.zone file.


Rename the file domainFIX.example.com.zone so FIX is replaced with the last octet of
desktopX's IP address. Make sure the changes are committed into the Subversion repository.
[stan@desktopY named]$ svn log 192.168.0.X.zone
[stan@desktopY named]$ svn mv domainFIX.example.com.zone domainX.example.com.zone
[stan@desktopY named]$ svn commit -m 'Moved domainFIX.example.com.zone to
domainX.example.com.zone'

3.

Examine Oliver's Subversion working directory on desktopX. Use Subversion to update his
working files and see what happens.
[oliver@desktopX
[oliver@desktopX
[oliver@desktopX
[oliver@desktopX

dnsfiles]$
dnsfiles]$
dnsfiles]$
dnsfiles]$

ls -R
svn status -u
svn update
ls -R

Practice Exercise

Subversion Conflict Resolution


Observe how Subversion behaves when two users modify the same file, sometimes with
conflicting changes.
1.

As Stan on desktopY, open domainX.example.com.zone in a text editor. Modify the SOA


line of the file so all occurrences of FIX are changed to the last octet of desktopX's IP
address. For example the student whose Satellite Server is station3.example.com would
modify the line to look like the following:
@ IN SOA desktop3.domain3.example.com.

root.desktop3.domain3.example.com. (

Save, exit, and commit the changes to the Subversion repository.


[stan@desktopY named]$ vi domainX.example.com.zone
[stan@desktopY named]$ svn commit -m 'Replaced FIX in SOA record.'

RH401-6-en-1-20110713

227

AppendixA.Solutions

2.

Without updating first, as Oliver on desktopX open domainX.example.com.zone in a text


editor. Fix the NS resource record by replacing each FIX with the last octet of desktopX's
IP address. Save, exit, and have Oliver commit the changes. This shouldn't require too much
effort since Oliver's changes do not conflict with Stan's.
[oliver@desktopX dnsfiles]$ cd var/named
[oliver@desktopX named]$ vi domainX.example.com.zone
[oliver@desktopX named]$ svn commit -m 'Replaced FIX in NS record.'
Sending
named/domainX.example.com.zone
svn: Commit failed (details follow):
svn: File '/dnsfiles/var/named/domainX.example.com.zone' is out of date

The commit above failed since Stan committed changes that Oliver hasn't downloaded yet.
Download Stan's changes and try to save the changes to the Subversion repository again:
[oliver@desktopX named]$ svn update
G
domainX.example.com.zone
Updated to revision 6.
[oliver@desktopX named]$ svn commit -m 'Replaced FIX in NS record.'
Sending
named/domainX.example.com.zone
Transmitting file data .
Committed revision 7.

3.

Have Stan on desktopY update his Subversion working directory and get Oliver's changes.
As Stan, edit domainX.example.com.zone and change each FIX in the MX line to the
last octet of desktopX's IP address. Update the serial number with the current date followed
by a two digit sequence number. Commit Stan's changes to the Subversion repository.
[stan@desktopY named]$ svn update
U
domainX.example.com.zone
Updated to revision 7.
[stan@desktopY named]$ vi domainX.example.com.zone
[stan@desktopY named]$ svn commit -m 'Replaced FIX in MX record.'
Sending
named/domainX.example.com.zone
Transmitting file data .
Committed revision 8.

4.

As Oliver on desktopX, make the same changes that Stan made but also change the MX
record priority to 15. Attempt to commit your changes. This will fail since Oliver's Subversion
working directory is not updated. Also update the zone file serial number to be greater than
the previous value.
Commit Oliver's changes into the repository since his changes are more complete than
Stan's changes.
[oliver@desktopX named]$ vi domainX.example.com.zone

For instance, if desktop3 were your desktopX, change the line in domain3.example.com.zone
to the following:

domain3.example.com.

228

IN MX

15

station3.domain3.example.com.

RH401-6-en-1-20110713

Using Subversion to Manage Changes

Once you have double checked your changes, commit them into the Subversion repository:
[oliver@desktopX named]$ svn commit -m 'Fixed MX priority.'
Sending
named/domainX.example.com.zone
svn: Commit failed (details follow):
svn: File '/dnsfiles/var/named/domainX.example.com.zone' is out of date

The command above failed since Oliver's Subversion working directory did not include
the most recent changes. Update Oliver's Subversion working directory. When a conflict
occurs, a .mine file and other version files are created when the update Subversion
command is issued. Commit Oliver's changes into the repository since his changes
are more complete than Stan's. One way to do this is to accept the changes in the
domainX.example.com.zone.mine file:
[oliver@desktopX named]$ svn update
Conflict discovered in 'domainX.example.com.zone'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options:

At this point, select 'p' to postpone the conflict resolution. This will allow you to view the
different versions of this file and compare them. After you see the further output below, use
mv and svn resolve to resolve the conflict and commit your changes:
C
domainX.example.com.zone
Updated to revision 8.
Summary of conflicts:
Text conflicts: 1
[oliver@desktopX named]$ mv domainX.example.com.zone.mine domainX.example.com.zone
[oliver@desktopX named]$ svn resolved domainX.example.com.zone
Resolved conflicted state of 'domainX.example.com.zone'
[oliver@desktopX named]$ svn commit -m 'Fixed MX priority.'
Sending
named/domainX.example.com.zone
Transmitting file data .
Committed revision 9.

5.

As either Oliver or Stan, update the remaining resource records in


domainX.example.com.zone that contain FIX with desktopX's number. Update the
serial numbers in the .zone zone files. Commit the changes into the Subversion repository.
[stan@desktopY named]$ svn update
[stan@desktopY named]$ vi domainX.example.com.zone
[stan@desktopY named]$ svn commit -m 'Replaced remaining FIXs with the desktop
number.'

RH401-6-en-1-20110713

229

AppendixA.Solutions

Red Hat Network Client Configuration


Practice Quiz

RHN Registration Steps


List the four steps (in order) that are taken when a client workstation registers with a RHN
Satellite server.
1.

Update Red Hat Network software tools

2.

Point to relevant Red Hat Network server

3.

Install SSL CA certificate (Satellite/Proxy only)

4.

Register the RHN client system: authenticate as valid Red Hat Network user, or register
with an activation key

Practice Performance Checklist

Graphical Red Hat Network Registration


You will register a system with a Red Hat Network Satellite using rhn_register in a graphical
environment. Since SSL encryption will be used, the organization CA certificate will have to be
located and used when registering the client system.
Your client workstation, desktopY.example.com, should already be installed to
provide a graphical environment. The classroom installation configures yum to point
to the instructor's server for additional RPMS. Remove the /etc/yum.repos.d/
dvd.repo configuration file and reset yum by executing the following command as
root:
[root@desktopY ~]# yum clean all
[root@desktopY ~]# rm /etc/yum.repos.d/dvd.repo

Browse http://desktopX.example.com/pub and locate the CA certificate for the


local organization provided by the Satellite Server. Download the CA certificate to the /
tmp directory on desktopY.
[root@desktopY ~]# wget http://desktopX/pub/RHN-ORG-TRUSTED-SSL-CERT -P /tmp

Log in as root on desktopX and monitor your Satellite server's Apache log files. Use
tail -f to monitor them continuously.
[root@desktopX ~]# tail -f /var/log/httpd/*

Open a terminal window on desktopY and execute rhn_register so it


displays a graphical dialog box. Configure the client to use the Satellite Server,
desktopX.example.com, for software updates. Use the SSL certificate you previously

230

RH401-6-en-1-20110713

Using Subversion to Manage Changes

downloaded and authenticate as the Red Hat Network user normal. Once the client is
configured, use yum repolist to verify it is talking with the Satellite Server.
[root@desktopY ~]# rhn_register

After reading the introductory screen, click the Forward button to advance. Select
the radio button that indicates you have access to a RHN Satellite Server. The
Location box will become active. Type the URL for desktopX in that box: https://
desktopX.example.com. Click the Forward button to advance.
Select the radio button indicating you have an SSL certificate. Browse and locate the file
in the /tmp directory of your local filesystem. Click the Forward button.
rhn_register will ask for Red Hat Network authentication. Enter the login normal and
the password redhat. Click Forward once the information is filled in.
On the next screen, take the default values for the system name and the profile data.
Click Forward again. rhn_register should contact the Satellite Server and send profile
information to the server. Click Forward then Finish to complete the registration and exit.
[root@desktopY ~]# yum repolist
Loaded plugins: refresh-packagekit, rhnplugin
repo id
repo name
rhel-x86_64-server-6 Red Hat Enterprise Linux Server ...
repolist: 3,583

status
3,583

Use a web browser to log into the Satellite server web user interface as normal and see
if the newly registered system shows up in the system list. Do the same for the Red Hat
Network user grouper. Finally log in as the Organization Administrator, example, and
see if the client shows up in his system list.
The normal and grouper users are unable to see the new system because it is not
associated with a system group they can view or administer. It is interesting that normal
cannot see a system that was registered using his login and password.
As the Organization Administrator, example, see if the client shows up in his system list
under the Systems tab. The new system should be visible to this account.

Practice Performance Checklist

Text-based Red Hat Network Registration


Register a system with a Red Hat Network Satellite using rhn_register in a text-based
environment. You should already have the CA certificate copied to the filesystem on the client
machine.
Log into a text-based virtual console (Ctrl+Alt+F2) as root on desktopY and
execute rhn_register to re-register your client with your Satellite server. When
rhn_register asks for RHN authentication information, provide the login of normal
with the password redhat.

RH401-6-en-1-20110713

231

AppendixA.Solutions

When you re-register your client with your Satellite server, it will print a warning:
System Software Updates already setup. Disregard the warning and select Yes to
continue.
After rhn_register asks for RHN authentication information, select Next to continue.
Accept the default values for profile name and other prompts.
After the system information is sent to the Satellite server, review the system
subscription details. You should see the software base channel, rhel-x86_64server-6, on the screen. Select OK then select Finish - the client registration is
complete.
Log into the Satellite server web interface as example. There should be two system
profiles labeled desktopY.example.com.

Practice Exercise

Automating Registration with Activation Keys


The previous exercises demonstrated how to register a machine with a Red Hat Network Satellite
Server using interactive utilities. Automate the registration process by creating an activation key
that registers with the Example RHN organization and use it to re-register your client.
1.

Log into your Satellite server as example and create an activation key named exampleservers. It should have a description of Example Servers, not have a usage limit, and
subscribe the client to the default RHN Satellite base channel for the system being installed.
This activation key should not consume any add-on entitlements and do not use it as the
universal default.
All systems registered with this activation key should automatically join the example
systems system group.
Log into the Satellite Server web interface as the Organization Administrator, example,
since this is the only user in the organization who has the privileges needed to create an
activation key. Another option would be to create a new user with the role of an Activation
Key Administrator or promote an existing user into that role.
Select the Systems tab then select Activation Keys from the menu at the left. Click on the
create new key link in the upper right-hand corner of the window. Provide the following
values in the fields of the dialog window that appears:

232

Field

Value

Description

Example Servers

Key (*)

orgID-example-servers

Usage

leave empty

Base Channel

Leave as RHN Satellite Default

Add On Entitlements

Leave everything unchecked

Universal Default

Leave unchecked

RH401-6-en-1-20110713

Using Subversion to Manage Changes

* - Record the organization ID number prefix (orgID) provided by the Satellite Server. This
prefix associates the system being registered with a specific RHN organization.
Click the Create Activation Key button once you confirm the form is filled out correctly.
Click the Groups tab, then click the Join sub-tab and click the check box to select example
servers. Click the Join Selected Groups button at the bottom of the screen to confirm the
selection.
2.

Log in as root on the client, desktopY.example.com, and use rhnreg_ks to register


your system using the activation key you just created. If the registration doesn't work
immediately, diagnose what the problem is and fix it.
The Satellite Server host name and information about the CA certificate already have useful
default values. Normally they would have to be specified, but the previous registrations
modified /etc/sysconfig/rhn/up2date so it points to valid values so the defaults can
be taken.
Be sure to include the organization ID prefix specified by the Satellite Server when the key
was created.
[root@desktopY ~]# rhnreg_ks --force --activationkey=orgID-example-servers

The two previous registrations consumed all of your subscriptions. One of the two system
profiles needs to be deleted, but we might as well delete both entries. Log into the Satellite
Server as example and select the Systems tab. Get the list of system profiles then click the
profile name of the system you want to delete. Click the delete system button at the upper
right-hand corner of the window then confirm the request by clicking the Delete Profile
button. Repeat this process with the other system profile.
Try the rhnreg_ks command again. This time it should work.
3.

Check the system profile of your client system in the Satellite Server. Is it a member of
the example servers system group? If not, make the necessary adjustments to your
activation key and re-register the client again. When you are finished with this exercise,
delete all of the system profiles in the Satellite Server.

Practice Exercise

Registering Clients with a Bootstrap Script


Red Hat Network Satellite software can create a template shell script, called a bootstrap script,
that can register a client system with the Satellite server. Customize and use a bootstrap script to
register a freshly installed system with your Satellite server.
1.

Reinstall your client workstation, desktopY, with a minimal footprint installation. Initiate
a PXE boot and choose the Install a minimal RHEL 6 installation option without any
arguments to begin the installation. While desktopY is installing, continue to the next step.

2.

A Satellite Server provides bootstrap scripts to all of its clients, not just to a specific
organization, so they must be created and managed by the Satellite Administrator.

RH401-6-en-1-20110713

233

AppendixA.Solutions

While the client workstation installs, log in as the Satellite Administrator, satadmin, and in
the web interface create a bootstrap script template as a starting point. The script should
enable SSL and client GPG checking. It should not enable remote configuration and remote
commands. These options will be introduced later in the course.
Optional - Use Subversion to manage the changes you make to the bootstrap script you
develop. Create a new Subversion project and check in the original version before you make
any changes.
Select the Admin tab then click the RHN Satellite Configuration menu option at the left.
Click the Bootstrap Script sub-menu option. Fill in the form that appears with the following
values:
Field

Value

RHN Satellite server hostname

Confirm it is desktopX.example.com

SSL cert location

Confirm the pathname to your local CA


certificate

Enable SSL

check

Enable Client GPG checking

check

Enable Remote Configuration

uncheck

Enable Remote Commands

uncheck

Leave the client HTTP proxy information blank since it doesn't apply. Click the Update
button to confirm and accept your changes.
Optional - To put the bootstrap script under control of Subversion, create a project called
bootstrap that manages all of the files under the bootstrap directory.
[root@desktopX ~]# cd /var/www/html/pub
[root@desktopX pub]# svn import bootstrap -m 'Bootstrap scripts' file:///var/local/
svn/bootstrap
Adding
bootstrap/bootstrap.sh
... Output omitted ...
[root@desktopX pub]# rm -rf bootstrap
[root@desktopX pub]# svn co file:///var/local/svn/bootstrap
A
bootstrap/bootstrap.sh
... Output omitted ...

3.

Edit your bootstrap script on your Satellite Server. Disable the exit 1 line and modify the
ACTIVATION_KEYS shell variable to point to the activation key you created earlier in this
lab.
[root@desktopX pub]# cd /var/www/html/pub/bootstrap
[root@desktopX bootstrap]# vi bootstrap.sh

echo "the exit below)"


echo
#exit 1
# can be edited, but probably correct (unless created during initial

234

RH401-6-en-1-20110713

Using Subversion to Manage Changes

# install):
# NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine.
ACTIVATION_KEYS=orgID-example-servers

Optional - Commit your changes into Subversion once you are satisfied with them.
[root@desktopX bootstrap]# svn commit -m 'Enabled script and added act key.'
Sending
bootstrap.sh
Transmitting file data .
Committed revision 14.

4.

Once the client machine has finished installing, log in as root, download the bootstrap
script, and execute it manually. Normally this step would be performed in the %post section
of a kickstart installation for full automation.
Sign into the Satellite Server web interface as normal and confirm the system is registered
and belongs to the example-servers system group.
[root@desktopY ~]# wget http://desktopX/pub/bootstrap/bootstrap.sh
[root@desktopY ~]# bash bootstrap.sh

RH401-6-en-1-20110713

235

AppendixA.Solutions

Red Hat Network Software Management


Practice Exercise

Custom Software Channel Administration


Create Linux and RHN Satellite accounts for the responsible person who is in charge of managing
custom channel content. Create a GPG key for signing trusted third-party packages. Once the
pieces are in place, create a custom software channel for Example, Inc. third-party software
packages.
1.

Create Linux and RHN Satellite accounts on desktopX.example.com for Charles


Channelman, the person responsible for managing software channels on the Satellite Server.
The login/user name for his accounts should be channelman with passwords of redhat.
His Red Hat Network account on the Satellite Server should permit him to manage software
channels and the systems in the example servers system group.
[root@desktopX ~]# useradd -c 'Charles Channelman' channelman
[root@desktopX ~]# echo redhat | passwd --stdin channelman

Create a Red Hat Network account for Charles on the Satellite Server. Log into Satellite web
UI as example, the Organization Administrator. Select the Users tab then click the create
new user link. Fill in the form that appears with the following values:
Field

Value

Desired Login

channelman

Desired Password

redhat

First, Last Name

Mr. Charles Channelman

E-mail

channelman@desktopX.example.com

Click Create Login to create his Red Hat Network account.


He needs additional privileges to do his job. To make him a channel administrator, click on
the channelman link to pull up his account settings. Put a check in the checkbox by the
Channel Administrator role then click the Submit button to confirm the change. Click the
System Groups tab within his account page then check the example servers checkbox.
Click the Update Permissions button to confirm your changes to allow channelman to
administrate the system group also.
2.

Log into a shell account on desktopX as channelman and create a GPG key. The key
should be a 2048-bit RSA key used for signing packages only. It shouldn't expire and
should be protected with a passphrase of redhat. The owner of the key should be Charles
Channelman <channelman@desktopX.example.com>.
Export an ASCII-armored version of the public key and copy it to /var/www/html/pub/
EXAMPLE-GPG-KEY.
What is the GPG key id and fingerprint of the key you just created?
[channelman@desktopX ~]$ gpg --gen-key

236

RH401-6-en-1-20110713

Using Subversion to Manage Changes

... Output Omitted ...


Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection? 5
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) Enter
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) Enter
Key does not expire at all
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment, and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Charles Channelman
Email address: channelman@desktopX.example.com
Comment: Enter
You selected this USER-ID:
"Charles Channelman <channelman@desktopX.example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.
Enter passphrase: redhat
Repeat passphrase: redhat
... Output Omitted ...
pub
2048R/GPG-key-ID 2011-06-09
Key fingerprint = GPG-fingerprint
uid
Charles Channelman <channelman@desktopX.example.com>
... Output Omitted ...

Even though the GPG key ID and fingerprint are displayed when a key is created, they can
also be displayed later using the following command:
[channelman@desktopX ~]$ gpg --list-key --fingerprint
/home/channelman/.gnupg/pubring.gpg
----------------------------------pub
2048R/GPG-key-ID 2011-06-09
Key fingerprint = GPG-fingerprint
uid
Charles Channelman <channelman@desktop1.example.com>

Export an ASCII armor version of the public key to publish to client machines so they can
verify RPM packages signed with the private key:
[channelman@desktopX ~]$ gpg --armor --export GPG-key-ID > /tmp/EXAMPLE-GPG-KEY
[root@desktopX ~]# cp /tmp/EXAMPLE-GPG-KEY /var/www/html/pub/

RH401-6-en-1-20110713

237

AppendixA.Solutions

3.

Create a custom child software channel named Example custom with a label of examplecustom and configure it to advertise Charles Channelman's GPG key for verifying package
signatures. It should be a child channel of the Red Hat Enterprise Linux Server
(v.6 for 64-bit x86_64) base software channel.
Log into Satellite web UI as channelman. Choose the Channels top-level tab, select Manage
Software Channels from the menu at the left, then click the create new channel link. Fill out
the form that appears with the following values:
Field

Value

Channel Name

Example custom

Channel Label

example-custom

Parent Channel

Red Hat Enterprise Linux Server (v.6 for 64bit x86_64)

Parent Channel Architecture

x86_64

Yum Repository Checksum Type

sha256

Channel Summary

Example third-party software

Channel Description

Example third-party software

Maintainer Name

Charles Channelman (not required)

Email Address

channelman@desktopX.example.com

Phone Number

leave empty

Support Policy

leave empty

Per-User Subscription Restrictions

Leave All users selected

Organization Sharing

Leave This channel is private selected

GPG key URL

http://desktopX.example.com/pub/
EXAMPLE-GPG-KEY

GPG key ID

GPG-key-ID

GPG key Fingerprint

GPG-fingerprint

Click the Create Channel button to create the custom software channel.

Practice Exercise

Loading Red Hat Content into RHN Satellite


All Red Hat base software channels have a child channel called Red Hat Network Tools. This
channel provides useful packages for machines that are clients of a RHN Satellite Server.

Log in as root on desktopX. In root's home directory you will find a subdirectory called
sat-rhel6-content. Examine its contents and import the channel that provides the Red
Hat Network Tools which pertain to the base channel content you already loaded in your
Satellite Server.
[root@desktopX ~]# satellite-sync -m /root/sat-rhel6-content -l

238

RH401-6-en-1-20110713

Using Subversion to Manage Changes

... Output omitted ...


19:29:05
19:29:05 Retrieving / parsing channel-families data
19:29:05 channel-families data complete
19:29:05
19:29:05 Retrieving / parsing channel data
19:29:05
p = previously imported/synced channel
19:29:05
. = channel not yet imported/synced
19:29:05
base-channels:
19:29:05
. rhel-x86_64-client-6 2911
19:29:05
p rhel-x86_64-server-6 3583
... Output omitted ...
19:29:05
rhel-x86_64-server-6:
19:29:05
. rhel-x86_64-server-fastrack-6 0
... Output omitted ...
19:29:05
. rhn-tools-rhel-x86_64-server-6 21
... Output omitted ...
[root@desktopX ~]# satellite-sync -m /root/sat-rhel6-content -c rhn-tools-rhel-x86_64server-6

Practice Performance Checklist

Loading Third-party Content into RHN Satellite


As channelman, take a third-party RPM provided by the instructor, sign it, and import it into the
RHN Satellite Server and associate it with the example-custom software channel.
Log in as Charles Channelman, channelman, on desktopX.example.com.
Copy the example-1.0-1.noarch.rpm RPM from /misc/instructor/RPMS to
Charles' home directory, and sign it with his GPG key.
[channelman@desktopX ~]$ cp /misc/instructor/RPMS/example-1.0-1.* ~
[channelman@desktopX ~]$ echo '%_gpg_name GPG-key-ID' > ~/.rpmmacros
[channelman@desktopX ~]$ rpm --resign example-1.0-1.noarch.rpm
Enter pass phrase: redhat
Pass phrase is good.
example-1.0-1.noarch.rpm:
gpg: WARNING: standard input reopened
gpg: WARNING: standard input reopened

Import the RPM into the Satellite Server so it is associated with the example-custom
software channel.
[channelman@desktopX ~]$ rhnpush --server=desktopX -c example-custom
example-1.0-1.noarch.rpm
Red Hat Network username: channelman
Red Hat Network password: redhat

RH401-6-en-1-20110713

239

AppendixA.Solutions

Practice Performance Checklist

Subscribing to a Custom Channel


Associate your client system, desktopY.example.com, with your custom software channel and
install the example RPM on the client host.
Subscribe your client system to the example-custom custom software channel.
Login as a RHN user who can administer the client system, either channelman or
normal will do. Select the Systems top-level tab then select Systems from the menu at
the left. Select the link to the client system to access its Details page. Click the Software
tab then the Software Channels sub-tab. Check the check-box by Example custom in the
Software Channels Subscriptions then click the Change Subscriptions button to confirm
your change.
Import the GPG key used to sign the packages provided by the custom channel into the
RPM database on the client system. Install the example RPM on the client machine using
the yum command.
Log in as root on desktopY and execute the following commands:
[root@desktopY ~]# rpm --import http://desktopX/pub/EXAMPLE-GPG-KEY
[root@desktopY ~]# yum repolist
Loaded plugins: refresh-packagekit, rhnplugin
repo id
repo name
status
example-custom
Example custom
1
rhel-x86_64-server-6 Red Hat Enterprise Linux Server ...
3,583
repolist: 3,584
[root@desktopY ~]# yum install -y example

Warnings will be displayed when the RPM installs because some of the files in the RPM
have broken ownerships.

Practice Performance Checklist

Managing Updates with Cloned Channels


Create clones of standard Red Hat channels and custom channels to control how software
updates are rolled out to client systems.
Create clones of standard Red Hat software channels (both base and child channels)
and the custom software channel in your Satellite Server. These channels will be
Production versions of their original counterparts so assign them labels identical to
the original channels with a prod- prefix. Use the default values provided for the access
controls of the cloned channels.
First, clone the base channel that is the parent of all the other channels. Log in to the
Satellite Server as the Channel Administrator, channelman. Click the Channels tab then
select the Manage Software Channels menu item from the left. Click the clone channel
link in the upper right-hand corner of the frame. Fill in the form that appears with the
following values:

240

RH401-6-en-1-20110713

Using Subversion to Manage Changes

Field

Value

Clone From

Select Red Hat Enterprise Linux


Server (v.6 for 64-bit x86_64)

Clone

Select Original state

Click the Create Channel button. Another form will appear requiring additional
information. Fill it in with the following values:
Field

Value

Channel Name

Production Red Hat Enterprise


Linux Server (v.6 for 64-bit
x86_64)

Channel Label

prod-rhel-x86_64-server-6

Leave the remaining fields with their default values then click the Create Channel button
to complete the creation of the cloned base channel.
Now the child channels must be cloned. Click the Channels tab then select the Manage
Software Channels menu item from the left. Click the clone channel link in the upper
right-hand corner of the frame. Fill in the form that appears with the following values:
Field

Value

Clone From

Select RHN Tools for RHEL (v.6


for 64-bit x86_64)

Clone

Select Current state

Click the Create Channel button. Another form will appear requiring additional
information. Fill it in with the following values:
Field

Value

Parent Channel

Select Production Red Hat


Enterprise Linux (v.6 for 64bit x86_64)

Channel Name

Production RHN Tools for RHEL


(v. 6 for 64-bit x86_64)

Channel Label

prod-rhn-tools-rhel-x86_64server-6

Leave the remaining fields with their default values then click the Create Channel button
to complete the creation of the cloned child channel. Repeat the same process for the
Example custom child channel.
Change the subscriptions of your client machine, desktopY, so it subscribes to the new
cloned channels. Include production versions of the base channel and the Example
custom child channel.

RH401-6-en-1-20110713

241

AppendixA.Solutions

Remove, then reinstall, the example RPM and confirm it comes from one of the cloned
channels just created.
Pull up the client system profile by selecting the Systems top-level tab, select Systems
from the menu at the left, then click the client host name link. Select the Software tab
then the Software Channels sub-tab. In the Base Software Channel frame, highlight the
Production Red Hat Enterprise Linux Server (v. 6 for 64-bit x86_64) base channel
and click Confirm. If a warning displays, click Modify Base Software Channel anyway
to confirm the assignment to the new base channel you have selected. After the screen
refreshes, check the checkbox to select the Production Example custom child channel.
Click the Change Subscriptions button to confirm your selection.
[root@desktopY ~]# yum -y remove example
[root@desktopY ~]# yum install -y example
... Output Omitted ...
Installing:
example
noarch
1.0-1
prod-example-custom
... Output Omitted

2.7 k

Practice Exercise

Update Notifications with RHN Errata


Sign and import a newer (fixed) RPM into the Satellite Server. Create an errata to notify client
system administrators that a fix has been published. Observe its impact on the client systems.
1.

Log in as Charles Channelman, channelman, on desktopX.example.com. Copy the


improved RPM, example-1.0-2.noarch.rpm, from /misc/instructor/RPMS to
Charles' home directory and sign it with his GPG key. Import the new RPM into the Satellite
Server so it is associated with the example-custom software channel.
[channelman@desktopX ~]$ cp /misc/instructor/RPMS/example-1.0-2.* ~
[channelman@desktopX ~]$ rpm --resign example-1.0-2.noarch.rpm
[channelman@desktopX ~]$ rhnpush --server=desktopX -c example-custom
example-1.0-2.noarch.rpm

2.

Create and publish an errata notification that announces the availability of the
example-1.0-2.noarch.rpm package. The errata synopsis should read, example - file
ownerships fixed. Advisory EXBA2010:0001 release 1 is a bug fix advisory.
Log into the Satellite Server as channelman since Channel Administrator privileges are
needed to manage errata. Click on the Errata tab then select Manage Errata from the menu
on the left. Click the create new erratum link in upper right-hand corner. Fill in the Errata
Management form with the following values:

242

Field

Value

Synopsis

example - file ownerships fixed

Advisory

EXBA-2010:0001

RH401-6-en-1-20110713

Using Subversion to Manage Changes

Field

Value

Advisory Release

Advisory Type

Select Bug Fix Advisory

Product

example

Topic

Example topic goes here.

Description

RPM produces warnings when


installing because of incorrect
ownership.

Solution

Fixed file ownership of created


file.
Leave non-required fields blank

Click the Create Errata button to confirm your changes and create the errata. Another form
should appear entitled Errata: EXBA-2010:0001-1. Click the Packages tab then select the
Add sub-tab. Select example-1.0-2.noarch by clicking the checkbox next to its name
then click the Add Packages button. Click the Confirm button to finalize the creation of the
errata. Click the Details tab then click the Publish Errata button to make the errata visible to
client systems. Click checkbox to select the Example custom software channel then click the
Publish Errata button.
3.

Browse the Satellite Server's web UI and verify that the Errata is published. Notice that the
client system is not impacted because we changed its software channel subscriptions to the
Production channels.
As channelman, click on the Errata tab then select Errata from the left menu. Notice
there are no relevant errata because there are no systems currently subscribed to the
Example custom channel. Select All under the Errata in the left menu and verify that
EXBA-2010:0001 shows up.

4.

Clone the errata and make it available to the prod-example-custom channel. Log into
the client system, desktopY, as root and confirm the new RPM is available for installation.
Note: The update may take up to 10 minutes to become available for installation because
the default yum settings cause metadata to expire after 10 minutes. Use yum clean all to
clear the caches and verify you can view the update.
As channelman, click on the Errata tab then select Clone Errata from the left menu. Find
the example bug fix and check the box next to it. Click on the Clone Errata button at the
bottom of the page. On the next page, click the Confirm button. This cloned errata will have
a CLA-2010:0001 advisory number. Click on the CLA-2010:0001 cloned errata link, then click
the Publish Errata button. As before, the next page allows you to choose which channel to
publish this erratum. Choose the Production Example custom channel this time and
click on the Publish Errata button. The next page confirms that you do not have the file in
the channel yet, so select the example package and click the Continue button to push the
package to the channel. Notice there are no relevant errata because there are no systems
currently subscribed to the Example custom channel. Select All under the Errata in the
left menu and verify that EXBA-2010:0001 shows up.
Log into desktopY as root and confirm the updated package is available for installation:

RH401-6-en-1-20110713

243

AppendixA.Solutions

[root@desktopY ~]# yum clean all


[root@desktopY ~]# yum list updates
... Output Omitted ...
Loaded plugins: rhnplugin
Updated Packages
example.noarch
1.0-2
example-custom

244

RH401-6-en-1-20110713

Building RPMs

Building RPMs
Practice Quiz

RPM Spec File


1.

The package Version is usually derived from the open source project while the
package Release is the packager's version.

2.

The name of the tarball containing the files used to build the package is specified with
the Source directive.

3.

The BuildArch directive specifies the target architecture the package is being built for.
noarch will be its value when the package can be installed on any architecture.

4.

The Summary directive specifies the one-line description of a package while the
%description section provides a more thorough explanation of what that package is
for.

5.

The %install section contains the code used to place files in the $RPM_BUILD_ROOT
chroot directory structure.

6.

The %files section defines which files and directories to package into the RPM.

7.

The %prep , %build , %install and %clean sections contain shell code used to
assemble a package and clean up after it has been built.

Test

Criterion Test
Performance Checklist

Building an RPM Package


Before you begin...
If you haven't already done so, create a non-root user called student on your RHEL 6
workstation, desktopY. You will use this unprivileged account to build your RPM packages for
RHEL 6 systems.
In this exercise you will create an RPM for a package called hello. It should have version 1.0
with a release of 1 and it should be able to be installed on multiple architectures.
Log in as root on desktopY and create a student account with a password of student.
[root@desktopY ~]# useradd student
[root@desktopY ~]# echo student | passwd --stdin student

Login as student on desktopY and make a directory called hello-1.0. Download the file
ftp://instructor.example.com/pub/materials/hello.sh and save it in that directory.

RH401-6-en-1-20110713

245

AppendixA.Solutions

[student@desktopY ~]$ mkdir ~/hello-1.0


[student@desktopY ~]$ cd ~/hello-1.0
[student@desktopY hello-1.0]$ wget ftp://instructor.example.com/pub/materials/
hello.sh

Create a simple RPM that installs hello.sh in /usr/local/bin. Make sure hello.sh
is installed with a mode of 755 and is owned by root on machines it is installed on. Also
make sure the RPM can be installed on all architectures.
First, create the necessary directory structure that rpmbuild requires. Also create the
tar archive with the source files:
[student@desktopY
[student@desktopY
[student@desktopY
[student@desktopY

hello-1.0]$ cd
~]$ mkdir -p ~/rpmbuild/SOURCES
~]$ mkdir -p ~/rpmbuild/SPECS
~]$ tar -czvf ~/rpmbuild/SOURCES/hello-1.0-1.tar.gz hello-1.0

Next create a spec file for the package. Remember that vim on RHEL 6 will provide a
template if you specify a file with a .spec extension:
[student@desktopY ~]$ vim ~/rpmbuild/SPECS/hello.spec

The contents of ~/rpmbuild/SPECS/hello.spec should look like the following when


you finish with your changes:
Name:
Version:
Release:
Summary:
Group:
License:
URL:
Source0:
BuildRoot:
BuildArch:

hello
1.0
1
Hello program
RH401
GPL
http://www.redhat.com
%{name}-%{version}-%{release}.tar.gz
/var/tmp/%{name}-buildroot
noarch

%description
hello.sh is a very friendly greeting program.
on every system around the world.

It should be installed

%prep
%setup -q -n %{name}-%{version}
%build
%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
install -m 755 hello.sh $RPM_BUILD_ROOT/usr/local/bin/hello.sh
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
/usr/local/bin/hello.sh

246

RH401-6-en-1-20110713

Building RPMs

%changelog
* Thu Jun 9 2011 George <george@redhat.com> - 1.0-1
- Original build

Install the rpm-build package if it isn't already installed.


[student@desktopY ~]$ su Password: redhat
[root@desktopY ~]# yum install -y rpm-build
... Output omitted ...
[root@desktopY ~]# exit
[student@desktopY ~]$ rpmbuild -ba ~/rpmbuild/SPECS/hello.spec
... Output omitted ...

Copy the binary and source RPMs to channelman's account on desktopX so he can sign
the package and publish it via the Satellite server.
[student@desktopY ~]$ scp -p ~/rpmbuild/SRPMS/hello-1.0-1.src.rpm
channelman@desktopX:
... Output omitted ...
[student@desktopY ~]$ scp -p ~/rpmbuild/RPMS/noarch/hello-1.0-1.noarch.rpm
channelman@desktopX:
... Output omitted ...

Log into desktopX as channelman and sign the hello binary and source RPMS. Import
both packages into the example-custom channel on your Satellite server.
[channelman@desktopX ~]$ rpm --resign hello-1.0-1.noarch.rpm hello-1.0-1.src.rpm
Enter pass phrase: redhat
Pass phrase is good.
hello-1.0-1.noarch.rpm:
hello-1.0-1.src.rpm:
gpg: WARNING: standard input reopened
gpg: WARNING: standard input reopened
[channelman@desktopX ~]$ rhnpush --server=desktopX -c example-custom
hello-1.0-1.noarch.rpm
Red Hat Network username: channelman
Red Hat Network password: redhat
[channelman@desktopX ~]$ rhnpush --server=desktopX -c example-custom --source
hello-1.0-1.src.rpm
Red Hat Network username: channelman
Red Hat Network password: redhat

Confirm these packages are in the Satellite server. Log in to the Satellite web interface
as the Organization Administrator, example, and select the Channels tab. Expand
the Red Hat Enterprise Linux Server (v.6 for 64-bit x86_64) entry
then click on the Example custom child channel. Click the Packages tab and confirm
hello-1.0-1.noarch.rpm package is listed. Click on the package name then scroll to the
bottom to see the Source Package link and confirm the source RPM is also imported.

RH401-6-en-1-20110713

247

AppendixA.Solutions

Configuration File Management with RHN


Practice Performance Checklist

Creating and Populating a Configuration Channel


Use your RHN Satellite Server to deploy configuration files. In this exercise you will create a
Configuration Administrator account, create a configuration channel, and populate it with a
custom configuration file for Example Inc.
Create a Configuration Administrator account for the Example Inc. organization on your
RHN Satellite Server. The account is for Ms. Janice Configurator and should have the
login of configurator with a password of redhat. RHN Satellite generated e-mail for
her should go to root@desktopX.example.com. Also she should be able to administer
systems in the example servers system group.
Log into the Satellite web UI as the Example Inc. Organization Administrator, example.
Select the Users tab then click the create new user link. Fill in the form that appears
with the following values:
Field

Value

Desired Login

configurator

Desired Password

redhat

First, Last Name

Ms. Janice Configurator

E-mail

root@desktopX.example.com

Click the Create Login button to create the account. Find the new account in the list of
Active Users and click on the link to the new user. Check Configuration Administrator
under the list of Roles then click the Submit button. To allow her to administer systems
in the example servers system group, select the System Groups sub-tab and check
the example servers checkbox. Click the Update Permissions button to confirm your
changes to her account.
Log in to your RHN Satellite Server as configurator and create a configuration
channel called Example Configs with the label example-configs.
Select the Configuration top-level tab, choose Configuration Channels from the menu
that appears, then click the create new config channel link. Fill in the form that appears
with the following values:
Field

Value

Name

Example Configs

Label

example-configs

Description

Example Inc. configuration


files

Click the Create Config Channel button to create the channel. The overview page for the
new configuration channel should appear.

248

RH401-6-en-1-20110713

Building RPMs

Add a configuration file to the example-configs configuration channel. The file


should provide a custom login banner for Example Inc. servers. The file to add to
the configuration channel should be /etc/issue. It should be have user and group
ownership of root in both cases and should have permissions of -r--r--r--. The file
contents should be:
*** Example Inc. ***
blank line

Navigate to the Example Configs management page if you are not already there. Select
the Add Files tab within the page then choose the Create File sub-tab. Specify the
following configuration file attributes and content:
Field

Value

File Type

Select the Text file radio button

Filename/Path

/etc/issue

Ownership

root/root

File Permissions Mode

444

File Contents

*** Example Inc. ***

Click the Create Configuration File button to confirm your changes.

Practice Performance Checklist

Deploying Configuration Files to a RHN Client


Configure your client server so it will pull custom configuration file content from the
configuration channel you created on your RHN Satellite Server.
Entitle your client server, desktopY, to be able to install the tools necessary to provision
it from your Satellite Server.
Log in as configurator since she can manage systems in the example servers
system group. Click the Systems tab then select the desktopY.example.com system
link. Click on the Details tab followed by the Properties sub-tab. Within the Add-On
Entitlements section select the Provisioning checkbox then click the Update Properties
button.
Install all necessary RHN configuration client software on desktopY. Configure your
client system so it will permit configuration files to be deployed on it.
First, subscribe your client system to the rhn-tools child software channel. Click the
Systems tab then select the desktopY.example.com system link. Click on the
Software tab followed by the Software Channels sub-tab. Select the checkbox by the
relevant RHN Tools child channel then click the Change Subscriptions button to confirm
your change.

RH401-6-en-1-20110713

249

AppendixA.Solutions

Because you added a new software channel, clean the yum cache on the client and install
the rhncfg-actions RPM on desktopY:
[root@desktopY ~]#
... Output Omitted
[root@desktopY ~]#
... Output Omitted
[root@desktopY ~]#

yum clean all


...
yum install -y rhncfg-actions
...
rhn-actions-control --enable-deploy

Modify the desktopY.example.com system profile so it subscribes to the exampleconfigs configuration channel. Execute commands on the client system so it downloads
the configuration files provided by example-configs. Verify the new /etc/issue file
successfully deploys.
Click the Systems tab then select the desktopY.example.com system link. Choose the
Configuration tab within the system overview page. Select the Manage Configuration
Channels sub-tab then choose the Subscribe to Channels tab that appears. Check the
Example Configs checkbox then click the Continue button. A page will appear entitled
Step 2: Rank Channels for Subscription. Since we only have a single configuration
channel, click the Update Channel Rankings button to complete the subscription.
Execute the following command as root on desktopY:
[root@desktopY ~]# rhncfg-client get
Deploying /etc/issue

Verify the new /etc/issue file was successfully deployed by displaying its contents.
[root@desktopY ~]# cat /etc/issue

Practice Performance Checklist

Command-line Configuration File Management


Red Hat provides tools that allow and administrator to manage configuration channel content
from the command-line. Use commands from the shell to update the configuration file content in
your RHN Satellite Server.
Install all necessary software on desktopY to perform configuration file management
from the command-line. Create a directory called ~/config-mgmt where configuration
files can be downloaded, modified, and uploaded back into the RHN Satellite Server.
[root@desktopY ~]# yum install -y rhncfg-management
... Output omitted ...
[root@desktopY ~]# mkdir ~/config-mgmt

Use the RHN command-line management tools to download the files for the exampleconfigs configuration channel below ~/config-mgmt. Modify the configuration
channel's /etc/issue file so it contains the following content:

250

RH401-6-en-1-20110713

Building RPMs

*** Example Inc. ***


No trespassing allowed.
blank line

Use the command-line management tools to upload your change into your RHN Satellite
Server.
[root@desktopY ~]# rhncfg-manager download-channel -t config-mgmt/ example-configs
Red Hat Network username: configurator
Password: redhat
Deploying /etc/issue -> config-mgmt/example-configs/etc/issue

When rhncfg-manager prompts for a RHN username and password, you must
authenticate as either an Organization Administrator or a Configuration Administrator.
[root@desktopY ~]# vi config-mgmt/example-configs/etc/issue
[root@desktopY ~]# rhncfg-manager upload-channel -t config-mgmt/ -c example-configs
Using config channel example-configs
Uploading /etc/issue from config-mgmt/example-configs/etc/issue

Pull configuration files from the Satellite Server down to desktopY. Verify the most
current version of /etc/issue has been deployed.
[root@desktopY ~]# rhncfg-client get
Deploying /etc/issue
[root@desktopY ~]# cat /etc/issue
*** Example Inc. ***
No trespassing allowed.

RH401-6-en-1-20110713

251

AppendixA.Solutions

Provisioning with PXE


Practice Exercise

Automating RHN Satellite Client Configuration


Use an activation key to register newly installed machines to your Red Hat Network Satellite
Server. It should subscribe the systems to useful software channels and join the Example
Servers system group.
1.

Create an activation key with a label of example-web. When clients are registered with this
activation key, the following actions should be performed:
Subscribe to the Red Hat Enterprise Linux Server (v. 6 for 64-bit
x86_64) base software channel
Subscribe to the related Red Hat Network Tools and Example custom child
software channels
Provide a provisioning entitlement
Subscribe to the Example Configs configuration channel
Deploy configuration files provided by the Example Configs configuration channel
Associate with the Example Servers system group
Log in as an Activation Key Administrator or an Organization Administrator for Example,
Inc., in this case log in to the Satellite web interface as example. Navigate to the Create
Activation Key screen. Select the Systems tab, choose Activation Keys from the menu at
the left, then click the create new key link. When the Create Activation Key page appears,
make the following selections:
Field

Value

Description

Example Web Server

Key

orgID-example-web

Usage

leave this field blank

Base Channels

Select Red Hat Enterprise Linux


Server (v. 6 for 64-bit x86_64)

Add-On Entitlements

Check the Provisioning checkbox

Universal Default

leave this checkbox unchecked

Click the Create Activation Key button to confirm your selections.


Examine each of the tabs that are presented for the new activation key. Start with the
Details tab. Check the Configuration File Deployment check box then click the Update
Activation Key button to confirm your change.

252

RH401-6-en-1-20110713

Building RPMs

Select the Child Channels tab. Highlight both the Example custom and the RHN Tools for
RHEL (v. 6 for 64-bit x86_64) child software channels. Click the Update Key button to
register your changes.
Select the Packages tab. Note the packages that are listed by default. Do not make any
changes to this list.
Click the Configuration tab then select the Subscribe to Channels sub-tab. Check the
Example Configs checkbox. Click the Continue button to confirm your selection.
Click the Groups tab then select the Join sub-tab. Check the Example Servers checkbox.
Click the Join Selected Groups button to confirm your changes.
2.

Since signed packages will probably be deployed when the new systems are provisioned,
the GPG keys used to verify their signatures need to be deployed as well. Import the
GPG key used to verify custom packages built for Example, Inc. and the GPG key used
to verify standard Red Hat released RPMS. These keys are found in /var/www/html/
pub/EXAMPLE-GPG-KEY and /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
respectively.
You should still be logged in your Satellite Server as example, the Organization
Administrator for Example, Incorporated. Navigate to the GPG Public Keys and SSL
Certificates screen. Select the Systems tab, choose Kickstart from the menu at the left,
then click the GPG and SSL Keys option from the sub-menu that appears. When the GPG
Public Keys and SSL Certificates screen appears you should see the RHN-ORG-TRUSTEDSSL-CERT SSL key selected by default.
Click the create new stored key/cert link and when the Create GPG/SSL Key page appears,
make the following selections:
Field

Value

Description

Example Custom Key

Type

Select GPG

Select file to upload

Click the Browse, then navigate to /var/


www/html/pub/EXAMPLE-GPG-KEY

Click the Create Key button to confirm your selections. When the GPG Public Keys and SSL
Certificates screen appears you should see your key added.
Perform the same steps listed above to import the GPG key Red Hat uses to check their
package signatures. The Description should be Red Hat Release Key and the path to
browse for that key is /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release.

Practice Exercise

Creating a Web Server Kickstart Profile


Create a kickstart profile to build a web server that is ready to use immediately after it is
installed from bare metal.

RH401-6-en-1-20110713

253

AppendixA.Solutions

1.

Create a kickstart profile labeled web-server that uses Red Hat Enterprise Linux 6 Server
to install a new machine. This profile will be used for bare-metal installations without any
use of virtualization. The most recent kickstart tree available should be used to perform the
installation. The initial root password for systems built with this profile should be redhat.
Click the Systems tab then choose Kickstart from the menu that appears. Click the create
new kickstart profile link to advance to the Step 1: Create Kickstart Profile page. When it
appears, make the following selections:
Field

Value

Label

web-server

Base Channel

Select Red Hat Enterprise Linux


Server (v. 6 for 64-bit x86_64)

Kickstartable Tree

Select ks-rhel-x86_64-server-6-6.0

Virtualization Type

Select None

Click the Next button. The Step 2: Distribution File Location screen should appear. Leave
the Default Download Location radio button selected and click the Next button again. The
final screen entitled Step 3: Root Password should appear. Specify a password of redhat,
verify it, then click the Finish when done.
2.

The kickstart profile should create three native disk partitions. The first partition should
contain a 256MB ext3 file system mounted as /boot. A swap partition should be created
2048MB large. The final native disk partition should be a 17GB LVM physical volume.
Create a volume group named vol0 that includes the 17GB physical volume. Two logical
volumes should be created within the vol0 volume group. The first logical volume should be
named home and it should be 512MB in size. It will contain the /home filesystem. The second
logical volume should be named root and it should consume the rest of the unused storage
in vol0. It will be used for the / filesystem.
Choose the appropriate time zone for your locale. Systems in this organization have
hardware clocks which keep time using UTC instead of local time.
The kickstart should install the GPG keys used to verify package signatures for RPMS
released from Red Hat and custom packages provided by Example, Inc.
To specify disk partitioning, within the kickstart profile click on the System Details tab.
Select the Partitioning sub-tab and make the following adjustments:
partition swap --size=2048
partition pv.01 --size=17000
partition /boot --fstype=ext3 --size=256
volgroup vol0 pv.01
logvol /home --vgname=vol0 --name=home --size=512
logvol / --vgname=vol0 --name=root --size=1000 --grow

Click the Update Partitions button to confirm your changes.

254

RH401-6-en-1-20110713

Building RPMs

To adjust the timezone, select the Locale sub-tab. Choose the appropriate timezone from
the pull-down menu and check the Hardware Clock uses UTC check box. Click the Update
Locale Preferences button to accept your selections.
To install GPG keys used to sign RPMS, click on the System Details tab, then select the GPG
& SSL sub-tab. The RHN-ORG-TRUSTED-SSL-CERT key should already be checked. Check
the checkboxes by the Example Custom Key and the Red Hat Release Key selections.
Click the Update keys button to confirm your selections.
3.

Systems built with this kickstart profile are web servers, but they are also used with
graphical utilities and Subversion. Ensure the subversion RPM and the following package
groups are installed: x11, basic-desktop, and web-server.
For package selection, click the Software tab. The Package Groups sub-tab should be
selected. Enter the following text into the dialog box on the display, one line per package
group/package:
@ Base
@ x11
@ basic-desktop
@ web-server
subversion

Click the Update Packages button to confirm your changes.


4.

Update the kickstart profile so systems built with this profile register with the Red Hat
Network Satellite Server using the Example Web Server activation key.
Select the Activation Keys sub-tab (not the menu selection to left). Check the Example Web
Server checkbox, then click the Update Activation Keys button to confirm your choice.

5.

Create a post script in the kickstart profile that performs the following tasks:
Create a user named oliver with a password of password
Install the example RPM provided by the custom software channel
Update all system software to its most current release
Configure the web server to start at boot
Select the Scripts tab then click the add new kickstart script link. Complete the form that
appears as follows:
Field

Value

Scripting Language

Leave this field blank to use bash

Toggle Editor

Check/uncheck - your preference

Script Contents

*** see below ***

Script Execution Time

Select Post Script

nochroot

Leave unchecked

RH401-6-en-1-20110713

255

AppendixA.Solutions

Field

Value

Template

Leave unchecked

# Create our Subversion user


useradd oliver
echo password | passwd --stdin oliver
# Install custom Example, Inc. RPM
yum install -y example
# Bring standard system software up to date
yum update -y
# Configure the web server to start at boot
chkconfig httpd on

Click the Update Kickstart button to confirm your changes.

Practice Exercise

Set up the Provisioning Network


Before desktopX provides any network services, it must be configured to communicate with and
act as a gateway for its backend network. Also configure the Cobbler component of Red Hat
Network Satellite Server to provide tftp and pxelinux capabilities for provisioning. Make sure
Cobbler is installed and functioning properly.
1.

Physically disconnect your client workstation, desktopY, from the classroom network. Cable
desktopY so it is connected to the second NIC of desktopX. This can be accomplished with
either cross-over cables or with a small switch with two patch cables. Your instructor should
have provided you with all necessary hardware to accomplish this task.

2.

Configure the backend interface of desktopX to have a static IP address of 10.100.X.254/24.


You will not be able to fully test the backend interface until you power up and configure
desktopY. Do a preliminary test by pinging the interface address.
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 a HWADDR line leave it in the interface configuration file. Do a preliminary
test by pinging the interface address.
[root@desktopX ~]# ifup eth1
[root@desktopX ~]# ping -c1 -s0 -W1 10.100.X.254

3.

Enable IPv4 packet forwarding on desktopX. Make sure this feature is persistent across
reboots.
Edit /etc/sysctl.conf to enable IPv4 packet forwarding at boot time:

256

RH401-6-en-1-20110713

Building RPMs

net.ipv4.ip_forward = 1

Load the settings in /etc/sysctl.conf into the kernel:


[root@desktopX ~]# sysctl -p

4.

The following diagram represents the configuration of your lab environment when you finish
this sequence:

RH401 Student Network Configuration


===================================
-----+-------------------- Classroom intranet
| eth0
| 192.168.0.X
,---+---.
|
| desktopX.example.com (desktopX)
|
|
`---+---'
| eth1
| 10.100.X.254
|
| eth0
| 10.100.X.1
,---+---.
|
| station1.privateX.com (desktopY)
|
|
`-------'

5.

When installing Red Hat Network Satellite Server, the installer asks if Cobbler should be
used to provide provisioning services. If it isn't already installed, use the cobbler-setup
command to install Cobbler and enable tftp services.
[root@desktopX ~]# cobbler-setup
Cobbler requires tftp and xinetd services be turned on for PXE provisioning
functionality. Enable these services (y/n, default = 'y')?y

6.

Run cobbler sync as root to install the necessary files to support PXE network
bootloading.
[root@desktopX ~]# cobbler sync

7.

Confirm xinetd and tftp are configured to run at boot time and that xinetd is currently
running.
[root@desktopX ~]# chkconfig xinetd --list
[root@desktopX ~]# chkconfig tftp --list
[root@desktopX ~]# service xinetd status

RH401-6-en-1-20110713

257

AppendixA.Solutions

Use chkconfig service on to configure tftp or xinetd to start at boot time if


necessary. service xinetd start will launch xinetd if it is not already running.

Practice Exercise

Configure DHCP to Support PXE


Install a DHCP server that will issue IP addresses, both generally and based on MAC address, to
your provisioning network.
1.

Install the dhcp package on desktopX.


[root@desktopX ~]# yum install -y dhcp

2.

Use the /usr/share/doc/dhcp-*/dhcpd.conf.sample file as a starting point for the


DHCP server.
Change the subnet to 10.100.X.0/255.255.255.0.
Change the router to the IP address of the backend network interface of your DHCP
server.
Set the DNS server to 192.168.0.254.
Set the default DNS search domain to example.com.
Issue IP addresses in the range from 10.100.X.2 to 10.100.X.10.
Deploy the network boot loader to support PXE booting.
Configure your DHCP service to only issue IP addresses on the Ethernet card attached to the
backend subnet.
Copy /usr/share/doc/dhcp-*/dhcpd.conf.sample to /etc/dhcpd.conf.
[root@desktopX ~]# cp /usr/share/doc/dhcp-*/dhcpd.conf.sample /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 the IP address of your frontend network interface.
authoritative;
ddns-update-style none;
subnet 10.100.X.0 netmask 255.255.255.0 {
option
option
option
option

258

routers
subnet-mask
domain-name-servers
domain-name

# change to your timezone


option time-offset
option time-offset

10.100.X.254;
255.255.255.0;
192.168.0.254;
"example.com";

-18000; # EST
-21600; # CST

RH401-6-en-1-20110713

Building RPMs

#
#

option time-offset
option time-offset

-25200; # MST
-28800; # PST

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;
filename "pxelinux.0";
}

Configure your DHCP service to only issue IP addresses on the Ethernet card attached to
the backend subnet. For example if your backend interface is eth1, edit /etc/sysconfig/
dhcpd to include this line:
DHCPDARGS=eth1

3.

In another terminal window or virtual console follow /var/log/messages. In your original


shell start dhcpd and configure it to start at boot-time.
PXE boot your client workstation. You may need to press a function key during the boot
sequence to choose network boot. Observe /var/log/messages as well as the boot
messages on desktopY. Record desktopY's MAC address for future reference:
[root@desktopX ~]# tail -f /var/log/messages
[root@desktopX ~]# service dhcpd start
[root@desktopX ~]# chkconfig dhcpd on

desktopY should receive the IP address 10.100.X.10 since dhcpd offers addresses
beginning with the last address in its range. /var/log/messages should contain a
message like the following. Note the MAC address of desktopY.
Jun

6 10:01:48 desktopX dhcpd: DHCPOFFER on 10.100.X.10 to 01:23:45:67:89:ab via eth1

It should have obtained the default Cobbler PXE configuration and therefore booted
normally according to its BIOS settings. If desktopY has no other boot loader 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! Power off desktopY.
4.

Use the MAC address of your second machine as recorded in /var/log/messages on


desktopX to add a host IP reservation for 10.100.X.1 to /etc/dhcpd.conf. The name of
the client host will be station1.privateX.com. Restart the dhcpd service.
PXE boot the client machine and verify that it gets the new address. It should also display
the Cobbler PXE boot menu.
Replace 12:34:56:78:AB:CD with the appropriate MAC address from /var/log/
messages. Replace X with your station number. For clarity, place the host declaration
below the bottom of the subnet scope.
subnet 10.100.X.0 netmask 255.255.255.0 {
...options truncated...

RH401-6-en-1-20110713

259

AppendixA.Solutions

}
host station1 {
hardware ethernet 12:34:56:78:AB:CD;
fixed-address 10.100.X.1;
}

[root@desktopX ~]# service dhcpd restart

Practice Exercise

PXE Installation of a Web Server


Now that all the pieces are in place, kickstart a client system as a web server within the Example,
Inc. organization.
1.

Delete all previous system profiles from the Satellite Server. This is required to free up all
entitlements needed for the new web server that will be kickstarted.
Log in to the Satellite Server web interface as example, the Organization Administrator for
Example, Inc. Click the Systems tab then select the Systems menu item from the menu that
appears. For each system displayed, click the host name link to bring up each system profile.
Click the delete system link that appears at the top of the screen then click the Delete
Profile button to confirm the deletion.

2.

Power on or reboot the client machine and select PXE boot. How PXE boot is selected varies
between various hardware vendors. Notice the Cobbler menu that appears has a new menu
item:
web-server:orgID:ExampleInc

Use the arrow keys and choose this menu item to begin the installation of your web server.
3.

Once the installation completes, confirm the new web server is built according to
specification. If anything didn't work properly, ask your instructor for help and troubleshoot
your RHN Satellite configurations.
[root@desktopY ~]# df -h
... Output Omitted ...
[root@desktopY ~]# service httpd status
... Output Omitted ...
[root@desktopY ~]# rpm -q gpg-pubkey
gpg-pubkey-fd431d51-4ae0493b
gpg-pubkey-2fa658e0-45700c69
gpg-pubkey-KEYID-4df66b78
[root@desktopY ~]# rpm -q subversion
... Output Omitted ...
[root@desktopY ~]# date
Should show your locale
[root@desktopY ~]# yum list updates
Should not display any packages
[root@desktopY ~]# id oliver
... Output Omitted ...

260

RH401-6-en-1-20110713

Building RPMs

4.

Completely automate the PXE installation of your web server. Delete the existing system
profile to free up entitlements before you being the automated installation. Configure the
system BIOS to PXE boot first then boot from the local hard drive.
Create a Cobbler system profile for your system called station1 based on the machine's
IP address. Configure Cobbler to PXE boot only once by default and use the netbootenabled flag within the system profile to control installation.
After you install your system and confirm everything worked correctly, delete the station1
Cobbler system profile so it doesn't conflict with later lab exercises.
Log in to the Satellite Server web interface as example, the Organization Administrator for
Example, Inc. Click the Systems tab then select the Systems menu item from the menu that
appears. Click the host name link for your web server to bring up its system profile. Click the
delete system link that appears at the top of the screen then click the Delete Profile button
to confirm the deletion.
Configure Cobbler to perform the automated installation via PXE:
[root@desktopX ~]# cobbler list
distros:
ks-rhel-x86_64-server-6-6.0
profiles:
web-server:orgID:ExampleInc
systems:
repos:
images:
[root@desktopX ~]# cobbler system add --name=station1 --profile=webserver:orgID:ExampleInc --ip=10.100.X.1
[root@desktopX ~]# cobbler system report --name=station1 | grep -i netboot
Netboot Enabled?
: True
[root@desktopX ~]# grep pxe_just_once /etc/cobbler/settings
pxe_just_once: 1
[root@desktopX ~]# rhn-satellite restart

Once the Satellite services have restarted, reboot the client system. The first time it PXE
boots it will immediately begin a kickstart installation without displaying a menu. After it
finishes installing, it should PXE boot again then boot from the local hard drive.
After you confirm the installation worked properly, clean up the station1 system with
cobbler to free up the IP address so it doesn't interfere with later labs.
[root@desktopX ~]# cobbler system remove --name=station1

RH401-6-en-1-20110713

261

AppendixA.Solutions

RHN Virtual Machine Management


Practice Exercise

Converting a Server to a Virtualization Host


Before you begin...
Your client machine, station1.privateX.com, will be transformed into a server that will host
virtualization guest machines.
Example, Inc. has existing machines registered with their Red Hat Network Satellite Server.
Virtualization is being introduced to their server room so existing hosts need to be converted
into virtualization hosts running virtual guests.
1.

First the network needs to be configured to provide a bridge network interface for virtual
guests. Disable the NetworkManager service to prevent network configuration files from
automatic modifications:
[root@station1 ~]# chkconfig NetworkManager off
[root@station1 ~]# service NetworkManager stop

Create/modify the network configuration files on station1 to support a network bridge. /


etc/sysconfig/network-scripts/ifcfg-br0 should contain the following lines:
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
DELAY=0
ONBOOT=yes

Modify /etc/sysconfig/network-scripts/ifcfg-eth0 so it contains the following


lines:
DEVICE=eth0
BRIDGE=br0
HWADDR=mac-address-of-eth0
ONBOOT=yes

Once the files have been modified, restart the network service and confirm station1 has a
working network with br0 bridge.
[root@station1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-br0
[root@station1 ~]# vi /etc/sysconfig/network-scripts/ifcfg-eth0
[root@station1 ~]# service network restart
[root@station1 ~]# ip addr show br0
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 01:23:45:67:89:ab brd ff:ff:ff:ff:ff:ff
inet 10.100.X.1 brd 10.100.X.255 scope global br0
inet6 fe80::223:45ff:fe67:89ab/64 scope link
valid_lft forever preferred_lft forever

262

RH401-6-en-1-20110713

Building RPMs

2.

Install additional software needed to support virtualization. Install the virtualization,


virtualization-client, and virtualization-platform package groups. Once all
the software is installed, reboot your client system.
[root@station1 ~]#
... Output omitted
[root@station1 ~]#
... Output omitted
[root@station1 ~]#
... Output omitted
[root@station1 ~]#

3.

yum groupinstall -y virtualization


...
yum groupinstall -y virtualization-platform
...
yum groupinstall -y virtualization-client
...
reboot

Copy the install-vserver script from the instructor's machine to your client
system, station1, and execute it. It will use kickstart to install a virtual guest called
vserver on the local machine. The script can be found at the following URL: ftp://
instructor.example.com/pub/materials/install-vserver.
[root@station1 ~]#
... Output omitted
[root@station1 ~]#
[root@station1 ~]#

wget ftp://instructor.example.com/pub/materials/install-vserver
...
chmod 755 install-vserver
./install-vserver

Practice Exercise

Red Hat Network Registration of Virtual Machines


Before you begin...
A virtualization host (station1.privateX.com) running RHEL 6 registered to your RHN
Satellite Server and a vserver virtual machine installed with RHEL 6 running as a guest.
In this sequence, you will register vserver with Red Hat Network under station1's
entitlement. Note the first couple steps of this exercise can be completed on the Satellite server
and virtualization host while vserver finishes installing.
1.

Log into your RHN Satellite using an account that can manage station1.privateX.com,
and ensure it is entitled to Virtualization service and its software channel subscriptions
include RHN Tools for RHEL.
Once you are logged in through the web interface, click on the Systems tab then on
station1.privateX.com's host name hyperlink on the table. This should bring up a detail
page for the host. Under System Properties, find the Edit These Properties link and click on
it. On the next page, ensure Provisioning and Virtualization are both checked under Add-On
Entitlements. Click the Update Properties button to confirm your changes.
Back on the system's detail page, verify the system is subscribed to the RHN Tools for RHEL
(v. 6 for 64-bit x86_64) child channel. If not, find the Alter Channel Subscriptions link and
click on it. Put a check mark in the RHN Tools for RHEL channel check box and click on the
Change Subscriptions button.

2.

Log in as root on the virtualization host. Use yum to install the rhn-virtualizationhost and osad packages. Start the osad service and ensure it will start automatically at
boot. This enables remote management of virtual machines from the RHN web interface.

RH401-6-en-1-20110713

263

AppendixA.Solutions

[root@station1 ~]# yum install -y osad rhn-virtualization-host


[root@station1 ~]# service osad start
[root@station1 ~]# chkconfig osad on

3.

After the virtualization guest has finished installing, make sure the vserver domain is
running. On the virtualization host run rhn_check and rhn-profile-sync as root.
[root@station1 ~]# virsh start vserver
[root@station1 ~]# rhn_check; rhn-profile-sync

4.

Log into the virtualization guest and download the bootstrap.sh script you completed in
a previous lab from your Satellite Server. Use it to register the guest with your RHN Satellite
Server.
Using the graphical console in virt-manager, log in as root on vserver. Download the
bootstrap.sh script you completed in a previous lab from your Satellite Server and use it
to register the virtual machine to your RHN Satellite:
[root@station? ~]# wget http://desktopX.example.com/pub/bootstrap/bootstrap.sh
[root@station? ~]# chmod 755 bootstrap.sh
[root@station? ~]# ./bootstrap.sh

5.

In the RHN web interface, select the Systems tab. You should see your newly-registered
vserver virtual machine listed under its host name. Note the different system icon.
Now click on your station1.privateX.com host name link, then on the system
detail page find its Virtualization link/tab and click on that. You should see the list of
the virtual machines running on station1 when you updated its RHN profile. If any
of them are not registered with Red Hat Network, you will see Unregistered System
instead of a host name for its profile name. Click on the hostname link for vserver (e.g.
station9.privateX.com) to see its RHN profile.

Practice Exercise

Provisioning a Virtualization Host


In previous exercises you converted an existing host to a virtualization host. Use RHN Satellite
kickstart capabilities to provision a virtualization host from bare metal.
1.

Create a kickstart profile called kvm-host in your Satellite Server to build a virtualization
host. The installing system should use the Red Hat Enterprise Linux Server (v. 6
for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the root password to redhat.
Log into your RHN Satellite Server as a Kickstart Administrator or an Organization
Administrator for Example, Inc. - the example user will work. Choose the Systems tab,
select the Kickstart menu item then click the create new kickstart profile link. When the
Step 1: Create Kickstart Profile form appears, complete it with the following values:

264

RH401-6-en-1-20110713

Building RPMs

Field

Value

Label

kvm-host

Base Channel

Select Red Hat Enterprise Linux Server (v.


6 for 64-bit x86_64)

Kickstartable Tree

Select ks-rhel-x86_64-server-6-6.0

Virtualization Type

Select None

Click the Next button to confirm your changes. When the Step 2: Distribution File Location
screen appears, click the Next to accept the default kickstart tree location. Specify redhat
as the default root password and click the Finish button to confirm your changes when the
Step 3: Root Password screen appears.
2.

Once the kvm-host kickstart profile is created, adjust the timezone to use the local
timezone and installed systems use UTC in their hardware clocks. Automate installation
of the standard Red Hat release GPG key. The @virtualization, @virtualizationclient, and @virtualization-platform package groups should be installed.
Use the %post script of the kickstart file to install the rhn-virtualization-host and
osad packages. Configure the osad service to start at boot time. Also provide some shell
code to configure the network to use a bridged network interface.
Once the kvm-host kickstart profile is created, adjust the timezone to use the local
timezone and installed systems use UTC in their hardware clocks. With the System Details
tab selected within the kickstart profile, click the Locale tab and select the local timezone
from the pull-down menu. Click the checkbox for UTC hardware clock then click the Update
Locale Preferences to confirm your choices.
Automate installation of the standard Red Hat release GPG key. With the System Details
tab still selected, choose the GPG & SSL sub-tab, check the Red Hat Release Key checkbox,
then click the Update keys button to confirm.
Select the Software tab then select the Package Groups sub-tab. In the frame that appears,
type @ virtualization, @ virtualization-client, and @ virtualizationplatform below the existing @ Base package group. Click on the Update Packages button
when finished.
To install the RHN virtualization management packages and create a bridged network
interface, select the Scripts tab and create a %post script (not nochroot) with the following
code:
# Install virtualization management software
yum install -y rhn-virtualization-host osad
chkconfig osad on
# Configure a network bridge
chkconfig NetworkManager off
cat > /etc/sysconfig/network-scripts/ifcfg-br0 << EOF
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
DELAY=0
ONBOOT=yes

RH401-6-en-1-20110713

265

AppendixA.Solutions

EOF
echo 'BRIDGE=br0' >> /etc/sysconfig/network-scripts/ifcfg-eth0

Click on the Update Kickstart button to accept your changes.


3.

Use the Satellite Server to schedule station1.privateX.com to kickstart install itself


using the kvm-host kickstart profile. The kickstart should be initiated immediately.
While the client system installs, use Cobbler to determine the system profile name of the
kickstarting system. Delete all other Cobbler system profiles then disable the netboot
feature for the installing system.
Use the Satellite Server to schedule station1.privateX.com to kickstart install itself
using the kvm-host kickstart profile. Navigate to the existing host profile. Choose the
Systems tab, select Systems from the menu at the left, then click the host name link for the
existing virtual host. Select the Provisioning tab within the system profile. The Kickstart
and Schedule tabs should be selected. In the Select Kickstart Profile section of the page
click the radio button by the kvm-host profile. The kickstart should be initiated immediately
when the client system checks in so leave the radio button selected for Begin kickstart at
the next system check in. Click the Schedule Kickstart and Finish button to confirm your
changes and schedule the kickstart.
Run rhn_check on station1 to facilitate the process:
[root@station1 ~]# rhn_check

Broadcast warnings that the system will reboot should begin immediately. You can either
wait a few minutes for the system to reboot itself or you can hurry the process along
manually:
[root@station1 ~]# reboot

After five minutes of warnings the client system will reboot and start the kickstart
installation. While the client system installs, use Cobbler to determine the system profile
name of the kickstarting system. Log in as root on the Satellite Server and execute the
following commands:
[root@desktopX ~]# cobbler list
distros:
ks-rhel-x86_64-server-6-6.0
profiles:
kvm-host:orgID:ExampleInc
web-server:orgID:ExampleInc
systems:
station1.privateX.com:orgID
repos:
images:

266

RH401-6-en-1-20110713

Building RPMs

Practice Exercise

Provisioning a Virtualized Guest


With the virtualization host built, now it is time to use Red Hat Network Satellite to provision the
virtual guests running on the host.
1.

Create a kickstart profile called kvm-guest in your Satellite Server to build a virtual guest.
The installing system should use the Red Hat Enterprise Linux Server (v. 6
for 64-bit x86_64) base channel for software and install from the ks-rhel-x86_64server-6-6.0 kickstart tree. Set the initial root password to redhat.
Log into your RHN Satellite Server as a Kickstart Administrator or an Organization
Administrator for Example, Inc. - the example user will work. Choose the Systems tab,
select the Kickstart menu item then click the create new kickstart profile link. When the
Step 1: Create Kickstart Profile form appears, complete it with the following values:
Field

Value

Label

kvm-guest

Base Channel

Select Red Hat Enterprise Linux Server (v.


6 for 64-bit x86_64)

Kickstartable Tree

Select ks-rhel-x86_64-server-6-6.0

Virtualization Type

Select KVM Virtualized Guest

Click the Next button to confirm your changes. When the Step 2: Distribution File Location
screen appears, click the Next to accept the default kickstart tree location. Specify redhat
as the default root password and click the Finish button to confirm your changes when the
Step 3: Root Password screen appears.
2.

Modify the virtual machine network configuration to use the br0 bridge interface of the
virtualization host and send console messages to ttyS0. Adjust the timezone to use the
local timezone and installed systems use UTC in their hardware clocks.
Once the kvm-guest kickstart profile is created, notice the various options for CPU,
memory, disk and network configuration available under the Details tab within the Kickstart
Details tab. Enter br0 for the value of the Virtual Bridge field. In the Kernel Options field
provide the value console=ttyS0. Click the Update Kickstart button to accept your
changes.
With the System Details tab selected within the kickstart profile, click the Locale subtab and select the local timezone from the pull-down menu. Click the checkbox for UTC
hardware clock then click the Update Locale Preferences to confirm your choices.

3.

Use the RHN Satellite to provision a virtual guest on station1.privateX.com. Schedule


a guest system to install using the kvm-guest kickstart profile. The guest name should be
named vserver and initiate the kickstart installation immediately.
Navigate to the existing virtualization host profile, station1.privateX.com. Choose the
Systems tab, select Systems from the menu at the left, then click the hostname link for
the existing virtual host. Select the Virtualization tab within the system profile, then the
Provisioning tab. Do not select the higher level Provisioning tab. Check the radio button by

RH401-6-en-1-20110713

267

AppendixA.Solutions

the kvm-guest kickstart profile and specify a guest name of vserver. The kickstart should
be initiated immediately when the client system checks in so leave the radio button selected
for Begin kickstart at the next system check in. Click the Schedule Kickstart and Finish
button to confirm your changes and schedule the kickstart.
Log in as root on the client system serving as the virtualization host server. The virsh
list command should show vserver running as it installs. Use the virsh console
vserver command to display vserver's console as it installs.
4.

After the installation of the virtual guest completes, use the Satellite web interface to
confirm that it has registered with the Satellite server.
Navigate to the existing virtualization host profile, station1.privateX.com. Choose the
Systems tab, select Systems from the menu at the left, then click the hostname link for
the existing virtual host. Select the Virtualization tab within the system profile, then the
Details tab. You should see an entry for the vserver virtualization guest in the list of hosts
displayed.

268

RH401-6-en-1-20110713

RHN Satellite Server Administration

RHN Satellite Server Administration


Practice Exercise

RHN Satellite Embedded Database Maintenance


Perform basic RHN Satellite embedded database maintenance functions such as extending an
internal table space and making a backup of your RHN Satellite database.
1.

Sometimes RHN Satellite embedded database performance can suffer when an internal table
becomes full. Determine the current size and utilization of the UNDO_TBS table then extend
it. Record both its original and new size and utilization below:
First, log in as root on desktopX then switch to the oracle user so you can perform
database administration.
[root@desktopX ~]# su - oracle
-bash-3.2$ db-control report
Tablespace
Size
Used
Avail
DATA_TBS
3.9G 641.5M
3.2G
SYSAUX
500M 110.8M
389.1M
SYSTEM
400M 249.8M
150.1M
UNDO_TBS
500M 146.3M
353.6M
USERS
128M
64K
127.9M
-bash-3.2$ db-control extend UNDO_TBS
Extending UNDO_TBS... done.
-bash-3.2$ db-control report
Tablespace
Size
Used
Avail
DATA_TBS
3.9G 641.5M
3.2G
SYSAUX
500M 110.8M
389.1M
SYSTEM
400M 249.8M
150.1M
UNDO_TBS
1000M 146.3M
853.6M
USERS
128M
64K
127.9M

Use%
16%
22%
62%
29%
0%

Use%
16%
22%
62%
15%
0%

What is its new size and utilization?


2.

Perform a backup of your Red Hat Network embedded database. Save the backup in a
directory called rhn-sat-backup-YYYYMMDD below the home directory of the oracle
account. How much disk space does the backup take?
Open another terminal window as root on desktopX so you can shutdown the Satellite
Server so the database can be backed up:
[root@desktopX ~]# rhn-satellite stop

In another window, get access to a shell as the oracle user. Create the directory where the
backup will be stored then perform the backup:
[root@desktopX ~]# su - oracle
-bash-3.2$ mkdir rhn-sat-backup-YYYYMMDD
-bash-3.2$ db-control backup rhn-sat-backup-YYYYMMDD
Initiating cold backup of database rhnsat...
/opt/apps/oracle/config/10.2.0/lkRHNSAT -> rhn-sat-backup-20100104/lkRHNSAT.gz ...
done.

RH401-6-en-1-20110713

269

AppendixA.Solutions

/opt/apps/oracle/config/10.2.0/spfilerhnsat.ora -> rhn-sat-backup-20100104/


spfilerhnsat.ora.gz ... done.
... Output omitted ...
Full cold backup complete.

Since the backup is finished, go to your other terminal window as root and restart the RHN
Satellite Server software:
[root@desktopX ~]# rhn-satellite start

How much disk space does the backup take? It should take up less than 1 GB of space. This
is because it only backs up the essential database information - not the RPMS, the RHN
Satellite software, nor the kickstart installation trees.
-bash-3.2$ du -sh rhn-sat-backup-YYYYMMDD/
699M
rhn-sat-backup-YYYYMMDD/

3.

Confirm the integrity of the RHN Satellite embedded database backup you just created.
Return to the window where you logged in as the oracle user and execute the following
command:
-bash-3.2$ db-control verify rhn-sat-backup-YYYYMMDD
Verifying backup from Mon Jan 4 08:52:42 2010...
rhn-sat-backup-20100104/lkRHNSAT.gz... done. Checksum verified.
rhn-sat-backup-20100104/spfilerhnsat.ora.gz... done. Checksum verified.
... Output omitted ...

Practice Exercise

Activating a New Satellite Entitlement Certificate


There are a couple of reasons a new RHN Satellite entitlement certificate is issued to a Red
Hat customer: expanded capabilities or an extension on the certificate expiration date. In
this exercise you will activate a new Satellite entitlement certificate that will provide more
capabilities.

On the instructor's server there is a more robust RHN Satellite entitlement certificate
available for your use. You can access the certificate using the following pathname
on your Satellite Server: /misc/instructor/rh401-satellite/redhat-glsmaximum-5.4.cert. Reactivate your Satellite Server using this certificate.
Log in as your Satellite Administrator, satadmin, and inspect the system and software
entitlements available for deployment.
[root@desktopX ~]# cp /misc/instructor/rh401-satellite/redhat-gls-maximum-5.4.cert ~
[root@desktopX ~]# rhn-satellite-activate --disconnected --rhn-cert /root/redhat-glsmaximum-5.4.cert

270

RH401-6-en-1-20110713

RHN Satellite Server Administration

Log into your RHN Satellite server as the Satellite Administrator, satadmin. Click the Admin
tab then select Subscriptions from the menu at the left. The total number of entitlements
should be doubled and a number of free entitlements should be available for use.

Practice Exercise

Exporting Custom Child Software Channel Content


Backing up the RHN Satellite embedded database does not preserve custom software channel
content. Use rhn-satellite-exporter to backup your custom software channel content.
1.

Log in as root on desktopX and display the list of software channels currently in your RHN
Satellite Server. Take note of the labels of the channels you want to save and the names of
their parent channel.
[root@desktopX ~]# rhn-satellite-exporter --list-channels
Channel List:
B = Base Channel
C = Child Channel
B rhel-x86_64-server-6
C
example-custom
C
rhn-tools-rhel-x86_64-server-6
... Output omitted ...

2.

Create a directory called custom-dump. Export the software channel content for the
example-custom channel into custom-dump so it can be taken and imported into another
disconnected Satellite Server.
[root@desktopX ~]# mkdir custom-dump
[root@desktopX ~]# rhn-satellite-exporter --step=short -d custom-dump -c rhel-x86_64server-6
10:18:36 Gathering channel info...
10:18:36 Gathering binary RPM info...
10:18:36 Gathering package info...
10:18:36 Gathering errata info...
10:18:36 Gathering kickstart data...
10:18:36 Gathering kickstart files info...
... Output omitted ...
Exporting: #################### - Done!
[root@desktopX ~]# rhn-satellite-exporter -d custom-dump -c example-custom
10:19:02 Gathering channel info...
10:19:02 Gathering binary RPM info...
10:19:02 Gathering package info...
10:19:02 Gathering errata info...
10:19:02 Gathering kickstart data...
10:19:02 Gathering kickstart files info...
... Output omitted ...
Exporting: #################### - Done!
[root@desktopX ~]# du -sh custom-dump
30M custom-dump

RH401-6-en-1-20110713

271

AppendixA.Solutions

3.

Confirm the channel content is usable with the satellite-sync command. Check
carefully and be sure the example-custom channel appears in the output of satellitesync.
[root@desktopX ~]# satellite-sync -m custom-dump -l
10:19:21 Red Hat Network Satellite - file-system synchronization
10:19:21
mp: /root/custom-dump
10:19:21
db: rhnsat/<password>@rhnsat
10:19:21
10:19:21 Retrieving / parsing channel-families data
10:19:21 channel-families data complete
10:19:22
10:19:22 Retrieving / parsing channel data
10:19:22
p = previously imported/synced channel
10:19:22
. = channel not yet imported/synced
10:19:22
base-channels:
10:19:22
p rhel-x86_64-server-6
3583
full import from Tue Jun 7 10:15:39 2011
10:19:22
rhel-x86_64-server-6:
10:19:22
. example-custom
2
full import from Tue Jun 7 10:17:57 2011
10:19:22
Import complete:
Begin time: Tue Jun 7 10:19:21 2011
End time:
Tue Jun 7 10:19:22 2011
Elapsed:
0 hours, 0 minutes, 0 seconds

272

RH401-6-en-1-20110713

RHN Application Programming Interface

RHN Application Programming Interface


Practice Exercise

Getting Started with the Red Hat Network API


This exercise will introduce you to the Red Hat Network API. Modify two versions of a script
written in Perl and Python so that they successfully query your RHN Satellite Server.
1.

There is a Perl script, list-users.pl, and a Python script, list-users.py, which list all
the users within an Red Hat Network organization. The scripts can be found in the /misc/
instructor/materials/rhn-api directory.
Log in as stan on desktopX, copy the scripts, and modify them so they will successfully
query your Satellite Server and list the users in the Example Inc. organization.
Optional - Use revision control software to log and manage the changes you make to your
copies of the scripts.
Log in as stan on desktopX. Use the following commands to copy the scripts from the
instructor's machine, make the scripts executable then optionally check them into revision
control:
[stan@desktopX
[stan@desktopX
[stan@desktopX
[stan@desktopX
[stan@desktopX
[stan@desktopX
[stan@desktopX

~]$ mkdir api ; cd api


api]$ cp /misc/instructor/materials/rhn-api/* .
api]$ chmod 755 *
api]$ svn import -m 'Sample RHN API scripts' file:///var/local/svn/api
api]$ cd .. ; rm -r api
~]$ svn checkout file:///var/local/svn/api
~]$ cd api

Edit list-users.pl and list-users.py and change the host and user authentication
information to work for your Satellite Server. For example the following lines need to be
modified in the Perl script:
my $SATELLITE_URL = 'https://desktopX.example.com/rpc/api';
my $SATELLITE_LOGIN = 'example';
my $SATELLITE_PASSWORD = 'redhat';

Execute both scripts. Their output should look similar to the following:
[stan@desktopX api]$ ./list-users.py
example
normal
grouper
channelman
[stan@desktopX api]$ ./list-users.pl
example
normal
grouper
channelman

If the scripts don't work, troubleshoot any problems they may have. A few possible issues to
investigate:

RH401-6-en-1-20110713

273

AppendixA.Solutions

Are the scripts executable?


Does SATELLITE_URL point to your Satellite Server? Were only the SATELLITE_*
variable definitions modified?
Are SATELLITE_LOGIN and SATELLITE_PASSWORD defined to use Organization
Administrator credentials for Example Inc.?
Organization Administrator privileges are required to access user account information
about an organization. API scripts run with privileges determined by the account they use to
authenticate into the Satellite Server with. Optionally commit your changes to Subversion
once your scripts are working and debugged.

[stan@desktopX api]$ svn commit -m 'Scripts working with Satellite server desktopX'

2.

Modify one of your working scripts to authenticate as the Satellite Administrator. How does
this affect the behavior of the script?
In one of the scripts change SATELLITE_LOGIN = 'example' to SATELLITE_LOGIN =
'satadmin' and run the script. For example:
[stan@dsk; api]$ ./list-users.py
satadmin

When you execute the script you should notice it doesn't list the users of Example Inc.
because the Satellite Administrator is not a member of that organization.

Practice Exercise

Using the Red Hat API to Produce Reports


Modify one of the provided scripts to produce a useful report by using the Red Hat Network API
to get more detailed information about the users from your Satellite Server.

Write a script, list-user-roles.pl or list-user-roles.py, that lists all of the users


within the Example Inc. organization. Print the following information about each user: their
login name and the list of their RHN administrative roles.
Copy one of your working scripts as a starting point for your new script. Optionally maintain
your script with revision control software.
The following commands copy the working Python script and commits the original version
into Subversion:
[stan@desktopX api]$ svn copy list-users.py list-user-roles.py
A
list-user-roles.py
[stan@desktopX api]$ svn commit -m 'Working on new script'
... Output omitted ...

274

RH401-6-en-1-20110713

RHN Application Programming Interface

The basic structure of the new program is the same as the sample scripts: connect to RHN,
authenticate, list the users, then log out. Some additional work needs to be done when
listing each user. The User namespace provides a method called listRoles that will get
the information we need. This method takes a session key and a login name and returns an
array of strings which are the RHN administrative roles assigned to the user.
Additional Python code needed (the plus signs are not literal, they indicate which lines to
add to the existing code):
for user in ulist:
login=user.get('login')
print login
+
# Identify and print each user's roles:
+
rlist = client.user.list_roles(key, login)
+
for role in rlist:
+
print '
' + role

Additional Perl code needed (the plus signs indicate which lines to add to the existing code):
my $ulist = $client->call('user.list_users', $key);
foreach my $user (@$ulist) {
print $user->{'login'} . "\n";
+
# Identify and print each user's roles:
+
my $rlist = $client->call('user.list_roles', $key, $user->{'login'});
+
foreach my $role (@$rlist) {
+
print '
' . $role . "\n";
+
}
}

The following shows what the output should look like when the script is working properly:
[stan@desktopX api]$ ./list-user-roles.py
example
activation_key_admin
config_admin
monitoring_admin
channel_admin
org_admin
system_group_admin
normal
grouper
system_group_admin
channelman
channel_admin

Optionally check your changes in once your script is working:


[stan@desktopX api]$ svn commit -m 'Working script'

RH401-6-en-1-20110713

275

AppendixA.Solutions

Test

Criterion Test
Exercise

Using the RHN API to Perform Satellite Administration


Write a couple Red Hat Network API scripts that perform RHN Satellite administration functions.
1.

Write two scripts that use the Red Hat Network API to administrate users. The userdisable.pl, or user-disable.py, script should deactivate a RHN user account. Its
positive counterpart, user-enable.pl or user-enable.py, should reactivate an existing
user account. Use a program variable for the RHN login to be enabled/disabled.
These programs don't have to be fancy, they just have to be functional. There is no need to
process command-line arguments or do extensive error checking.
Optionally use revision control software to manage the changes you make to your new
script.
The basic structure of the new program is the same as the other RHN API scripts: connect
to RHN, authenticate, enable/disable the specified user account, then log out. The User
namespace provides a couple useful methods called enable and disable that will do
what we need. These methods take a session key and the RHN login name of the account to
manipulate.
Below is working Perl code that implements the disable script:
#!/usr/bin/perl -w
use strict;
use Frontier::Client;
# Define RHN Satellite host and authentication values:
my $SATELLITE_URL = 'https://desktopX.example.com/rpc/api';
my $SATELLITE_LOGIN = 'example';
my $SATELLITE_PASSWORD = 'redhat';
# Login name of user to disable:
my $login_name = 'login_to_disable';
# Connect to the RHN Satellite Server:
my $client = new Frontier::Client(url => $SATELLITE_URL);
# Authenticate as a valid user to get a session key:
my $key = $client->call('auth.login', $SATELLITE_LOGIN,
$SATELLITE_PASSWORD);
# Disable the user in our organization:
$client->call('user.disable', $key, $login_name);
# Logout from RHN session:
$client->call('auth.logout', $key);

The Python solution is similar to the above code with a few syntactical differences. Also the
enable function is a trivial change to the above program.

276

RH401-6-en-1-20110713

RHN Application Programming Interface

2.

Use one of your scripts to disable the channelman account. Go into the RHN Satellite web
interface and verify his account has been disabled. Execute the other script to reactivate his
account and verify that channelman can log into your Satellite Server.
Optionally commit your changes to Subversion once your scripts are working and debugged.
[stan@desktopX api]$ svn add user-disable.py user-enable.py
OR
[stan@desktopX api]$ svn add user-disable.pl user-enable.pl
[stan@desktopX api]$ svn commit -m 'Added working administration API scripts'

RH401-6-en-1-20110713

277

AppendixA.Solutions

Comprehensive Review
Practice Resequencing Exercise

Provisioning with a RHN Satellite Server


Below are the steps you will take to deploy a provisioning Red Hat Network Satellite server. Take
5-10 minutes to prioritize and order the following steps. We will discuss them as a class before
you begin to implement them.
4
12
16
7
1
6
3
13
2
9
15
11
17
10
14
8
5

Configure desktopX to serve as a Subversion repository.


Clone the RHEL 6 Server base channel and all of its child channels.
Create a kickstart profile.
Import the relevant Red Hat software channels into the Satellite server.
Install desktopX with Red Hat Network Satellite software.
Prepare software channel content for import into the RHN Satellite.
Deploy DHCP on desktopX and configure it to support PXE.
Build and sign a custom RPM package on desktopY.
Configure desktopX as a routing gateway for the backend network.
Create a RHN system group.
Create an activation key to automate system registration.
Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel.
Provision the client system using PXE menu.
Create RHN user accounts, assign appropriate roles, and allow them to administrate a
common system group.
Import GPG keys into the Satellite server for deployment.
Create a Red Hat Network organization and assign it system and software subscriptions.
Import the open source project code into the Subversion repository.

Test

Criterion Test
Case Study

Red Hat Network Satellite Server Deployment Requirements


The following are the specifics for setting up your Red Hat Network Satellite server and client
machine. desktopX should already be installed with a minimal RHEL 5 installation and desktopY
will serve as your client server and should be installed with RHEL 6 server.
The requirements for this review are specified in more detail below. They aren't necessarily listed
in the order they are to be performed.
Install desktopX as a Red Hat Network Satellite software. The materials you need to perform
the installation can be found in the /misc/instructor/rh401-satellite directory on
desktopX. The installation ISO is named satellite-embedded-oracle-5.4.0-20101025rhel-5-x86_64.iso. Activate the Satellite server using the certificate named redhatgls-maximum-5.4.cert.

278

RH401-6-en-1-20110713

RHN Application Programming Interface

After the Satellite server is installed, create a satellite administrator account with a login of
rhnsatadm and a password of redhat.
Prepare software channel content for import into the RHN Satellite. The content ISO's are in
the rh401-satellite directory in a sub-directory called sat-rhel6-content.
Import the Red Hat software channels into the Satellite server that will support provisioning of
RHEL 6 Servers.
Configure desktopX as a routing gateway for the backend network. The network addresses will
be in the 10.100.X.0 subnet with a netmask of 255.255.255.0. The second network interface
of desktopX should have a static address of 10.100.X.254. Ensure IPv4 packet forwarding is
enabled persistently in the kernel.
Deploy DHCP on desktopX and configure it to support PXE provisioning. Determine the MAC
address of desktopY and have DHCP consistently assign it the 10.100.X.7 IP address. Continue
to use 192.168.0.254 for DNS services.
Build a custom RPM package on desktopY for the bubbles application. Consult the README
and Makefile for information about building the package. Make sure both the binary
executable and README are provided by the binary RPM that you create. The README should
be classified as documentation by RPM.
Generate a GPG key pair and sign the package.
Create a custom software channel as a child of the Red Hat RHEL 6 Server base channel. Set
the channel name to Custom Software with a label of custom-software. Specify the GPG
key information you will use to verify the signature of RPMS you create.
Create a Red Hat Network organization called Review Inc.. The organization administrator
should log in as review with a password of redhat. Assign all available entitlements to this
organization.
Create a RHN system group in the Review Inc. organization called Review Systems. Put
some meaningful text in the Description field.
Configure desktopX to serve as a Subversion repository. The top-level URL to access the
directory should be svn+ssh://desktopX/var/local/svn. Create a group called
svnusers and set permissions on the repository that allows all users in that group to create
new projects and modify files.
Create a user called builder on both systems. This user should be a member of the
svnusers group on desktopX. Also create ssh keys on desktopY and deploy them so builder
can check in files to the repository without providing a password.
Create RHN user accounts, assign appropriate roles, and allow them to administrate systems in
the Review Systems system group according to the following table:
Login

swadmin

cfgadmin

Password

redhat

redhat

Roles

Channel Administrator

Configuration Administrator

RH401-6-en-1-20110713

279

AppendixA.Solutions

Import the open source project code for the "bubbles" program into the Subversion repository.
The source code for this program can be found at the following URL: http://instructor/
pub/materials/bubbles-1.0.tar.gz.
Clone the RHEL 6 Server base channel and all of its child channels. Prefix the channel names
with "Development" and the channel labels should have a "dev-" prefix.
Create an activation key to automate system registration. The key ID should be review-reg.
It should register systems in the Review Inc. organization. Systems should join the Review
Systems system group. They should also subscribe to cloned base software channel and rhntools and custom cloned channels. Also allow for configuration file provisioning and subscribe
to the Review Configurations configuration channel.
Create a kickstart profile. It should register the provisioned system with the review-server
activation key for Review Inc. It should install the web-server package group and update all
available errata during its installation. The bubbles custom package should be installed and
any available configuration files should be deployed.
Create a configuration channel called Review Configurations with a label of reviewconfigs. It provides /etc/issue which should contain the following text:
Red Hat Enterprise Linux Server release 6.0 (Santiago)
Kernel \r on an \m
Review Inc.

Import GPG keys into the Satellite server for deployment. Import the standard Red Hat key,
RPM-GPG-KEY-redhat-release, and the GPG key used to verify custom packages.
Provision the client system using PXE menu provided by Cobbler. Confirm that it installed
properly and is properly configured.

280

RH401-6-en-1-20110713