RedHat Enterprise Satellite Server 6

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 [email protected] 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

v

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.

x

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

Table 1. 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

Table 2. Language Codes

RH401-6-en-1-20110713

xix

xx

Chapter 1.

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

1

Chapter 1. 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

2

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

3


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.

4

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

5


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.

6

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

7


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

8

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

9


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

Chapter 2.

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

Chapter 2. 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


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

Table 2.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


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 = [email protected] # 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 [email protected] 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


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 [email protected]. 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


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



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: RHN-SATELLITE-001 Red Hat GLS Cert

RH401-6-en-1-20110713

25


2011-02-11 00:00:00 2013-02-11 00:00:00 6 3 3 5.0 4 ...

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



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 [email protected] 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


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

Chapter 3.

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

Chapter 3. 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 [email protected]. 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


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


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


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 [email protected] as the e-mail address for both RHN Satellite accounts.

RH401-6-en-1-20110713

39


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


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


Personal Notes

42

RH401-6-en-1-20110713


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

Chapter 4.

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

Chapter 4. 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


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


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


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


[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

A

File will be added when committed

C

File has unresolved conflicts

D

File has been marked for deletion

M

File has been modified

Space

No modifications

?

File is not under version control

!

File is missing (removed by non-Subversion command)

Table 4.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


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

Table 4.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

Table 4.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


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


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


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


Personal Notes

RH401-6-en-1-20110713

61


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

Chapter 5.

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

Chapter 5. 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 ID-1000010027

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


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


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


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



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


• 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


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


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 ID-1234567890

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


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

Chapter 6.

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

Chapter 6. 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


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 = key expires in n days w = key expires in n weeks m = key expires in n months 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: [email protected] Comment: Enter You selected this USER-ID: "My Name " 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 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 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


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


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

Table 6.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


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


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


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


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


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



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


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


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

Chapter 7.

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

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


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


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


# 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 - 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


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


[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 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


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


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

Chapter 8.

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

Chapter 8. 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


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


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 [email protected]. 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


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



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

Table 8.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


References rhncfg-manager(8) man page

128

RH401-6-en-1-20110713

Configuration File Management


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


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


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

Chapter 9.

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

Chapter 9. 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


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


[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


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


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


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


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


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


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


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


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

Chapter 10.

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

Chapter 10. 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


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


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


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


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


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


Personal Notes

168

RH401-6-en-1-20110713


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

Chapter 11.

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

Chapter 11. 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


• 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


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


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


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


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


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 [email protected]. 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


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

Chapter 12.

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

Chapter 12. 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


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


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


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


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


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

Chapter 13.

UNIT THIRTEEN

COMPREHENSIVE REVIEW

RH401-6-en-1-20110713

201

Chapter 13. 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


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


Test


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


• 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

Appendix A. 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


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

Appendix A. 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


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


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


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 = [email protected] # 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 [email protected] 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


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 [email protected]. 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

[email protected]

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


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


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


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/@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/@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


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


• State = your state • Country = your two-letter country code Also specify [email protected] 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 = [email protected] 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 = [email protected] 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 [email protected] 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/@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


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 [email protected]. 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 [email protected] 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


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


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


[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


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


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


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


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


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


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


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.


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


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


* - 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


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


# 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


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

[email protected]

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


... 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 = key expires in n days w = key expires in n weeks m = key expires in n months 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) " Real name: Charles Channelman Email address: [email protected] Comment: Enter You selected this USER-ID: "Charles Channelman " 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 ... 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

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


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

[email protected]

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


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


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



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.


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


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


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


Field

Value

Advisory Release

1

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


[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


[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 - 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


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 [email protected]. 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

[email protected]

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.


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


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


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


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


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


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


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


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


} 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


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: 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


[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


Kickstartable Tree


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


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


Kickstartable Tree


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


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


/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


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/@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


• 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


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


Test


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


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


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


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


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


• 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

RedHat Enterprise Satellite Server 6

Recommend Documents